DrupalGeddon 2.1 and the state of vulnerability management
If you’re running Drupal 7.x, 8.4.x, or 8.5.x, a new patch was released Wednesday. The patch was rated Critical with a score of 20/25. The Drupal team notified users two days before the patch was released so they could be ready to patch. The patch went live in the middle of the US workday, meaning that organizations wishing to patch had to take an outage window during business hours (not normally advisable). Several organizations we work with wanted to take more time to patch and scheduled a patch window for this weekend (something we strongly advised against).
Unfortunately (and unsurprisingly), attackers began exploiting this vulnerability mere hours after the patches were released. Since this is a remote code execution vulnerability, attackers that exploit it take control as the user that runs the web server software (thankfully this is rarely root). However (depending on configuration), attackers may be able to:
- Upload a web shell
- Dump data from a backend database
- Create landing pages for spam on your domain
- Exploit users who come to your site
- Steal credentials from users who come to your website
So definitely patch – right now. Well, on second thought, maybe don’t bother. If you haven’t patched by now and your Drupal system is publicly accessible, it’s already been hacked. We have seen evidence at the Rendition Infosec SOC that after attackers compromise a system they are also patching the vulnerability (if they have appropriate permissions to do so).
The speed with which attackers are turning vulnerabilities into exploits speaks to the need for security monitoring and threat hunting over vulnerability management. Obviously all of these activities are important, but the tides are changing.
In years past, infosec has primarily focused on vulnerability management and penetration testing. These are obviously still important. But in this scenario, an annual penetration test does little to discover the critical vulnerability that attackers have exploited and subsequently patched. Even advocates of continuous vulnerability assessments must admit that there is no way to keep pace with attackers in a vulnerability management program when the time to exploit is measured in hours.
Only real time network security monitoring can truly address the new pace of exploitation currently observed in the wild. Monitoring detects the exploitation attempts and can easily determine if exploitation was successful. If monitoring isn’t in place, then threat hunting is needed to determine whether exploitation occurred. Threat hunting starts by assuming compromise and investigates the host for indicators of compromise. Even in environments where monitoring is in place, regular threat hunting activities are highly recommended. We like to think of threat hunting like a safety net for a trapeze artist – you hope you don’t need it, but when you need it you really need it.
If your network doesn’t have continuous monitoring, reach out to Rendition Infosec to help. Our analysts can monitor your network, freeing you up to deal with your business with maximum peace of mind. If you think you may have already been compromised, our expert threat hunting and incident response teams can quickly assess your network for latent security threats. If you run Drupal and don’t know whether or not you were compromised, our analysts can help with that too.
We’ll close by noting that while Drupal is used as a case study, the issue is bigger than Drupal. The attack lifecycle has changed and if you’re not doing real-time network monitoring, you’re doing it wrong.