It’s a follow up to my post about server-wide iframe injection attack where I asked for any information about that tricky hack. Thanks to my readers and administrators of infected servers I have some new information about it. Now I know how it works and what is infected, but still have no idea how hackers break into servers, so your input is welcome.
This post is a request for information.
This summer I come across some clearly infected servers where I can’t figure out how exactly the hack works and what should be done to clean them up and to protect other servers from similar hacks. So I decided to share my information about the issue and hope someone could shed some light on it.
Here we go »»
What can be even worse is storing user passwords in plain text.
Brian Kreb was recently shocked when his hosting provider sent him his password in plain text. He wrote a post about it and made a conclusion that it is quite a common practice among hosting providers and that “naming and shaming may be the only way to change” it.
But why do hosting providers save passwords in plain text? Maybe because most of them don’t invent anything and just rely on web hosting automation programs?
Today I came across an interesting attack that injects malicious scripts at the very bottom of existing .js files.
Update: at the bottom of this post you’ll find information about how a security hole in Plesk Panel was used to infect websites. Comments are also worth reading.
Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article. Information about the Plesk security issues are still can be found in the current post and comments.
The script (surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments ) looks like this:
Full source code can be found here
On Google diagnostic pages of infected sites you will currently see something like this
Malicious software is hosted on 2 domain(s), including ctonxidjqijsnzny .ru/, znycugibimtvplve .ru/.
I say “currently”, because the most interesting thing about this script is the built-in domain name generator.
Foks, a frequent contributer to my investigations, recently pointed me at an interesting black hat SEO campaign where thousands of hacked WordPress blogs and Joomla sites were used to create doorways promoting online stores selling various “slimming pills” and fake luxury goods.
During the last few years I saw many attacks where cyber criminals created large spammy sites in subdirectories of hacked legitimate sites. It’s an easy way to create millions of doorway pages on thousands of established domains with good reputation for free (owners of hacked sites pay for hosting, bandwidth and domains) — typical parasitic behavior. Webmasters normally only visit pages they created themselves and rarely check what happens in subdirectories so they may not notice spammy sections for months. Sometimes such sections may be significantly larger than legitimate sections of hacked websites and attract much more search traffic.
The back end of such rogue sections is usually some doorway generating script along with rewrite rules in .htaccess or a simple blogging engine like FlatPress that doesn’t require a database. The only requirement of such solutions is PHP so they will work on most websites.
However this time spammers chose WordPress as a back end for their doorways. After all, if they hack a WordPress blog, the server is guranteed to be compatible with WordPress and all they need to do to install a new instance is get MySQL password from existing wp-config.php and chose a different table prefix for their WordPress database.
Here’s how the attack works »»
Most WordPress bloggers know the “Always keep your WordPress blog up-to-date” mantra. To make upgrades painless, WordPress developers introduced the “Automatic Update” features in version 2.7. A blog admin only needs to visit the “Update WordPress” page (Tools -> Update) and click on the “Update Automatically” button. That’s it! Easy!
Sometimes I see how webmasters misinterpret the importance of upgrades for WordPress security. They expect that if they upgrade a hacked blog, it will immediately become clean and secure. Unfortunately it doesn’t work this way. Upgrades can only clean core WordPress files, leaving backdoors, infected themes, plugins and database records intact. That’s why it is important to clean up your site before the upgrade.
Moreover, a few days ago I came across a new massive infection (more than 1,000 currently known infected blogs) that hijacks the “Automatic Update” feature and makes it the event that triggers blog re-infection.
A few days ago I investigated a hack where the following script was injected into web pages:
<sc ript src="hxxp://www .copytech .lu/js/java.js"></script>
The script was at the very top of the HTML code and in the middle of the page. It was a WordPress site so I suggested to check the index.php and theme files for the malicious code.
The topmost script was indeed in the theme’s index.php file. But theme files didn’t contain the script that I found in the middle of web pages’ HTML code.