No panic despite red alert
The German Federal Office for Information Security (BSI) has declared a red alert and the Swiss Cybersecurity Center has also issued urgent recommendations. Even mass media have already reported on the vulnerability: Log4j, the widely used logging framework for Java, has a critical vulnerability that is already being actively exploited. A large part of all applications and APIs written in Java are potentially at risk. Java's success factor "Write once, run everywhere" is now becoming a boomerang.
The problem is serious for two reasons: First, log4j is a widely used logging framework for Java and has also been translated into various other programming languages. Millions of systems worldwide are therefore likely to be vulnerable, and prominent manufacturers such as Google, Apple and Tesla are also affected. And secondly, a lot of damage can be done with little effort: Danger exists when log4j is used to log a string controlled by the attacker, such as the HTTP User Agent. With a simple string, log4j can be persuaded to reload additional program code from a server on the Internet. An attacker can therefore inject arbitrary malicious code and thus attack companies from the inside.
Application security testing is not enough
More and more developers are automatically testing their own code and third-party libraries (like Log4j) for vulnerabilities. This is a big step forward for application security because it gets to the root of the problem. However, it is deceptive to rely on a database of known vulnerabilities. Application security testing helps identify a potential vulnerability, but it doesn't protect against it. When such a tool raises an alarm, it often takes days or weeks before the fix can be rolled out. Sometimes it is even impossible to patch all affected systems.
Buy yourself time with virtual patching
A clean solution takes time. Of course, all Java programmers are already working on switching to the latest log4j version. But the bigger problem might be to identify all affected systems first. Depending on the Java version, this log4j gap can be closed by an additional option when starting the Java environment. Either way, it will probably be several weeks before all affected systems are protected.
But it would be counterproductive to panic now. Because there is an effective immediate measure to gain time: Virtual Patching. An upstream application firewall (WAF) or API gateway detects dangerous content and blocks it before it reaches the vulnerable system. This has greatly reduced the likelihood of a successful attack, and IT can take its time patching the affected systems. The National Cyber Security Center also recommends updating the security rules of a WAF if necessary.
Hardened security rules thanks to bug bounties
The challenge of a WAF is to detect not only the obvious forms of an attack, but a whole class of complex variations. This requires that the filter rules of a WAF are continuously developed and hardened. At Airlock Gateway, we rely on a bug bounty program for this purpose. Good-natured hackers from all over the world are paid to bypass Airlock's filter rules. Those who manage to trick the protection mechanisms receive an attractive reward (bounty). One of the hackers complimented us on this: unlike other products, he had cut his teeth on Airlock.
Daily bread for security professionals
Airlock engineers are used to new security vulnerabilities appearing on a regular basis, even if many of them don't get much attention in the press. Just the critical vulnerabilities in the transport encryption TLS fill several screen pages. It's part of our job to respond to new threats and anticipate future attack scenarios as much as possible. And so we analyzed this vulnerability as well and made all the necessary adjustments in Airlock.
Conclusion
- Application security should be addressed in all phases of the software lifecycle: Even in the development phase, application security testing can highlight potential problems. And from testing to operations, WAFs and API gateways provide additional protection at runtime.
- Professional web application firewalls and API gateways can even fend off attacks that are not yet known. The prerequisite, of course, is that the protection mechanisms are active right from the start. An
- Airlock already protected against this vulnerability before it became known. Other manufacturers only adjusted their security rules after the vulnerability became known in order to adequately protect back-end applications.
- WAF rules must be developed and continuously reviewed by security professionals to ensure that the protection mechanisms cannot be circumvented by experienced attackers. This is ensured, for example, by our Airlock Bounty program, in which hackers from all over the world try to find gaps in the Airlock protective shield.
Is Airlock vulnerable itself?
- According to our current knowledge*, Airlock Gateway and Airlock Microgateway cannot be attacked from the internet. Nevertheless, an update has been published to protect the internal interfaces (monitoring, management GUI, etc.).
- All backend applications have been protected since Airlock Gateway 7.6, i.e. before the vulnerability became known. An update to the security rules has been made available for older versions of Airlock Gateway.
- Airlock IAM is affected by the vulnerability and has also been updated. However, because Airlock IAM is run behind Airlock Gateway in the rules, as per our recommendation, this update is not time-critical.
- More technical info and hotfixes are available on Techzone: https://techzone.ergon.ch/CVE-2021-44228.
*This blog article is based on the status as of 12/13/2021.
Blognews directly in your mailbox
The Airlock Newsletter informs you continuously about new blog articles.