In late 2021, the Apache Software Foundation disclosed a vulnerability that set off a panic across the global tech industry. The bug, known as Log4Shell, was found in the ubiquitous open-source logging library Log4j, and it exposed a huge swath of applications and services.
Nearly anything from popular consumer and enterprise platforms to critical infrastructure and IoT devices was exposed. Over 35,000 Java packages were impacted by Log4j vulnerabilities. That’s over 8% of the Maven Central repository, the world’s largest Java package repository.
When Log4j was discovered, CISA Director Jen Easterly said, “This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious.”
Since Log4j surfaced, how has the security community responded? What lessons have we learned (or not learned)?
Log4Shell is no longer a massive, widespread danger. Still, researchers warn that the vulnerability is still present in far too many systems. And actors will continue to exploit it for years to come.
Log4Shell was unusual because it was so easy to exploit wherever it was present. Developers use logging utilities to record operations in applications. To exploit Log4Shell, all an attacker has to do is get the system to log a special string of code. From there, they can take control of their victim to install malware or launch other attacks.
“Logging is fundamental to essentially any computer software or hardware operation. Whether it’s a phlebotomy machine or an application server, logging is going to be present,” said David Nalley, president of the nonprofit Apache Software Foundation, in an interview with Wired. “We knew Log4j was widely deployed, we saw the download numbers, but it’s hard to fully grasp since in open source you’re not selling a product and tracking contracts. I don’t think you fully appreciate it until you have a full accounting of where software is, everything it’s doing and who’s using it. And I think the fact that it was so incredibly ubiquitous was a factor in everyone reacting so immediately. It’s a little humbling, frankly.”
According to Nalley, they had software fixes out within two weeks. Alarmingly, Apache still sees up to 25% of downloads involving non-patched versions of Log4j.
Threat actors continue to exploit the Log4j vulnerability to this day. CISA has released alerts regarding Iranian and Chinese actors using the exploit. From Iran, cyber threat actors took advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server, installed crypto mining software, moved laterally to the domain controller, compromised credentials and implanted reverse proxies on several hosts to maintain persistence. Meanwhile, the top Common Vulnerabilities and Exposures (CVEs) most used by Chinese state-sponsored cyber actors since 2020 is Log4j.
Given the danger and ongoing threat, why do so many vulnerable versions of Log4j still persist? Could it be that some IT pros don’t really know what’s in their software?
The problem isn’t software vulnerability alone. It’s also not knowing if you have vulnerable code hiding your applications. Surprisingly, many security and IT professionals have no idea whether Log4j is part of their software supply chain. Or even worse, they choose to ignore the danger.
Part of the challenge is due to the rise of open-source software (OSS). Coders leverage OSS to accelerate development, cut costs and reduce time to market. Easy access to open-source frameworks and libraries takes the place of writing custom code or buying proprietary software. And while many applications get built quickly, the exact contents might not be known.
In a Linux Foundation SBOM and Cybersecurity Readiness report, 98% of organizations surveyed use open-source software. Due to the explosion of OSS use, it’s clear that supply chain cybersecurity may be impossible to gauge for any given application. If you don’t know what’s in your supply chain, how can you possibly know it’s secure?
The threat of vulnerabilities (both known and zero-day) combined with the unknown contents of software packages has led security regulators and decision-makers to push for the development of software bills of materials.
According to CISA:
A “software bill of materials” (SBOM) has emerged as a key building block in software security and software supply chain risk management. An SBOM is a nested inventory, a list of ingredients that make up software components.
If you have a detailed list of individual software components, you can assess risk exposure more accurately. Also, with a well-developed SBOM, you can match your list against CISA’s Known Exploited Vulnerabilities Catalog. Or, if you hear about an emerging mass exploit like Log4j, you can quickly confirm if your stack is at risk. If you don’t have an SBOM, you’re in the dark until you are notified by your vendor or until you get hacked.
If you were to scan your systems for software vulnerabilities, you might discover hundreds of thousands of weaknesses. Also, if you merged with another company recently, you inherit their risk burden as well. For larger enterprises, detected vulnerabilities can number in the millions.
Trying to patch everything at once would be impossible. Instead, proper triage is essential. For example, vulnerabilities nearest to mission-critical systems should be prioritized. Also, an organization should audit, monitor and test its software vulnerability profile often. And since IT teams might add applications at any moment, an up-to-date network inventory and scheduled vulnerability scanning are critical. Automated software vulnerability management programs can be a great help here.
Many companies don’t have the time or qualified resources to identify, prioritize and remediate vulnerabilities. The process can be overwhelming. Given the high risk involved, some organizations opt to hire expert vulnerability mitigation services.
While Log4j sent some into a frenzy, others didn’t even seem to notice. This gives rise to the debate about cyber responsibility. If my partner hasn’t patched a vulnerability, and it affects my operations, should my partner be held responsible?
In one survey, 87% of respondents said that given the level of cyber risk posed by Log4j, government regulatory agencies (such as the U.S. Federal Trade Commission) should take legal action against organizations that fail to patch the flaw.
Only time will tell how far the security community will take responsibility for vulnerabilities — whether by being proactive or by force.
The post Log4j Forever Changed What (Some) Cyber Pros Think About OSS appeared first on Security Intelligence.
Log4Shell is a critical vulnerability with the highest possible CVSSv3 score of 10.0 that affects thousands of products running Apache Log4j and leaves millions of targets potentially vulnerable. CVE-2021-44228 affects log4j versions 2.0-beta9 to 2.14.1. Log4j is an incredibly popular logging library used in many different products and various Apache frameworks like Struts2, Kafka, and [...]
The post Log4Shell VMware vCenter Server (CVE-2021-44228) appeared first on Hacking Tutorials.
Since Friday, December 10, 2021, researchers from the Synack Red Team (SRT) have been solving customer needs related to CVE-2021-44228—the CVE that details a critical log4j vulnerability with wide-reaching implications across industries.
Responding to the Critical Vulnerability with Synack Testing
By 8 A.M. PST, when its magnitude and implications became clear to Synack operations, a new CVE entry was created in the Synack Platform to address CVE-2021-44228. Log4j immediately became available for customers to launch, long before most of the world read about the vulnerability in headlines and social feeds.
Synack CVE Checks connect an organization to SRT researchers capable of accomplishing specific security tasks. In this case, organizations can select CVE-2021-44228 within the Synack Platform and have a researcher check for the vulnerability on-demand.
Testing with the Best Researchers on the Planet
Over 30 SRT members assembled to cultivate ideas and improve the entire community’s efficiency and effectiveness. Together, they are bringing a diverse spectrum of perspectives from different backgrounds, ranging from military and government to academia and tech. This collaboration of top researchers allows Synack to improve the quality of testing for all customers with better processes, tools, and payloads.
The SRT often shares best practices within the community to help each other level up and make the entire internet safer. Compared to traditional testers or automated scanning tools, the SRT brings these sorts of advantages: human collaboration, diversity and creativity.
The Landscape of CVE-2021-44228 Across Industries
Since Friday morning, Synack has checked over half a million IP addresses across our customer base, confirming the status of thousands of CVE-2021-44228 checks and providing detailed reports containing proof of work and methodologies. With a combination of human intelligence and automated tools, Synack is addressing the vulnerability at an unprecedented scale and pace.
Vulnerable instances span across countries and industries and exist both in the government and private sectors. The urgency of the vulnerability has not been overstated by news outlets and social media – Synack recommends that customers activate the CVE check as soon as possible.
Checking for CVE 2021-44228 On-Demand—The Advantages of Synack Campaigns
Since the weekend that followed the CVE’s publication, Synack customers have utilized the Synack Platform to activate hundreds of checks from researchers around the world.
Synack beats other models to the punch. Scanners do not yet have the vulnerability’s signature, traditional pentesting engagements take significant time to spin up, and other bug bounty models do not provide the immediacy or certainty of a vulnerability as this one requires. The model provides on-demand services relevant to CVEs today and prepares organizations for the next 0day like CVE-2021-44228. Reach out to a Synack representative today to explore existing CVE checks, as well as other offerings available in the Synack Catalog.
The CVE-2021-44228 testing provided by Synack provides immediate results and reporting. The researcher will provide a clear yes/no answer on an asset’s vulnerability status, as well as details about their methodology, screenshots, and general proof of work.
Activate the Synack CVE-2021-44228 Test Today
Reach out to your Synack representative to activate the CVE-2021-44228 test today. If you’re new to the Synack Platform, reach out to us here and learn how to get started with Synack’s on-demand security platform and pentesting.
Update: Synack was asked whether our systems are vulnerable to Log4j. Synack does not use Log4j and has determined that we are not vulnerable to exploitation. In response to increased attack traffic attempting to exploit the vulnerability, we have taken additional steps to block the malicious traffic accordingly.
The post Providing On-Demand Testing for CVE-2021-44228 (Log4j) with Synack Testing appeared first on Synack.
Login