ProFTPD.org Compromised, Backdoor Distributed

Orome1 writes "A warning has been issued by the developers of ProFTPD, the popular FTP server software, about a compromise of the main distribution server of the software project that resulted in attackers exchanging the offered source files for ProFTPD 1.3.3c with a version containing a backdoor. It is thought that the attackers took advantage of an unpatched security flaw in the FTP daemon in order to gain access to the server."

Comments

Re:FTP

[kyrio]

I'm pretty sure the unpatched security flaw was the protocol itself. Plain text passwords FTW.

Anyone checking these source file changes?

[digitaldc]

Isn't there some type of review process for all changes? Or can you just go in and change things willy-nilly?

Maybe they need some more code oversight, just my opinion.

Re:Anyone checking these source file changes?

[Sockatume]

I've often wondered why there isn't a standard hash check built into browsers. If you store the hash and the file on different servers (cooperatively) then you greatly reduce the risk of this sort of attack. That said I suspect that the benefit is probably a lot smaller than the difficulty in establishing such a system.

Re:Anyone checking these source file changes?

[fuzzyfuzzyfungus]

I suspect that the real problem would be chicken-and-egg adoption issues. Anybody with competence in the right area could probably bang out a functioning prototype firefox plugin addressing either the cases of SSLed sites also being expected sign their binaries with their existing SSL setup, or the FOSSier case of developers signing with their GPG keys and posting MD5 hashes in approximately an afternoon.

Trouble is, unless broadly and swiftly adopted, people won't see the "this package is not cryptographically verified" message as being problematic in the slightest, if that is the case, the attacker can simply not sign, and nobody will care(the current situation on Windows, which offers cryptographic verification of installers before install is largely this way. Enough outfits, even fairly respectable ones, just don't bother, that the security gains are minimal, despite the mechanism being technically and mathematically sound). If you make the message scarier and/or harder to get around, people will just go with something that doesn't get in their way. Only if lack of signature was considered a shocking fault would anybody really be saved...

Architecturally and mathematically, the solution works just fine; but it fails on the critical adoption mass problem...

Re:Anyone checking these source file changes?

[jellomizer]

Open Source doesn't have a peer review process. Some projects might not not Open Source.

Only enough technically there isn't much difference between closed and open source software. They will still get security issues, bugs, and other problems.

Perhaps it is because GNU and other FOSS are distribution license not a technical guide or operational guidelines. I can produce crap and put it under whatever license I want and it will still be crap.

Now there will be the argument if I make crap and make it Open Source then someone else can see if an make it better. However it was crap then they would make their own or just not bother with your product. As if it was closed source no one would buy it.

Now if it was a good product (and got enough attention) other developers will flock to add stuff to it and make it better if it was open source. If it was closed source your product will sell you will make money and hire more developers to add to it so you can sell more or new versions.

Good or Bad software isn't from the license. It is from design of the system, the quality of the coding, how well it fixes a problem... The issue with the license is more about legal, funding, business model, personal beliefs etc...

Should have used vsftpd

[sparkz]

Oh, the irony

Re:Should have used vsftpd

[carlhaagen]

Well... VSFTPd has had its share of problems, too, y'know. Speaking of... it's actually currently suffering from an exploitable "feature" (as the author insists on calling it) that allows attackers to very rapidly and without restraint mine legit usernames from the host running VSFTPd. I reported this, along with patch, in 2007. Hole not plugged yet - 'coz it's a "feature".

Re:Should have used vsftpd

[SigmundFloyd]

Well... VSFTPd has had its share of problems, too, y'know. Speaking of... it's actually currently suffering from an exploitable "feature" (as the author insists on calling it) that allows attackers to very rapidly and without restraint mine legit usernames from the host running VSFTPd.

Not much use to an attacker, without the passwords. By your logic, you could deem it a security risk that on any Unix system the super-user is always called "root".

Re:Should have used vsftpd

[Anonymous Coward]

Well... VSFTPd has had its share of problems, too, y'know. Speaking of... it's actually currently suffering from an exploitable "feature" (as the author insists on calling it) that allows attackers to very rapidly and without restraint mine legit usernames from the host running VSFTPd. I reported this, along with patch, in 2007. Hole not plugged yet - 'coz it's a "feature".

