Just a few weeks ago, we announced incremental updates to the Vulnerability Rating Taxonomy (VRT), an ongoing effort to define and prioritize vulnerabilities in a standard, community-driven way so that hackers and customers alike can participate in the process. Since 2016, the Bugcrowd Platform has incorporated the VRT alongside a CVSS conversion tool. This integration has enabled us to validate and triage hundreds of thousands of submissions from the crowd at scale. Our platform’s rigorous validation process ensures that these submissions are consistently recognized as valid vulnerabilities by program owners.

The VRT is designed to constantly evolve in order to mirror the current threat environment, and thus helps bug bounty program owners create economic incentive models that engage and motivate hackers to spend their valuable time looking for the right things with the expectation of a fair reward. Now, with the mainstreaming of generative AI and the appearance of government regulation including Executive Order 14410 and the EU Artificial Intelligence Act, it’s time for the VRT to take another evolutionary step to account for vulns in AI systems, particularly in Large Language Models (LLMs).

With these AI security-related updates to the VRT (and more to come) and our experience working with AI leaders like OpenAI, Anthropic, Google, the U.S. Department of Defense’s Chief Digital and Artificial Intelligence Office, and the Office of the National Cyber Director, the Bugcrowd Platform is positioned as the leading option for meeting that goal.

Bringing AI security into the ecosystem

Although AI systems can have well-known vulnerabilities that Bugcrowd sees in common web applications (such as IDOR and Broken Access Control vulns), AI technologies like LLMs also introduce unprecedented security challenges that our industry is only beginning to understand and document, just as we had to contend with new classes of vulnerabilities introduced by mobile technology, cloud computing, and APIs.

For that reason, our announcement today of VRT version 1.12 is a milestone in the crowdsourced cybersecurity industry: For the first time, customers and hackers will have a shared understanding of how the most likely emerging LLM-related vulnerabilities are defined and should be prioritized for reward and remediation. With this information, hackers can focus on hunting for specific vulns and creating targeted POCs, and program owners with LLM-related assets can design scope and rewards that produce the best outcomes.

In the interest of alignment with industry-standard definitions, the updates below overlap with the OWASP Top 10 for Large Language Model Applications. Special thanks to Ads Dawson, a senior security engineer for LLM platform provider Cohere and a core team member of the OWASP LLM Top 10 project, for inspiring these updates and his contributions to VRT v1.12!

What’s inside VRT v1.12?

Update to existing category:

• Varies: Application Level DoS > Excessive Resource Consumption – Injection (Prompt)
  In the context of LLMs, application-level DoS attacks take the form of engineered prompts that can crash the client or otherwise make it unusable by others. When the LLM is integrated with other systems, the damage can also spread beyond the application.

New “AI Application Security” category and “Large Language Model (LLM) Security” subcategory:

• P1: AI Application Security > Large Language Model (LLM) Security > Prompt Injection
  In “Prompt Injection”, an attacker manipulates the prompt in a way that causes the LLM to behave maliciously – such as by jailbreaking via “Do Anything Now” (DAN), developer mode, and roleplaying.

• P1: AI Application Security > Large Language Model (LLM) Security > LLM Output Handling
  As LLMs become more common, there is a risk that LLM output will be accepted unconditionally by other applications. This can introduce vulnerabilities that invite Cross-Site Scripting (XSS) attacks, privilege escalation, and more.

• P1: AI Application Security > Large Language Model (LLM) Security > Training Data Poisoning
  In Data (or Model) Poisoning attacks, a threat actor gets their input or prompts to influence the model for nefarious purposes. Model Skewing–in which the attacker attempts to pollute training data to confuse the model about what is “good” or “bad” – is among the most common Data Poisoning techniques.

• P2: AI Application Security > Large Language Model (LLM) Security > Excessive Agency/Permission Manipulation
  Excessive Agency flaws are ones in which an LLM has more functionality, permissions, or autonomy than is intended, enabling an attacker to manipulate it to reveal sensitive data (including its own source code) or do other unexpected tasks. When the model is integrated with other systems, those flaws can have particularly dangerous consequences such as privilege escalation. (Note: Data leakage, which we expect to become a common LLM vulnerability in itself, is accounted for in the VRT’s existing “Disclosure of Secrets” category.)

