This weekend, a very serious vulnerability in the popular Java-based logging package Log4j was disclosed. This vulnerability allows an attacker to execute code on a remote server; a so-called Remote Code Execution (RCE). Because of the widespread use of Java and Log4j, as well as the relative ease with which the vulnerability can be exploited, this is likely one of the most serious vulnerabilities on the Internet since both Heartbleed and ShellShock.

This was a “zero day exploit”, meaning that the bad guys found this vulnerability and started exploiting it before that vulnerability could be fixed. The NIST has catalogued this as CVE-2021-44228 with a 10/10 severity (the most severe).

Who’s affected

Put simply – Java applications that use the log4j package. It is almost impossible to conclusively list all affected software and services, given such widespread use and the multiple versions and implementations that affects the ability to exploit the vulnerability.

An attempt to list responses from as many vendors and service suppliers can be found here, though this list shouldn’t be taken as authoritative.

What you can do

Most importantly you should take immediate action to do the following:

• Identify usage of affected log4j versions within your infrastructure.
• Apply available patches from your software vendors, or consider disabling elements of your infrastructure/services until patches are available.
• Monitor your systems/logs for signs of previous and ongoing exploit attempts.
• Take immediate steps to restore any affected systems to a known good state.

Our Customers

We are actively following the steps above and triaging those affected. Those most severely affected will have already been contacted and we will continue to proactively monitor all infrastructure to ensure all systems are patched as soon as possible.

Shellshock is a bug in the bash shell.  The main issue comes from the fact that commands can be executed if they are crafted into environment variables.  This means anyone who can send a user agent to Apache can run commands as the user running Apache.

Am I affected?

You can test if your server is vulnerable by logging in and running

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If it outputs vulnerable there are a few steps you can take to try to prevent it being exploited.

Prevention for website owners

The easiest solution is to update to a version of bash that isn’t vulnerable however if one has not yet been released on your distribution you will have to consider other prevention methods.

Since an attacker needs to exploit a vulnerable service two likely targets being SSH and Apache you can mitigate most attack vectors by stopping these services.
As long as you have another way to login it is worth stopping SSH since it is likely to be running as root it could allow an attacker to gain root access to the server.
Stopping Apache is a more difficult decision since it will prevent customers from accessing your site however if you are very concerned then it may be the best cause of action.

A more complex solution is to switch to a different shell instead of bash but this is more complex and may have unexpected consequences to how applications run so we don’t recommend doing this blindly.

If you have a maintenance agreement with us then you don’t need to worry because we are updating bash whenever possible.

Feel free to get in touch if we can help with this.

Feature image – “Shellshock” by Linux Screenshots is licensed under CC BY 2.0