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):
- 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.
- 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.