According to Ads Dawson, “The main intention of this VRT update is to capture the correlation between LLM/AI-based vulnerabilities inline and application-based taxonomies – because one associated risk within each realm can trigger a downstream exploit, and vice versa. This not only opens up a new form of offensive security research and red teaming to program participants, but helps companies increase their scope to include these additional attack vectors inline with security researcher testing, receiving submissions, and introducing mitigations to secure their applications. I am looking forward to seeing how this VRT release will influence researchers and companies looking to fortify their defenses against these newly introduced attack concepts.”

Contributions needed!

This update represents our first step in recognizing these attack vectors within the VRT, but is far from the last–the VRT and these categories will evolve over time as hackers, Bugcrowd application security engineers, and customers actively participate in the process. If you would like to contribute to the VRT, Issues and Pull Requests are most welcome!

The post Defining and Prioritizing AI Vulnerabilities for Security Testing appeared first on Bugcrowd.

Over time, the attack surface and submissions associated with the VRT evolve, as do the needs of hackers and customers – so the VRT needs to grow and change, too. In that spirit, we are pleased to announce the latest release, VRT version 1.11, will be rolling out on the Bugcrowd Platform and reflected in our submission form shortly.

Overview of changes

This release includes several updates. As you can see below, they reflect changes to the threat environment, and how hackers, customers, and the Bugcrowd triage team view certain vuln classes and their relative impacts differently than before. 

New Top-Level Category: Cryptographic Weaknesses
A new category has been added to cover all common flaws in the cryptography area. This approach will help guide hackers when submitting a report about a specific weakness – such as insufficient entropy, predictable PRNG or IV, missing cryptography steps, timing attacks, or insufficient key stretching, to name just a few.

Multiple Category Updates: Insecure Direct Object Reference (IDOR)
This category has been a bit of a thorn in the side of hackers for a while now as a single IDOR category with the priority of ‘Varies’ can be frustrating especially when the finding has proven demonstrated impact. Additionally, with a lack of default priority, it could mean a program owner is more exposed than they should be, compared to if it were a P1.

Therefore, we’ve added several specific variants to the category:

• P1 – Read Personal Data (PII) – Iterable Object Identifiers
• P2 – Modify/Delete Sensitive Data – Iterable Object Identifiers
• P2 – Read Personal Data (PII) – GUID/Complex Object Identifiers
• P3 – Modify/Delete Sensitive Data – GUID/Complex Object Identifiers
• P4 – Read Sensitive Data – GUID/Complex Object Identifiers
• P5 – Read Non-Sensitive Information

This change should cover most common IDOR cases. However, hackers who find something that isn’t in these specific variants can always select the top-level category and appropriate adjustments will be made by our triage team.

New Variant: HTML Injection
The existing P4 ‘Email HTML Injection’ variant receives a lot of false-positive submissions from hackers submitting HTML injection in a web application. We did a lot of research on this category, reviewing the outcomes from the P4 false positives and how many led to accepted submissions and resulted in fixes. The answer was: not very many. As a result, the new category for these is considered P5, and you’ll find it under the existing ‘Content Spoofing’ specific vulnerability name. We’ll update existing submissions under the old P4 variant to the new P5 one, accordingly.

Update To Existing Category: Server-Side Request Forgery (SSRF) – External
We reviewed a number of SSRF findings across the existing P4 variant ‘External – Low Impact’. Most of these submissions are not accepted by customers, as they typically arise from intended functionality such as a webhook or image download. As a result, we have moved this category to the P5 level. 

New Specific Vulnerability: HTTP Request Smuggling
Thanks to amazing work by James Kettle at PortSwigger, this category has been revitalized across the internet. We see this vulnerability reported on a daily basis, but more often than not, it has low impact – so, we’re introducing it at the ‘Varies’ priority level in the ‘Server Security Misconfiguration’ category. The triage team will adjust affected submissions as needed.

New Specific Vulnerability: LDAP Injection
While certainly not the most reported vulnerability we see, LDAP Injection was a conspicuous omission in previous versions of VRT. We’ve remedied that by adding it to the ‘Server Side Injection’ category. 

