Questions abound as malicious phpMyAdmin backdoor found on SourceForge site

Secret code added to the package gives attackers the ability to hijack servers.

A screenshot of a system containing a malicious backdoor that was snuck into the open-source phpMyAdmin package. Researchers said the file date may be fraudulent.

Developers of phpMyAdmin warned users they may be running a malicious version of the open-source software package after discovering backdoor code was snuck into a package being distributed over the widely used SourceForge repository.

The backdoor contains code that allows remote attackers to take control of the underlying server running the modified phpMyAdmin, which is a Web-based tool for managing MySQL databases. The PHP script is found in a file named server_sync.php, and it reads PHP code embedded in standard POST Web requests and then executes it. That allows anyone who knows the backdoor is present to execute code of his choice. HD Moore, CSO of Rapid7 and chief architect of the Metasploit exploit package for penetration testers and hackers, told Ars a module has already been added that tests for the vulnerability.

The backdoor is concerning because it was distributed on one of the official mirrors for SourceForge, which hosts more than 324,000 open-source projects, serves more than 46 million consumers, and handles more than four million downloads each day. SourceForge officials are still investigating the breach, so crucial questions remain unanswered. It's still unclear, for instance, if the compromised server hosted other maliciously modified software packages, if other official SourceForge mirror sites were also affected, and if the central repository that feeds these mirror sites might also have been attacked.

"If that one mirror was compromised, nearly every SourceForge package on that mirror could have been backdoored, too," Moore said. "So you're looking at not just phpMyAdmin, but 12,000 other projects. If that one mirror was compromised and other projects were modified this isn't just 1,000 people. This is up to a couple hundred thousand."

An advisory posted Tuesday on phpMyAdmin said: "One of the SourceForge.net mirrors, namely cdnetworks-kr-1, was being used to distribute a modified archive of phpMyAdmin, which includes a backdoor. This backdoor is located in file server_sync.php and allows an attacker to remotely execute PHP code. Another file, js/cross_framing_protection.js, has also been modified." phpMyAdmin officials didn't respond to e-mails seeking to learn how long the backdoored version had been available and how many people have downloaded it.

Update: In a blog post, SourceForge officials said they believe only the affected phpMyAdmin-3.5.2.2-all-languages.zip package was the only modified file on the cdnetworks mirror site, but they are continuing to investigate to make sure. Logs indicate that about 400 people downloaded the malicious package. The provider of the Korea-based mirror has confirmed the breach, which is believe to have happened around September 22, and indicated it was limited to that single mirror site. The machine has been taken out of rotation.

"Downloaders are at risk only if a corrupt copy of this software was obtained, installed on a server, and serving was enabled," the SourceForge post said. "Examination of web logs and other server data should help confirm whether this backdoor was accessed."

It's not the first time a widely used open-source project has been hit by a breach affecting the security of its many downstream users. In June of last year, WordPress required all account holders on WordPress.org to change their passwords following the discovery that hackers contaminated it with malicious software. Three months earlier, maintainers of the PHP programming language spent several days scouring their source code for malicious modifications after discovering the security of one of their servers had been breached.

A three-day security breach in 2010 on ProFTP caused users who downloaded the package during that time to be infected with a malicious backdoor. The main source-code repository for the Free Software Foundation was briefly shuttered that same year following the discovery of an attack that compromised some of the website's account passwords and may have allowed unfettered administrative access. And last August, multiple servers used to maintain and distribute the Linux operating system were infected with malware that gained root system access, although maintainers said the repository was unaffected.

Promoted Comments

This could be damaging to a few people. I know that every few days, some chinese script kiddie scans my site for every version of phpMyAdmin released. I don't have phpMyAdmin. And I don't use MySQL. Or PHP.

So how wide open was this back door? If it can execute code that code will normally be executed as the apache user, not root, and if SELinux is running at least in targeted mode (as it should) then the things that the attacker can do should be pretty minimal, no?

Or is the attack not just a backdoor but also an elevation exploit in PHP?

Based on a quick looksie, it's about as simple and straightforward as a PHP backdoor can possibly be. It can't do anything a normal PHP source file can't do in your installation. But there's usually a lot a PHP file can do - think databases.

When I heard there was a phpmyadmin problem I kinda assumed it would have been the devs who screwed up, but it looks like it was not the fault of anyone on the phpmyadmin team; it could have been any package on that server which was targeted, and indeed they need to very very carefully look for more.

I don't get why all the comments are about phpMyAdmin - the same thing could have been done to any PHP script such as say, SugarCRM. If you're going to bother doing a hack like this you may as well go for something popular.

