Critical RCE vulnerability in Log4j Java package can lead to server take over
3 minute read
A very critical remote code execution (RCE) vulnerability has been discovered in Log4J – a popular Java package for logging. A huge number of applications, frameworks and even cloud services are likely using this package and therefore, is at grave risk.
The vulnerability enables a remote, unauthenticated attacker to instruct the application to load any arbitrary code from the internet and execute it on the application server, just by sending a simple instruction through an input form field (such as a search box), and take full control of a vulnerable target system.
Mitigation steps
- Immediately analyze your Java applications and their dependency tree and upgrade Log4j to 2.15.0
- If upgrade isn’t an option, disable ‘message lookup substitution’ as mentioned here
Zero Trust security best practices to protect production environments
As covered in the Zero Trust whitepaper,
Increased dependency on Third-party services and components has multiplied the attack surface
It’s obviously not possible to definitively verify, let alone control the security posture of the third-party SaaS services and packages from public repositories. Therefore, Zero Trust approach is needed to prevent or limit the exploit originating from these services and components.
Further, the best practices to ensure security of the application environment are given in the same whitepaper, some of them are reproduced here:
- Keep your packages up-to-date. Especially, keep a watch on release of security patches by subscribing to the notification feature of your package manager or something similar.
- Prefer packages that have gone through a security audit over ones without it. Refrain from using obscure packages. It’s true that popular packages aren’t immune to exploitation, but they are also quick to get patched for the same reason that they are popular. An obscure or little-known package might just carry the vulnerability for longer period of time, before anyone even notice it. Or, it might get taken over by the hacker and the original author has already moved on to something else, so again, no one notices the transfer of ownership.
- Turn off features you don’t need from a package through its configuration (if it provides such settings) and/or see if you can load the package in a lower trust mode rather than full trust.
- Use signed packages and include verification of signature of every package in your build and verification step.
- Create and safely store in a read-only configuration the MD5 hash of every package binary once you have installed/upgraded a version; verify the binaries using this hash as part of your build and verification system.
Read more on the whitepaper.
Build Zero Trust thinking for software development
Because Zero Trust is not just an approach; it’s a mindset.
You can also develop this mindset by going through the hands-on tutorials from the Zero Trust Thinking (ZTT) series. ZTT is brought to you by ASPSecurityKit, the first true security framework for ASP.NET and ServiceStack built from scratch on the Zero Trust model.
Leave your email below to receive a notification of new ZTT articles and videos right in your inbox, once every two weeks or so.
Need help?
Looking for an expert team to build a reliable and secure software product? Or, seeking expert security guidance, security review of your source code or penetration testing of your application, or part-time/full-time assistance in implementation of the complete web application and/or its security subsystem?
Just send an email to [email protected] with the details or call us on +918886333058.