Modified Specific Vulnerability: PII Leakage
The existing ‘PII Leakage’ category is commonly misused, with many hackers simply searching for ‘PII’ in the VRT selection box and selecting this category regardless of whether the specific vulnerability is related to automotive security. As a result, the existing category under ‘Automotive Security Misconfiguration – Infotainment’ has been changed from ‘PII Leakage’ to ‘Sensitive Data Leakage/Exposure’, retaining its usability for automotive submissions specifically.

A new vulnerability called ‘PII Leakage/Exposure’ with the default priority of ‘Varies’ has also been added to the category ‘Sensitive Data Exposure’. We believe that a ‘Varies’ priority is important here because not all instances of PII – a single email address in an AEM response, for example – are a P1 by default. However, the triage team will adjust submissions to a P1 as needed.

Deprecated Specific Vulnerabilities and Variants
‘Existing P4 Cross-Site Scripting IE-Only / IE11’ has been removed and the existing P5 category ‘Cross-Site Scripting – IE Only < IE11’ modified to cover all versions of IE. These changes have been pending for some time due to Microsoft retiring Internet Explorer version 11 in 2022.

New Specific Vulnerability: On Permission Change
This vuln is documented by OWASP and other sources, but is also very use case specific. To support these customer use cases, we’ve added it to the ‘Failure to Invalidate Session’ variant of ‘Broken Authentication and Session Management.’

This is a healthy, albeit not major, update to the VRT with contributions from hackers in the Bugcrowd community, our triage team, and our customers. There is still more work to be done, so you’ll soon be hearing from us again very soon about additional changes that reflect the evolving environment.

Why contribute to the VRT?

As we said in the introduction, an open-source governance model helps the VRT evolve at a pace and in concert with the changing environment – but that only happens if hackers and customers actively participate in the process. Contributions to the repository are reviewed by the VRT Council, which meets regularly to discuss new vulnerabilities, edge cases for existing vulnerabilities, priority-level adjustments, and general validation experiences. When the team comes to a consensus regarding a proposed change, it is committed to the master.

If you would like to contribute to the VRT, Issues and Pull Requests are most welcome!

The post Announcing Our Latest Vulnerability Rating Taxonomy Update appeared first on Bugcrowd.

The good news is that bug bounty and crowdsourced security are tailor-made to help address the problem, and their adoption by hyperscalers for their cloud products and open source projects is proving it.

Hyperscalers Double Down

Microsoft is an enthusiastic adopter of bug bounty, and recently announced that it paid out $13.7 million in rewards through its 17 active bug bounty programs over the past 12 months. (Bugcrowd processes bounty payments for Microsoft’s programs.) The bounty table is impressive: The Platform Program for Microsoft Hyper-V offers up to $250,000 for findings in the area of critical remote code execution, information disclosure, and denial of services vulnerabilities, and a similar program for Microsoft Windows Insider Preview offers a bounty range of up to $100,000 for critical/important vulnerabilities. 

Possibly based on the rapidly expanding attack surface associated with cloud infrastructure (including the discovery of six critical Azure vulnerabilities in 2021), Microsoft expanded its bug bounty programs in the past year, adding “high-impact security research scenarios” to its Microsoft Azure Bounty Program. 

Although Amazon Web Services has a less systematic approach to crowdsourced cybersecurity than Microsoft to date, it does accept vulnerability submissions for its cloud products and open source projects, and provides public infrastructure for running private bug bashes (with a goal of squashing 1 million bugs, collectively).

Beyond cloud infrastructure itself, cloud applications are inherently at risk due to potential misconfigurations or data exposure, insecure APIs, lack of tenant isolation, and numerous other reasons. As Bugcrowd Founder/Chairman/CTO Casey Ellis has remarked, “A lot of people would just assume that [security] is all sorted when they go to use a cloud provider — and might be a bit surprised to find out it’s not.”

Google Brings Bug Bounty to Open Source

Meanwhile, in August 2022, Google rolled out a new self-managed bug bounty program focusing solely on Google’s open source projects. The new Open Source Software Vulnerability Rewards Program (OSS VRP) will offer vulnerability rewards that range from as low as $100 to slightly over $31,000, with possible bonus increments that range to $1,000 in the case of a “particularly clever or interesting” vulnerability.

