Tag Archive for: vulnerability

CVE-2021-44228 – Log4j2 vulnerability

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.

CVE-2014-3566 – POODLE

What is POODLE

The POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability allows an attacker to obtain data transferred with the SSL 3.0 protocol.  An attacker acting as a man in the middle can downgrade a TLS connection to SSL 3.0 and then use a padding-oracle attack to access sensitive information such as cookies.  Since stealing a user’s cookies will allow an attacker to login as that user, they are the most likely target of a POODLE attack.

Prevention

This vulnerability can be fixed either on the server or in the client.

Site owners can protect their users against POODLE attacks by disabling TLS fallback or SSL 3.0 (Note that disabling SSL 3.0 will break the site for IE6 users):

  • For Apache: SSLProtocol all -SSLv2 -SSLv3
  • For Nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Browsers are rolling out fixes but for users the quickest fix is to disable SSL 3.0:

  • In Firefox this is done by going to about:config and setting security.tls.version.min to 1
  • Chrome users have to use the command line flag --ssl-version-min=tls1

Going deeper

This attack is possible because SSL pads requests to fill the last block before encryption.  SSL 3.0 only requires the last byte to be checked by the server; it must have a value equal to the number of bytes that have been used for padding.  The values of the other padding bytes are not validated, this allows an attacker to move the block they want to decrypt to the the last block and try all 256 possible values until the server accepts the request, allowing them to decode one byte of the cookie.  An attacker in a privileged network position (or sharing public WiFi) just needs to downgrade the SSL connection from TLS to SSL 3.0 and then use JavaScript to quickly obtain a cookie one byte at a time.

For more technical information I would recommend this article by ImperialViolet.

Feature image made by Koji Ishii licensed CC BY 2.0

CVE-2014-6271 – Shellshock

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

CVE-2014-0160 – Heartbleed

A vulnerability has been discovered that allows anyone over the internet to read data straight off of your server.

“Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.
– Bruce Schneier

Labelled “Heartbleed” this vulnerability leaves your servers memory vulnerable and accessible to be read by anyone. A lot of private information is at risk, everything from passwords to SSL certificate keys are loaded into memory so often it is only a matter of time until a malicious user gets them.

The affected software, OpenSSL is a library that provides tools for encryption. OpenSSL is installed by default on many Linux systems as many core tools depend on it for SSL. It is widely used by servers for web, email, remote shell, VPN, file transfer and much more…

Test your website for the Heartbleed vulnerability.

The following command lists all services using libssl:

sudo lsof | grep libssl

The only fix is to upgrade OpenSSL to a non-vulnerable version and restart all services using it. Since it is used by so many services it can quickly become a large job to restart each process, especially in the correct order. The quickest way of doing this is by rebooting your server.

For more reading see the official Heartbleed website.

Our advice regarding this matter is:

  1. Ensure a fixed OpenSSL package is installed.
  2. Reboot your server (or restart all processes that use OpenSSL)

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

Feature image by Alan O’Rourke under the CC 2.0 license.