Slashdot Mirror
Hundreds of Drupal Sites Targeted With Fake Ransomware (softpedia.com)
An anonymous reader writes: A group of hackers have created a ransomware strain that specifically targets Drupal sites. Infection occurs thanks to an automated bot which scans Drupal sites and then uses an SQL injection (CVE-2014-3704) to change the site admin's password. The bot also dumps any emails it finds on the server, and then overwrites the site's main page to show a typical ransomware note.
Over 400 sites have been infected until now, but nobody has paid the ransom yet.
This case yet again proves why "Web ransomware" will never work because even the worst Web hosting service provides automatic backups from where they could retrieve a clean version of their site.
This case yet again proves why "Web ransomware" will never work because even the worst Web hosting service provides automatic backups from where they could retrieve a clean version of their site.
"This case yet again proves why "Web ransomware" will never work because even the worst Web hosting service provides automatic backups from where they could retrieve a clean version of their site."
WTF, the writer of this post lives in a delusional bubble. Most sites don't have backup's, backups cost money. Ransomware exists because it is extremely successful, it only has to work on 1 in a hundred or 1 in a thousand to make it profitable.
Further, of the perhaps 12 hosting companies we've contacted about restoring backups, most of the time the backups didn't actually work. A common scenario was that the backups stopped working several months earlier but nobody noticed until they were needed.
That type of experience, and web hosting companies that go out of business, eventually forced us to create Clonebox.
You know, you could actually use the exploit to change the sites password back, right? And if it's just the main page, even if it isn't backed up it isn't much work to rebuild (well, relatively anyway). Unless they patched it after your site got infected.
You are missing something, more precisely you are missing the fact that Drupal was written in PHP. If you want to iterate over an array in PHP you will probably write something like this: ... }
foreach($array as $key => $data) {
A construct like that was used in Drupal to construct an SQL query with a list of named parameters, the values for which were then supplied later. You'd get an SQL clause like this:
... IN (:idlist_1, :idlist_2, :idlist_3) ...
And the values would be filled in and escaped by the SQL backend later. Array indices are numbers, so it's all perfectly safe, right? The thing is, PHP contains a critical security bug in that it doesn't enforce declaring the distinction between arrays and maps. So if an attacker can somehow trick the code into executing on a map, $key might be a string containing arbitrary SQL commands which will be executed as is.
Note that in many languages this cannot happen because an array is not a map, but PHP is unsafe by default here. Yes, if you know about this issue you can work around it, for example by inserting a call to array_values, but the language should really be changed to make it distinguish arrays and maps, and to make impossible to use maps as arrays. It is especially unforgivable since PHP was designed for the web and to be easy to use by novice programmers.
Link to CVE page.
Link to earlier /. discussion.
Sounds real to me.
Lame, perhaps, but certainly real to the extent that someone is (at least temporarily) locked out of their system and has to take steps to restore it or pay the ransom.
From the fine article, it didn't bother encrypting anything so that certainly bumps it way up on the lame scale. But it's not like people received notices in their inbox demanding ransom for something that never got installed.
From the article, it's about 400 sites. Pretty easy to find infected sites with Google, since it changes the home page of the site.
The ransom is to be paid to a specific bitcoin address, so anyone can look at the blockchain and see how much bitcoin has ever been transferred to that address. The answer being 0 makes the folks in the article pretty confident nothing has been paid so far.
The infected sites appear to be mostly abandoned by their creators, which explains why they're 2 years behind in Drupal 7.x security updates.
The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.