Google was an early adopter of bug bounty through what is now called its Bug Hunters Community, with 12 years of experience and more than $38 million in payouts on record. In 2021, Google disbursed a total of $8.7 million in bug bounty rewards to nearly 700 security researchers across 60 countries. 

This new program is another proof point that the open source software supply chain has become nearly impossible to defend with traditional means due to complex dependencies, constant code churn, increased opportunities for malicious code injection, and other factors. In its announcement, Google cites a 650% year-over-year increase in open source ecosystem attacks, including the recent major incident involving Log4j. 

Next Steps

Now that cloud adoption and open source software are ubiquitous, more security leaders are learning the lesson that Microsoft and Google learned years ago: that status-quo, reactive approaches to cybersecurity alone fall short as scale grows–and nothing says “scale” like cloud and OSS. 

To learn more about crowdsourcing and cloud vulnerabilities in particular, grab a seat for our webinar on the subject with Enterprise Strategy Group cloud security analyst Melinda Marks.

The post Cloud and OSS risks have Bug Bounty adoption humming appeared first on Bugcrowd.

It has been challenging for insurers to understand and manage risk in the face of nation-state  attackers/advanced persistent threats, particularly because of a lack of measurable insight into their clients’ cybersecurity defenses. Nevertheless, the consensus is that such attacks could result in massive claims that potentially bring “unmanageable losses” to the insurance market.

The Attribution Problem

As a case in point, Lloyd’s of London recently required its insurers to stop covering state-backed cyberattacks in their standard cyber insurance policies. This policy has followed in the wake of concern over an increased threat of cyber attacks from Russian threat actors due to the war in Ukraine. Lloyd’s has indicated that standalone cyber-attack policies will require clauses that exclude liability to Lloyds from nation-state attacks, unless explicitly approved by Lloyds. 

Attribution of cyber attacks is far from a simple task, however. We have seen that nation states are prepared to expand their use of malicious hacking to reinforce strategic goals, and that this trend is increasing. However, the lines between those actors and stateless cybercrime gangs are increasingly blurry, so many attacks are hard to attribute with any accuracy: Per RAND Corporation research, “The practice of attribution has been diffuse and discordant, with no standard methodology used in the investigations to assess evidence, nor a universal confidence metric for reaching a finding.” For those cases, Lloyd’s wants to take the conservative step of placing the onus of attribution on the policyholder.

Platform Values

The moral of this story is that it’s more than a lack of understanding about cyberattack attribution that is driving how insurance companies calculate risk. It’s also a lack of visibility into the security posture of their policyholders, too few of whom can understand or quantify their own risk by answering questions like: What vulnerabilities do we have, and how can they be exploited? Which and how many vulns have we identified and remediated? How long does it take us to remediate, and how does that compare to industry norms? (And so on). Without that insight, improving security posture in a measurable way is quite difficult for the CISO.

Access to that information requires a cybersecurity platform with rich built-in analytics and access to a historical knowledge about vulnerabilities, asset risk profiles, remediation strategies, and the hidden relationships between them. Those capabilities are key difference-makers in the Bugcrowd Security Knowledge Platform, which makes historical knowledge and modern data infrastructure and key product values–driving analytics, reporting, and even machine learning for important tasks like crowd matching and program discovery. 

Learn more about the Bugcrowd Platform here!

The post Defining Cyber Attack Liability appeared first on Bugcrowd.

MedusaLocker is an expansive ransomware family which was first discovered in 2019. Over the past few years, it has continued to spawn variants in an effort to improve its capabilities. MedusaLocker has three capabilities that are more unique than not. This includes an ability to encrypt the contents of mapped network drives, the manipulation of windows to remap network drives so that the content on these drives can be encrypted, and the use of ICMP sweeping to profile the network to help optimize their chances of extorting a ransom payment. As you may recall, an ICMP sweep, also known as a ping sweep, is a network scanning technique. ICMP sweeping is used to identify which range of IP addresses map to live host computers. 