There is no hole in phpMyAdmin behind this. There is, evidently, a hole in sourceforge's security. The comments relating to checking hashes are the only ones that makes any sense, and they should compare checksums across all the packages it's hosting before wiping it completely. SF's been dismal for years; I've moved everything to GitHub which is far more effective at fostering a community spirit.

Unfortunately I wouldn't be able to see HeidiSQL, having already stabbed my eyes from having had to use Windows. I've tried about 20-odd desktop MySQL apps on numerous platforms, but have never liked any (not least because they usually require external MySQL access, something that web-based tools don't need), and I always end up back in a terminal.

45 Reader Comments

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I'm not going to say that phpMyAdmin doesn't make things easier, but *database administration is not something that everyone should be doing.* Making it seem easy is only a liability, choice of tools aside.

Even if the tool is perfectly secure, many of the things you can do with it aren't "safe". Sure, you can restrict those unsafe actions with MySQL permissions. But the more you restrict, the less valuable phpMyAdmin becomes. All they probably "need" is SELECT access. There are other ways to give that, like some of the MySQL GUI tools.

I should actually verify those SHA1 hashes of packages I download. That's why many open-source projects distribute the package hashes with the downloads, after all - it's to detect tampering like this.

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I would much rather risk security attacks than have to clean up the database after every malformed command-line SQL query.

So how wide open was this back door? If it can execute code that code will normally be executed as the apache user, not root, and if SELinux is running at least in targeted mode (as it should) then the things that the attacker can do should be pretty minimal, no?

Or is the attack not just a backdoor but also an elevation exploit in PHP?

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I would much rather risk security attacks than have to clean up the database after every malformed command-line SQL query.

Yessir. Like it or not, lots of people that don't know what they're doing use MySQL, PHP, and a plethora of other webby stuff. And depending on what your job is, it's a requirement to enable these folks whether you like it or not.

On the bright side, I'm sure many OSes, like FreeBSD do have a package/ports system that verifies downloaded software against a stored hash.

And speaking of best practices, this hack is not useful to attackers if you have another layer protecting your install (restrict based on IP if only your internal people need to reach it, restrict with http-auth if outside users need it, etc.).

So how wide open was this back door? If it can execute code that code will normally be executed as the apache user, not root, and if SELinux is running at least in targeted mode (as it should) then the things that the attacker can do should be pretty minimal, no?

There are plenty of environments (SELinux or not) where having full run of a box as the httpd user will let you do plenty of damage. Think about a typical hosting environment where all the sites have files owned by a single UID and that UID is the httpd user... Then think about how wide open some people leave overrides for htaccess files.

This isn't automatic rooting, but I think someone attacking a site these days is looking for a place to park some bots, serve malware, serve phishing pages, and send spam/phish email.

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I would much rather risk security attacks than have to clean up the database after every malformed command-line SQL query.

Rather than, say, restore the DB after someone got an itchy finger "playing" with their phpMyAdmin during lunch time?

Users (and PHBs) will be users, no reason to give them even *more* options to screw up.

So how wide open was this back door? If it can execute code that code will normally be executed as the apache user, not root, and if SELinux is running at least in targeted mode (as it should) then the things that the attacker can do should be pretty minimal, no?

Or is the attack not just a backdoor but also an elevation exploit in PHP?

Based on a quick looksie, it's about as simple and straightforward as a PHP backdoor can possibly be. It can't do anything a normal PHP source file can't do in your installation. But there's usually a lot a PHP file can do - think databases.

When I heard there was a phpmyadmin problem I kinda assumed it would have been the devs who screwed up, but it looks like it was not the fault of anyone on the phpmyadmin team; it could have been any package on that server which was targeted, and indeed they need to very very carefully look for more.

This could be damaging to a few people. I know that every few days, some chinese script kiddie scans my site for every version of phpMyAdmin released. I don't have phpMyAdmin. And I don't use MySQL. Or PHP.

I would much rather risk security attacks than have to clean up the database after every malformed command-line SQL query.

Rather than, say, restore the DB after someone got an itchy finger "playing" with their phpMyAdmin during lunch time?

Yes. Absolutely yes. While there are people who will meddle with a database, they are less rare than people who make typos (every human being who has ever touched a keyboard). The people who meddle with the database can meddle through a command line, so giving them a UI simply eliminates one potential vector for errors. Of course, someone who's incapable of recognizing that elementary distinction probably shouldn't have any authority over other peoples' workflows.

I'm not going to say that phpMyAdmin doesn't make things easier, but *database administration is not something that everyone should be doing.* Making it seem easy is only a liability, choice of tools aside.

Even if the tool is perfectly secure, many of the things you can do with it aren't "safe". Sure, you can restrict those unsafe actions with MySQL permissions. But the more you restrict, the less valuable phpMyAdmin becomes. All they probably "need" is SELECT access. There are other ways to give that, like some of the MySQL GUI tools.

That is why in my DB admin job (they call me an 'analyst') We use only tools given to us and approved by upper management. While I believe this is NOT The best approach in our shop, at least I won't be blamed if something goes wrong with a tool we are using.

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I would much rather risk security attacks than have to clean up the database after every malformed command-line SQL query.

Rather than, say, restore the DB after someone got an itchy finger "playing" with their phpMyAdmin during lunch time?

Frankly, yes.

Although I generally don't find people using it out of boredom during lunch, more like following some tutorial about how to fiddle with some WP installation or something.

In my experience, novice users tend to do much more damage with a command line (be it a login shell or a sql shell) than a GUI. I say this having been responsible for maintaining public shell servers since 1997 or so... we had a mix of users - some would run tin or trn to fetch all their usenet binaries, then hang up the modem and dial back in without ppp/slip (we supported direct login to the shell box over dialup) and send all the booty down using "sz" - they didn't want 'all that ppp overhead'. I still have a handful of people around today. Some can't do anything but login and type "pine" - those are the ones you have to watch out for.

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I would much rather risk security attacks than have to clean up the database after every malformed command-line SQL query.

Rather than, say, restore the DB after someone got an itchy finger "playing" with their phpMyAdmin during lunch time?

Frankly, yes.

Although I generally don't find people using it out of boredom during lunch, more like following some tutorial about how to fiddle with some WP installation or something.

In my experience, novice users tend to do much more damage with a command line (be it a login shell or a sql shell) than a GUI. I say this having been responsible for maintaining public shell servers since 1997 or so... we had a mix of users - some would run tin or trn to fetch all their usenet binaries, then hang up the modem and dial back in without ppp/slip (we supported direct login to the shell box over dialup) and send all the booty down using "sz" - they didn't want 'all that ppp overhead'. I still have a handful of people around today. Some can't do anything but login and type "pine" - those are the ones you have to watch out for.

Heh. Taking me back there a little bit - sz! And usenet. I was a kid but damned if I can't remember those days...

Which is why I fight tooth and nail to eliminate these things. My boss *loves* phpMyAdmin. Webby interface, easier than terminal mysql? Awesome.

The problem is, every little thing you add increases the attack surface. So now we have *two* things to worry about: mysqld and phpMyAdmin. Nevermind the usual stuff that interacts with the DBs (password security, webapps, firewall rules, etc.) And when stuff like this happens... it's got nothing to do with keeping up with updates (my job) or an appropiate deployment strategy (also my job) or best practices (everyone's job).

