Why the Log4j vulnerability has been a problem for years

It didn’t sound very exciting at first: A security hole had been found in the open source Apache logging library Log4j. After initial investigations, however, a great deal of excitement quickly spread among system administrators and security experts. On Saturday, the German Federal Office for Information Security BSI sorted the vulnerability into the highest possible warning level.

The problem: The vulnerability known as Log4shell makes some of the world’s most popular applications and services vulnerable. The attacks are very easy to carry out and Log4j is used on millions of servers, sometimes as a pure dependency. Many an operator will therefore not even know that their systems are also using Log4j. Many will only find out about it when they have already become victims.

It was only on Tuesday that security researchers presented how easy it is to attack Apple and Tesla servers. They just changed the names of an iPhone and a Tesla and used an exploit string instead of a descriptive name. That worked, but initially does not allow any further conclusions to be drawn as to how vulnerable a system actually is.

Researchers from Cisco and Cloudflare have since found out that hackers have been exploiting the bug since the beginning of the month. However, the number of attacks has increased dramatically since the vulnerability was published on Thursday. Like Microsoft in a recent report writes, attackers are said to have already exploited the vulnerability to install crypto miners on vulnerable systems, steal system credentials, penetrate deeper into compromised networks and steal data. The digital forensics platform Cado reportedfor discovering servers trying to exploit the Log4j vulnerability to install Mirai botnet code.

Potential attackers have a broad target because logging frameworks such as Log4j are practically omnipresent. They are used wherever there is a need to keep track of what is happening in a particular application – in other words, everywhere.

To exploit the loophole called Log4shell, an attacker only has to trick the system into accepting a strategically created code string. This can be used to encode URLs, for example, which lead to malicious servers, from which malware could be installed later. The smuggling in is very easy. A renamed iPhone is enough, as is the sending of SMS to the servers of a cellular network provider, like it The Verge recently tried. It should also work to send the exploit code in an email or to set it as a user name for an account.

Just a few days after the vulnerabilities became known, practically all large technology companies such as Amazon Web Services, Microsoft, Cisco, Google Cloud and IBM declared that they were at least partially affected by the vulnerability. There are now several updates that were implemented immediately by the large companies – where the problem was already known.

Security experts see a danger in the gap, especially in the future. Malicious actors could build back doors into affected systems in order to take them over at a later point in time. These acquisitions could not come about months later if they were no longer acutely associated with the loophole.

A race between hackers and admins can currently be observed, explains Rüdiger Trost from the IT security company F-Secure. Both sides would look for vulnerable servers with automated mass scans. It is not yet clear how widespread the problem actually is. So the hardest part is tracking down all of the devices that could be affected.

Many – if not most – companies do not keep clear records of all software products they use and the software components built into them. The British National Cyber ​​Security Center emphasized accordingly on Mondaythat in addition to patching the usual suspects, companies must “discover unknown instances of Log4j”. Organizations with smaller IT departments or smaller software houses that may lack resources or awareness of the problem could face the Log4shell threat more slowly.

The vulnerability is already being used by a “growing number of threat actors”, warns Jen Easterly, director of the US security agency CISA (Cybersecurity and Infrastructure Security Agency). In a conference call with operators of critical infrastructures, she added on Monday that the vulnerability is “one of the most serious that I have seen in my entire career, if not the most serious”. That reports Cyberscoop.

Even if the long-term risks certainly have a high threat potential, server operators should initially stick to the short-term effects. Attackers are now actively looking for obvious vulnerabilities right now. This has to be eliminated as soon as possible. We can deal with the subtleties later.

“If you have a server with Internet access that is vulnerable to Log4shell and that you haven’t yet patched, you almost certainly have an incident to handle,” former NSA hacker Jake Williams told Wired. “Threat actors quickly exploited this vulnerability”. Williams therefore expressly recommends patching quickly without a prior, detailed test for compatibility. Security over functionality, one could say.

The researcher Marcus Hutchins, who found a kill switch for the infamous Wannacry worm in 2017, believes fears that someone could program a worm to particularly effectively exploit the Log4shell vulnerability are at least unlikely. “While it’s always a possibility, worms for this type of exploit are rare because the development effort generally exceeds the perceived benefit,” says Hutchins. “It is much easier to attempt to exploit from an inherited server than it is to develop code that is self-propagating. Also, it’s usually a race to exploit as many systems as possible before they are patched or exploited by others, so it doesn’t really make sense to take the time to develop a worm. “

So Log4shell will probably stay with us for years to come. If the loophole has a positive effect, it is that the approach of implementing software bills of materials (SBOM) is given a new impetus. This is a strict inventory that is intended to facilitate the inventory of the components used on the one hand and compliance with security measures in the software supply chain on the other.

Likewise, the Log4j gap should bring the discussion about whether system-important tools should only be looked after by interested developers after work, which in the best case will lead to changes.