MedusaLocker continues to be distributed primarily via spam email and phishing. In many cases, the malware is packaged as an attachment to email and sometimes as a link to a malicious website. MedusaLocker has shown considerable capabilities to shut down security controls, such as those from Symantec, that might slow it down. The threat actors behind MedusaLocker exhibit flexible ransom pricing behavior. 

Source: Ransomware.org 2022 Ransomware Survey

MedusaLocker uses strong AES-256 encryption to encrypt files and encrypts the AES key using an RSA-2048 public key. MedusaLocker targets files for encryption using a list of appended extensions for encrypted files. Any file found without these extensions are considered fair game to be encrypted. MedusaLocker runs periodically, seeking to identify additional files to encrypt.

RagnarLocker first came to light in early 2020 and has continually targeted critical infrastructure sectors since then, with the FBI reporting 50+ infrastructure-related attacks during that time across government, financial services, manufacturing, information technology, and energy. RagnarLocker had its “15 minutes of fame” in an attack on Capcom, a leading video gaming company. (Capcom was a major target — they are known for some of the most popular games, including Street Fighter.) This breach, discovered in 2021, resulted in the exfiltration of shareholder and employee data, and more, and encrypted over 1 terabyte of data. RagnarLocker is also known for successful high-profile ransom attacks on Dassault Aviation, Campari Group, and Energias de Portugal. 

RagnarLocker targets files to encrypt by first deciding which files not to encrypt. This helps RagnarLocker stay hidden — the computer will continue to operate in a reasonably normal fashion while the RagnarLocker ransomware continues to encrypt files.

This Trend is Not Your Friend

There are numerous mitigations for RagnarLocker and MedusaLocker, including implementing a recovery plan, enforcing MFA, patching, disabling unused remote access methods, and the other usual suspects. But at the end of the day, organizations of all types and sizes need to step up their game to defend against these dangerous ransomware families and similar emerging threats. It’s a race against time: The threat actors who build ransomware continue to improve their code, add functionality, harden their defenses, and spin off new variants–and automated/reactive tools alone are no protection against this “firehose” of emerging threats. 

For these reasons, make it your top priority to:

• Implement proactive, crowdsourced security solutions to get hundreds, or even thousands, of friendly eyes on your attack surface. Only crowdsourcing gives you access to skills, tools, and mindsets that can help uncover hidden ransomware risk before it bites you, and only the Bugcrowd Security Knowledge Platform helps you do that at scale through a SaaS-based, data-driven approach.
• Social engineering awareness and prevention training can yield excellent results. Regularly provide users with training on information security principles and techniques as well as overall emerging cybersecurity risks and vulnerabilities, such as ransomware and phishing scams.

Want to learn more about ransomware and proactive methods for battling it? Read our Ultimate Guide to Managing Ransomware Risk.

The post The Ransomware “Firehose” Makes Crowdsourced Security a P1 appeared first on Bugcrowd.

The growth, lack of management, and increasing complexity associated with using APIs means more attack surface for security teams to contend with and more opportunities for attackers to breach organizations. If APIs were properly managed and secured, then this wouldn’t be such a big deal. However, as with other IT and digital assets in an organization, APIs are no different. They get created, deployed and used without awareness of security teams. Lurking there without being seen, waiting to be attacked–we call them “shadow APIs.” 

Eventually, “zombie APIs” also emerge as new API versions get deployed, and legacy APIs are not shutdown or deprecated. They are the APIs that have been forgotten and neglected, leading to potential soft targets in your attack surface that attackers are constantly seeking to exploit.

So why worry about shadow and zombie APIs? Because attackers love them. According to Salt Security’s API Security Trends research, API attacks were up 348% in the first six months of 2021, and API usage had increased 141%. Salt also reported that 94% of respondents said they experienced an API security incident in the last 12 months. API usage isn’t slowing down, and it’s safe to assume that attacks will continue at the same or greater pace.

So how do you combat shadow and zombie APIs? First, you need visibility of the APIs that are exposed and could be abused by attackers. Second, you need assurance that the APIs are resilient to attack.

