Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ProFTPD.org Compromised, Backdoor Distributed

CmdrTaco posted more than 3 years ago | from the scary-world-we-live-in dept.

Open Source 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."

cancel ×

152 comments

Sorry! There are no comments related to the filter you selected.

FTP (-1, Flamebait)

kyrio (1091003) | more than 3 years ago | (#34416194)

People still use FTP?

Re:FTP (3, Insightful)

kyrio (1091003) | more than 3 years ago | (#34416210)

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

Re:FTP (1)

thijsh (910751) | more than 3 years ago | (#34416420)

Shouldn't be a problem for local use or behind a VPN... other than that it's a bad idea.

Re:FTP (0)

kestasjk (933987) | more than 3 years ago | (#34416736)

Why not use SSH/SCP for unix or SMB for Windows? (I accept Windows should have an SSH/SCP alternative, and that it's one of PowerShell's few failings, but SMB is okay for encrypted local file transfers)

Re:FTP (1, Informative)

Bill, Shooter of Bul (629286) | more than 3 years ago | (#34417278)

Why not just use SSH/SCP for windows( it already exists, not difficult to install)?

Re:FTP (4, Interesting)

jimicus (737525) | more than 3 years ago | (#34417922)

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 (0)

Anonymous Coward | more than 3 years ago | (#34417710)

Why not use SSH/SCP for unix or SMB for Windows? (I accept Windows should have an SSH/SCP alternative, and that it's one of PowerShell's few failings, but SMB is okay for encrypted local file transfers)

Because SCP and SFTP are slow (not due to encryption, but due to their chatty nature). You can get quite close to wirespeed from FTP even from WAN. With SCP you are lucky to get >10MB/s from WAN. SCP and SFTP are quite slow even in LAN.

Re:FTP (1)

cuncator (906265) | more than 3 years ago | (#34417498)

That's assuming everyone on your local net is trustworthy, which pretty much leaves out any network with more than one user on it. For internal transfers you don't really care about securing, though, it's probably fine with appropriate chroot, iptables, etc.

Security is for losers. (0)

Anonymous Coward | more than 3 years ago | (#34417640)

Yeah, it's OK to use plain-text password transports on a network that you think is secure, even though there are freely available secure transports that are drop-in replacements, and even though any network that has more than one computer on it is potentially insecure and should always be treated as insecure for data transport purposes.

It's also OK to leave your keys in your car every night if you trust your neighbors, and it's OK to let your daughter dance nude in clubs as long as everyone in the club is a police officer.

Re:FTP (2)

dimethylxanthine (946092) | more than 3 years ago | (#34416218)

People still compromise. Now that's impressive.

Re:FTP (0)

Anonymous Coward | more than 3 years ago | (#34416238)

Sure they do. Public ftp that is

Re:FTP (2)

Corporate Troll (537873) | more than 3 years ago | (#34416288)

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 (4, Funny)

Rhaban (987410) | more than 3 years ago | (#34416356)

People still use Joomla?

Re:FTP (1)

Corporate Troll (537873) | more than 3 years ago | (#34416368)

Apparently... Guess this is a case of "I know this tool, and I'll use it".

Re:FTP (1)

kestasjk (933987) | more than 3 years ago | (#34416788)

You'd be surprised.. Recently I installed Invision for someone, and they insisted on having Joomla integration.

Re:FTP (1)

Mr. DOS (1276020) | more than 3 years ago | (#34417060)

The sad part is that people do still use Invision...

Re:FTP (1)

Corporate Troll (537873) | more than 3 years ago | (#34417682)

Says the guy who calls himself "Mr. DOS" ;-)

Re:FTP (2)

An ominous Cow art (320322) | more than 3 years ago | (#34418114)

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

Re:FTP (1)

The Moof (859402) | more than 3 years ago | (#34416868)

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:FTP (2)

Megane (129182) | more than 3 years ago | (#34416294)

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

Re:FTP (1)

AndrewNeo (979708) | more than 3 years ago | (#34416506)

WebDAV?

Re:FTP (0)

Anonymous Coward | more than 3 years ago | (#34416566)

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

Shared drive?

Re:FTP (1)

smash (1351) | more than 3 years ago | (#34416582)

Who cares? Anyone still on IE6 deserves whatever maltreatment/second-class service they get.

Re:FTP (0)

Anonymous Coward | more than 3 years ago | (#34417076)

The backdoor trojan which gets installed via an ActiveX exploit will take care of uploading for you.

Re:FTP (0)

Anonymous Coward | more than 3 years ago | (#34416642)

OP has the same unanswered question that I have. What is the point of FTP today? I mean Google Chrome doesn't even recognize gopher URLs. Apple's Safari screws up FTP sites by mounting them in the Finder. I just can't think of a need for FTP when there is HTTP.

Re:FTP (1)

surgen (1145449) | more than 3 years ago | (#34417004)

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:FTP (1)

JonJ (907502) | more than 3 years ago | (#34417636)

You can't write to ftp with Finder, so that argument is moot. Safari or Finder, it's read only anyway.

Re:FTP (1)

nschubach (922175) | more than 3 years ago | (#34417826)

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:FTP (1)

Wolvenhaven (1521217) | more than 3 years ago | (#34416720)

One of our clients where I work required us to modify our application in such a way that they could use FTP on their own server for the file transmission instead of using our already built application which every other one of our clients uses; and yes, it's become the biggest pain to manage and constantly causes issues.

So yea, people still use it, even with much better systems available.

Re:FTP (0)

Spazmania (174582) | more than 3 years ago | (#34417086)

Yeah, exactly. I used and liked proftpd back in the day, but why is anyone still using an FTP server for anything? The protocol is not secure or reasonably securable. Come on folks, the writing has only been on the wall for 15 years now...

Re:FTP (3, Informative)

a_nonamiss (743253) | more than 3 years ago | (#34417576)

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 (0)

Anonymous Coward | more than 3 years ago | (#34417274)

Automated file drops. FTP is great for this.

I'm not talking about a cron job running a shell script that sends a file through an FTP command. I'm talking about a purpose-built application that builds a data file and sends it via FTP to a remote system for processing.

Security should be handled by a firewall (allow only $sender_IP to connect to port 21), not by the FTP protocol itself. Encryption can be handled by the app that creates the data file. This is how FTP is supposed to work anyway. It's just a dumb pipe. File Transfer Protocol, not File Encryption, Authentication, Authorization, and Transfer Protocol.

Learn to use a tool for what it's for. FTP is for transferring files. Nothing more.

Re:FTP (1)

nschubach (922175) | more than 3 years ago | (#34417972)

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:FTP (1)

SanityInAnarchy (655584) | more than 3 years ago | (#34418372)

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?

The unfortunate case (0)

Anonymous Coward | more than 3 years ago | (#34418570)

Annoyingly. Yes they do still use FTP. Its mostly clueless users who continue to use antiquated software and yell loudly when you turn FTP off. I'm a sysadmin at a hosting company and we've been trying to turn off FTP officially for 6 years now. Almost every new server that we bring up we leave FTP off for as long as we can, but eventually users start threatening to cancel instead of migrate to newer or different software on their end. For instance, some people use website creation software that doesn't support SSH, like old versions of Dreamweaver.

I was really mad when WinSCP added FTP support because that just adds fuel to the fire. Plus there are people out there who want to do things like have sub accounts, which SSH has no way of doing AFAIK.

Yo, Dawg, I heard you like backdoors (-1, Offtopic)

Even on Slashdot FOE (1870208) | more than 3 years ago | (#34416196)

So I put a backdoor in your backdoor so you can be compromised while you're being compromised.

Anyone checking these source file changes? (3, Insightful)

digitaldc (879047) | more than 3 years ago | (#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.

Re:Anyone checking these source file changes? (2)

Sockatume (732728) | more than 3 years ago | (#34416254)

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? (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34416400)

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? (1)

hedwards (940851) | more than 3 years ago | (#34416568)

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.

Re:Anyone checking these source file changes? (1)

kestasjk (933987) | more than 3 years ago | (#34416808)

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)

Re:Anyone checking these source file changes? (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34417326)

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 strong downmarket pressures, to the point where my nonexistent cat could probably find some 'trusted' CA who would be happy to issue it a certificate for bankofamerica.ru... Then somebody dreams up "Extended Validation: what certs were always supposed to be; but for real this time, we promise!". And so begins the cycle again...

The only vaguely novel quasi-solution I can see to this problem would be the concept of "stability attestation". There would be a number of servers(similar to DNS) that would operate as follows: I generate a keypair and an object(domain name, email address, etc.) that I wish to stabilize. I send that tuple to one or several "stability attestation servers". The server says "Ok, fuzzyfuzzyfungus, if that is in fact your public key, pass this challenge-response test.". If I do, the server generates a signed manifest stating that the tuple {fuzzyfuzzyfungus/slashdot account, $Public_Key} passed verification at $TIME.

At any future point, anyone can query an SAS, with my tuple and receive either "Verified at $TIME" or "Yeah, not so much, a tuple containing the same object; but a different public key, verified at $TIME. Impersonation suspected."

This would be useful in situations where you want the ability to do crypto with someone, as with SSL or PGP; but knowing somebody's real name/SSN/whatever either won't help you much, or is not something they want.

In my case, for example, knowing my real name wouldn't help you much in determining whether "fuzzyfuzzyfungus" is full of shit or actually a pretty insightful guy. My bio is just pretty bland, and I have no real desire to tie it to slashdot. However, knowing that I'm the same "fuzzyfuzzyfungus" as the one who posted my last N messages allows you to judge me by my record, and would allow you to reset your trust metrics if I suddenly changed.

The same is true of most websites, FOSS authors, small companies, and so forth. Knowing "Who they are in real life" barely matters. Knowing that their server got hacked yesterday and that I SHOULD NOT extend my historical trust metrics on them into the present is highly valuable...

Re:Anyone checking these source file changes? (1)

jones_supa (887896) | more than 3 years ago | (#34416418)

Cool idea.

Re:Anyone checking these source file changes? (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#34418206)

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.

Re:Anyone checking these source file changes? (1)

markkezner (1209776) | more than 3 years ago | (#34416370)

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:Anyone checking these source file changes? (1)

daid303 (843777) | more than 3 years ago | (#34418370)

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.

Another dumb comment. (0)

Anonymous Coward | more than 3 years ago | (#34416460)

The attackers changed the distribution files. These would be past the review process. Commits to the SCM would have been highly visible. Avoid criticizing what you clearly do not understand.

Re:Anyone checking these source file changes? (2)

jellomizer (103300) | more than 3 years ago | (#34416630)

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

Re:Anyone checking these source file changes? (1)

kestasjk (933987) | more than 3 years ago | (#34416822)

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

Re:Anyone checking these source file changes? (1)

Pharmboy (216950) | more than 3 years ago | (#34417112)

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

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

Re:Anyone checking these source file changes? (1)

arndawg (1468629) | more than 3 years ago | (#34417246)

Hotmail ran on Solaris and FreeBSD, not linux.

Re:Anyone checking these source file changes? (1)

Bill, Shooter of Bul (629286) | more than 3 years ago | (#34417346)

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.

Please explain... (0)

Anonymous Coward | more than 3 years ago | (#34417690)

Why is it relevant whether you use your own software to distribute itself? Why am I any less vulnerable when I use someone else's potentially buggy software instead of my own (when they're both open source projects, so there's no security through obscurity argument)?

Or do you just mean it's a bad idea to use unstable development software on production servers? Obviously, I'd want to use a stable, QA approved release for the server, and not -r head trunk.

Re:Anyone checking these source file changes? (1)

SigmundFloyd (994648) | more than 3 years ago | (#34418186)

it's why the OpenBSD guys use Solaris

False. As they explained clearly in the FAQ, they used to run Apache on Solaris simply because the hosting company who donated server space and bandwidth was Sun-based. Now they run their web servers on OpenBSD, though, and have been for a while.

Re:Anyone checking these source file changes? (1)

Nerdfest (867930) | more than 3 years ago | (#34417252)

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 (4, Funny)

sparkz (146432) | more than 3 years ago | (#34416240)

Oh, the irony

Re:Should have used vsftpd (2)

carlhaagen (1021273) | more than 3 years ago | (#34416530)

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 (0)

Anonymous Coward | more than 3 years ago | (#34416732)

Link?

Re:Should have used vsftpd (2)

SigmundFloyd (994648) | more than 3 years ago | (#34418040)

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 (1)

SanityInAnarchy (655584) | more than 3 years ago | (#34418400)

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:Should have used vsftpd (1)

quinto2000 (211211) | more than 3 years ago | (#34418584)

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

Re:Should have used vsftpd (0)

Anonymous Coward | more than 3 years ago | (#34418596)

or pureftpd.

Quite. (4, Insightful)

Spad (470073) | more than 3 years ago | (#34416264)

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. (2)

bigjocker (113512) | more than 3 years ago | (#34416322)

You should always host the MD5 or SHA hashes offsite.

Re:Quite. (1)

profplump (309017) | more than 3 years ago | (#34416466)

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 not available on the distribution server would be useful. Hashes are better than nothing, but they're much better at protecting against random download errors than a knowledgable attacker.

Dumb comment. (5, Informative)

Anonymous Coward | more than 3 years ago | (#34416364)

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

Re:Dumb comment. (1)

Anonymous Coward | more than 3 years ago | (#34416534)

How do you know what their public key is?

Re:Dumb comment. (1)

Anonymous Coward | more than 3 years ago | (#34416558)

And how, exactly, do you verify the key used to sign the distribution files?

Re:Dumb comment. (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34416752)

And how, exactly, did you get so fucking stupid, you fucking stupid asshole?

Re:Dumb comment. (0)

Anonymous Coward | more than 3 years ago | (#34417600)

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

Assuming it wasn't stored on the same server that they rooted.

Re:Quite. (1)

nedlohs (1335013) | more than 3 years ago | (#34416416)

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

Re:Quite. (0)

Anonymous Coward | more than 3 years ago | (#34416456)

I guess that they already replaced the compromised files, so the current keys are valid.

  Alternatively you can download the source again, configure/change it again, compile it again and install it again, to replace your current version, which might not be affected.

Re:Quite. (1)

T.E.D. (34228) | more than 3 years ago | (#34417470)

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.

Recursion fail? (2)

IDK (1033430) | more than 3 years ago | (#34416366)

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?

Re:Recursion fail? (1)

bigpresh (207682) | more than 3 years ago | (#34417082)

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?

I suspect whatever vulnerability was used allowed the attackers to upload files, but didn't give them actual control over the machine; their backdoored version, as stated in the article, allowed attackers to gain root on the box.

Only ProFTPd? (1)

ThePhilips (752041) | more than 3 years ago | (#34416404)

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

Re:Only ProFTPd? (1)

drinkypoo (153816) | more than 3 years ago | (#34416450)

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:Only ProFTPd? (1)

ThePhilips (752041) | more than 3 years ago | (#34416510)

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:Only ProFTPd? (1)

drinkypoo (153816) | more than 3 years ago | (#34416606)

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:Only ProFTPd? (0)

kestasjk (933987) | more than 3 years ago | (#34416846)

And those of you are a waste of your company's time.

Re:Only ProFTPd? (0)

Anonymous Coward | more than 3 years ago | (#34417354)

Sounds like someone's a contractor.

Re:Only ProFTPd? (0)

Anonymous Coward | more than 3 years ago | (#34418180)

Because getting hacked due to your complete stupidity is definitely a wise time investment. Retard.

Re:Only ProFTPd? (1)

surgen (1145449) | more than 3 years ago | (#34417028)

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:Only ProFTPd? (1)

19thNervousBreakdown (768619) | more than 3 years ago | (#34417362)

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:Only ProFTPd? (1)

SigmundFloyd (994648) | more than 3 years ago | (#34417934)

+1 on vsftpd: its config file is so well commented that it's almost a tutorial on FTP administration. Top notch work, both on the server itself and the documentation.

Re:Only ProFTPd? (1)

Hatta (162192) | more than 3 years ago | (#34416572)

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:Only ProFTPd? (0)

Anonymous Coward | more than 3 years ago | (#34416614)

ProFTPd, while great when it came out in the early 2000s and had many features, was always plagued with security issues, and many places I worked at stopped used it even though it was relatively easy to setup and was feature rich.

vsftpd [beasts.org] was at one point the most secure ftpd I could find. Not sure how good it is anymore.

If you need a simple Windows FTPd on a small LAN for quick file transfers check out ftpdmin [sentex.net] which is really minimal (free and source available!). I use it all the time for quick ISO transfers on my personal LAN. Does the job. Much better than HTTP transfers, that's for sure.

Re:Only ProFTPd? (1)

Alioth (221270) | more than 3 years ago | (#34417856)

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.

There's a backdoor in my backdoor. (2)

eyeball (17206) | more than 3 years ago | (#34416422)

R E C U R S I O N

Re:There's a backdoor in my backdoor. (1)

miffo.swe (547642) | more than 3 years ago | (#34416746)

Damn, i was just about to write that. XD

Funny as hell!

Funny (2)

Masterofpsi (1643965) | more than 3 years ago | (#34416516)

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

Re:Funny (0)

Anonymous Coward | more than 3 years ago | (#34416624)

I don't understand. How is that funny?

not on Debian stable (2)

orange47 (1519059) | more than 3 years ago | (#34416654)

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 (2, Funny)

Anonymous Coward | more than 3 years ago | (#34417010)

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 (1)

bl8n8r (649187) | more than 3 years ago | (#34416758)

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 md5sum '{}' \; > /tmp/md5.txt )
Save it on your internal lan. Nightly, allow a box from your lan to ssh into the server to re-create the list and compare them. It will be a short list because you've certainly removed all unnecessary software from the box.  This will tell you what files have changed,rooted,trojaned.  For extra security burn the binaries on a cdrom and stick it on the server.  create the list using r/o binaries in case they themselves get hacked. (eg: ssh server '/mnt/cdrom/find / -exec /mnt/cdrom/md5sum ...')

2) scan messages logs hourly from cron
Look for attacks (eg: Invalid login from alicia, .. from alex, .. from albert, etc). Usually, people don't make one connection and crack your server.  It takes some probing and guesswork first and I've seen dictionary attacks last for an entire week before the attacker gives up. This is where you should be catching the attack - at the probe stage.  (eg: fgrep 'session opened for user' /var/log/auth.log)

3) watch your firewall logs
connection attempts for services you do not host on the box are cause for notice. Repeated connections for port 22, on a server you do not host ssh on, should be prime candidates for the bitbucket on the firewall. (eg: iptables -A INPUT -p tcp --dport 22 -m limit --limit 4/min --limit-burst 4 -j LOG --log-prefix "SSH_INGRESS: ")

   

Re:Implement better IDS (1)

icebraining (1313345) | more than 3 years ago | (#34417464)

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

2 and 3 are probably better and enough to catch them, though, unless they use social engineering to get the username/password of a valid user.

Compromised code in distros? (1)

Urban Garlic (447282) | more than 3 years ago | (#34416766)

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? (4, Funny)

jonaskoelker (922170) | more than 3 years ago | (#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.

Phew! (1)

Durzel (137902) | more than 3 years ago | (#34417024)

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? (1)

master_p (608214) | more than 3 years ago | (#34418182)

Was it a buffer overflow?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?