Updates on CyberSecurity, WordPress and what we're cooking in the lab today.

If You Use This Script, You’ve Probably Already Been Hacked

This entry was posted in WordPress Security on July 25, 2017 by Mark Maunder   48 Replies

Hacking Made Easy

Several years ago, web publishing company Interconnect/IT released a handy tool for finding and replacing text in a website’s database. This tool, a stand-alone file published as searchreplacedb2.php, includes built-in WordPress compatibility that makes working with WordPress databases a breeze.

Unfortunately, it doesn’t include any authentication or security measures, which makes infecting WordPress databases equally easy.

During the last few weeks, our Security Services Team has noticed a spike in infections using this script. The hackers use their botnets to look for the script all over a target site. The following is a sample of log entries searching for this file.

We tracked scans from a set of known malicious IPs over the past two months and you can see the activity below:

If they find this file, they simply use it the same way a website owner would – except in this case, they exploit a website.

We have prepared screenshots of the script in action. It’s a very simple process using several pages. The first page prompts the user choose to automatically get the database login information from the WordPress configuration file. Note the warning about removing the script – we’ve omitted it from the rest of the screenshots, but that warning is actually present on every page.

In the second step, you confirm the preloaded database login credentials.

In the third step, you select the table(s) you want to work with. Hackers are selecting the posts table.

Finally, you enter the text you want to search for and the text with which you want to replace it.

This is what the hackers are doing:

They’re simply looking for “<a href” which is code they know will be present in virtually every post on a WordPress site, and they’re prepending a remote Javascript include to it. This Javascript immediately redirects users through several intermediate sites, finally arriving at pages containing spam or malware.

Here is an example of a destination page:

 

The hackers actually don’t even have to walk through each of those steps – they can collapse it all into a single request. In an instant, an innocent site is completely hijacked.

Who Is Behind This?

Like most malware campaigns, this one involves computers around the world with no clear connection to each other. Many of them are probably infected with malware, unwittingly participating in the hackers’ botnet. However, we noticed that a few key servers are located in the Netherlands.

traffictrade[dot]life -> 185.183.96.33 (Host Sailor Ltd, NL)
trafficbroker[dot]club -> 185.183.96.33 (changed on June 20 from 5.149.248.164, which is registered to another Dutch company, HZ Hosting Ltd)
2clicks[dot]xyz -> 109.206.179.191 (Serverel Corp, NL)

Passive DNS data shows that the IP addresses associated with these domain names have not changed throughout this campaign. In other words, the hackers haven’t had to switch to a new server after their first one was shut down. They may have found a set of lenient Dutch hosting companies who turn a blind eye to their illicit activities.

Does Updating Help?

Searchreplacedb2.php is actually an old version of the script. But the present version, 3.1.0, is essentially the same tool and still does not include any security measures (besides a warning). So updating to the latest version doesn’t make it any safer.

This newer version isn’t a single file, but instead runs as a collection of scripts in a folder named Search-Replace-DB-master. We don’t have any records of hackers checking for the presence of this folder, but it is only a matter of time before they add it to their list of targets.

Test Your Site

To check if this file is present on your site, simply run a Wordfence scan. If you are not using WordPress, you can also run a Gravityscan Рand make sure you install the Accelerator for the best available detection.

What to Do If You Are Vulnerable

If you have searchreplacedb2.php on your site but you don’t need it anymore, delete it immediately.

If you do need to use it on your site, then upload it with a different filename. Keep it uploaded only as long as you need it, and then immediately remove it.

A broader security principle applies here: run only as much software as you need. If you leave a script lying around, whether it’s a powerful tool like searchreplacedb2.php or a simple file with nothing but phpinfo() in it, you are offering some portion of your site to hackers. If you keep plugins and themes around even though you don’t use them, you are maintaining a risk that is completely unnecessary.

What to Do If You Have Been Hacked

If you have searchreplacedb2.php unsecured on your WordPress site, then the odds are high that you have probably been hacked. If you have it and your users are being redirected away, then you have definitely been hacked. Head to our site cleaning page and let the experts on our Security Services Team handle it for you.

Lesson For Developers

Developers, take heed: it doesn’t matter if you put a security warning on every page of your product. It doesn’t matter how bold the font is or how dire the wording is, or how easy it is for the user to delete the vulnerable script when they are done with it. Users will still forget or just ignore the warnings, and when that happens, bad guys profit. Make your code secure by default.

Conclusion

As always, be aware of what is installed on your system, and routinely enlist the help of Wordfence and Gravityscan to assist you in finding any possible security holes.