But traditional application security solutions alone are not enough to protect APIs; if they were, the problem would be much less acute. The Bugcrowd Security Knowledge Platform offers a Pen Testing as-a-Service solution for APIs, and a Bug Bounty solution that can include APIs in its scope, as proven, think-outside-the-box ways to proactively find API risk before it bites you. That’s a potent combination for protecting your APIs, getting security assurance, and earning trust from customers and partners. (Add a Vulnerability Disclosure program, and now you’re really covered.) 

Furthermore, Attack Surface Management solutions on the Bugcrowd Security Knowledge Platform are highly effective at rooting out zombie and shadow APIs that are lurking out there in your environment. ASM – Asset Inventory provides continuous monitoring and visibility of the external IT and digital assets across your attack surface. ASM – Asset Risk applies the power of the crowd to give you the same view of your attack surface that attackers have, and more. The combination of these Attack Surface Management solutions will help discover the shadow and zombie APIs in your environment, and let you take action to make them more resilient to attacks.

Contact us to learn more about Bugcrowd solutions or get started today!

The post Fight the Fear of Shadow and Zombie APIs appeared first on Bugcrowd.

At Bugcrowd, we believe the value of our platform goes well beyond its role as a technology framework for collaborating with ethical hackers and security researchers. Its ability to separate signal from noise through meticulous, rapid triage, and to provide prioritization and remediation recommendations based on past experiences, are just as critical.  

Rapid Response at Scale

The Log4j incident is a perfect illustration of this fact. Consider that:

• To date, ethical hackers and security researchers worldwide have submitted more than 1,200 raw Log4j-related reports on the Bugcrowd Security Knowledge Platform, and 500+ of those were validated, triaged/prioritized, and passed on to customers for remediation by Bugcrowd (the remainder turning out to be duplicates, false positives, or otherwise invalid).
• Activity on the Bugcrowd platform started to spike on December 9 and peaked on December 11, with nearly 300 submissions on that date.
• During that critical period and beyond, most Log4j issues were validated, triaged, prioritized, and accepted/payout approved to the researcher in well under a single business day (even accounting for nights and weekends) under the stress of skyrocketing scale–with one $90,000 payout for a particularly impactful bug. Most P1s, initially including a proof of concept beyond a DNS pingback response, were handled in under three hours. And keep in mind that this activity was incremental to the thousands of other vulnerability reports the Bugcrowd platform processes daily.
• Even with this surge, response times were maintained across the holidays to ensure quick visibility into Log4j-related issues for customers.

Platform Power

The key to our rapid response time is the Bugcrowd Security Knowledge Platform–a unique blend of technology, data, and human intelligence. Rather than treating validation and triage as a check box or afterthought, we consider it an integral part of the platform and a critical ingredient for customer success. For that reason, the Bugcrowd platform orchestrates and streamlines triage-related workflows for security researchers, customers, and our own Security Engineering team alike. 

Through the platform, Bugcrowd’s globally distributed team of 40+ Security Engineers also have access to data collected over a decade of building 1000s of customer solutions that informs how vulnerabilities are validated, triaged, and remediated. The result is super-fast triage (meeting internal SLOs more than 99% of the time) and actionable remediation advice enhanced with contextual intelligence for customers like Atlassian, Netflix, Tesla, and Twilio.

Learn more about the Log4j vulnerability/Log4Shell exploit and Bugcrowd’s response here. To learn more about the Bugcrowd approach to validation and triage, download this product sheet.

The post Bugcrowd’s Log4j Response: Behind the Numbers appeared first on Bugcrowd.

Today’s post is about what front line security and technology teams should be mindful of in the coming weeks/months, particularly those that are reeling from or have been impacted by the Log4j vulnerability in its various shapes or forms. Some things to consider for battling it:

Be in Red-Alert Mode (for many weeks):

• Log4j was the entry in. You must now look for abnormalities/anomalies elsewhere in your organization that might have taken a different form. SOC teams need to be in “DEFCON 1” alert mode until you have high confidence that you have a clean bill of health.

Use Deep Assurance Tools and Ensure that Trusted Images and Continuous Testing Practices are in Place, such as: 

