Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Open Source Security Software News IT

ProFTPD.org Compromised, Backdoor Distributed 152

Posted by CmdrTaco from the scary-world-we-live-in dept.
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."
This discussion has been archived. No new comments can be posted.

ProFTPD.org Compromised, Backdoor Distributed More

ProFTPD.org Compromised, Backdoor Distributed

Comments Filter:

  • Anyone checking these source file changes? (Score:4, Insightful)

    by digitaldc ( 879047 ) * on Thursday December 02, 2010 @08:46AM (#34416222)
    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.

    • 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? (Score:4, Insightful)

        by fuzzyfuzzyfungus ( 1223518 ) on Thursday December 02, 2010 @09:00AM (#34416400) Journal
        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...
        • And previous to recent changes people didn't see a problem with a lack of that color deal in the URL bar of their browser showing that the cite was being access via SSL either. The way you handle that is education, and things like that which are simple are more likely to be used. The real problem with that is if an attacker manages to screw with the hash function to support an exception for certain files.
        • That and you need to pay a fair chunk of change to get your app signed. (Though it's hard to see a reasonable way around this)
          • As with SSL, you run against the fundamental problem of mechanisms that attempt to both verify and identify...

            It costs money to identify people/corporate entities, make sure they are who they say they are, etc. Therefore, nobody is going to issue a cryptographically incontrovertible statement about who you are for free. However, there are lots of people who really just want the crypto, not the ID, which means that(in absence of some sort of strong central control, like a state or Microsoft) you'll see st
      • Cool idea.
      • They never are on separate servers though, or very rarely - so naturally if someone can upload a compromised source tar, they can also upload the appropriate checksum.

    • I guess the question is how exactly did the CVS repository get compromised? I imagine there's only a set number of people with commit access, and no one who works on it would willingly compromise it.

      • Re: (Score:2)

        by daid303 ( 843777 )

        Login as root, edit the CVS files directly. Not that hard really. With a bit of trickery you can even make it look like a legit commit, or something that has always been there.

    • 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 Sour

      • To be fair ProFTPD may or may not be crap; I remember back in the day it was pretty good. I do know it's a bit silly to use the same software as you use to distribute your own software, for this very reason (it's why the OpenBSD guys use Solaris).

        • (it's why the OpenBSD guys use Solaris).

          Is that that why Microsoft ran Hotmail on Linux for so many years? ;)

          • No, it ran on FreeBSD. And it ran that way when they bought it. Converting it to run on Win NT 4 took some time and many more boxes. They couldn't get it to run on win NT reliably enough until win 2000 was released.

      • However it was crap then they would make their own or just not bother with your product.

        The test for code quality is not usually boolean. If someone has put work into something, and they have a lot of the basics in, or they've got a lot of the complex logic in place, but have a bad UI, then something is worth building on or improving. Yes, occasionally you run into code where the quality is so low it's not worth using, but most of the time you can use some of the work that was done.

  • Should have used vsftpd (Score:5, Funny)

    by sparkz ( 146432 ) on Thursday December 02, 2010 @08:47AM (#34416240) Homepage
    Oh, the irony
    • 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".

      • 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".

        • Actually, that is a security risk, currently mitigated on modern systems by not giving the root account a password, and only allowing root access through tools like sudo -- so in order to root a system, first you need to figure out which account is mine, only then can you break it.

        • Pretty real security risk--first thing any good sysadmin does is disable remote access to known account names like "root" and "administrator"--you greatly reduce your attack surface by doing so. Take a look at ssh access logs and see how many denied attempts there were for "root".

        • By your logic, you could deem it a security risk that on any Unix system the super-user is always called "root".

          The UNIX super user is not always called root, and it's actually quite good practice to change it. It can have any name, it just has to have UID 0. On FreeBSD systems, there are (by default), two login names with UID 0: root and toor. It is fairly common to set the shell for the toor user to the administrator's favourite shell, so that it can be used more conveniently, while the root shell is always something in /bin so it can be used when /usr/local is not mounted.

          Most systems disable remote root lo

      • Re: (Score:3, Interesting)

        by 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

        • Mod parent up. Unless the GP can provide the link of the bug report where it's not been acknowledged or fixed I'd say this has been called out.

  • Quite. (Score:5, Insightful)

    by Spad ( 470073 ) <slashdot@Nospam.spad.co.uk> on Thursday December 02, 2010 @08:49AM (#34416264) Homepage

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

    • You should always host the MD5 or SHA hashes offsite.

      • Yes. Offsite at a necessarily public URL on a system that, for administrative ease, is configured identically. That will definately be worth the effort.

        And if it's not identically configured you're looking at a lot of extra expense to provide platform diversity for a file that A) most users (particularly those interested in downloading an FTP server) will never use and B) still doesn't provide any reliable guarantee that the hash wasn't regenerated as part of the attack.

        Cryptographic signatures from keys no

    • Dumb comment. (Score:5, Informative)

      by Anonymous Coward on Thursday December 02, 2010 @08:58AM (#34416364)

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

      • Steal it, because it's hosted on the same server?
        Okay, it probably isn't, in this case, but the weakest link is always the one made of meat.
        (I mean seriously, have you ever tried making a chain of meat? I got bacon to hold a few pounds once, but then I gave in and ate it. :()

    • Because generating PGP signatures without the private key is so trivial.

    • Re: (Score:2)

      by T.E.D. ( 34228 )
      If you already have a working FTP server and are just looking to take the latest update, wouldn't it be more sensible to just do a source diff before you compile? Not only would that show you the trojan almost instantly, but it would also show you if there are any other changes to important bits of functionality that might cause you trouble. The latter seems far more likely.
  • 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?

  • Is this news?

    Over the years not once I was going through bunch of ftpd picking one to install on my Linux box, all of them, ProFTPd included, had a ... front door wide open: anonyms had pretty much unlimited read access to everything.

    And obviously all of the ftpds were refusing auth users by default. On the few occasions I need the FTP for my LAN server (mostly for Windows clients) it was such a royal pain to setup properly ... while welcoming all anonyms from everywhere to copy all the stuff all the

    • Over the years not once I was going through bunch of ftpd picking one to install on my Linux box, all of them, ProFTPd included, had a ... front door wide open: anonyms had pretty much unlimited read access to everything.

      Everything inside the chroot'd home, sure. If you were giving anonyms read access to the root, you were doing it wrong.

      • If you were giving anonyms read access to the root [...]

        I wasn't - that was default setup of pretty much all fptds I have seen in RH and Debian.

        • You have to take responsibility for the actions of your contractors. Some of us like to vet config files and don't trust anyone who is not us.

        • Re: (Score:2)

          by surgen ( 1145449 )

          I wasn't - that was default setup of pretty much all fptds I have seen in RH and Debian.

          Default configuration found inadequate. Film at 11.

        • vsftpd [beasts.org] has always been excellent for me--you can limit the anonymous user in a number of ways, and by default it's extremely locked down (may not even be enabled at all, can't remember, but if it's disabled, even when you enable it it's still very locked down).

    • Re: (Score:2)

      by Hatta ( 162192 )

      If you have files that you don't want the world to see, why are they world readable? Properly set your UNIX permissions and the settings of the FTP server don't matter.

    • Re: (Score:2)

      by Alioth ( 221270 )

      FTP ought to be deprecated already (and years ago). sftp/scp has been much better for authenticated users, and has existed for a while now, and has things like chrooted sftp/scp only implementations if you need to keep users separated. It has clients available on pretty much all operating systems. HTTP is better for anonymous users. FTP with the requirement for two connections to be opened (one on a random port) adds complexity to firewalls.

    • And how exactly are you supposed to authenticate users on FTP? The protocol, barring incompatible extensions, doesn't allow for anything but plain text. It should be never used except for tightly controlled environments and if you have it tightly controlled, why won't you use something sane and secure?

      With non-anonymous FTP being a bad idea, having anonymous access as the default makes sense.

  • There's a backdoor in my backdoor. (Score:3)

    by eyeball ( 17206 ) on Thursday December 02, 2010 @09:02AM (#34416422) Journal

    R E C U R S I O N

  • Funny, I was just trying to install ProFTP on Debian stable yesterday. Couldn't get it to work at all.
  • thankfully that fancy new version will be available from official repository for Debian stable in about 100 years or so..

    • Re: (Score:2, Funny)

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

  • Anyone with an internet facing anything should be doing (better) intrusion detection. It doesn't need to be expensive and doesn't need to be fancy. I ran an ftp box for over 10 years and we had some simple, automated processes to detect attacks. The box took a lot of flack but never got cracked and we could prove it. You know your security is working when you can *prove* it's working. "Set-and-forget" isn't a secure option.

    1) (md5|sha1)sum everything on the box. (eg: find / -exec md5

    • If the attacker knows about the command being run through SSH, I can think of plenty of ways to attack it.
      * modify bash to "alias" the command to a simple "cp valid_hashes /tmp/md5.txt"
      * umount /mnt/cdrom and put trojaned files in that directory
      * use inotify to replace /tmp/md5.txt with a valid copy when the find/md5 process stops writing in it
      * mount /tmp as a FUSE fs, ignore writes to /tmp/md5.txt and always return a valid answer to reads

      I'm sure there are more, but this was what came up to my head in a f

      • Re: (Score:2)

        by Vario ( 120611 )

        All your ways of attacking the mention IDS scheme from the parent can work, given the right circumstances. Basically what it comes down to is that if the attacker gained access successfully and is in control of the targeted machine it can always send out messages, as if it was not infected. At this point it is too late trying to detect anything. With a challenge-response scheme you might be able to ask for the exact contents of /usr/bin/md5 but you will never be able to tell whether there is also a /usr/bin

  • So how long was this in upstream, and which distros have packaged up the broken one?

    Debian's got 1.3.1 in stable, and 1.3.3 in squeeze, so the latter might be built from the compromised one.

    Others?

  • Wait, what was the hole again? (Score:5, Funny)

    by jonaskoelker ( 922170 ) <jonaskoelker@yaho o . c om> on Thursday December 02, 2010 @09:40AM (#34416854)

    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.

  • On Sunday, the 28th of November 2010 around 20:00 UTC the main distribution server of the ProFTPD project was compromised. The attackers most likely used an unpatched security issue in the FTP daemon to gain access to the server and used their privileges to replace the source files for ProFTPD 1.3.3c with a version which contained a backdoor.

    I'm glad they found the backdoor before someone backdoored my up-to-date ProFTPd 1.3.3c server to install it.

  • I suppose for public sites serving very large files, it may make some sense, but for even internal use, we never use FTP, as HTTP transport can easily be secured via SSL, and it's easier to secure the single httpd server and port rather than having two services running.

    Is the bandwidth savings really worth the extra security risk?

  • Wait, what? (Score:3)

    by Arancaytar ( 966377 ) <arancaytar.ilyaran@gmail.com> on Thursday December 02, 2010 @12:44PM (#34419826) Homepage

    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?

Slashdot Top Deals

You can be replaced by this computer.

Close