ProFTPD.org Compromised, Backdoor Distributed 152
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."
Anyone checking these source file changes? (Score:4, Insightful)
Maybe they need some more code oversight, just my opinion.
Re: (Score:3)
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)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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)
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.
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
(it's why the OpenBSD guys use Solaris).
Is that that why Microsoft ran Hotmail on Linux for so many years? ;)
Re: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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)
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
Re: (Score:2)
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)
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: (Score:3)
You should always host the MD5 or SHA hashes offsite.
Re: (Score:2)
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)
And how, exactly, would the attackers sign the distribution files with the same private key the project uses?
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Because generating PGP signatures without the private key is so trivial.
Re: (Score:2)
Recursion fail? (Score:2)
Re: (Score:2)
The vulnerability could have been this bug:
http://bugs.proftpd.org/show_bug.cgi?id=3521 [proftpd.org]
This bug would have allowed them full access to the machine, assuming the daemon ran as root. I certainly had a few Plesk machines that were compromised by this bug. It's a pain clearing out rootkits from the system, I can tell you.
The bug was patched a month ago, so their server could have been exploited for that long, with crackers setting up backdoors into the system to regain root access. Just a hypothesis.
Only ProFTPd? (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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)
On the contrary, no company for which I have been the admin has ever had important resources taken over (there's always windows infections to deal with... I got a trivial PC owned here at home through two firewalls and was only browsing with firefox with noscript at the time.) There was that one time Media X was used as an FTP drop, but that's because the dipshit managing business hired his idiot friend to work there, and that guy decided he was smarter than I was and would do my job for me. He set up an FT
Re: (Score:2)
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.
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
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)
R E C U R S I O N
Funny (Score:2)
not on Debian stable (Score:2)
Re: (Score:2, Funny)
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.
Implement better IDS (Score:2)
1) (md5|sha1)sum everything on the box. (eg: find / -exec md5
Re: (Score:2)
If the attacker knows about the command being run through SSH, I can think of plenty of ways to attack it. /tmp/md5.txt" /mnt/cdrom and put trojaned files in that directory /tmp/md5.txt with a valid copy when the find/md5 process stops writing in it /tmp as a FUSE fs, ignore writes to /tmp/md5.txt and always return a valid answer to reads
* modify bash to "alias" the command to a simple "cp valid_hashes
* umount
* use inotify to replace
* mount
I'm sure there are more, but this was what came up to my head in a f
Re: (Score:2)
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
Compromised code in distros? (Score:2)
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)
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: (Score:2)
No, with two security holes. :)
Phew! (Score:2)
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.
Anyone knows what was the nature of the flaw? (Score:2)
Was it a buffer overflow?
Can anyone tell me who uses FTP anymore? (Score:2)
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)
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?
Re:FTP (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2, Informative)
Re:FTP (Score:5, Interesting)
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: (Score:2)
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.
Sure I would, because sftp and scp are bog slow compared to ftp, while the encryption overhead on an ssh terminal session isn't really anything compared to unencrypted telnet. Also, ssh logins offer a lot over telnet (key-based login, port forwarding, etc.).
Give me anything, just make it quick! (Score:3)
You got that Bass Ackwards son (Score:2)
She's not going to get raped in the club, but her safety after they cuff her and take her away isn't guaranteed by any means. It could be a bad apple on the force. It could be here new "girlfriend." No matter how you slice it, being in the custody of the police is not even remotely safe (excuse the pun.)
Re: (Score:3)
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 [proftpd.org]
Re: (Score:2)
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 (Score:5, Funny)
People still use Joomla?
Re: (Score:2)
Re: (Score:2)
The sad part is that people do still use Invision...
Re: (Score:3)
Maybe "Señor TWO" was already taken? :-)
Re: (Score:2)
Re: (Score:2)
People still use Joomla?
Along with Drupal and Wordpress, Joomla is one of the big three open source CMS solutions out there. As far as I know, it is very current software, and highly regarded.
Re: (Score:2)
I said "simply use sftp", but that was not acceptable.
A better suggestion for the average user would be going FTPS. No tunneling required, it's built right into the protocol.
Re: (Score:2)
Many architectural practices use FTP for exchanging files but I reckon if you just gave them scp and said this is the new way of doing ftp they would be satisfied. It does Transfer Files of course.
Re: (Score:2)
Re: (Score:2)
WebDAV?
Re: (Score:2)
Re: (Score:2)
Anyone still on IE6 is at work, where the intranet is dependant on it.
Re: (Score:2)
Wich prove the point, anybody working for a company that is tolerant of an IT team that is IE6 dependent for its intranet deserve to have a shitty internet experience at least at work...
Re: (Score:2)
I'd say your thinking is pretty much bass ackwards.
It's company policy, not IT policy, that keeps most organizations dependent on IE6. This stems from the company not wanting to spend the money to rewrite the apps, not IT insisting that they continue using IE6. What geek/IT guy do you know that insists on using IE6 at home, or anywhere else? Every IT guy I know likes using modern software.
Re: (Score:2)
Nope,
The company does not have an IE6 policy, it has a policy of "buying an intranet" with the support of the IT team.
And then some shiny consulting firm suggest some expensive software to handle the watchalicallits
and develop some addon software that only work with the "core software"...
Meanwhile the IT team, or more preciselly it's PHB is enjoying information gathering trips, power lunches and conference invitations to learn how right s/he was to buy this software...
And then the company policy just make s
Re: (Score:2)
So, you admit it's a PHB making the decision based on a sales pitch from an outside vendor, but insist it's the fault of the IT team. I find your logic less than persuasive. Since when did a PHB ever listen to the employees under him? Isn't that impossible by the definition of a PHB?
Re: (Score:2)
The PHB is part of the IT team, and the IT team is either:
- accepting stupid decision while knowing it is bad for the company
- being stupid because the only know a couple of "pre packaged clickomatic junk"
in both case they are "guilty as charged" ...
Re: (Score:2)
Really??? Go read Dilbert as he is the one that defined a PHB.
Once you've done that tell me how often you reverse the decisions your boss makes. You know, walk up to him and tell him how he's wrong and how nobody is going to follow his directions. If you tell me you actually do that, and not get fired, I'll know you're a liar.
Re: (Score:2)
No I leave the company, that is the point...
Actually I use the dilbert test, when I feel that Dilbert is about "me" I leave..
Re: (Score:2)
They're not getting the shitty experience, I am. they couldn't care less.
Re: (Score:2)
So yea, people still use it, even with much better systems available.
Re: (Score:2)
Apple's Safari screws up FTP sites by mounting them in the Finder.
It sounds like Safari encountered a URI for which it doesn't handle the protocol, and passed it to the operating system. That's a sensible thing to do.
Mouting a remote directory as if it were a local one, how is that screwing up? Or do you just want the "hey we kind-of implemented this protocol in a receive-only way, it may or may not be completely unusable for your use case, but built into your browser anyway".
Re: (Score:2)
Re: (Score:2)
You missed his point... you can't really blame Safari for passing the URL to the OS to let it open whatever application is associated with ftp:// [ftp] protocol links. That's the whole idea behind prefixing http:/// [http] and ftp:// [ftp] in the first place.
The problem lies in the fact that this particular installation OSX likely doesn't have a program installed that can handle writing to ftp:// [ftp] links.
Re: (Score:2)
mount_ftp only supports mounting read-only
I've obviously never tried writing to a mounted FTP directory - OS X includes a recent version of the BSD ftp client, and I've always used that instead.
Re:FTP (Score:4, Informative)
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: (Score:2)
for fast, simple transfers on a LAN, it's the best protocol out there.
rsync is the tool I prefer.
Re: (Score:2)
Yeah, we have an internal FTP server that accepts and stores an average of 60,000 files per day from workstations all over the company. My import job cleans them off after 9 days so at any point in time we have over half a million files sitting on the server. If I had to deal with all those files in SMB or across a share, I'd have to wait hours to be able to do anything with them.
Re: (Score:2)
Re: (Score:2)
The process I explained isn't for distributing apps though... I'm collecting results from each workstation (usually multiple results.) The workstation upload files to an FTP server which I download to process.
Re: (Score:2)
You don't even have to install software on the client, just put the rsync.exe on your \\logonserver\netligon folder and make it world-executable. Configure a server with the rsync server end of it. It's only a couple of minutes to setup the server.
Re: (Score:2)
That's moronic.
First, you've got a purpose-built application. What's stopping you from implementing whatever protocol you want? Why on earth would you use FTP?
Second, IP-based security isn't security.
Third, why would you re-implement encryption, authentication, and authorization in your application when you can get them for free from FTPS, SFTP, HTTPS, etc?
Re: (Score:2)
For simple file drops, why not use HTTP PUT requests? They can be handled by any web server, and the server can handle encryption and client authentication (via passwords or certificates) out of the box for you.
For more complex use, why not use WebDAV? Pretty much any mainstream OS (including Windows, since Windows 98) has support built in. It includes fine-grained access controls, authentication, encryption, and works everywhere. Because it's an extension of HTTP, you can easily export a WebDAV shar