• Software composition analysis tools, asset inventory tools, Log4j scanners, and other continuous testing practices need to be pointed internally (while continuing to validate  externally) to pick up ALL known Log4j libraries and dependencies. Leave no known and outdated Log4j library unturned. Unfortunately, there’s probably a long tail of many more product vendor patches, just around the corner. Your mid- to long-term strategy should focus on fixing the problem at its source to stem any further re-introductions of this vulnerability into your organization. Organizations need to be sure they are using trusted and up-to-date images to fix the build pipeline rather than patching production constantly.

Watch Out for Upcoming Third-Party Supply Attacks 

• It’s a given that in the next few weeks news will likely surface that third-party organizations you rely on have or will be impacted by threat actors (TAs) who used Log4j as their initial access into your organization / supply chain. Heightened monitoring and canvassing of your suppliers (and what they have and will be doing) is imperative to form an understanding of potential upcoming exposure areas. Start assessing them now.

Evolve your Controls with the Times 

• TA TTPs (tactics, techniques, and procedures) have evolved in the last week and will continue to morph. Therefore so should your WAF and ingress/egress rules. Don’t drop the ball here – constantly monitor, adapt like a chameleon, and proactively update.

Be on Guard for Log4j-born Malware, Worms and Ransomware

• Log4j is an absolute ripsnorter. It has five dangerous “characteristics of an exploit” where previous well known worms only need two to be considered “wild” and impactful. As a result, we will certainly see funding from cyber criminal groups and Initial Access Brokers (IABs) that will transform this vulnerability into ransomware and worm-able variants.

Increase Management (and Regulatory – if applicable) Oversight: 

• Manage internal stakeholders’ expectations with proactive updates and concrete treatment plans. Internal, constant, and simplistic updates on Log4j to stakeholders are always important.
• If you’re a regulated entity and submitted breach reports, expect a fair degree of upcoming supervision. Plan for this in advance, with your teams and support functions such as Compliance and Risk.

Review  Investment Slates and Reprioritize:

• Depending on the impact of Log4j on your organization and where (or if) you have failed at any stage to detect, respond, or contain Log4j exploits, take a process, controls and ‘defense in depth’ approach to the event and learn from it. Put a plan in place for future events like this if you have not already done so. We’re approaching the end of the year when most large- and medium-sized organizations are finalizing next year’s investments, so it’s a great opportunity to reprioritize accordingly based on lessons learned from the Log4j incident. You don’t want to be tripped up over and over by the same control failure occurring later down the track, so being properly funded is imperative.

See our full list of Log4j/Log4Shell resources here.

The post Living with and Learning from Log4Shell appeared first on Bugcrowd.

Key Facts

Affected: Systems and services using Apache Log4j versions 2.0-beta9 to 2.14.1
Severity: 10.0 Critical
CVE Entry: CVE-2021-44228
NIST NVD Publish Date: 12/10/2021
Source: Apache Software Foundation

On Dec. 9, 2021, a zero-day exploit (since dubbed “Log4Shell”) was observed in the wild targeting a critical RCE vulnerability in Log4j, the ubiquitous open source logging tool. (Per NIST, in affected versions, JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI-related endpoints.) Numerous platforms appear to have been affected–including Apple, Cloudflare, and Twitter–in addition to the raft of popular Java ecosystem products with Log4j embedded in their software supply chains, such as Logstash, Apache Kafka, Elasticsearch, and even Minecraft. 

Observers consider the Log4j vulnerability the worst one in years, perhaps even more critical than the Apache Struts RCE vulnerability (CVE-2017-5638) of 2017 that contributed to a massive breach at Equifax. Per Bugcrowd Founder and CTO Casey Ellis, this new vuln is a toxic cocktail combining immense attack surface, easy exploitation, hard-to-avoid dependencies, and extreme virality. Among other things, it’s a reminder that software supply chains have become deeply complex, with layered inter-dependencies that are usually beyond the reach of automated tools like scanners.

When the dust inevitably settles, it will be a clarifying moment for organizations that have yet to take a continuous, platform-powered security testing approach that combines data, technology, and human intelligence, including the force multiplier of the Crowd, to find and remediate vulnerabilities before they cause damage. In a future blog post, we’ll describe how that approach helped Bugcrowd verify, validate, contextualize, and communicate Log4Shell exposures to customers within hours.

