Slashdot Mirror
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."
I'm pretty sure the unpatched security flaw was the protocol itself. Plain text passwords FTW.
People still compromise. Now that's impressive.
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.
He who knows best knows how little he knows. - Thomas Jefferson
Sure they do. Public ftp that is
Oh, the irony
Author, Shell Scripting : Expert Re
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'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.
How else are you going to upload files from Internet Explorer 6?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
People still use Joomla?
And how, exactly, would the attackers sign the distribution files with the same private key the project uses?
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?
Apparently... Guess this is a case of "I know this tool, and I'll use it".
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.
All hope abandon ye who enter here.
Shouldn't be a problem for local use or behind a VPN... other than that it's a bad idea.
R E C U R S I O N
_______
2B1ASK1
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.
WebDAV?
Funny, I was just trying to install ProFTP on Debian stable yesterday. Couldn't get it to work at all.
How else are you going to upload files from Internet Explorer 6?
Shared drive?
Who cares? Anyone still on IE6 deserves whatever maltreatment/second-class service they get.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
thankfully that fancy new version will be available from official repository for Debian stable in about 100 years or so..
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.
Orwell was an optimist.
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)
// MD_Update(&m,buf,j);
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.
/tmp/md5.txt ) /mnt/cdrom/md5sum ...')
.. 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)
1) (md5|sha1)sum everything on the box. (eg: find / -exec md5sum '{}' \; >
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
2) scan messages logs hourly from cron
Look for attacks (eg: Invalid login from alicia,
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: ")
boycott slashdot February 10th - 17th check out: altSlashdot.org
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?
2*3*3*3*3*11*251
You'd be surprised.. Recently I installed Invision for someone, and they insisted on having Joomla integration.
// MD_Update(&m,buf,j);
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.
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.
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".
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.
The sad part is that people do still use Invision...
The backdoor trojan which gets installed via an ActiveX exploit will take care of uploading for you.
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...
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
Why not just use SSH/SCP for windows( it already exists, not difficult to install)?
Well.. maybe. Or Maybe not. But Definitely not sort of.
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.
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.
-Arthur
Cave ne ante ullas catapultas ambules
You can't write to ftp with Finder, so that argument is moot. Safari or Finder, it's read only anyway.
-- Linux user #369862
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.
Says the guy who calls himself "Mr. DOS" ;-)
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.
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.
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:// protocol links. That's the whole idea behind prefixing http:/// and 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:// links.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
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.
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.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Maybe "Señor TWO" was already taken? :-)
Was it a buffer overflow?
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?
Don't thank God, thank a doctor!
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.
Anyone still on IE6 is at work, where the intranet is dependant on it.
Free Martian Whores!
for fast, simple transfers on a LAN, it's the best protocol out there.
rsync is the tool I prefer.
We use rsync to distribute internal apps -- the clients hit the server on logon to grab the latest version. It's not complicated and doesn't require any support. If the same version is already installed, it's like 200 bytes transferred per client, which is about as lightweight as you can get.
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
"Lame" - Galaxar
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.).
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...
Looks like the code was from ACIDBITCHEZ.. which is a pretty well known group.
Interesting that it had a hard coded IP from Saudi Arabia in it. http://www.exploit-db.com/exploits/15662/
What bothers me about this is the assumption that proftpd has a remote root bug. I would guess that
a local account was compromised and then a local root exploit was used to gain control before saying
proftpd was buggy.
Why? Because ACIDBITCHEZ would never show their hand like this if they had something juicy bug wise
that could own the newest release of proftpd as well as go back in time on older releases. This was something
they did for kicks with the access they had.
There is nothing I want to download quickly more than a hacked file that isn't the one I was expecting!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
"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."
Um, Finder asks if you'd like to login as guest or someone specific, so it looks to me like there is no reason to think you can't write with permission.
Hey buddy, can i bum a karma? ~}CinderellaManson{~
Maybe he's Mr. Denial Of Service. No Invision for you!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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?
Make sure everyone's vote counts: Verified Voting
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?
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.
I am TheRaven on Soylent News
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 share as simple web page if you want to give people read-only access.
I am TheRaven on Soylent News
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.
"while democracy seeks equality in liberty, socialism seeks equality in restraint and servitude." de Tocqueville
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.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
They're not getting the shitty experience, I am. they couldn't care less.
Free Martian Whores!
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 sure that anybody that complain or points out that there are alternatives is silenced.
The CEO couldn't care less if the staff is using IE6 or lynx, he just listen to the IT director then cuts a big check and finaly does not want to hear about this ever again.
And since he typically never uses the companies platform (except for some emails, preferably sent from his blackburry) s/he never sees anything wrong with the infrastructure.
Moreover if you are living in a company that has this policy it does not matter if it is the CEO CFO or CIO that is responsible, the best advice is "run as fast as you can it is not worth it..."
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?
"while democracy seeks equality in liberty, socialism seeks equality in restraint and servitude." de Tocqueville
Works the same way, only the permissions are different (it's a read/write rsync share not a read-only). Unlike FTP, rsync can either pull or push data.
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.
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.
http://michaelsmith.id.au
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" ...
How about using secure FTP? People are used to secure HTTP and they might not even notice the diference. :: FTP : FTPS
HTTP : HTTPS
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.
"while democracy seeks equality in liberty, socialism seeks equality in restraint and servitude." de Tocqueville
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..
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.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
That's very strange... machines of quite a few years ago could saturate 100 Mb/s (about 12 MB/s) ethernet with SSH encryption. Modern machines should be able to get into the 300-400 Mb/s range without too much trouble. Where encryption struggles is to get wirespeed on gigabit networks. There is either something wrong with your 2 foot cable, your gigabit NICs, or your disk subsystems.
In the wide area for normal people, encryption has no performance impact. Rather, TCP backoff due to congestion has a big impact. Going parallel with lots of TCP sockets (like bittorrent does) will help a lot, by not backing off as much in the aggregate. A better protocol than FTP also helps, by allowing small files to be pipelined without round-trip synchronization delays. Running rsync or tar over ssh is much faster than plain FTP in the wide area for this reason, when transferring lots of smaller files.
There are two big open source cms: drupal and ezpublish.
worpress is a blog engine, not a cms (even if it has some cms features and is extensible)
joomla is certainly the worst available cms, but is widely used because it is easy to start with even without any knowledge. And this is maybe its only strong point.
security in joomla is a joke, and with joomla and a ftp on a same server I wouldn't worry about the ftp.
I feel your pain because I've had the exact same problem. It doesn't really matter how hard you try to explain that plain-text passwords over the wire is a really BAD idea. The wierdest part is that WinSCP behaves exactly like any other FTP client - but nooooo, it has to be FTP for some frikkin' reason.
dammit.