“If an attacker was able to infiltrate a popular library like log4j, they would very quickly be running with privilege inside most data centers in the world.” — Jeff Williams, Contrast Security (2018)
Why Today's Cybersecurity Threats Are More Threatening and How They May Differ From the Hurdles We Met in the Past
Over the past two years, the rise of ransomware that goes It's the Tip of The Iceberg. The front-page headlines and revelations of harmful software supply chain attacks have raised cybersecurity to the top of many governments' and organizations' agendas. Meanwhile, even the general public has awakened to the new array of cyber-threats posed by nation-state actors and criminal organizations.
By the time I was writing this article, Log4Shell had happened. So that becomes the best example of what I will share — why cyber-threats nowadays are more threatening.
I need to tell you the nature of cybersecurity threats is different from the challenges we faced in the Past — from technological complexity to the growing interdependence. Attackers, therefore, seized opportunities faster, much faster than our mitigation. But first, let's talk about what is Log4Shell.
Log4j 0-day RCE Vulnerability aka "Log4Shell" (CVE-2021–44228 & CVE-2021–45046)
Companies worldwide are racing to limit the damage from one of the most significant open-source software security vulnerabilities discovered in years. A flaw in a program called Log4j, used in countless numbers of Java applications built over the last two decades, forced nearly every company to investigate their software to determine if they were vulnerable.
A zero-day vulnerability (CVE-2021–44228), publicly released on 9th December 2021 and known as Log4j or Log4Shell, is vigorously being targeted in the wild. As a result, CVE-2021–44228 has been assigned the highest "critical" severity rating with a risk score of 10/10.
As I wrote the article, a second vulnerability was uncovered, logged as CVE-2021–45046. According to MITRE, the description of the new vulnerability, CVE 2021–45046, says the fix to address CVE-2021–44228 in Apache Log4j 2.15.0 was "incomplete in certain non-default configurations."
Updated Log4j CVEs Summary
- CVE-2021–44228 (CVSS score: 10.0) — A remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
- CVE-2021–45046 (CVSS score: 9.0) — An information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0)
- CVE-2021–45105 (CVSS score: 7.5) — A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
- CVE-2021–4104 (CVSS score: 8.1) — An untrusted deserialization flaw affecting Log4j version 1.2 (No fix available; Upgrade to version 2.17.0)
Why is this Vulnerability So Destructive?
Most security holes require a certain degree of expertise to exploit. However, the effort required with this one, called "Log4Shell," is slight.
- Most software (and indeed all commercial software) maintains a log of all activity while the software is running, allowing developers and operators to review and figure out what went wrong when users are having trouble.
- That activity includes keystrokes from user input into web forms on a site.
- The Log4Shell bug allows an attacker to enter a carefully crafted string of characters in a web form that, once logged, controls the computer on which it is running to download malicious code.
- Depending on what data the application decides to log, this malicious string could be found in various areas, from an HTTP User-Agent against a web server to a chat room message in Minecraft.
- At that point, that computer was "hijacked."
- Malware designed to exploit the vulnerability was starting to spread Sunday night.
- Adversaries then further exploit affected systems, such as installing crypto-mining software, ransomware, and much more.
The result of the exploitation can allow for complete control of the infected system. Additionally, this vulnerability is exploitable with or without authentication, thus increasing the overall severity, scale, and impact potential, hence the unusually high CVSS score.
- Install crypto-miners on vulnerable systems;
- Steal system credentials (Credential theft);
- Deploy ransomware;
- Hide deeper within compromised networks (Persistance), and;
- Steal data.
Recommendations
At this time, the vulnerable versions of Log4j range from version 2.0 to 2.14.1. Additionally, there remain potential vulnerabilities in the deprecated 1. x versions. The reasonable solution is implementing the currently available patched version of Log4j that resolves this vulnerability, publicly known as Log4j version 2.16.0.
Also, cybersecurity solutions like Endpoint Detection and Response (EDR), Web Application Firewall (WAF), and Intrusion Detection System (IPS) are trying to mitigate the problem by providing “virtual patches.”
UPDATED — 20th Dec 2021 (CVE-2021–45105)
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0 and 2.12.3.
Nature of Cybercrime
When we looked at the cyber-criminals 20 years ago, they had to be very technical — the "real hackers" we saw in the movies wearing hoods and typing fast on the keyboards. Now the barriers to cybercrime entry are low, and cybercrime is becoming a service.
Today's most lucrative cybercrime activity is ransomware, which fosters more dangerous threats and the need for more innovative cyber defenses. For example, Ransomware-as-a-Service (RaaS) gives non-technical criminals the to tap into cyber-extortion. However, given all the rapid changes in the threat landscape, the real challenge is understanding the risk.
Another way hackers can profit from more sophisticated cybercrime is by providing cybercrime "infrastructure-as-a-service." Those in this field provide the services and infrastructure — including bulletproof hosting and botnet rentals — which other bad actors leverage to do their dirty work.
Bulletproof hosting helps cybercriminals put web pages and servers on the Internet without worrying about takedowns by law enforcement. And cybercriminals can pay for botnet rentals that give them temporary access to a network of infected computers they can use for spam distribution or DDoS attacks, and much more.
Complexity & Interdependency
To be clear, it is not the first time we faced such a holiday-breaker. The last time we faced such a crisis was when the Heartbleed vulnerability was discovered in OpenSSL in 2014. Shouldn't we learn from our mistakes?
Almost all the major enterprise tech companies agreed to contribute to a fund that would maintain the security of OpenSSL and other key open-source projects. However, there are two further compounding problems:
- Scale: Java has been one of the most famous enterprise software programming languages for a long time, and Log4j is one of the most popular logging tools used in Java applications.
- How software is built: Log4j has also been used in various open-source software programs that often serve as a foundation for other software.
Open-source software has led to an explosion in enterprise software innovation over the last two decades. Still, there's an open secret in this world: Scores of famous and prominent open-source projects are maintained by a handful of people who aren't necessarily paid to do that work.
The problem, however, is not a lack of money: There are so many open-source projects that have been used to build some of the most critical software in the world that is simply determining the ones that need support is an enormous challenge.
More Attack Surface — IoT (Example)
Even if some major tech players such as Microsoft have improved their security postures, today's attack surface is far more extensive than it was before. One particular contributor to this cause is Internet-of-Things (IoT) devices.
One of the things that hackers can do to take devices offline is send malicious packets that crash the machine. Another thing is when they can execute code on the device, which opens up the possibility of persistence on the network or moving laterally to other kinds of targets.
Unlike mainframe servers, desktop computers, laptops, and mobile devices, IoT are difficult to update from a security perspective. It is not a simple "to do or not to do" ideology, but limitations lead to challenges of securing IoT.
Many IoT devices are designed to be small and have just enough power for a specific function. Thus, there is not enough memory, storage, or CPU capabilities to accommodate security updates. As a result, patching is impossible for most IoT operating in the wild.
In August, Realtek has warned of four vulnerabilities in three SDKs in its WiFi modules. According to the advisory, almost a million vulnerable devices may be in use, including VoIP devices, wireless routers, repeaters, IP cameras, smart lighting controls, possibly any WiFi-connected devices with that chip design.
As in the example of Realtek, the fix involves updating the firmware of the related products in which introduced multiple difficulties:
- Finding if the IoT devices in use contain the chipset
- Seeing if the device is under a vulnerable version
- Updating the firmware
Updating firmware involves typically direct access to the devices. That is another challenge in most cases in which those IoT devices may locate in hard-to-reach locations (ceiling, inside the oil tank, inside another machine…).
It's perhaps worth adding that everyone can find affected hardware using the Shodan vulnerability search engine, which means hackers can do the same. In other words, that's the scary monster under the bed.
Back into BlackHat 2016, Log4Shell was Found.
Lastly, there's also the reminder that we should pay more attention to security research. For example, in Black Hat USA 2016, Alvaro Muñoz and Oleksandr Mirosh researched issues with JNDI.
Although not naming Log4j specifically, it is the flaw in the underlying interface that Log4j uses. Knowing that Log4Shell is an "I told you so" is, of course, little comfort now to all security professionals who are working at 110% looking to address the problem.
However, knowing that it was found in 2016 highlights the importance of giving security teams access to relevant information from the research and the resources — time, money, and more — required to apply these lessons to an organization's own infrastructure and practices.
Recommendation — Again, Zero Trust & Defence-in-Depth
Proven security principles, such as defense-in-depth and Zero Trust Framework, also have a substantial role to play. Many security teams understand these concepts well and wish to apply them to their organizations' software and solution deployments.
However, they are often met with resistance from other stakeholders or lack the resources to deploy them. As I mentioned previously, we are still on the journey of getting there.
Hopefully, the increased adoption of automation— such as infrastructure as code, mainly when used in modern pipelines built around CI/CD — makes it possible for security teams to cooperate with developers to build more secure solutions from the beginning and across multiple systems.
The Zero Trust principle also plays a vital role at the host, application, and network levels. For example, what actual privileges and capabilities do the process leveraging Log4j need at the host level. Increasingly, behavior monitoring (EDR, NDR, and XDR) alongside runtime protection can act as a powerful combination to mitigate the impact of an exploited system.
Notably, Zero Trust access exemplifies itself via micro-segmentation at the network level. With Log4Shell being a two-stage attack — where the payload has to be downloaded from an attacker-controlled system — the ability to isolate the infected system is advantageous.
Final Words — Time Bombs Inside Software
No matter Log4j or Realtek Vulnerability — It's the Tip of The Iceberg. Those early days when worms and viruses were poised to cripple significant portions of the web, we didn't do anything as an industry: We didn't implement better technologies, reduce our attack surface, or work on memory corruption issues in the codebase.
Much work is left to understand the real dangers behind the foundations of IT/OT/IoT connectivity. However, the more parties we can get involved in finding vulnerabilities, fixing them, and providing higher-level solutions, the faster we can transition to a more secure world.
Please visit the link below for the most updated guidance on Log4j vulnerability mitigation:
Also published behind a paywall here.