Everyone who is even slightly involved in IT has noticed that a new, dangerous security bug is doing the rounds: Log4j promises to be a difficult, risky problem for our digital community.
Is your mainboard IPMI firmware/software vulnerable for the Log4j issue? S3S asked cybersecurity expert Jan Guldentops to shine his light on the new bug and how to fix it.
What is the Log4j security bug Log4Shell?
Log4Shell is a simple bug in a piece of software that is widely used by Java developers to log everything that happens with their software. Wether you love or hate Java, you cannot deny that it is one of the most frequently used languages to build our digital infrastructure. Log4j is the Swiss army knife of logging if you’re doing Java.
So what is happening? The people behind Log4j put a feature in their software that allows you to look something up from an external source (e.g. user info from an external LDAP server like an AD, a domain name on a DNS server, …). But they implemented it in a bad, uncontrolled way, allowing any logging starting JNDI to connect to an outside server, download a piece of arbitrary code and execute it. In other words: just by sending a certain string to a web or other application (e.g. as User Agent in your webcall or as content that you put into a form) you can have it download code like a program that opens a backdoor and execute it.
It’s a painful and dangerous bug that potentially affects all software using this logging. And the list of vulnerable software is great: someone used it successfully on his Tesla car, VMware vCenter is vulnerable, Apple iCloud was affected, … And yes: you gamers better check that Minecraft server.
What should you do?
First, you should check all the external and internal software you use. (Best case, you already have a list of all the software you’re using.) For software from external companies, you can use this list compiled by the NCSC and see if your software is vulnerable. If it is not on the list, ask your supplier or check it with one of the audit tools that are available. Standard vulnerability assessment tools like Nessus can help you make a good inventory. Start with internet-facing public infrastructure, but don’t forget what’s on the inside of your company. In 2021 the security perimeter has disappeared.
For companies developing software solutions in house, check what libraries are used and how they are configured. Make an inventory of all libraries and external software used in your solutions from operating systems, containers, virtualization technology, program languages, extra tools, … The availability and use of a lot of (open source) libraries has helped us build excellent and high performing software, but you also have to keep up with all the libraries you use.
From an infrastructure side, there is a large potential for break-ins of essential building blocks of your digital infrastructure. Most server boards have a lights-out or remote management board. These components in Supermicro server hardware were checked by the industry (see the list compiled by the NCSC) and have no Log4j problems. Only if you are using the The Supermicro Power Manager software (SPM) you need to take action. Check this link for further details.
But this doesn’t mean that you are in the clear: VMware vSphere for instance is vulnerable, and at the time of writing there is only a workaround. Infrastructure components like JBoss Fuse (and everything built on and around it) and all the stuff you built around Elasticsearch should be patched and reconfigured ASAP.
How do you fix it?
There are two ways of fixing the Log4j security bug:
- Patch the software (with a patch supplied by the vendor or by updating Log4j yourself) to the latest version.
- Turn off external calls from Log4j in the software if you can’t patch.
Aside from this, I also believe that it’s essential to have an integrated security policy for your organisation. This is not going to be fun and it’s going to cost money and effort. But IT and everything powered by it is too important to take a firefighter approach to security. There should also be fire prevention: a strategy for how to prevent that stuff is set on fire.
E.g. why should your server infrastructure be able to make random LDAP, JNDI or DNS calls to every machine on the internet? A decent outgoing firewall policy would have prevented a lot of problems. This is the time to create a complete, integrated approach to security.
Still looking for more information? The best place to start is the page that the NCSC set up on github with links to all the tools and info you need: https://github.com/NCSC-NL/log4shell
Jan Guldentops is a security and open source researcher, consultant and educator. With his team at BA N.V. he helps organisations to research, build, secure and troubleshoot today’s and tomorrow’s digital infrastructures. You can follow him on Linkedin and Twitter, or contact him by e-mail.