Curious to know if anyone else in the DHIS2 community has ever conducted a manual penetration test of their own instance? A collaborative discussion around around the test and potential solutions would be of interest to us. Thank you!
1 Like
Never tried my self but… and not an expert.
By design, eg letting an admin provide a custom data entry with html/js, the application is probably open to a lot js/xss injection. CORS are enabled, so not that bad but still easy to exploit if you are admin.
Targeting admin user with attack to get their session or trigger some admin task is probably easier since there’s no crsf token but all operation are hidden behind POST/PUT/DELETE operations make it a bit more complex, so probable but needs some resources (just sharing a link won’t trigger the operation). Audit of admin task is possible now (at least metadata changes), and audit of datavalue changes is implemented. For session protection, verify your tomcat version and configuration.
The librairies under the hood (spring, struts,…), might be vulnerable too. I know that one of them was subject to remote code execution that was exploited on running servers (hopefully by script kiddies to do bitcoin mining). Dhis2 developers released an updated war asap. Spring has announced several security issues (path traversal, ddos,…) but I don’t know if dhis2 was affected/updated.
As the code is on github, developers gets notified on known vulnerabilities in their dependencies. I assume they assess them regularly (shows up on git push, pullrequest,…).
It’s probably a bad idea to offer a generic readonly user, and so keep “trustable” users only in the system. And a good idea to limit the number of super/admin users.
2 Likes
Thanks Stéphan. Wondering if you have taken any additional steps to secure your instance given the exploits you are aware of?
1 Like
on older versions (eg 2.30), dhis2 developers are patching the war so you need to verify regularly for bug fixes/security fixes and update your instance accordingly.
as described in the documentation
- forcing https ,
- limiting the access rights of the user running the tomcat
- encryption of the database
I’ve setup dhis2 to be on 2 machines, having the database on a separate server.
To be able to quickly respawn a fresh application server in case of scale up or compromised server.
Making sure the filesystem is on s3 with credentials limited to that bucket.
Configuring unattended security upgrades at os level.
Audit of access right using the dhis2 api
I hope some dhis2 developers will comment on this thread.
1 Like
Hi Stéphan and Kate
Great thread and important topic. There have been a few penetration tests of DHIS2 which have been shared with developers. These has been generally useful (if sometimes uncomfortable!) and each time has resulted in improvements to the code. So I would certainly encourage more of it. A few principles I would advocate:
(i) be very clear in reporting the exact DHIS2 version and as much info about the environment as possible;
(ii) vulnerabilities should be reported with steps to reproduce. This makes the report much more easily actionable.
(iii) when reporting a vulnerability from the field there is a disclosure process described at Security - DHIS2. Do use that.
There are existing vulnerabilities in DHIS2, new ones are constantly being found, and the developer and the release processes has improved considerably in terms of dealing with them. That is a good situation, much better than a year or two back.
I addition the UIO academic department has established a small security group of MSc students who are producing interesting work on a range of security issues. Some of that was reported at June Oslo conference. That’s something we hope to see continuing and strengthening.
There is a lot which can be done on the implementation side to mitigate common problems. I have run a number of DHIS2 server related academies over the past few years and am collecting together my notes into a sort of manual/set of tools. Will be ready for public consumption later this week and I’ll keep you posted.
In general I agree with all Stéphan’s advice above, with a number of additions. I’ll list a few here, but not preempt my more complete notes.
(i) the best way you have of defending against CSRF is to inject the SameSite flag to the session cookie using your web proxy. The way I do this on apache2 is:
Header edit Set-Cookie ^(.*)$ “$1; Secure; SameSite=strict”
You can do something similar with nginx following a hack something like:
Add samesite to cookies using Nginx as reverse proxy - Server Fault.
As an additional precaution do always advise users during training that they should not be browsing there email, the web etc while they are logged in to the application. Especially admin users.
(ii) for sensitive applications, do reduce the session timeout. The default is 3600s (1 hour) which is long. 10 minutes seems more appropriate for most cases. See system.session.timeout at Home - DHIS2 Documentation
(iii) Harden up your tomcat. As Stephan says, run it on a separate machine, vm or container. I use lxc for this, but docker is also fine. Don’t let it run as root. As an extra precaution, I dont allow it to unpack war files into the webapps directory. Do that as root. Enter the name of the tomcat user into /etc/cron.deny and /etc/at.deny. In the past where we have experienced remote code execution due to exploitation of struts hack, the attacker has always tried to use either cron or at to run code. So don’t let it do that.
(iv) Again endorsing Stephan’s suggestion, don’t create anonymous guest accounts on your production server holding sensitive data. This simply opens up a whole new surface of attacks which may be available to the logged in user. All accounts should be traceable ie. avoid accounts like nurse1, clinicABC etc.
More to follow. I’ll post link to ongoing work towards the end of the week. Staying safe is an ongoing process requiring collaboration between developers, implementers and users.
3 Likes