"In a sensational wave of attacks, tens of thousands of servers worldwide fell victim to cyberattacks in December 2021 due to a security vulnerability in Log4j. The vulnerabilities had been utilised in the so-called zero-day exploit by a previously unknown espionage group..."
| TABLE OF CONTENT |
Wait a minute... I have written this before! Almost word for word, in March this year. Only, it was with Microsoft Exchange instead of Log4j.
As always, when this kind of incidents happened, there are a lot of gloating: this wouldn't have happened with certain technologies; administrators were too slow, etc.
Well, unfortunately these "certain technologies" are affected this time. The attacks occurred even before the patch is available for many affected products, so the administrators have no chance to react quickly enough. The extent of the wave of attacks cannot yet be predicted. "The Internet is on fire" is the headline of Wired Magazine.
Instead of showering each other with gloating and almost religiously emphasising alleged superiority of certain technologies, it would be better to learn how to prevent such waves of attacks in the future. IT security must finally come to a goal-oriented error culture. People make mistakes, that is a fact that cannot be changed. It is of little use to punish the developers of Log4j for a "catastrophic design error" - as some specialist media are demanding.
"Console for human error; Coach at-risk behaviour; Punish reckless behaviour" - in my view, this Just Culture Algorithm is the only error culture everyone should adopt. At DriveLock, we internalise this concept, bring it into our software and, with our software, to the customer.
Applying to the Log4j hack... The Log4j developers made a mistake. Certainly not intentionally. The focus should be in finding out why and how exactly this mistake was made, not who made it. That is the task of the Log4j community - "to console when human errors are made".
The at-risk behaviour in this case is shown by the application operators. Apparently, servers are not sufficiently protected. With an appropriate endpoint protection solution - i.e. application whitelisting and application behaviour control - the attackers would not have got very far.
Our technicians have thought about this and summarised useful information below - "coaching for at-risk behaviour".
I closed my blog in March with "The next security gap will surely emerge. ... Application control with application whitelisting could have prevented such worst-case scenarios."
This is still true.
Log4j stands for Logging for Java and is a logging library for applications written in Java. The library allows Java applications to write application messages and errors to a log file when they are executed. It is very widely used.
Log4j is used in all operating systems. Client-server architectures that can be influenced from the outside in such a way that a user-defined text is written to the log file are affected. For example, this could be the user name in a login mask of a server application. Log4j can be found in many network and system components as well.
If you want to know which applications are affected, you can find information on the internet, e.g. in this list: https://github.com/authomize/Log4j-log4shell-affected
A vulnerability named CVE-2021-44228, called Log4Shell, has been discovered in the underlying Log4j functionality. By exploiting the vulnerability, attackers gain the ability to reload arbitrary Java code and thus execute malicious code. Since there cannot be a uniform patch and the vulnerability is already being actively exploited, it is considered a classic zero-day exploit. Typical resulting attack purposes could be ransomware attacks in which data is encrypted for money. The infected computer could also be integrated into a botnet or misused to mine cryptocurrencies.
The top priority is to check which components in the company are affected. Here, companies should definitely consult the software manufacturers' information on the Log4j vulnerability and apply all available patches immediately.
Start with the systems that are accessible from the internet!
The Log4j vulnerability differs from other vulnerabilities in that it is not a bug in the software - because everything works exactly as specified. In this respect, one can speak of a collective failure. Neither the developers nor the users of the library were aware of the exploitability of this feature.
In principle, preventive protection against such errors is not possible. However, the potential damage can be largely contained by endpoint protection software - in this case application whitelisting. In this case, classic antivirus software will usually not be sufficient to detect and stop the malware created specifically for the victim.
The fundamental difficulty in preventing cyber attacks is that the potentially affected person does not know exactly what the attack looks like until after it has occurred. It is not enough to prepare for a specific attack. General protective measures must be taken that remove the basis for cyber attacks.
One important protective measure is to limit how software can communicate. Even a few simple firewall rules ensure that a program can only communicate with the computers it is supposed to communicate with.
In a similar way, Application Whitelisting ensures that only certain applications are allowed to run at all. The malware or ransomware introduced by the perpetrators is not included. With DriveLock, as with the firewall, just a few rules are enough to ensure security. In addition, Application Behaviour Control ensures that an application - even if it has already been taken over - cannot perform any harmful actions, such as accessing files or starting other programmes. As with a firewall, application behaviour control follows the approach of allowing a programme to do what it needs and prohibiting everything else, and is thus the third layer of protection in the example described. Such attacks can only be reliably prevented if several protection levels are coordinated with each other.
Attention-grabbing topics such as Log4j often put free riders on the trail, who exploit the need for information on the topic with SPAM mails in order to help with allegedly useful information regarding Log4j or Log4Shell. These often serve the purpose of phishing. Regular training of all employees on this topic, for example via the DriveLock Security Awareness Module, ensures that the appropriate knowledge is available to avoid falling for such SPAM mails.