April 14, 2018 at 00:25Drupalgeddon2: SA-CORE-2018-002 launched
Drupalgeddon2 still came to us.
What happened? After the crazy announcement of “one of the worst Drupal vulnerabilities”, everyone froze in anticipation of a working exploit and after 4 days even started to feel a little sad, considering that all the panic was in vain, since no one could come up with anything worthwhile. But as soon as CheckPoint today published a working PoC on SA-CORE-2018-002, the army of bots began attacking sites on Drupal, which is called “in the wild”.
According to the logs, it looks like this:
3 requests, the first GET checks the fact of the possibility of an attack, the second POST - an attack with a payload, and the third - checks the success of the loaded backdoor.
The hackers didn’t have enough time for payloads, or fantasies, so they look very similar:
In general, the Achtung is quite serious, the process has begun and the trouble is that everything happened before the weekend. However, hosters or services that proxy traffic could protect clients by blocking requests with fragments at the server level:
So far, the logs show that all attacks are based on the same Python script (hackers, fortunately, are lazy), and only the request to the account / mail object is operated, but there is at least one more attack through the timezone object.
So far, current attacks can be closed even at the ModRewrite level of the rule, but probably all sorts of more complex options will appear.
If anyone is interested, a .php backdoor is loaded into the payload via wget or curl. What hackers will do next with them depends on their imagination. Given the popularity of miners, most likely backdoors will be used to place js miners on pages (or start mining processes on the server), download phishing pages or spam mailing lists.
In any case, if you are a site administrator on Drupal, we highly recommend updating or at least closing the site with attack rules and, just in case, scan it with the AI-BOLIT file scanner and the ReScan.Pro online scanner to be sure that you are not hacked.
What happened? After the crazy announcement of “one of the worst Drupal vulnerabilities”, everyone froze in anticipation of a working exploit and after 4 days even started to feel a little sad, considering that all the panic was in vain, since no one could come up with anything worthwhile. But as soon as CheckPoint today published a working PoC on SA-CORE-2018-002, the army of bots began attacking sites on Drupal, which is called “in the wild”.
According to the logs, it looks like this:
3 requests, the first GET checks the fact of the possibility of an attack, the second POST - an attack with a payload, and the third - checks the success of the loaded backdoor.
The hackers didn’t have enough time for payloads, or fantasies, so they look very similar:
In general, the Achtung is quite serious, the process has begun and the trouble is that everything happened before the weekend. However, hosters or services that proxy traffic could protect clients by blocking requests with fragments at the server level:
account/mail/%23value (account/mail/#value)
timezone/timezone/%23value (timezone/timezonel/#value)
So far, the logs show that all attacks are based on the same Python script (hackers, fortunately, are lazy), and only the request to the account / mail object is operated, but there is at least one more attack through the timezone object.
So far, current attacks can be closed even at the ModRewrite level of the rule, but probably all sorts of more complex options will appear.
RewriteEngine On
RewriteCond %{QUERY_STRING} account/mail/%23value [NC,OR]
RewriteCond %{QUERY_STRING} account/mail/#value [NC,OR]
RewriteCond %{QUERY_STRING} timezone/timezone/%23value [NC,OR]
RewriteCond %{QUERY_STRING} timezone/timezone/#value [NC]
RewriteRule .* - [L]If anyone is interested, a .php backdoor is loaded into the payload via wget or curl. What hackers will do next with them depends on their imagination. Given the popularity of miners, most likely backdoors will be used to place js miners on pages (or start mining processes on the server), download phishing pages or spam mailing lists.
In any case, if you are a site administrator on Drupal, we highly recommend updating or at least closing the site with attack rules and, just in case, scan it with the AI-BOLIT file scanner and the ReScan.Pro online scanner to be sure that you are not hacked.