I didn't know it was possible for anyone to actually like phpMyAdmin. I thought the only reason it was still around was because hosting companies force it on unwitting clients. The interface is just horrid. Introduce your boss to HeidiSQL. So much more powerful, far easier to use, and it won't make you want to stab your eyes when you look at it.

I guess I'm a bit baffled by why automated software isn't routinely used to check that the md5 (or a better cryptographic hash algorithm) checksums across all official mirrors match the master source repository. It wouldn't even need to be compute intensive, since most download sites precompute an md5 hash for you.

I used to love sourceforge, but since their website went to shit (anyone who used sourceforge years ago, knows what I mean) it just seems a little less trustworthy.

++I'm particularly concerned by the number of projects that don't post any kind of source code. SF should be deleting these projects if they don't upload the source within an hour after uploading the binary.

I have flagged several of these projects, but haven't seen any evidence that SF did anything about them. I believe this makes SF extremely untrustworthy and they are no longer my "go to" site for FOSS.

And this is why you don't just blindly implement open source anything, unless you have the expertise and staff on hand to check it all first.

What? That doesn't make any sense. The fact that this is open source is the reason why the backdoor was found so quickly. If it weren't open source, you couldn't even "check it all first" yourself in the first place.

So how wide open was this back door? If it can execute code that code will normally be executed as the apache user, not root, and if SELinux is running at least in targeted mode (as it should) then the things that the attacker can do should be pretty minimal, no?

Or is the attack not just a backdoor but also an elevation exploit in PHP?

You mean code the apache user can execute like "Select * From Customers Inner Join SavedCreditCard on Customers.CustomerID = SavedCreditCard.CustomerID;"?

I guess this calls for modifying my apt repos and all software repos for that matter to only use the original site, not any of the mirrors...

