Instances of WordPress installed on certain clusters of MediaTemple's GridServer [also called (gs)] were recently hit with an exploit that appended an external JavaScript to each post's content field, ultimately redirecting to redirecting to a TinyURL address, resolving to the domain http://www.qooglesearch.com.
MediaTemple asserts in a July 16, 2010 blog entry, which as of November 2012 had been removed from their site: "We do not believe that this is an infrastructure issue, but we are still investigating the root cause(s)."
I believe I have evidence to the contrary.
I noticed today my WordPress blogs had been hit by the Redirect Exploit. I followed the fix instructions and came across something fishy.
Before upgrading one of my old blogs from WordPress 2.5 to 2.6, I had made a full copy of the database. So I then had two identical databases up with different names. I switched the database name in my WordPress config and went along with the upgrade. So my WordPress 2.5 database lay dorment, without an active frontend to administer it.
I ran the fix code against my old WP 2.5 database, and found it had been injected with the exploit code, even without an active WordPress install pointing to it.
This is significant because most WordPress exploits are local to the installation itself, and likely do not affect installations on a host's entire network.
This leads me to believe the exploit was carried out as a result of a system-level security breach by obtaining a list of all databases on all compromised accounts, and running an UPDATE query to inject code into every WordPress database.
MediaTemple's head of support and a few sysadmin/security guys were nice enough to give me a call after I put out this tweet to discuss what I had found, and divulge a bit of what they know.
They believe someone possibly obtained a list of database credentials, then used those credentials to scan and inject code. They said they had already enacted some system changes to mitigate some security issues, and were in the process of re-architecting some aspects of the shared system.
I expect we will see more news from the MediaTemple crew about this exploit in the coming weeks.
To prevent further exploits, you should manually change the password of every database account on your (gs) account, and check that your /domains/ directory is not world-readable (chmod 755 750)
July 21, 7:50pm Update: A previous version of this article had info that could be interpreted as users having access to other users accounts on the system. That was not the intended message and the wording has been updated to reflect this change.
September 30, 2010 Update: Since this article, I have needed to remove malicious JavaScript from this blog two more times, each time with a slightly different-looking exploit code. The most recent exploit I discovered yesterday when a user reported Google was reporting my blog as hosting malware. Sadly, this was not limited to just my blog.
MANY domains on my MediaTemple grid-server account were found to be listed as hosting malware by Google. Even domains without WordPress installed. This points to a larger issue where either the server itself is insecure or a web application on the server (WordPress?) is being used as an attack vector to modify files on the filesystem.
2011 Update: I have since left MediaTemple's (gs) hosting and started hosting on a dedicated VPS. Surprise, none of my sites, this blog included, have not been knowingly exploited since.
comments powered by Disqus