In the meantime, we’re eager to help by offering:

1. A 30-day “Log4j On Fire” bug bounty solution for continuous, crowd-powered discovery of Log4Shell exposures on your perimeter. See details and get started here.
2. Deeper insights about this vuln’s risk profile and future impact in this Security Flash video featuring Casey Ellis and Application Security Engineer Adam Foster.
3. A live Q&A session with Casey next week (Monday Dec. 20 at 10am PST) to answer your questions about finding, safeguarding, and using best practices to address the Log4j vuln and Log4Shell exploit. Save your seat here.
4. A single view into all our Log4j/Log4Shell resources here.

We are super proud of our customers, researchers, and team-members who are working together tirelessly to make our digitally connected world safer during this crisis. As always, we’ll get through it together!

The post Log4Shell, The Worst Java Vulnerability in Years appeared first on Bugcrowd.

Here are the basics:

• PrinterNightmare – CVE-2021-34527
• CVE ID: CVE-2021-1675
• CVE Title: Windows Print Spooler Remote Code Execution
• CVE Release Date: 01 July 2021
• CVSS 3.0 Score: 8.8/8.2

This remote code execution vulnerability exists when the Windows Print Spooler service improperly performs privileged file operations. An attacker who successfully exploited this vulnerability could run arbitrary code with SYSTEM privileges. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

This vulnerability is similar but distinct from the vulnerability that is assigned CVE-2021-1675. The attack vector is different as well. CVE-2021-1675 was addressed by the security update released on June 8, 2021. Initially this was labeled as “Local Privilege Escalation using the spoolsv.exe print spooler” but Microsoft updated this before the 28th of June, 2021 after it was discovered that it could be triggered remotely, updating it to Remote Code Execution. 

Here’s more information on CVE-2021-1675:

• CVE Title: Windows Print Spooler Remote Code Execution Vulnerability
• CVE Release Date: Jun 8, 2021
• CVSS 3.0 Score: 7.8/6.8

PrintNightmare History

This vulnerability was discovered by researchers at the Tencent Security Xuanwu Lab. No proof of concept or write-ups were released for the exploit alongside it’s CVE. 

Patches were released with the KB5003671 and KB5003681 updates by Microsoft on 8th of June 2021. Proof of concept was shown on Twitter by QiAnXin Technology, showing exploitation for the vulnerability on the 28th of June, 2021. On accident, they released a full technical write up and working proof of concept for this exploit on June 29th, 2021 which contained both exploits for local privilege escalation and remote code execution. 

The exploit was hosted on Github for a few hours before being pulled down, but it was cloned in that time by multiple people. As they say, nothing on the internet can ever truly be deleted. 

GentleKiwi has released a proof of concept for this exploit as well, which has been implemented into the security tool Mimikatz.

Remediations and Workarounds

Microsoft has released an “Out of Bands” update for this in KB5004954 and KB5004958 on 6th of July 2021. 

Organizations can disable the print spooler service, but this option is not ideal because it will also disable the ability for the computer to print. One option is to update group policy to “Allow Print Spooler to accept client connections” to be disabled. The system will no longer function as a print server, but local printing to a directly attached device will still be possible. 

SIGMA and YARA rules have been released by different people, including Florian Roth, which can be implemented into an IDS. 

I recently presented on a Bugcrowd 15 Minute Security Flash about this vulnerability. In this, we dive into:

• The unique history behind this vulnerability
• What defenders’ next steps should be
• This vulnerability from the security researcher perspective
• Information on the active patch
• How Bugcrowd can help organizations better understand their exposure to vulnerabilities like this

Resources

• CVE: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
• CVE: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675
• Analysis: https://risky.biz/RB629/
• Reporting: https://therecord.media/poc-released-for-dangerous-windows-printnightmare-bug/
• Reporting: https://www.itnews.com.au/news/researchers-accidentally-publish-printnightmare-stuxnet-style-zero-day-566767
• Exploitation: https://twitter.com/gentilkiwi/status/1410066827590447108
• Exploitation: https://github.com/gentilkiwi/mimikatz

The post PrintNightmare: What You Need to Know appeared first on Bugcrowd.