WordPress plug-in vulnerability could be used to steal database content

Dark Reading Staff, Dark Reading

November 2, 2011

4 Min Read

A vulnerability in an obscure WordPress add-on script that was discovered in August is currently being used to compromise more than 1.2 million websites -- and could be easily used to siphon data out of databases hosted on servers also hosting the compromised websites, security experts warned today.

Different than the many mass compromises of late that have been accomplished via SQL injection, this attack takes advantage of a local file inclusion (LFI) vulnerability that allows attackers to insert PHP shells onto Web servers that can be used as the jumping-off point for other attacks, including database hacks.

The vulnerability in question comes from the timthumb.php script, a photo-resizing utility used by many third-party WordPress plug-ins that allows hackers to write whatever content they point to as long as a few restrictions are met, says Mike Geide, senior researcher at Zscaler ThreatLabZ.

"For example, the utility might have as a check that you only pass it content from YouTube, but the check that it does will only make sure YouTube exists within the URL path, so you could create your own domain, youtube.com.evil.com, and it would pass that check, and then you could pass it phpshell.php," Geide says. A recent blog post from researchers with Sucuri Security showed how they were tracking infections from the vulnerability. A Google search today found 1.2 million sites affected by the infection.

According to Josh Shaul of Application Security Inc., this type of mass attack is different than a lot of the mass compromises we've seen this year, such as LizaMoon. "It's not like one of these SQL injection attacks where we're injecting some code into the database that's going to be run later," Shaul says. "It's really injecting some code onto the Web server that is going to be stored as a file and run later. The tie back to the database is now the attacker has this PHP code running on the Web server -- effectively in a trusted mode in a trusted location. And from there as an attacker, I've got that proverbial foothold on the network and can now take advantage of a connection to a database, get into that database, pull data, and use that database to navigate to other places on the network."

At the moment, the hole in TimThumb is currently one vulnerability popularly used to serve up the Black Hole exploit kit, according to reports from Avast earlier this week. But it could just as easily be used to exfiltrate database information and perpetrate other sweeping attacks.

"Remote shells are PHP files that, in essence, provide fairly complete remote control capabilities to anyone who knows the exact path to the PHP file on the server and navigates there with a browser," says Andrew Brandt, director of threat research for Solera Networks. "I gave a talk about remote shells and other malicious PHP at the RSA conference in San Francisco last year, and I've seen a lot of these. In essence, remote shells provide a lot of functionality: You can reconfigure the server; you can manipulate files and directories in the filesystem; you can run raw SQL queries on any database, or perform a number of "canned" queries to accomplish certain database tasks. "

According to Tal Beery, Web research team leader for Imperva, the LFI vulnerability in timthumb.php is a common way to exploit databases. Imperva says in October alone it found four different LFI vulnerabilities being used to this end: the Joomla YJ Contact us Component Local File Inclusion Vulnerability, CMSmini 0.2.2 Local File Inclusion, 1024 CMS 1.1.0 Beta force_download.php Local File Inclusion, and Ruubikcms v 1.1.0 (/extra/image.php) Local File Inclusion Vulnerability.

As for TimThumb, the utility's maker provided an update to fix the vulnerability in August, but clearly few people bothered to patch it.

"You've got to be incredibly vigilant, both from a knowing-what-you're-using perspective -- you can't just go out there and grab any random code -- and from the perspective of staying on top of patches and fixes," Shaul says.

These issues highlight the fact that database security is more than just patching and locking down the database itself.

"It's not the database itself, but it's everything else that plugs into it," says Mike Murray, partner for consultancy MAD Security. "It's the modular world we live in, and so if you're a DBA or a database person and you're worried about securing your database, you shouldn't be worried about securing Oracle or MySQL or the database itself. It's all of the things that you're allowing permission into the databases."

And that includes the plug-ins used within the software connecting into those databases. These are low-hanging fruit for hackers because often they're quickly written and infrequently reviewed for security.

"It used to be that I'd just allow my Web code, but now it's my Web code and all of the 15 other plug-ins that some guy in Kathmandu wrote in an afternoon and got integrated into some other plug-in. Your code control has just gone out the window, and you have no control over any of it," Murray says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

About the Author(s)

Dark Reading Staff

Dark Reading

Dark Reading is a leading cybersecurity media site.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights