Last week, Drupal published a remote PHP code execution vulnerability (CVE 2019-6340) that could lead to the complete compromise of the targeted Web server. The report for this highly critical vulnerability was accompanied by the corresponding patch, and everyone was urged to upgrade to the latest branch versions (8.6.10, 8.5.11). For those who couldn’t upgrade, the Drupal security team suggested disabling of all Web service modules or configuring the Web server to not to allow GET requests. Still, and as is always the case, some web administrators did nothing at all, and threat actors were quick to take advantage of this negligence.
According to a report by Imperva, it took hackers only three days to exploit the aforementioned vulnerability, injecting Javascript cryptocurrency miners on websites that remain unpatched. This results in the exploitation of the site visitors, whose systems run the mining script when browsing the main page of the infected site. The miner is called “CoinIMP” and focuses on the mining of Webchain and Monero, always to the benefit of the malicious hackers, and not the infected websites of course. This is a perfect example of how regular and unsuspected site visitors can be the actual victims of the irresponsibility of website administrators.
Publicly releasing the proof-of-concept code is always a double-edged sword. Security researchers and developers learn from the exploitation path, can verify the findings, and are enabled to create safer and more robust platforms. However, hackers are also waiting in the corner for these useful examples, and utilize them to take advantage of security flaws quickly. In this case, the published PoC helped them develop exploitation tools in just three days, a period of time that is admittedly too short for quite a few Web admins to respond to the disclosed risks and take patching action.
The current pool of exploitation includes around 63,000 websites that use Drupal 8, so hackers are urgently looking for a specific combination of active modules that make the exploitation possible. This required combination of modules reduces the number of sites that are vulnerable down to very low figures, but still, this period is the hackers’ delight. As more Web admins patch their sites and plug the flaws over the next weeks, hackers will give up trying to locate websites that are still vulnerable as the attack surface will get impractically small. Again, all this goes to show the effects of publishing PoC code, the importance of patching immediately, and the level of readiness of hackers.
What tools against Javascript exploitation are you currently using? Let us know in the comments section beneath, and feel free to do the same on our socials, on Facebook and Twitter.