This blog post was written by Brad Haas, a senior security analyst at Wordfence and team lead for our Security Services Team. Brad has years of experience both in incident response and in securing sensitive government networks. 

Did you enjoy this post? Share it!


3.95 (55 votes) Your rating:

48 Comments on "If You Use This Script, You’ve Probably Already Been Hacked"

Corey C. July 25, 2017 at 10:06 am • Reply

We used to use this tool (with a modified filename and deleting it immediately after use). It was a good tool at the time, but I can't recommend using it today. Instead, use WP-CLI; it offers the same functionality, but it's locked behind an SSH login.

AndB July 25, 2017 at 10:20 am • Reply

The funny thing is that Google indexes that file so you can even do a simple search to find sites that left that file

Lucas July 25, 2017 at 10:27 am • Reply

I used that script several times on different wordpress installations.... but i used to delete the file after the use...

Marc July 25, 2017 at 10:31 am • Reply

I look after several website and it seems in every one of them this file (searchreplacedb2.php) only exists within your wordfence plugin folder structure... What action woudl you reccomend for me to take?

Best,
Marc

Mark Maunder July 25, 2017 at 4:21 pm • Reply

I strongly recommend you remove that. Those directories are publicly accessible. And check if your site has already been hacked.

Steven July 25, 2017 at 10:33 am • Reply

I remember this tool and have used it but never on a server - just as a local one-time script before putting a site live and as Corey says we would delete it after use. WP-CLI is a good alternative and the Better Search and Replace wp plugin from Delicious Brains is also good and easy as a one-off solution as needed.

Tony July 25, 2017 at 10:33 am • Reply

We've used the script many times but as the author says you need to remove the script for security purposes. Obviously if you can replace content in your database anyone could.

Good to know Wordfence would find the script if it forgotten.

Adam P. July 25, 2017 at 10:35 am • Reply

What if you have the file stored above root (above the /public_html/ directory)?

Mark Maunder July 25, 2017 at 4:20 pm • Reply

That is pointless because it will not be accessible via your browser and so you won't be able to use it. But as long as it is not publicly accessible you are not vulnerable.

Rodger Sellers July 25, 2017 at 10:45 am • Reply

