Slashdot Mirror
Malicious PhpMyAdmin Served From SourceForge Mirror
An anonymous reader writes with a bit of news about the compromised download of phpMyAdmin discovered on an sf.net mirror yesterday: "A malicious version of the open source Web-based MySQL database administration tool phpMyAdmin has been discovered on one of the official mirror sites of SourceForge, the popular online code repository for free and open source software. The file — phpMyAdmin-3.5.2.2-all-languages.zip — was modified to include a backdoor that allowed attackers to remotely execute PHP code on the server running the malicious version of phpMyAdmin."
The Sourceforge weblog has details. Someone compromised a mirror (since removed from rotation of course) around September 22nd. Luckily, only around 400 people grabbed the file before someone caught it.
They should had md5'd files after downloading.
It's open source so I'm sure all the users did a code review and found the problem. This is why open source is more secure and less buggy than closed source software.
Is this 1998? Was the malicious file found on the world wide web?
I think someone's head is in the clouds at the moment what with the recent buyout of sourceforge, slashdot et al. I'm with a big ol' (12 year) open source project on Sourceforge and it's going through the migration procedure currently to the new Sourceforge look and feel - lots of problems, lots of broken stuff, unhappy admins and developers and slow response to tickets.
There are plenty of alternatives out here now for the open source types to host their code. It might be time to start thinking about exit strategies..
to save time and the virus was hidden in it?
I don't have any frenids either.
What's a frenid again?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Anyone who understands how security works would consider phpMyAdmin's very existence on a server to be a security hole.
Local GUI client + ssh tunnel ftw.
TODO: Something witty here...
I used to work in a Managed Hosting department, and customers would insist on having this piece of crap on the server. I hated it because there was always some vuln version that they ABSOLUTELY had to have. Finally a new exploit came out for a current version(at the time), and we had two compromises... Then we banned it across the entire customer base. There are too many alternatives to use this piece of garbage. However I suggest insisting your users run something on their local client side and not on your server... eg: heidisql, sequel pro, etc. So it doesnt surprise me at all that this occurred. LEARN YOUR LESSON ALREADY PEOPLE!
A widely used web package has a backdoor inserted.
Scary.
One of the regional mirrors of the largested software respository containing tens of thousands of projects is either hacked or was a plant from the start.
Scarier.
The backdoor code looks to be the work of someone who learned PHP on Monday.
Scariest.
Honestly, the only way it could have been more obvious is if the file was called backdoor.php. There was no attempt made to disguise the location or what the code was doing which is why it got caught so quickly. A complete amateur got caught with control over a chunk of Sourceforge downloads. In computer security when you find a breach you don't just close the obvious point of entry, you have to take a big step back and seriously ask 'what else was compromised'. In this case the big question is who else.
If this clown could do it and didn't get caught until an end user saw the stupidly obvious file and its stupidly obvious code (as opposed to a server log or other Sourceforge audit turning it up) what are the competent hackers up to. Real backdoors are blended into the existing code instead of being added as a seperate file. Real backdoors are designed to be hidden from casual inspection instead being completely obvious in their function and 'I don't belong here status'. Really good backdoors are designed to not look like intentionally malicious code even after they are found (ex. the wait4 backdoor attempt in the Linux kernel was pretty good, it got caught because the CVS hack used to insert it in a regional CVS mirror was flawed in several ways that raised alarms).
So, what kind of security/procedure/audit could have been in place, needs to be in place, so that something like this will raise an alarm even when the hacker isn't the most incompetent backdoor author in history? What kind of audit is needed to be sure it hasn't already happened?
of course is, should they use the backdoor to warn the users?
I have used phpmyadmin while learning about servers/web hosting (on my only computer to experiment) and while dealing with the Gallery php software on a more recently hosted site (not on my computer), so I have a general idea of what it does and how to use it (as basic as it gets like backing up DBs).
My question is when the backdoor gives full access to the hacker, what is the extent of compromise? Does it give you all data but you cannot read the passwords ? Do you have the ability to decrypt passwords by gaining root access with this or is the data still protected?
Forgive my ignorance
Does anyone put a phpmyadmin open to the world? Not just passworded but on a port that is firewalled off from all but a set of trusted ips???
I guess it has PHP in the name so probably some idiots do.
The backdoor was basically an eval that ran anything posted to it (according to the Ars article posted up thread). On my web host, Suhosin is enabled by default, and setup to block eval from ever running.
I.e. Even if I had installed this bad version of PhpMyAdmin, I would not have anything to worry about with regards that eval statement. So, security hey. It's hard, but not that hard.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
The parent has a point. It should be made clear that people destroying other people's data actually are sick fatass losers.
How would you know which md5 hash was correct?
OK, maybe I'm paranoid, but I usually get the download file and the MD5 from separate sources. Ideally the MD5 is from the home site of the project rather than one of its mirrors.
This is a reason why I generally avoid using mirrors.
As an alternative, one can use phpMiniAdmin. Way smaller, with fewer places to hide malicious code. Also, being less complicated than phpMyAdmin, it is easier to get it running.
There, I fixed it for you. You're welcome.
Not so much PHP (although every function is broken in some way), but the fact that any n00b can pick it up and start "programming." Without a harsh feedback loop, poor coding practices become calcified and lead to the massive security holes you've observed.
The beauty and curse of PHP is that its default fail state is to act as if nothing bad happened. This keeps unskilled, sloppy n00bs from getting so discouraged with the "NO YOU CAN'T FARKING ASSUME null AND false ARE THE SAME THING, DUMMY!" error messages that they find Something Else To Do like become Energy Meter Readers or Sportscasters or Tiger Food.
That is why PHP sucks.
Yeah, right.
I am surprised that the OpenSSL hole in Debain didn't cause people to leave Debain in droves. That's why I use CentOS on my servers now, not because I like it more than Debian, but because I cannot trust the Debain project allowing incompetent teenagers to work on core system security libraries. This will have to happen more than once for people to question sourceforge over their security practices.