Not really ... Debian and its derivatives sign all the packages anyway, so your package manager will warn you immediately if the package isn't officially signed and with the expected hash.

And, you'll never really know whether the distribution maintainer who built the package actually built it from a "clean" source unless you go through all their patches and changelogs and rebuild it yourself using apt-src and apt-build. (which is possible, for sure, and often useful is you're doing deep debugging)

I don't get why all the comments are about phpMyAdmin - the same thing could have been done to any PHP script such as say, SugarCRM. If you're going to bother doing a hack like this you may as well go for something popular.

There is no hole in phpMyAdmin behind this. There is, evidently, a hole in sourceforge's security. The comments relating to checking hashes are the only ones that makes any sense, and they should compare checksums across all the packages it's hosting before wiping it completely. SF's been dismal for years; I've moved everything to GitHub which is far more effective at fostering a community spirit.

Unfortunately I wouldn't be able to see HeidiSQL, having already stabbed my eyes from having had to use Windows. I've tried about 20-odd desktop MySQL apps on numerous platforms, but have never liked any (not least because they usually require external MySQL access, something that web-based tools don't need), and I always end up back in a terminal.

I should actually verify those SHA1 hashes of packages I download. That's why many open-source projects distribute the package hashes with the downloads, after all - it's to detect tampering like this.

SourceForge ... hosts more than 324,000 open-source projects, serves more than 46 million consumers, and handles more than four million downloads each day.

Whether or not people use it for new projects, there are hundreds (thousands?) of very useful and heavily-used projects supported by SF. Not being able to trust what you're downloading is a very big deal.

Even when there's nothing happening, they just keep coming back! I'm a maintainer of a very popular PHP project that moved to Google Code and GitHub 2 years ago, but it's still getting > 5k downloads a day on SF, despite there being nothing new in that long. Some people just seem to love buggy, unmaintained, obsolete code!

Even when there's nothing happening, they just keep coming back! I'm a maintainer of a very popular PHP project that moved to Google Code and GitHub 2 years ago, but it's still getting > 5k downloads a day on SF, despite there being nothing new in that long. Some people just seem to love buggy, unmaintained, obsolete code!

I don't use SF as a developer so I don't know the ins-and-outs, but it seems to me that it falls to the maintainer of a project (i.e. you) to close/wrap-up/whatever the project and direct people to the new repository to prevent this. Am I missing something?

...Unfortunately I wouldn't be able to see HeidiSQL, having already stabbed my eyes from having had to use Windows. I've tried about 20-odd desktop MySQL apps on numerous platforms, but have never liked any (not least because they usually require external MySQL access, something that web-based tools don't need), and I always end up back in a terminal.

A terminal to manage MySQL data? Useful when it's urgent and you only have putty on your phone (as it has saved my skin several times), but for day-to-day use, it's like poking your eye out!

And this is why you don't just blindly implement open source anything, unless you have the expertise and staff on hand to check it all first.

What? That doesn't make any sense. The fact that this is open source is the reason why the backdoor was found so quickly. If it weren't open source, you couldn't even "check it all first" yourself in the first place.

Conversely, if it wasn't open source, the back door wouldn't have been so straight forward to implement.

I'm a maintainer of a very popular PHP project that moved to Google Code and GitHub 2 years ago, but it's still getting > 5k downloads a day on SF, despite there being nothing new in that long. Some people just seem to love buggy, unmaintained, obsolete code!

I'll presume you updated the description and homepage link on sourceforge to tell people the new address, maybe even added a nice big "DO NOT DOWNLOAD THIS!"

Spoiler: show

Or maybe you're just having a bit of fun with the exaggerations... when searching sourceforge for php language projects, sorting by most popular, the only one that only comes close to 2y old and 5k/day downloads this week is Appserv whose docs and non-sourceforge webpage say nothing about any other hosting (though there is a completly empty site at https://code.google.com/p/appserv/&#41;

So how wide open was this back door? If it can execute code that code will normally be executed as the apache user, not root, and if SELinux is running at least in targeted mode (as it should) then the things that the attacker can do should be pretty minimal, no?

Or is the attack not just a backdoor but also an elevation exploit in PHP?

You mean code the apache user can execute like "Select * From Customers Inner Join SavedCreditCard on Customers.CustomerID = SavedCreditCard.CustomerID;"?

If you half-ass together something like this and store it all in plaintext on the open web, you're going to have a whole lot of 'splainin to do - to your customers, Visa and Mastercard, your bank, the police, etc, etc. Sure, you'll be kicking yourself for not checking that hash...from the poor house, when your general failure at life has caught up with you.