Leading platforms report back from the front line as vendors grapple with landmark bug
UPDATED Bug bounty hunters have already submitted thousands of vulnerability reports related to the Apache Log4j bug that continues to send shockwaves through the global software ecosystem.
Submitted via a bug bounty program itself, the critical, CVSS 10-rated flaw in Log4j, an open source Java logging library, allows cybercriminals to launch remote code execution (RCE) attacks against an arguably unparalleled number of potential targets.
Less than two weeks since the bug was publicly disclosed, more than 500 hackers have submitted close to 1,700 reports to over 400 programs on HackerOne alone, a company representative told The Daily Swig.
The US-based platform says that “during the initial peak” day for submissions, nearly 30% of hackers submitted vulnerability reports related to ‘Log4Shell’, as the bombshell bug has been dubbed.
Related payouts on HackerOne have so far totalled $249,500.
Fellow US-headquartered platform Bugcrowd says it too has validated and triaged thousands of Log4j-related submissions since the crisis erupted.
Elsewhere, Paris-based bug bounty platform YesWeHack says it received 140 reports during the first week following Log4Shell’s disclosure on December 9.
Over the weekend that followed the disclosure, fellow European platform Intigriti said it evaluated more than 130 such reports.
“Increased automatization and reconnaissance tooling allow for prompt detection and quick coverage of wide attack surfaces, faster than most of our customers could take action,” Inti De Ceukelaire, head of hackers at Intigriti, tells The Daily Swig.
‘Achilles heel’
The rapid response of bug hunters could hardly be more valuable given the widespread in-the-wild exploitation of a flaw reportedly described by US Cybersecurity and Infrastructure Security Agency (CISA) director Jen Easterly as “one of the most serious I’ve seen in my entire career, if not the most serious”.
The issue, which was complicated by a bypass of the initial patch, affects numerous Apache projects, as well as consumer and enterprise applications from the likes of Microsoft, Cisco, and Google.
RELATED Log4j: Security pros call for urgent patch implementation as in-the-wild exploitation continues
“In this particular case, a component used by almost all systems – often without knowing it – for such a harmless and usually ‘unassailable’ function as logging proves to be the Achilles’ heel of the internet,” says Gilles Yonnet, deputy CTO of YesWeHack.
Intigriti has noted that “while it’s straightforward to map out internally developed applications” with affected Log4j versions, the flaw is “particularly difficult to track” through third-party software dependencies.
Enhanced rewards
Mindful of the complexity of handling such an urgent issue, Yonnet says YesWeHack customers began requesting the integration of Log4j clauses into their programs on December 10, the day after the flaw was first disclosed.
The French platform says it has helped customers identify vulnerable components beyond internal resources, understand the impact of exploitation of vulnerable components in various technical contexts, and validate whether patches have created fresh flaws or could be bypassed.
Read more of the latest hacking news from around the world
Bugcrowd CTO and founder Casey Ellis tells The Daily Swig that some Bugcrowd customers have added “explicit, increased rewards” for Log4j bugs, while Bugcrowd has run several Log4j-focused, on-demand private programs – “like a CTF, but with more Java!”
Given the “incredible” volume of Log4j activity, Bugcrowd has “been working 24/7 to ensure the signal/noise is as high as possible”, he adds.
HackerOne tells The Daily Swig that between day one (after the flaw emerged) and day 11, the number of programs with Log4Shell in scope had risen from 30% to 77%, while related payloads had evolved markedly – highlighting the creativity of ethical hackers in circumventing web application firewalls (WAFs) and other defensive measures.
‘Opposite thinking’
The bug bounty model is proving a vital part of a layered defense during the crisis, the platforms argue.
“Bug bounty is an active approach to security that involves tens, hundreds or even thousands of researchers, and can be of great help as organizations scramble to address this critical flaw with limited internal resources and time,” says Yonnet of YesWeHack.
Adds Bugcrowd’s Casey Ellis: “Bug bounty hunting, and indeed almost all building/breaker feedback, is all about ‘opposite thinking’ – taking the assumptions of the builder and defender, inverting them, and seeing where risks and unintended consequences exist from a security standpoint,” he explains.
“Right now with Log4j, the thinking that many are needing to invert is ‘I know where all of my Log4j instances are’, and that’s where we've seen the power of the crowd demonstrated over the past week and a half – finding publicly accessible resources on the fringes of what they know.”
Ellis continues: “The next phase of value, in my opinion, comes from the fact that these Log4j vulnerabilities exist at the library-level, not at the protocol level that most security teams are used to enumerating. ‘Research-driven assurance’, as I refer to it, is brilliant at looking for the second and third order triggers for this vulnerability, as we scan novel ways to trigger it which may not have been considered before.”
‘No weak spot left behind’
Inti De Ceukelaire says approaches to paying bounties for freshly discovered zero-days vary widely. “Most of our customers include a short 0-day cooling period into their bug bounty policy, allowing them to patch their systems first,” he explains.
“Bounties for reports submitted within the cool down period are awarded at the discretion of the company. As a general rule of thumb, we advise to award a bounty in case that the vulnerability would not have been caught as part of the internal efforts within this period.”
He adds: “Some bug bounty programs have introduced bonuses or special rewards specifically for log4j vulnerabilities after their internal investigation was over. Doing so allows you to cross-validate your implemented fixes and ensures no weak spot is left behind.”
This article was updated on December 22 to reflect the fact Intigriti received more than 130 Log4Shell-related reports over the weekend following the bug’s disclosure – not around 80 as originally stated
RECOMMENDED Multiple vulnerabilities in Microsoft Teams could spoof URLs, leak IP addresses