Could you be more specific? The only thing remotely resembling what you're describing that I know of is that vsftpd used to respond differently to a good username/bad password combo than a bad username/password combo, thus revealing which usernames were valid. It did this because this vulnerability is part of the FTP specification--in order to fix this, you needed to violate the spec. vsftpd fixed this issue many years ago because they decided the spec was stupid and not worth following in this instance (i.e. it now requests a password for usernames that don't exist). Not sure about other FTP servers.

I follow vsftpd development very closely and know of no known/unaddressed weaknesses.

Re:Should have used vsftpd

[WraithCube]

Wrong... Answer this: which is more secure?

1) unknown 4-letter username + unknown 12 letter password

2) known 4-letter username + unknown 16 character password

Isn't this more a case of:

1) unknown 4-letter username + unknown 16 character password

2) known 4-letter username + unknown 16 character password

There's no reason why you should make the password on an unknown username less secure and no reason to leave a username like root or administrator for the botnets to take cracks at.

Quite.

[Spad]

To confirm their integrity, they are advised to verify the MD5 sums and PGP signatures of the downloaded files and compare them to that of the legitimate source tarballs.

Because the people who compromised your server and uploaded a trojaned version of your software would *never* think to upload their own MD5 sums and PGP signatures to match...

Re:Quite.

[bigjocker]

You should always host the MD5 or SHA hashes offsite.

Re:FTP

[Corporate Troll]

You'd be surprised... Recently I installed Joomla for someone, and they insisted on having FTP. Apparently FTP support is built-in to Joomla (I know not much about Joomla). I said "simply use sftp", but that was not acceptable. I did restrict the FTP server to trusted IP addresses though.

Re:FTP

[Megane]

How else are you going to upload files from Internet Explorer 6?

Re:FTP

[Rhaban]

People still use Joomla?

Dumb comment.

[Anonymous Coward]

And how, exactly, would the attackers sign the distribution files with the same private key the project uses?

Recursion fail?

[IDK]

If they use ProFTPD for hosting the code too, why wouldn't the Hackers just use that same exploit on that? Why do they need to insert another way in?

There's a backdoor in my backdoor.

[eyeball]

R E C U R S I O N

Funny

[Masterofpsi]

Funny, I was just trying to install ProFTP on Debian stable yesterday. Couldn't get it to work at all.

not on Debian stable

[orange47]

thankfully that fancy new version will be available from official repository for Debian stable in about 100 years or so..

Re:not on Debian stable

[Anonymous Coward]

thankfully that fancy new version will be available from official repository for Debian stable in about 100 years or so..

That newfangled FTP protocol is still pretty new to the Debian Stable folks.

Wait, what was the hole again?

[jonaskoelker]

resulted in attackers exchanging the offered source files for ProFTPD 1.3.3c with a version containing a backdoor. It is thought that the attackers took advantage of an unpatched security flaw in the FTP daemon in order to gain access to the server.

So instead of downloading an FTP server with a security hole, you could download one with... a security hole.

Re:FTP

[a_nonamiss]

FTP isn't secure, but it's got a very low overhead compared to sftp or smb. Still a very efficient way to send very large files over a trusted, reliable LAN. On a gigabit LAN, I get a significantly higher transfer speed than when using smb.

I'm not saying I'd put it in production over the Internet. It's crazy insecure and is a pain in the butt to set up on a firewall, but for fast, simple transfers on a LAN, it's the best protocol out there.

Re:FTP

[jimicus]

I have been asked on a number of occasions to set up an FTP server.

You would not believe the trouble I have had suggesting SSH/SCP - even from people who develop on Unix and use SSH to log in all day long. I've tried providing a web interface, I've tried providing a link to WinSCP, I've tried pre-installing WinSCP on the person's PC before it even goes on their desk.

In almost every case, it was pretty damn obvious that the person asking for an FTP server had already decided that they were going to have an FTP server, and would not even discuss the idea that there might be alternatives.

Re:FTP

[An ominous Cow art]

Maybe "Señor TWO" was already taken? :-)

Re:FTP

[Crudely_Indecent]

Plain text passwords

I'm pretty sure that's not the only way to use ProFTPD.

http://www.proftpd.org/localsite/Userguide/linked/config_ftpoverssh.html

Give me anything, just make it quick!

[Zero__Kelvin]

There is nothing I want to download quickly more than a hacked file that isn't the one I was expecting!

Wait, what?

[Arancaytar]

They used a security flaw that already existed in the FTP daemon to surreptitiously introduce a backdoor into the FTP daemon's source, evidently hoping it would be propagated? Why not just use the security flaw to attack whatever site they wanted to hit directly?