[SECURITY] Urgent zero-day spring4shell - protect your DHIS2 instance against remote code execution

One of the worst class of exploits against web applications are those which allow the attacker to run malicious code on the server. This can lead to unauthorized access to credentials and data as well as whole range of other destructive activities.

Today there is news of one such vulnerability which has been named spring4shell (see for example https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ and GitHub - craig/SpringCore0day: SpringCore0day from https://share.vx-underground.org/ & some additional links). The DHIS2 team are still actively investigating to what extent we may or may not be affected and at time of writing there is no comment from the spring maintainers. If it is found to be a genuine danger then it is expected that spring will produce a patch which will result in patched releases of DHIS2 which we will make available as soon as possible as security hotfixes.

Meanwhile we can offer some generic advice to mitigate against a wide range of RCE attacks, including the proof-of-concept attack described above.

Protection against remote code execution (RCE)

===========================================

There are a few measures you can take which should provide protection against a range of attacks which I describe below (these assume that the user running the tomcat server is called tomcat):

  1. Protect the webapps directory

A solid defence is to make the tomcat webapps directory owned by root. For example:

chown -R root.root /var/lib/tomcat9/webapps

This makes it impossible for attackers coming in through the web application to modify the web application itself by, for example, dropping a webshell (Web shell - Wikipedia) into the webapps directory.

The tomcat user is able to run the application, not modify the application.

This is often exactly what you want until you get to to the point where you want to deploy a new web application. In which case you have two choices, either:

(i) to temporarily change the ownership of webapps back to tomcat; or

(ii) to “manually” unzip the war file into webapps as the root user

This adds a little inconvenience, but bear in mind that for the 99.999% of the rest of the time you can rest easy that your webapp is not modifying itself in malicious ways.

  1. Prevent execution through cron and at daemons

Using a webshell in the webapps dirtectory is one way of doing RCE. But after getting files on to the host, attackers can often find other ways to trigger code execution by the tomcat user, typically using the cron or at daemons. A very simple protection here is to create two files (if they dont exist) called /etc/cron.deny and /etc/at.deny and add the tomcat user as a line on its own in each file.

DISCLAIMER

There are many ways that attackers have found to launch RCE attacks against complex web application. The above guidance won’t guarantee that you are protected from all of them. For example the recent log4shell exploit would not have been mitigated by the above. But they are simple measures which will provide protection against quite a wide range of known attacks. There are additional approaches, for example intrusion detection monitoring for suspicious activity on the file system, but it does no harm to do the simple things which make an attacker’s life a lot more difficult.

7 Likes

IMPORTANT UPDATE

Spring has confirmed the vulnerability referred to as spring4shell above.

They have now released patches : https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

It is highly likely that DHIS2 will also be vulnerable so we will be releasing security hotfixes soon. Start to plan now for deploying them.

In the meantime please consider applying the mitigation advice above, particularly ownership of the webapps directory, urgently.

5 Likes

PLEASE NOTE

as reported in the “Am I impacted?” section of official link Bob posted above,

THIS VULNERABILITY ONLY AFFECTS SYSTEMS RUNNING JAVA 9 AND ABOVE

If your DHIS2 implementation is running on Java 8, it is not susceptible to this vulnerability.

5 Likes