HackerOne

Log4j Vulnerability Activity on the HackerOne Platform

HAC LOG4j

This post is about the severe and widespread Log4j vulnerability, known as Log4Shell. It gives a technical overview of the vulnerability, mitigations HackerOne has put in place to protect our platform and customers, and the related vulnerability submission activity HackerOne is seeing on its platform. HackerOne will continually update this with technical reports, updates of vulnerability submissions, triage and remediation reports, information about what hackers see, and other industry information.

December 17th Update: 

Vulnerabilities in Log4j have been evolving over the course of this week since the original disclosure of CVE-2021-44228, also known as Log4Shell.  There is now a second critical vulnerability in Log4J, which will require additional mitigation efforts.

Unfortunately, the patch released to fix Log4Shell was incomplete, and CVE-2021-45046 was discovered in version 2.15.0.  This second vulnerability was originally given a low severity rating, but the Apache Logging security team has since upgraded it to critical with a 9.0 CVSS base score.

We are recommending upgrading to Log4j version 2.16.0 to fix both vulnerabilities. 

The discovery of this second vulnerability has highlighted the complexity of responding to critical and severe vulnerabilities. Your internal security resources are working around the clock to find where you are vulnerable, but there is always a risk of missing something. 

This is a great opportunity to leverage the ethical hacker community. We would like to share some guidance about how to maximize the value of your bug bounty and vulnerability disclosure programs.

This guidance is applicable to anyone running these programs, not only HackerOne customers.
 

  1. Add Log4j vulnerabilities to the scope of your bug bounty program.
     
  2. Offer increased bounties or bonuses for Log4j vulnerabilities. Offering additional incentives to investigate and submit to your program is valuable regardless of how far underway your internal response is. For organizations that believe they have already remediated, providing this additional incentive may uncover blind spots in your internal response. 

    Organizations still investigating can also benefit by being able to remediate faster - which is especially valuable as the volume of attacks, and therefore the risk of compromise, continues to increase.
     
  3. Post an update to your HackerOne policy page. Given the number of websites that may be vulnerable, hackers want to know where they should concentrate their efforts.

    Make it easy by posting an update highlighting your additional bounties, the status of your remediation efforts, and any preferences you may have about report data. Even if you are not going to be accepting any Log4j reports, which we don’t recommend at this time, it’s still valuable to share that.  

    While VDPs do not offer payouts, you can still provide an update to let the community know if you are accepting reports on Log4J. While the majority of submissions have been to bug bounty programs, we have seen nearly 100 reports to our customer’s VDPs.

 

December 16th Update:

We have continued to observe the response to Log4Shell across our platform. The immediate response of our ethical hacker network has helped our customers respond quickly, submitting hundreds of reports within 24 hours of the public disclosure of this vulnerability. That quick response window is incredibly valuable.

Cloudflare - who’s network allows them to monitor a significant amount of global internet traffic -  has shared that exploit attempts are reaching new highs. That data tells us the risk of attack is still increasing and has not yet peaked. 

Everyone, both attackers and defenders, was notified of this vulnerability at the same time. While security teams are working around-the-clock to remediate, attackers have also been busy. We are now 6 days out from disclosure of Log4Shell which has given attackers time to familiarize themselves with this vulnerability, develop exploits, and share knowledge. 

Organizations that moved quickly and are well underway with, or have already completed their remediation, have protected themselves during a very small and critical window where attackers were still developing effective exploits and ramping up attack volume.

We are continuing to see submissions coming in across our platform.  HackerOne customers have now received 1350 total reports. Daily submissions are up slightly from yesterday, but still far below their peak on December 11th. 

Seventy five reports have been confirmed and awarded, for a total of $142,250 in payouts for Log4Shell related vulnerabilities (an average of $1,896). A large number of reports are still being triaged by security teams.

HackerOne Report of Log4Shell Vulnerability Submissions - Updated Daily

Daily submissions of Log4J Log4Shell related vulnerabilities to the HackerOne platform.


 

December 15 Update:

