Sophos: Log4Shell would have been a catastrophe without the Y2K-esque mobilisation of engineers
Anti-malware biz weighs in on one of the worst security flaws of recent times
Anti-malware outfit Sophos has weighed in on Log4Shell, saying that the galvanization of the IT world to avert disaster would be familiar to those who lived through the Y2K era.
The Log4Shell vulnerability turned up in the common-as-muck Apache Log4j logging library late last year. As a remote code execution (RCE) flaw, miscreants wasted no time in exploiting it following its disclosure.
However, the IT community promptly responded by patching it. "As soon as details of the Log4Shell bug became clear," explained Sophos, "the world's biggest and most important cloud services, software packages and enterprises took action to steer away from the iceberg."
The company noted that Log4Shell attacks blocked by its firewalls peaked between 20 and 23 December, then tailed off during January. Sophos put the high numbers down to people trying to gauge how bad things were by looking for exposed systems and redundant scans trying different ways to exploit different applications.
The infosec firm noted:
In the first few days, the volume of scans was moderate, reflecting the early development of Proof-of-Concept exploits and preliminary online scanning for exploitable systems.
Within a week, there was a significant increase in scan detections, with numbers peaking between December 20 and December 23, 2021.
As January wore on, Sophos noted that only a "handful" of its customers were subject to attempted Log4j intrusions. "The majority of these were cryptominers."
There are a few parallels that can be drawn with the Y2K panic. The action of engineers to deal with the problem undoubtedly saved the day for many organisations in both cases. The absence of a total IT meltdown left the rest of the world wondering, "well, was it as bad as all that?"
However, as Sophos observed, "just because we've steered round the immediate iceberg, that doesn't mean we're clear of the risk" with attempted exploits rumbling along "for years."
Where the Y2K incident shone a light on coding practices of decades previous, the Log4Shell vulnerability has made it clear just how dependent some companies are on open-source components they don't even know about, don't contribute to or don't have a support contract for.
- Open source, closed wallets, big profits – nobody wins the OSS rock, paper, scissors game
- Google says open source software should be more secure
- Open source maintainer threatens to throw in the towel if companies won't ante up
- Four million outdated Log4j downloads were served from Apache Maven Central alone despite vuln publicity blitz
The issue was summarised neatly by curl creator Daniel Stenberg with both a tweet and a later blog post detailing an email he'd received from a large company with a number of questions aimed at gauging how vulnerable his components might be. The company had no support contract with Stenberg and he correctly suggested that one would be a good idea before he slogged through the questionnaire.
"The level of ignorance and incompetence shown in this single email is mind-boggling," he said of the request.
"I think maybe this serves as a good example of the open source pyramid and users in the upper layers not at all thinking of how the lower layers are maintained. Building a house without a care about the ground the house stands on."
Stenberg also said: "No code I've ever been involved with or have my copyright use log4j and any rookie or better engineer could easily verify that."
Sophos concluded that the threat was not yet over and "the urgency of identifying where it is used in applications and updating the software with the patch remains as critical as ever."
While the danger from the Log4j vulnerability may have ebbed in the weeks since its disclosure, thanks in large part to an almost Y2K-esque mobilisation of engineers, some good might come of the RCE.
Companies are waking up to the open-source components they are using in their estate and hopefully understanding that just because something can be downloaded for free, ensuring it is supported and maintained means somebody must get paid. ®
- Black Hat
- Common Vulnerability Scoring System
- Cybersecurity and Infrastructure Security Agency
- Cybersecurity Information Sharing Act
- Data Breach
- Data Protection
- Data Theft
- Digital certificate
- Identity Theft
- Kenna Security
- Palo Alto Networks
- Trusted Platform Module
- Zero Day Initiative
- Zero trust