No one’s losing faith over open source software despite Log4Shell, says expert

IT departments and developers around the world are furiously scanning applications for evidence of the critical zero-day vulnerability in the Apache log4j2 Java-based logging library in open source code on their systems. According to Apache, the vulnerability — called by some Log4Shell — was discovered by  Chen Zhaojun of the Alibaba Cloud Security Team.

What they aren’t doing, says one expert at a cybersecurity consulting firm, is hesitating over adopting open-source software.

“Not at all,” said Ollie Whitehouse, London-based global CTO of the NCC Group. “That’s like asking if we see hesitancy because there was a Microsoft patch. This is just part of doing business.”

“We are still in the foothills of understanding cybersecurity as a science and how to both write programs in a secure way and maintain them securely. I don’t think this has anything to do with the philosophy on which the software was developed, because we see many, many examples on a weekly basis of similar issues in closed-source software.”

Reports are wrong, he added, that only one developer is responsible for developing log4j2. To be an Apache project there have to be three developers. And more than that number oversee security, which comes under the Open Source Security Foundation (OpenSSF). It’s funded by big technology companies (including Cisco Systems, Amazon, Ericsson, Dell Technologies, Microsoft, Google, IBM, Intel, Oracle, Red Hat, and VMware), he pointed out. NCC Group is also a member, as well as on the foundation’s board of directors.

The OpenSSF is the successor to the Core Infrastructure Initiative, which was set up in 2014 after the discovery of another critical open source vulnerability, dubbed Heartbleed. The goal of the CII was to help boost the security of critical open-source software by giving financing to developers to work full-time on projects. When it started, the CII reportedly had just over $3 million in funding. Whitehouse said the OpenSSF has $10 million.

“That initiative is only starting to get going, starting to flex its muscles,” he said.

“What we recognize is there are lots of critical projects, of which log4j is just one, and as our dependence grows on all of these technologies it is for all of us … to ensure that the components are secure for the benefit of all technology consumers.”

“All software, open-source, closed-source, has latent cybersecurity vulnerabilities. We are only now getting to a point where we understand how to industrialize the detection and remediation of that. And the Open Source Security Foundation, with very large technology vendor backing now, is making concerted efforts to give it support, understanding that some of these projects are maintained by small teams.”

But he doesn’t deny the global impact the vulnerability may have. As others have noted, threat actors — some believed to be nation-states or nation-state backed — are already trying to exploit the bug.

He has already seen five customers who use the Ivanti/MobileIron unified endpoint management solution being exploited. One was a breach of security controls that NCC Group detected and stopped, “so the impact was minimized.” Ivanti has issued remediation advice for customers.

NCC Group has created this log4j2 resource page.

Security researchers at Huntress have created this vulnerability tester.

Cisco Systems’ Talos threat intelligence service notes that an additional vulnerability, designated CVE-2021-4104, has also been discovered, which identified that in specific, non-default configurations, a similar vulnerability can be triggered in Log4j v1.2.

ADolus, a Victoria, B.C., company that makes a solution that verifies the software supply chain’s legitimacy and safety, said on its resource page that the Log4j2 vulnerability “is a result of overly-provisioned features that were enabled by default, an insecure default configuration, and the implicit trust of messages.”

However it’s described, IT departments need to act fast to remediate the bug, said James Carder, CSO of LogRhythm. “The known Indicators of Compromise (IOCs) relevant to this attack are comprised of IP addresses that have been observed attempting to exploit the vulnerability and contents of the requests being sent. The log sources with the best visibility into these IOCs will be firewalls, intrusion detection systems, web application firewalls, and proxies.

“While these log sources can potentially provide detection for the initial exploit, keep in mind that IOCs change over time and there are many possible variations of this attack that can evade rules-based detection. It is also crucial that each organization looks for abnormal behavior on the servers using log4j in their environment, including unusual process behavior and unusual outbound network connections from the server. Endpoint logging, such as operating system logs and endpoint detection and response (EDR) observations, will significantly help round out behavioral detections.”

The combination of Log4j being practically everywhere and the fact that it is trivial to exploit, with many exploits and PoCs already available, makes it extremely dangerous and highly lucrative for every type of malicious activity,” said Yana Blachman, a threat intelligence specialist at Venafi. “An unauthenticated RCE (remote code execution) vulnerability in such a popular library is every attacker’s dream.”

 Jeff Williams, c-Founder and CTO at Contrast Security, cautions that there is a wide range of methods hackers can use to access personal information through Log4j’s vulnerability. “Firewalls aren’t going to stop hackers,” he said. “They still have plenty of other ways to break into organizations’ systems through Log4j which are undetectable by the firewall. This includes malicious code embedded into JSON, XML, and other common data structures that power nearly every website and application.”

The discovery of critical vulnerabilities will continue, said NCC Group’s Whitehouse, so CISOs have to be prepared. “Treat these things [vulerabiltiies] as marathons, not as a sprint. Ingrain the processes and responses as ‘business as usual.’ If organizations are requiring heroic responses to this particular incident, that is not going to be a sustainable strategy over the medium term.”

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada

Featured Download

Howard Solomon
Howard Solomon
Currently a freelance writer, I'm the former editor of ITWorldCanada.com and Computing Canada. An IT journalist since 1997, I've written for several of ITWC's sister publications including ITBusiness.ca and Computer Dealer News. Before that I was a staff reporter at the Calgary Herald and the Brampton (Ont.) Daily Times. I can be reached at hsolomon [@] soloreporter.com

Related Tech News

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.