HackerOne has seen a range of approaches from customers using their bug bounty programs to address the Log4j vulnerability. Some customers, like Coinbase (shown below) are incentivizing the community to find Log4j vulnerabilities with a $30,000 bonus bounty payout for confirmed reports. Others have communicated via their program pages that they have completed their initial response using scanning, log management and other tools and are willing to pay for Log4j vulnerabilities. Still others are asking for 30 days before reports are processed, presumably to give them time to complete their initial response. 

We will closely track these patterns and come back with any findings in terms of efficacy that we can surface.

Coinbase's bug bounty page with an update for Log4j

 

Also of note, we’ve seen 417 individual hackers submit reports. We are also seeing reports via Vulnerability Disclosure Programs (VDPs). More information on those submissions and how they compare will be posted in coming days.  In total, nearly 1200 reports have been submitted.

 

December 14 Update: Several HackerOne customers launched Log4j-specific initiatives for hackers working or wanting to start bug hunting in their bug bounty programs. They include Glassdoor and Hyatt, among others. See below for more information:

Glassdoor—Glassdoor has patched most of the log4j vulnerable(CVE-2021-44228) applications over the weekend. If you happen to find any endpoints that are vulnerable to log4shell(CVE-2021-44228) please report it to us we will pay double our critical bounty up to $5,000. Detections in the form of pingbacks that include host information such as hostname or IP are acceptable and preferable. Please share your IP when you get the pingback for us to triage your reports faster.

For researchers interested in this initiative, go to https://hackerone.com/glassdoor.

Hyatt—We believe we have taken adequate steps to protect our external-facing environment—code assurance, detective controls, and protective controls—from the recently-discovered vulnerability in the log4j library. We want to ensure we take all precautions to protect our guests and colleagues, however, throughout this week— ending Sunday, December 20, we are creating a super-critical category for successful remote code execution of CVE-2021-44228 on any in-scope assets. The payout for this category will be US$25,000. As always, thank you for your important contributions to the safety of our guests and colleagues. Happy hunting!

For researchers interested in this initiative go to https://hackerone.com/hyatt.

 

Original Post:

The newly discovered critical security zero-day vulnerability in the widely used Java logging library Apache Log4j is easy to exploit and enables attackers to gain full control of affected servers. Tracked as CVE-2021-44228, the vulnerability is classified as severe, allowing unauthenticated remote code execution. It’s being actively exploited across the globe, and cyberattacks using Log4j continue to grow daily. The vulnerability was reported by Chen Zhaojun of Alibaba Cloud Security Team and disclosed by The Apache Software Foundation on December 9th.

Technical Details of Log4j

The Log4j vulnerability (CVE-2021-44228) triggers because log messages were interpreted as a special language, and one of the abilities of that language is to execute arbitrary Java classes. The result is a powerful remote code execution (RCE) vulnerability. The CVSS score is the highest possible, 10.0.

To remediate this vulnerability, organizations must update all affected instances of Log4j to version 2.15.0. HackerOne is recommending that our customers only consider a version update at this time.  

Apache’s official Log4j’s security advisory, including updated information, can be found here.

What HackerOne Has Done Internally

HackerOne identified several internal non-production services we run as tertiary architecture that were impacted by Log4j. We immediately put mitigations in place and patched them when the library updates were released. We believe we are fully remediated and continue to remain alert and vigilant. In addition, through our own Bug Bounty Program, we've announced a substantial bounty for any Log4j vulnerability exploits against HackerOne.

What HackerOne is Seeing With Customers

Since the Log4j vulnerability was first reported on December 9, HackerOne has received numerous customer submissions of Log4j vulnerabilities found. These raw numbers may be greater than the number of instances of the vulnerability. See below for a graphic of Log4j submissions by day. This graph is updated daily.

Updated Daily

HackerOne Report of Log4j Vulnerability Submissions for December 13th

Log4j submissions by day
HackerOne Log4j Vulnerability Submissions - December 13th

HackerOne Report of Cumulative Log4j Vulnerability Submissions for December 13th

Log4j submissions by day
HackerOne Cumulative Log4j Vulnerability Submissions. - December 13th

 

HackerOne will continue to monitor the Log4j vulnerability and its impact on the industry and our customers. We will regularly post updates regarding this significant cybersecurity event.

 

The 8th Annual Hacker-Powered Security Report

HPSR blog ad image