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?

[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...

Should have used vsftpd

[sparkz]

Oh, the irony

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.

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: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?

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.