Anyone being infected through the SR script obviously never read the instructions accompanying it. They are very clear and should never cause a problem like this. RENAME the file, use it, then IMMEDIATELY DELETE IT! (This ain't really rocket science...) I hate it for folks but security is mostly common sense and not cutting corners.

Lou July 26, 2017 at 5:17 am • Reply

The script is not safe even if you rename it or delete after use. Hackers will catch up and exploit the vulnerability in new and inventive ways. Botnets may soon find it by the page's content in the short time you are using it and exploit instantly. Take security more seriously. It's your users that get hurt.

Rob Chant July 25, 2017 at 10:49 am • Reply

In fairness, the authors tell you explicitly it's not secure and strongly recommend not leaving it on a production server.

Rich S. July 25, 2017 at 10:54 am • Reply

I use that tool for WordPress server migrations, but I've renamed it with a random name, and never leave it on the server after a migration is finished.

Would be far more secure if the authors changed it slightly: Force the user to enter the WordPress database password manually, and enforce a 5s delay upon failed password attempts.

Jana B. July 25, 2017 at 3:25 pm • Reply

I have also used that tool for WordPress server migrations, and for implementing SSL, and I also rename it and never leave it on the server after use.

Your suggestion, Rich S., sounds good to me. Two relatively small changes would make an otherwise very useful product more secure.

LeeS July 25, 2017 at 11:03 am • Reply

I have to say I do still use this tool a lot in development and will continue to.

The new version is in a folder, as you say, I use a non standard filename for it always (I have it saved in a folder on my server so no messing around)

It also has a 'Delete Me' button right under the scripts results section which removes the entire folder after you have finished with it.

Leaving the thing in place is obviously a security risk, but in my opinion it's nothing more than user error that is the issue here, not really the tool itself! (the older version was probably worse to be fair)

Lee

Grogrevenge July 25, 2017 at 11:07 am • Reply

This is why programmers shouldn't rely on user to do the right thing. if you make such code make sure you secure it. always assume the user won't listen. DELETE ME doesn't work.

Can Margairni July 25, 2017 at 11:09 am • Reply

I use this tool, on a local environment in a separate sub domain on a completely separate project folder.

It's a really good tool, and very easy to use. Just need to be careful to not include it in your project.

James Revillini July 25, 2017 at 11:10 am • Reply

We used to use this script and we'd place a link to it on the home page and dare people to hack us, but we got hacked too many times and had to stop playing with fire.

We still use the script.

Brad July 25, 2017 at 11:13 am • Reply

I really don't understand why a dev would risk their own reputation by setting up a plug-in with such blatantly well known weakness. It's obvious that their big red letters won't stay in the user's mind for long.

With the reputation that hackers have for wanting to attack WP sites it is extremely irresponsible to leave the security of the plugin up to the user who has no clue how to make anything secure.

Once again Mark thank you for your lazer guided heat seeking Gorillas that watch over us 24/7/365

Robert July 25, 2017 at 11:16 am • Reply

So, just curious, if you were writing a script like this, what kind of security features would you supply? Is the script really defective, or is the deployment bad? Wouldn't the easiest fix be to password protect it (like apply basic authentication to the script directory)?

Mark Maunder July 25, 2017 at 4:13 pm • Reply

Authentication and authorization. Same as WordPress or any other sensible application that controls who has access and their access level.

David Coveney July 26, 2017 at 2:08 am • Reply

Hi all - I wrote the original script. Others both inside and outside the firm have taken it and run with it.

We warn people, several times over, that it's not designed to be left online. It's there for a developer who can't run command line tools on a webserver (common with clients) who needs to run a comprehensive Search/Replace across a database and from outside of WP. It's usually for migrations.

It isn't meant to be secure. It isn't meant to be left lying around. Your headline should be "If you leave this script lying around on a public facing webserver, you're probably already hacked."

To say it is insecure is correct. We've never suggested anything else. It is insecure by default. To suggest that we're risking our reputation in building and supplying a tool for other coders to use is complete nonsense. That's lying saying that all knives should be blunt in order to protect people from cuts and any knife maker supplying sharp knives is being irresponsible.

The very first paragraph on the download page states "Please read all instructions and familiarise yourself with the risks of using this tool first, downloading of this tool signifies your acceptance of the risks and problems associated with the script."

On the script's own page as it runs it says "DON'T FORGET TO REMOVE ME!"

So we're left with a problem... it's a free, GPL script designed to do a job for developers and those developers should have a good understanding of what they're up to or they should really not be using such a tool. You mustn't leave it simply lying around. Just don't. And if you're installing server side software without reading the instructions then there's only so much the industry can do to protect you.

If anyone is willing to sponsor further development to turn this into a script that's safe to leave lying around, then we can do so.

In my view the confusion here is a fundamental misunderstanding of GPL - it's there for developers to help other developers. It's not there for end users to just get free stuff with the entitlement baggage that comes with it.

I'm going to have a good think about what the best path is. If non-devs or inept devs are leaving this tool lying around and they think that's somehow our fault (as you imply) then it'll be in our best interests to simply remove the tool from general availability *unless* we can create a business model around it. So I'm going to have a good think and see what makes sense.

Mark Maunder July 26, 2017 at 8:42 am • Reply

Hi David. Thank you very much for sharing your thoughts here. I'd like to be clear that I don't agree with the more 'accusatory' comments that have appeared here.

Our perspective is this: We clean hacked websites and we do quite a few each day. The team lead in our site cleaning team who has a lot of visibility on what is happening on the ground came to me and asked if I'd noticed how frequently this issue is coming up in our "site-cleaning" channel on Slack. I had noticed a pattern and we agreed that he should dig into it a bit deeper and perhaps write a blog post to create awareness to stop people leaving this script in public locations and getting their sites hacked.

So the post above is simply us reacting to seeing many hacked sites that are as a result of this script left lying around.

Brad, the author of the post should probably weigh in - and I haven't looked at the code. But I'd say that starting by simply making it secure by default is a good first step. To put it in perspective, many of the attack shells we see have an admin password you have to enter to be able to use the shell. So even hackers have tools that are secure by default.

Perhaps an easy first step is to modify the code so that you have to enter a complex password to be able to access it. And by default if you have not configured a password, the script throws up a message that says "please edit line X of the file Y and set an admin password to be able to us this utility".

Thank you again for sharing your thoughts.

Mark.
PS: Sorry for the delay in approving your comment. We have a bunch of security conferences on this week (Black Hat and DefCon among others) and so it's taken me a while to get to moderating comments.

David Coveney July 27, 2017 at 1:56 am • Reply

I think I now have a plan. For now the form+email approach should act as a filter to at least make sure people are aware of the risks. For the future we'll likely add http auth and email the zip, along with a generated password for the authentication. That at least adds a layer of protection.

Phil July 25, 2017 at 12:28 pm • Reply

You would have to be a complete muppet to install that on any publicly accessible website or service. There's no need to use something like that on a production environment. There are many tools available for you to make the DB changes locally and deploy to either a live /staging server.

Anyone that uses this on a production box needs to seriously reconsider their profession.

Phil July 25, 2017 at 12:31 pm • Reply

... I failed to mention, I use this tool many times a day to help with Wordpress & Drupal websites. It's a great tool and makes my job a lot easier. I'd strongly recommend it to any developer that needs to find and replace serialized data within a MySQL database. I'd rate it 11 out of 10 it's that good.

It's just a shame that with the skills that InterConnect/IT have, they couldn't figure out a way to fix the stupid in some of their end-users :/

Marvzg July 26, 2017 at 8:38 am • Reply

Also a developer should have enough with mysql skills why would they even need a script like that? that is for noobs that does not know how to use mysql search and replace function in phpmyadmin.. and also if for wordpress there are a few plugins which do not ask for database information and that it is only visible on the wp-admin.. so the point is if it asks for database and login information to be saved locally outside of a wordpress environment that should be a no go..

David Coveney July 27, 2017 at 1:15 am • Reply

A skilled developer will also know that you can't just run a search/replace on serialised data and expect it to then be readable...

Icy Sedgwick July 25, 2017 at 1:06 pm • Reply

If I run a Wordfence scan (using the free version), exactly what am I looking for?

Mark Maunder July 25, 2017 at 4:18 pm • Reply

If this script is detected you will see a result similar to when malware is detected. But it will include a description that this tool is a maintenance tool and should not be in a publicly accessible directory.

Gary Cameron July 25, 2017 at 1:13 pm • Reply

I figure if someone is smart enough to be using this tool they should be smart enough to remove it. Ignore the big bold warning and you deserve what you get.

This is intended as a quick and dirty search and replace tool to be used by people who understand WordPress and basic 'nix security. Mainly to be used with site migrations.

Sallie Goetsch July 25, 2017 at 1:41 pm • Reply

If you're not bright enough to follow the very clear instructions about deleting the script after you use it, you probably shouldn't be using it.

Daniel Parsons July 25, 2017 at 2:47 pm • Reply

Always appreciate what WordFence does to keep us safe from attacks. I remember getting hacked with spam link injections & it takes weeks to manually clean up the hacked pages & posts.

Jobst July 25, 2017 at 4:30 pm • Reply

I just did a search on all of my servers ... but I searched for "searchreplace" only.
Turns out that tinymce has a script that is named "searchreplace.php".

SInce I do not have the code for the original searchreplacedb2.php script I cannot compare.

Can anyone check whether searchreplace.php from tinymce is in any way related to searchreplacedb2.php, please!

Rubb July 25, 2017 at 10:45 pm • Reply

I using the new version and I used it all the time to change to URLs when I moving site or nice to change lot of the same text, but I delete it right after I done with it.
Am I safe?

David Coveney July 26, 2017 at 2:09 am • Reply

Apologies - I inadvertently had my comment on a sub-comment rather than the root - here goes again:

Hi all - I wrote the original script. Others both inside and outside the firm have taken it and run with it.

We warn people, several times over, that it's not designed to be left online. It's there for a developer who can't run command line tools on a webserver (common with clients) who needs to run a comprehensive Search/Replace across a database and from outside of WP. It's usually for migrations.

It isn't meant to be secure. It isn't meant to be left lying around. Your headline should be "If you leave this script lying around on a public facing webserver, you're probably already hacked."

To say it is insecure is correct. We've never suggested anything else. It is insecure by default. To suggest that we're risking our reputation in building and supplying a tool for other coders to use is complete nonsense. That's lying saying that all knives should be blunt in order to protect people from cuts and any knife maker supplying sharp knives is being irresponsible.

The very first paragraph on the download page states "Please read all instructions and familiarise yourself with the risks of using this tool first, downloading of this tool signifies your acceptance of the risks and problems associated with the script."

On the script's own page as it runs it says "DON'T FORGET TO REMOVE ME!"

So we're left with a problem... it's a free, GPL script designed to do a job for developers and those developers should have a good understanding of what they're up to or they should really not be using such a tool. You mustn't leave it simply lying around. Just don't. And if you're installing server side software without reading the instructions then there's only so much the industry can do to protect you.

If anyone is willing to sponsor further development to turn this into a script that's safe to leave lying around, then we can do so.

In my view the confusion here is a fundamental misunderstanding of GPL - it's there for developers to help other developers. It's not there for end users to just get free stuff with the entitlement baggage that comes with it.

I'm going to have a good think about what the best path is. If non-devs or inept devs are leaving this tool lying around and they think that's somehow our fault (as you imply) then it'll be in our best interests to simply remove the tool from general availability *unless* we can create a business model around it. So I'm going to have a good think and see what makes sense.

Stacy July 27, 2017 at 9:38 am • Reply

I happen to love this script and find it to work consistently, when some of the plugins that purport to do the same thing do not. I have managed to follow the directions to rename it during use and delete it after use, and have never yet been hacked. Ignore the naysayers, Mr Coveney; some of us are able to follow directions!

I wonder how many people who have been "hacked" because of not removing this script ALSO don't have the rest of the WordPress installation/plugins/themes updated? No code and no computer is "secure by default"; security is a multifaceted requirement and part of the requirement is taking the actions recommended by the developer of the software or system.

Lee Shields August 2, 2017 at 6:28 am • Reply

Hi David, thanks so much for creating Search and Replace, it's so much easier to use than messing around in phpMyAdmin, I just rename the folder, use the script while I do the migration, or moving to https etc, then hit the delete button. It's a great tool and I would NEVER think of it as a tool for end users. Thanks

Jaco July 26, 2017 at 2:59 am • Reply

I have a plugin called better search replace. Is this the tool you talking about?

David Coveney July 26, 2017 at 8:40 am • Reply

Hi all - I had my think.

I've now put the plugin behind a form where you have to acknowledge your awareness of the issues before you can download the script. Hopefully that helps educate more people that this isn't a tool to leave lying around. It has a very specific purpose and it's designed to make that purpose as quick and easy as possible. Many many developers use it regularly and I don't want to make *their* job slower or more difficult simply to rescue people who don't know what they're doing. It's a tool by developers, for developers.

The form, once completed, auto-emails you a download link, and it also offers to add you to an email list so we can alert people to changes and issues as they arise.

Thank you for raising the issue - I hadn't realised quite how many people who didn't know better were using the tool. I kind of assumed that anyone who was using something like this would be fully aware of the risks. Hopefully the changes help reduce the number of people being affected. It isn't our aim to make this the most successful tool or anything like that - it has some specific purposes and does them well. But it's a sharp tool and it'll hurt you if you use it incorrectly.

Mark Maunder July 26, 2017 at 8:45 am • Reply

Hi David,

Another thought is to provide instructions on how to create a .htaccess file that blocks use of the script unless you have a specific IP address or unless you pass basic authentication. That's actually really easy to do and one could either configure .htaccess to only throw up authentication for that script or you could recommend they put it in it's own directory and then provide auth for the directory. Just thinking out loud.

Mark.

Mark Maunder July 26, 2017 at 8:58 am • Reply

...and chatting to Brad about this he came up with another possibility. I'll paste it below:

Another technique I thought of would be for the script to require a separate file to exist containing a password hash, and if that file isn't there, don't allow use of the script. There could be a guided installation that generates the file and says "OK, now upload this file to the same place as searchreplacedb and you're all set."

He's also thinking out loud and I caught him as he's getting on a flight - but just wanted to share that thought with you asap.

Mark.

David Coveney July 26, 2017 at 9:20 am • Reply

It's that difficulty of balancing convenience over security. It's a developer tool - you're busy doing a migration - you can drop the script in, run it, delete it and leave in very short order.

I prefer making the script harder to download, so that the inept are less likely to use it, than to make it hard to use for the skilled.

I really don't think there's a perfect answer.

We very rarely use the script ourselves these days as we rarely use servers where we can't be running WP-CLI. But in our early days we knew what it was like to deal with consumer grade hosting that didn't let you do such things.

Mark Maunder July 29, 2017 at 2:42 pm • Reply

I'd strongly recommend adding authentication and authorization at the earliest opportunity.

Daniel Lo Nigro July 29, 2017 at 6:00 pm • Reply

> Another thought is to provide instructions on how to create a .htaccess file

More and more web hosts are using Nginx rather than Apache, where .htaccess files won't work. Even on Apache, it's generally recommended to edit the Apache config itself rather than using .htaccess files, as having .htaccess files enabled slows down the server a bit due to the disk I/O required to search for the .htaccess files.

Bret Weinraub August 2, 2017 at 9:44 am • Reply

I was just messing with this script on a test site, so I just dropped this into .htaccess before I got started:

order deny,allow
deny from all
allow from

Mark Maunder August 2, 2017 at 10:59 pm • Reply

You've omitted your own IP after 'allow from'.

Chris Astley August 1, 2017 at 5:18 am • Reply

Scripts like this I modify to include a simple line at the top to die; if not my static IP.
Common sense for a developer as you also wouldn't want a client to use this either.

Get the latest WordPress security updates and news

Sign up for WordPress security alerts, Wordfence product updates and security news via email.