Forgot your password?
typodupeerror

R.I.P. FTP 359

Posted by CmdrTaco
from the and-good-riddance-to-ye dept.
Slashdot contributor Bennett Haselton says "Using FTP to administer a website is insecure -- but not for the reasons that you probably think. You yourself can stop using FTP any time you want, but how do we change the landscape Net-wide, to reduce the number of breakins using stolen FTP credentials?" You know what to click on if you want to read the rest.

On July 1st I found that one of my less important websites, hosted on a low-cost shared Web hosting service, had been broken into. A friend emailed me to say that the site was showing up in Google's search results with the Google "This site may harm your computer" warning listed next to it. I found that on one of the pages, about 1,500 HTML script tags had been inserted, loading JavaScript files from pseudo-random Russian hostnames like "www.chk06.ru" and "www.errghr.ru", none of which are currently resolving. Usually, when such script tags are maliciously inserted into a page on a website, the script tags attempt to install spyware on the machines of people who visit the site.

I immediately replaced the infected file on the website with the backed-up clean copy from my machine, and changed the password on the website in case the attacker had gotten in by using the old one. (The original file with the script tags inserted is here if you want to examine it, but use with caution -- if the .ru hostnames in the script tags start resolving again, then opening the file could cause the JavaScript on the pages to be loaded, which might infect your machine.) Then I started investigating (a) how this probably happened; (b) whether future similar attacks could be prevented, by changing some defaults in the way that hosting accounts are set up; and (c) whether the incentives for hosting providers are such that these changes are likely to happen by themselves, or whether it will require some third-party advocacy to change what we think of as "best practices".

Denis Sinegubko, the webmaster of Unmask Parasites, a free service that scans websites on demand for signs of break-ins, says:

The majority of web site compromises happen because of:

  1. Stolen FTP credentials. Spyware on webmasters' computers: key-loggers, traffic sniffers (FTP protocol sends username/password as plain text), trojans that steal credentials from various programs' configuration files (FTP clients, DreamWeaver, etc).
  2. Security holes in popular web software: CMS (Joomla, Drupal, etc), Forums (phpBB, vBulletin, Simple Machines, etc), Blogs (WordPress). Once a vulnerability discovered, hackers configure their automated tools to search the web for websites running vulnerable versions of the software and exploit them. This can be done easily and at almost no cost when they have an army of zombie computers.
  3. Security hole in "in-house" web software. Many novice (and even many experienced) web developers don't properly sanitize user input making various attacks possible (SQL injections, XSS, etc)
  4. Poor security practices (Something that should be manually configured by site/server admins and cannot be fixed with automated security updates): Weak passwords, open ports, insufficiently strict permissions for limited accounts, files and directories with world write permissions, etc.

I didn't have any third-party web software or custom-made software installed on the PublicEditorMyAss.com site, the password was a seven-letter meaningless mix of letters and numbers, and I didn't have permission to change most of the things like open ports and file permissions. That left the possibility of stolen FTP credentials. This is in fact what Sinegubko says is the most common cause of such break-ins:

I guess 90% of attacks use stolen FTP credentials this year. Check this Google's graph that shows the top 10 malware sites as counted by the number of compromised web sites that referenced it:
http://googleonlinesecurity.blogspot.com/2009/06/top-10-malware-sites.html

I reviewed 4 most widespread of them (Gumblar, Martuz, Goooogleadsense, Googleanalytlcs). All four used stolen FTP credential to penetrate web sites and upload malicious content. The chances are the rest used this vector too.

When the PublicEditorMyAss.com site was set up, the default setting was for pages to be edited over FTP. Even though FTP sends and receives passwords without encrypting them (in contrast with alternatives like SFTP or "secure FTP", which encrypts passwords), for a long time I had assumed that this was not a major security problem, because in order for an attacker to intercept the passwords in transit, they would have to control a machine somewhere on the path between my home computer and the PublicEditorMyAss.com server. I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer. And if an attacker managed to do that, then I assumed that the risk of passwords being stolen by spyware was about the same whether I used FTP or SFTP -- because either way, the spyware could just steal my password by reading it out of a configuration file where the password was stored. (Even though FTP and SFTP programs both store passwords in an encrypted format, the programs have to be able to decrypt the passwords in order to use them whenever the user wants to open a connection. So the spyware could just mimic whatever steps the client programs use to decrypt the stored passwords, in order to steal one of my passwords stored in a file.) So, I assumed it made no difference whether I used FTP or SFTP.

But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted:

[Passwords can be stolen by] sniffers that read all TCP traffic on local computers. Like personal firewalls but malicious. They can easily intercept FTP credentials since they are sent as a plain text.

Sinegubko describes how one of his contacts obtained evidence that a common spyware program was doing exactly this:

One of them even infected a spare WinXP computer (with Gumblar) to test the consequences. On the infected computer he created a new account in a popular FTP client and saved it. The server address was correct (his server) and the username/password pair was not valid. A few hours later in FTP logs, he discovered login attempts that used that invalid username/password pair from a Singapore IP, then from a Florida IP, the some other country's IP. Apparently the FTP credentials were somehow stolen from that infected computer.

I know of only two instances where I've ever definitely been infected with spyware. I don't do stupid things like downloading and running strange programs from third-party sites, so I think both infections were probably caused by a site exploiting a security hole in Internet Explorer, or in a plug-in like Adobe Acrobat or the Flash player. Both times, once I noticed I was infected, I got rid of the infection with Malwarebytes, but I don't know how much damage the spyware did in the meantime.

So this was a case where a little knowledge can be a dangerous thing. If I had known nothing about Internet architecture, and someone told me "FTP is less secure than SFTP," I would have found a way to switch to administering the site via SFTP. But because I knew that the main reason FTP was considered "insecure" was because it transmitted passwords unencrypted, but I also knew that most of of the machines relaying those passwords in transit were secure and trustworthy, I thought it didn't matter. Now it seems that is probably how my password got compromised after all.

In that case, why don't more people switch to administering their sites via SFTP instead of FTP? Here are the steps it took me to enable SFTP on my GoDaddy hosting account. Feel free to use this as a reference, but the obvious point is that as long as this many steps are required, it's safe to say that most users won't be switching:

  1. Go to the "Hosting" menu and pick "My Hosting Account."
  2. Next to the name of your website, pick "Manage Account." This will open the Hosting Control Center.
  3. In Hosting Control Center, click to expand the "Settings" options.
  4. In the "Settings" control panel, click the "SSH" icon.
  5. You will see a page saying "SSH is not set up", and prompting you to enter a phone number so that their automated service can call you with a PIN number. After you enter your phone number, the phone rings a second later, and you enter the PIN in a form on the GoDaddy website.
  6. You will then see a page which says:

    Current Hosting Account Status: Pending Account Change
    Your request to enable SSH is being processed. This upgrade may take up to 24 hours.

In fact, even if only one step were required to switch, most users probably wouldn't change from the default setting to use FTP, due to the eternal, unchangeable fact that most people do not change their default settings, ever. (What percent of users ever change the default set of toolbars that are displayed at the top of their Web browser window?)

If more Web hosting companies made SFTP the default, then the number of websites that were compromised by stolen login credentials, would probably go down. Spyware authors might start to make their programs smarter at that point, enabling them to read the passwords stored by popular FTP and SFTP programs, so that it would make no difference whether the passwords were transmitted in the clear or not. However, this would be harder for spyware authors to do correctly, so it would at least raise the bar for a successful malware attack, and the number of compromised websites would be reduced.

Unfortunately, Web hosting companies don't have much incentive to make users switch to the more secure SFTP protocol. This isn't necessarily true of all security risks; sometimes the hosting company has a strong incentive to pass on the right wisdom (and select the right default settings) for their customers. From the hosting company's point of view, you could divide risks into three categories:

  • Risks where the hosting company pays a large part of the price for a customer's machine being compromised. For example, if a cyber-criminal takes over a customer's machine and uses it to launch a denial-of-service attack by sending it a flood of traffic, the hosting company will see that traffic spike on their network. The hosting company has the most incentive to help prevent these types of attacks.

  • Risks where the hosting company doesn't directly pay a price for the customer's machine being compromised, but they may have to deal with complaints sent in by third parties. For example, a customer's website could get broken into, and script tags could be inserted into the pages that cause visitors' machines to be infected with spyware. Those visitors might complain to the webmaster of the infected site, or they might complain to the hosting company, which then forwards the complaint to the webmaster. The hosting company may have to provide a few minutes of tech support to the customer, advising them to change their password and scan their own machine for spyware, but they probably won't incur any other material costs.

  • Risks where neither the hosting company nor the customer pays a price for the machine being infected, but the price is paid by "Internet users as a whole." The only attack that I can think of in this category, is an attack where a cyber-criminal inserts key words into your web page and links them to his site, in order to increase his Google ranking for searches for those key words. Neither the website owner, nor any visitors to the website, are victimized directly; the harm being done is that the quality of Google search results is reduced for everybody. The only reports of the attack would probably come from "good Samaritan" Web surfers, who tell the hosting company or the webmaster that one of their pages has been vandalized.

When a customer's FTP credentials are stolen, the price paid by the hosting company lies somewhere in the middle. An attacker who stole my current PublicEditorMyAss.com credentials would only be able to deface the content on the site, but they wouldn't be able to launch an attack against a third-party network (my PublicEditorMyAss.com hosting account doesn't have the ability to initiate an outgoing connection to a third-party site).

Weighing in the other direction are the costs of switching to SFTP. If existing customers are forcibly switched over, phone lines will be clogged by customers wanting to know why their old method of logging in to their site has suddenly stopped working. A better choice would be to allow existing customers to stay with FTP while making SFTP the default for new customers. But there is a time and money cost of changing anything, even a default setting.

So GoDaddy doesn't have much incentive to make SFTP their new default. Indeed, I've used many different shared hosting companies before I started running proxies exclusively on dedicated servers, and none of the shared hosting companies ever used anything but FTP as the default method for customers to administer their websites. So who can blame them? They're not making the choice that makes the most sense for their customers or for Internet security as a whole, they're making the choice that makes the most sense in terms of costs and benefits for themselves, and I'm not being judgmental about that. We shouldn't expect most companies to ever behave in any other way.

That's why I think that glib "solutions" to security problems, like "Everybody install anti-virus software", or "Everybody stop using Windows", aren't helpful, because regardless of whether these ideas would work if everybody actually followed them, the fact is that most people won't. The problems have to be addressed in terms of changing incentives for the choices people make.

What's an idea for reducing the risks of FTP credentials stolen by malware, that addresses the incentives problem? Maybe give tax breaks to Web hosting companies that set up customer accounts to use SFTP instead of FTP by default? Or ask more computer vendors to include a desktop link to pre-installed SFTP software, so that when Web hosting companies present options to their customers, it's easier for users to choose the SFTP option since they have a client already installed? (I was tempted to recommend that Microsoft include a universal SFTP client pre-installed in Windows with a prominent desktop link, but the problem with that is that if almost everybody used the same SFTP client, malware authors would have greater incentive to reverse-engineer the algorithm that the client used to store saved passwords -- and then passwords would be just as easily accessible to spyware, as if the user were using FTP all along. So a good mix of SFTP clients is safer for this purpose.)

Since the difference between SFTP and FTP usually only matters in cases where a customer's machine has been infected with malware, obviously the best solution is to avoid malware altogether, but that's much harder problem to solve, as long as malware authors can keep finding security holes in Internet Explorer and other popular programs. Making SFTP the new standard for Web hosting accounts is something that we know how to do, right now. The incentives aren't currently right for Web hosting companies to make it happen. But there may be ways to change that, and I'll bet some people can think of better ideas than the ones I've suggested. I'm just saying that the incentives problem is where attention should be focused.

This discussion has been archived. No new comments can be posted.

R.I.P. FTP

Comments Filter:
  • by Godeke (32895) * on Monday July 13, 2009 @11:20AM (#28676899)

    I know of only two instances where I've ever definitely been infected with spyware. I don't do stupid things like downloading and running strange programs from third-party sites, so I think both infections were probably caused by a site exploiting a security hole in Internet Explorer, or in a plug-in like Adobe Acrobat or the Flash player. Both times, once I noticed I was infected, I got rid of the infection with Malwarebytes, but I don't know how much damage the spyware did in the meantime.

    Malwarebytes is good software, but as you point out you don't know how much damage was done. Secondary infections can easily be missed, and many malware programs open your machine to further exploitation. As tired as the suggestion is, you needed to do what you did with your website: revert the machine to a known good backup of the system state, formatting first. Anything less and you *should* have that nagging doubt that you haven't actually cleaned everything up. There are ways to diminish the concern: inspecting the machine for unexpected packet flows, using anti-rootkit tool, etc... but only by formatting and restoring a know clean state or formatting and just restoring your data files will you be confident).

    • by Phroggy (441) <.moc.yggorhp. .ta. .3todhsals.> on Monday July 13, 2009 @12:23PM (#28678029) Homepage

      This assumes your "known good" backup is really clean. If you can't tell whether your current system is clean after removing the malware, how can you know whether your last backup was clean?

      • Re: (Score:3, Informative)

        by MindStalker (22827)

        Exactly. A reinstall of your operating system is your best bet. While you will obviously have to copy the files back over you should be able to scan the files before/during copying. The files will only reinfect upon launching them generally not upon copying them (some old DOS systems excluded).

      • Re: (Score:3, Informative)

        by BikeHelmet (1437881)

        Some of the stuff that can be missed by a thorough examination can't be purged through a reinstall.

        I'm talking about those nasty buggers that hide in the BIOS chips, and re-infect on OS reinstall.

        My (current) computer has never been infected by a virus or any malware - but I'm so anal that I open any possibly dangerous links in Opera, with all plugins disabled, rather than my default browser. (Firefox)

        I also type many sites into the address bar in a form that'll go through Google's servers(www.slashdot.org

    • Re: (Score:3, Funny)

      by clam666 (1178429)

      I told you people the God-damned internet was going to be a problem when you bought it, and now you're messed it up real good.

      Next time listen to Daddy. Your mother and I told you pr0n and dirty pictures would lead to nasty business. Now we can add this one to the list.

      1. Blindness
      2. Hairy Palms
      3. Broke the God-damned internets
  • by Canazza (1428553) on Monday July 13, 2009 @11:21AM (#28676937)

    Back we go then to HTTP based web forms...

    • by suso (153703) * on Monday July 13, 2009 @03:24PM (#28681131) Homepage Journal

      I'm the founder and main admin of a web hosting company [suso.com] and we've been trying to switch people to SSH/SFTP/SCP for many years. We even put an ultimatum on FTP users back in 2006 that by the end of the year, we'd be turning off FTP. You know what happened? Users backlashed and complained that their old antiquated website software like old versions of Dreamweaver or whatever couldn't do SFTP or SCP even though versions that did had been available for a few years. Also, people who came from other hosting companies too us didn't know about more secure protocols and complained when they had to switch away from their old programs that they liked, even if WinSCP works great. So in the interest of keeping customers, we had to leave it on. We've been pushing SSH since the 90s. And I wrote the # 1 ranked SSH tutorial on the net. So how do you think I feel? Its a really annoying problem and it may take several more years before it completely goes away.

      On the other hand, there is one thing that I haven't seen available with SSH and that's the ability to have virtual users and let them be created by the parent user. Maybe there is a trick to make it possible in SCP/SFTP, but there are customers out there who need the ability to have sub users who manage parts of their site and so on. Many FTP servers allow this, but SSH does not. So this is another FTP feature that keeps it going.

      And while I'm griping about it, it REALLY doesn't help the situation that WinSCP started supporting FTP.

      • Re: (Score:3, Informative)

        by x2A (858210)

        Tunnelier [bitvise.com] is rather good, includes an FTP bridge. Connect to your ssh server, and it listens on localhost for ftp commands, translates and sends them to your server over ssh. Not only means encryption, but also compression (something I often care more about). Will sit in your system tray and auto reconnect if connection drops, and enable all old ftp-only software to talk to an ssh only server. I talk to everything over it, mysql, imap/smtp, even web traffic can be sped up.

  • RIPFTP! (Score:5, Funny)

    by SteveHeadroom (13143) on Monday July 13, 2009 @11:22AM (#28676957) Homepage

    Isn't that the sound someone makes after eating enough chili or lentils?

  • This came up in a class I took at college. It was a bullshit "internet concepts" class, where they talked about setting up a website, basically. One of the things they talked about was ftp and how it's used to upload content to your "web host". Needless to say I felt the need to hurt those responsible for promoting this crap. While I did the assignments as they wanted, I made it a point to try to educate people in the class as to the proper protocols to use for uploading content.

    • Re:Amusingly.. (Score:5, Insightful)

      by Archangel Michael (180766) on Monday July 13, 2009 @11:37AM (#28677215) Journal

      So, how does one upload to a website? CPanel? Secure Shell? Do Tell! You know, not everyone manages their own server ....

      • by davidwr (791652) on Monday July 13, 2009 @11:49AM (#28677403) Homepage Journal

        I send my files in by paper tape [wikipedia.org] sent by a bonded, armed courier.

        • Re: (Score:3, Funny)

          by LihTox (754597)

          I send my files in by paper tape sent by a bonded, armed courier.

          You only think he's a courier. Muhahahaha!

          (Now where's that Anonymous button...?)

      • Re: (Score:2, Insightful)

        by maxume (22995)

        If you are maintaining a local copy and then 'uploading' it to the server, you freaking use rsync. If your host doesn't support rsync, you quit them.

      • scp would be my protocol of choice.

      • Given the fact that most websites will be hosted on a Linux box I would say that using either scp or sftp (both of which use the server's ssh server) is the most secure way to go. It's what I use and there is a GUI tool for those using Windows on the desktop (WinSCP) [winscp.net]. As for how you would get around this if using a Windows/IIS server I wouldn't have the first clue and my advice would probably be along the lines of "get a man's operating system and stop using asp"!
        • Re:Amusingly.. (Score:5, Informative)

          by ThePhilips (752041) on Monday July 13, 2009 @12:23PM (#28678017) Homepage Journal

          Given the fact that most websites will be hosted on a Linux box ...

          That makes it easier. Most Linux systems I have installed in past years don't have ftpd preinstalled.

          On security note, default configs of ftpds found in Fedora, SUSE and Debian are [censored] insecure: they allow anonymous to access anything on hard drive while rejecting (even over SSL) valid users.

          Unfortunately, raw FTP still rules when you need a high bandwidth. With SCP/SFTP I get consistently 4-5 times lower transfer speeds compared to FTP. It doesn't matter much if one transfers megabytes. But SCP/SFTP becomes a pain when one needs to upload dozens/hundreds megabyte. 'tar cf - . | ssh tar xf -' trick speed things up, but not always available.

          As for how you would get around this if using a Windows/IIS server I wouldn't have the first clue and my advice would probably be along the lines of "get a man's operating system and stop using asp"!

          IIRC, M$ stack uses WebDAV over HTTPS for such stuff. Abomination had spared me, thus do not have any performance numbers.

          • Re: (Score:3, Insightful)

            I used to work at a place where we used SCP to throw files around on the local 10/100 network. Those transfers always maxed out the network speed (11MBps or so). FTP didn't go any faster... I'm guessing your problem was elsewhere :P

          • Re: (Score:3, Informative)

            by Bert64 (520050)

            SCP is 4-5 times slower than FTP? What kind of CPU do you have?
            I am easily able to saturate a 100Mbit link using a core2 system thats a couple of years old now... Even on a 1Gbit link i think the disk is the bottleneck moreso than the encryption these days.. Yes it uses a lot more cpu, but it isn't any slower.

            Perhaps you are using an extremely poor implementation of SCP?

            • Re: (Score:3, Informative)

              by ThePhilips (752041)

              Nothing special: Linux to Linux over GB LAN or the internet. CPUs are C2D or AMD X2 or better.

              Also note that SCP/SFTP transfer files one by one and the handshake times (especially if you have number of smaller files) dominates over actual file transfer times. That's why I have mentioned the tar trick. FTP for whatever reasons doesn't have the problem.

              • Re: (Score:3, Informative)

                by profplump (309017)

                FTP opens an entire new TCP connect for each file transfered, and is plenty chatty in the command channel while that happens. It's probably not the handshake times that are slowing you down.

                More likely it's the relative inefficiency of SFTP on high-latency links -- SFTP has a relatively small transfer and pending request window, which means that with any significant latency you'll spend a lot of time waiting for confirmations instead of actually sending data.

                For example, in OpenSSH prior to 4.7 the default

          • Re: (Score:3, Informative)

            by Tanktalus (794810)

            A tar trick? At least add Z, z, or j to the commands: tar cjf - . | ssh tar xjf -. Or, simpler, try rsync -avz --delete -e "ssh -l webhostuser" . myhost.org:. The bz2 compression (j option for tar) probably has better compression, but rsync compresses some things that tar can't (see rsync's man page).

          • Re: (Score:3, Interesting)

            by raju1kabir (251972)

            Unfortunately, raw FTP still rules when you need a high bandwidth. With SCP/SFTP I get consistently 4-5 times lower transfer speeds compared to FTP.

            Switch to the blowfish cipher, it will speed things up substantially. This is an option in most gui clients; in openssh you can use the -c switch.

      • Re:Amusingly.. (Score:5, Informative)

        by Hatta (162192) * on Monday July 13, 2009 @12:16PM (#28677877) Journal

        Rsync.

      • Re: (Score:3, Insightful)

        by Bashae (1250564)

        You'll be fine if you take care of your own computer (which you do indeed manage). This article states that FTP is insecure, but that is based on the assumption that everyone's computer is infected periodically. So if your server is secure and your computer runs a secure OS, or at least a good firewall, a good antivirus, all security patches and is periodically scanned for malware, I don't see what harm the evil spammers can possibly cause.

        Personally I barely follow a half of that advice, and yet I am never

  • WebDav (Score:5, Informative)

    by lymond01 (314120) on Monday July 13, 2009 @11:25AM (#28677001)
    • Frankly, in my opinion, WebDAV is a slow and unreliable p.o.s.

      I prefer properly configured/secured sshfs/sftp over webdav in all cases.

      And with FUSE it is really comfortable. I run the following on login:

      sshfs -o follow_symlinks,nonempty,idmap=user,allow_root $USER@$SERVER:. /home/$USER/server.$SERVER

      Which gives me complete transparency. :)

      (For Windows I recommend WebDrive, which can do the same.)

  • It doesn't matter (Score:5, Insightful)

    by RenHoek (101570) on Monday July 13, 2009 @11:29AM (#28677067) Homepage

    Look, if your machine is infected by malware, it's not going to make any difference if you use FTP or SFTP or god know what else.

    Either your passwords are stored on your harddisk or you're going to have to type them in at a later point. In both cases software is going to be able to get your passwords. And they have that they can get in without a problem, regardless of protocol used.

    So instead of this looooong article, some more vigilance online to avoid the infection to begin with would be more helpful.

    And if you _have_ to use MSIE, use SandboxIE.

    • You're missing the point. If you're using FTP a hacker has no need to infect your machine. All he has to do is intercept your packets that you sent out to the public internet, and he has your password to the FTP account.

      • Re: (Score:2, Informative)

        by hrimhari (1241292)

        And it looks like the article also missed your point, since it says how intercepting packets in public internet is not the problem, but infecting your machine to sniff them from the source.

      • How often does that actually happen, in this day and age? Compared to the accounts that are comprimised by other means? I mean, every time there's a security conference someone makes a point of capturing FTP and POP3 passwords sent in the clear, but how often does this happen in the wild? Even if you were able to comprimise some big-time router on the internet somewhere, it seems like you'd have larger fish to fry than intercepting the FTP passwords for Flo's Florist (100 unique visitors per day!)
        • Re:It doesn't matter (Score:5, Interesting)

          by a-zarkon! (1030790) on Monday July 13, 2009 @01:00PM (#28678683)

          Funny, I've heard the same arguments against implementing encrypted protocols and banning plain text protocols too many times to count:
                1) That's not possible on a LAN because we have ______ select from (switches/firewalls/antivirus/leprechauns)
                2) That's not possible because someone would have to hack into the Internet to see that traffic
                3) That's not possible because anyone who could do something that tricky would not waste their time on us
                4) It doesn't matter because we don't have any _____ select from (credit cards/SSNs/personal info/nuclear launch codes)

          In my experience and at the risk being modded a troll (believe me, that is not my intent) these assertions are typically made by system admins who resent being asked to change the way they do anything and generally won't take a step in the right direction until they've already been burned. Let me state that these arguments are all wrong. However, let's conveniently side-step the proving of why these assertions are wrong for now. Instead let's examine the alternatives:

          -Replace Telnet/RSH with SSH
          -Replace FTP with SFTP or SCP
          -Replace HTTP with HTTPS (at least for sensitive data and/or authentication)

          In all cases, implementing a secure access method is relatively trivial. Even if you don't believe in Santa Claus - is it going to really cause you that much hassle to leave a couple of cookies and a glass of milk out on Christmas Eve just in case?

        • Re: (Score:3, Interesting)

          by Bert64 (520050)

          A lot of web hosting is done on colocated boxes, sitting on a lan with a lot of other colocated boxes... If one of them gets compromised, running a sniffer to capture insecure logins to the others is not too hard.

      • Re: (Score:3, Informative)

        by tehdaemon (753808)
        As if the other replier weren't enough... In order to read your IP packets some machine in the network between you and the FTP server needs to be compromised. And the easiest by far is your own machine. The whole point of this story is that malware does just that - it sniffs the packets as they leave your own machine to get those passwords. That is easier than installing a keylogger.

        T

    • Re: (Score:3, Insightful)

      by Goaway (82658)

      You know, the article addressed that, but let's have it one more time:

      Sure, a determined attacker with malware on your machine can get your password for anything. But these aren't determined attackers. They are people throwing their nets very, very wide, and they rely on automation to find their passwords. Getting every keystroke isn't going to tell them what your password is without manual analysis, and nobody has the time for that. And making your keylogger smart enough to figure it out by itself requires

  • FTPS (Score:5, Informative)

    by xororand (860319) on Monday July 13, 2009 @11:30AM (#28677089)

    It's unfortunate that FTPS still seems to be widely unknown. FTPS is an extension of the FTP protocol which secures the control & data channels with TLS. It's standardized in RFC 4217.

    Restricting users to their home directory is much easier with FTPS than with SSH. The latter requires you to setup a chroot jail for each user. At least OpenSSH has built-in chroot support that allows you to specify a chroot environment for each user via /etc/passwd.

    Many FTP clients and servers support the FTPS protocol, for example:
    * FileZilla
    * curl (and curlftpfs)
    * lftp

    Servers:
    * vsftpd (can enforce encrypted FTP)

    • Re:FTPS (Score:5, Interesting)

      by hardburn (141468) <hardburn@@@wumpus-cave...net> on Monday July 13, 2009 @11:46AM (#28677341)

      Does it fix FTP's multiple port usage? This design is a constant source of problems on firewalls, particularly stateful firewalls. Many types of firewalls from various vendors and operating systems have been penetrated over the years due to handling the complexities of FTP's port usage. There are fixes out there, of course, but the problem would go away if we standardized on OpenSSH SFTP.

    • by danaris (525051) <danaris@@@mac...com> on Monday July 13, 2009 @11:50AM (#28677435) Homepage

      I have tried to set up an FTPS site.

      Even with vsftpd, I was unable to configure it with settings that allowed it to connect with more than 1 different type of client at a time. So far as I can tell, there are a half-dozen different implementation of FTPS out there, none of which are able to interoperate properly.

      SFTP is much more standard and well-supported, and more or less just works, and there are various tutorials out there for setting it up.

      Dan Aris

    • I actually only let people on my server, that I trust to have shell access, and to be able to properly use it in the first place. This gives them many advantages too.

      Ok, I run SELinux on the box anyway. ^^

    • by BitZtream (692029)

      So many reasons why this post is silly:

      chroot is not a jail, its a hack to make shitty software work in a specially constructed enviroment. It does not in any way prevent a malicious program from breaking out of the chroot, it just makes a poorly written one have the option of working in a special section of the filesystem where you can put specific versions of files without effecting the entire system.

      FTP without a chroot is not really any different than ssh without a chroot. If you're just depending on

      • Re:FTPS (Score:5, Informative)

        by Hatta (162192) * on Monday July 13, 2009 @12:21PM (#28677989) Journal

        How does one break out of chroot [linuxsecurity.com]?

        Third, if there is no root user defined within the chroot environment, no SUID binaries, no devices, and the daemon itself dropped root privileges right after calling chroot() call (like in the code below), breaking out of chroot appears to be impossible. In other words, if there is no way to gain root shell or perform actions that only root can usually perform (e.g. create devices, or access raw memory) breaking chroot is not clearly possible. Ideally, if the custom software uses chroot for security the sequence of calls should be:

        chdir("/home/safedir");
        chroot("/home/safedir");
        setuid(500);

        Keep in mind, that after these lines are executed there will be no way for the program to regain root privileges.

        Chroot can clearly add to security if used correctly.

        • Re:FTPS (Score:4, Interesting)

          by mzs (595629) on Monday July 13, 2009 @02:51PM (#28680663)
          Okay the guy you replied did not write in a pleasant way but he has a point. chroot is not jail, chroot is easy to break out of on many systems. The reason is because once you are chrooted you can call chroot yourself. The canonical approach to break out of a chroot jail that has been known about now for 10 years or so works like so:

          mkdir "foo"
          fd = open "."
          chroot "foo"
          fchdir fd
          for (i = 0; i < 0x100; i++) chdir ".."
          exec "/bin/sh"

          Most chroots don't change the the cwd so the fchdir is often not needed also the dirent approach works as well in other cases.

          So now you are running as nobody or yourself and you can use the local privilege escalation of the day to get root access, but just breaking out of the chrooted environment may have been the goal, you know like you were not supposed to be able to run a shell at all. Or you may now run some denial of service (local or remote).

          So some systems prevent this. One notable is BSD where chroot fails if you have fds open. There also are other approaches for breaking out of a chrooted environment, as well as countermeasures.

          One point is how would you run this stuff at all. Well one argument is that this might be a webserver where you have CGI and therefore an interpreter like perl, and doesn't that example I wrote there look a whole lot like perl. The other argument is that this was first seen in the wild against wu-ftpd back in 1999, and it used a buffer overflow to inject that same code to break out of the chroot jail and execute the shell in place.

          So the argument I am trying to make in a much more civil manner is that if you need something like jail, use something like jail and not the poor substitute of chroot instead.
      • First: It's not just "shitty software". It can be very useful for things like installation. I always like the Gentoo Linux approach -- format the disk yourself, mount it, untar one tarball, and chroot for the rest of the installation.

        Second, every single security "problem" with chroot is based on the root user breaking out. Non-root users cannot break out of a chroot'ed environment. It therefore does add some additional security.

        And finally:

        If you're just depending on the authors of your ftp daemon to protect you then your an idiot.

        If you don't see the difference between explicitly allowing any use

      • Re: (Score:3, Insightful)

        by fnj (64210)

        Horse shit. chroot is a tool. Used properly, where applicable, it can greatly enhance security. Used improperly, it does little or no good. It doesn't matter what it was invented for; it doesn't matter how many times people make blanket statements about it; the fact is that it can be used as a useful security tool.

        Some of the other commenters point you to sources detailing chroot's weaknesses and pitfalls, and how to avoid them.

        There is no perfect, cure-all security measure. That doesn't mean you don't

    • Until FTP can let me use a keypair instead of a password, I'll stick with OpenSSH public key authentication.

      Never mind that ssh only requires a single port to be open...

      Of course, it depends on your goals, but there's also the fact that I wouldn't pay for a server that I didn't already have some sort of shell access to. Since I already have ssh access (I'm assuming we're not even considering telnet), I already have scp and probably sftp.

    • One major issue with FTP over SSL/TLS is that network address translation (NAT) devices, such as firewalls and load-balancers, that eavesdrop on the FTP control channel in order to open dynamic data ports fail hard with FTPS.

      If you use "explicit mode" FTPS, the client negotiates up to FTPS via a standard port 21 connection. After secure authentication, they can issue a 'CCC' (clear control channel) command which backs the control channel back to a NAT compatible mode. Problem is, this is a client side opt

  • (What percent of users ever change the default set of toolbars that are displayed at the top of their Web browser window?)

    I'm guessing that when it comes to users who administer their own websites, and do it through FTP rather than the Geocities page builder, it's actually pretty high. This is a group of people that could probably navigate a simple menu to the SSH toggle intuitively. Now, the whole phone-number-PIN rigmarole is an un-necessary headache, but generally this isn't an end-user usability issue

  • by Anonymous Coward on Monday July 13, 2009 @11:33AM (#28677137)

    Our end users keep asking and referring to FTP, when all they need is a way to transfer files temporarily (especially when the email server doesn't like 2 gig attachments). So we setup a web interface to post files, download them, and autodelete. They have been happy with it since then. What do they call it? The FTP server.

    The FTP term has lost its meaning to represent a protocol (which is what the IT staff thinks of it as) vs the end users with think of FTP as a generic term to transfer files.

  • With SSH you also know you are talking to the right server, not a man-in-the-middle or a DNS hijack.
    • Re: (Score:3, Informative)

      by minsk (805035)

      Most SSH clients will verify that you are connecting to the _same_ server as last time. However they can not verify the actual identity of that server.

      (Well, server with the same key as last time you connected to that domain name or IP, but close enough)

      • by hackel (10452)

        Then you don't know how to use SSH properly. You need to obtain the public key beforehand, and then *verify* it the first time you connect to a host (you know, when it prints the fingerprint and asks you, "Are you sure you want to continue connecting?") Even Putty in the Windows world does this. It's extremely important.

        • I like that this is an option.

          Of course, I'll be honest -- I still often say "screw it" and just connect, rather than trying to transfer the key ahead of time, verify the fingerprint, etc. But then, I only connect from my laptop, and I intuitively know which machines I've already connected to, and which will give me the security prompt. So, generally, once I've connected once without a MITM, every connection from then on is secure.

  • by King_TJ (85913) on Monday July 13, 2009 @11:35AM (#28677173) Journal

    Switching from FTP to SFTP on the server side is great, in theory, but it's really only a trivial task for people running Unix type operating systems.

    SSH isn't an integral part of most Windows operating systems, and nearly all of the well-regarded, commercial FTP servers for Windows have no SFTP support in them.

    (I understand the Serv-U FTPD for Windows does support it, but it's an exception to the rule.)

    I recently ran into this at my workplace. We've run the commercial WFTPD product (from Texas Imperial software) for years, but I had to get rid of it when our bank started requiring SFTP connections to send us electronic scans of daily check deposits.

  • Any credentials being stolen is a security Risk. I had some sites on Ipowerweb, which the credentials were stolen. They deny all knowledge of it, but it was the only source of the leak. I tracked this when I moved a site to my own server, but used the same credentials.

  • My Server (Score:5, Interesting)

    by ironicsky (569792) on Monday July 13, 2009 @11:36AM (#28677205) Journal
    I run a linux server that has FTP services on it.I did have an issue a while back where someone's ftp account got cracked, someone uploaded a malicious root kit, then executed it through the web and... BLAMO! I was compromised. Every .html and .php file on the server was over written. I didn't feel like cleaning it up, so I just loaded the back ups on the a clean server and took the compromised one out of production.

    But I did make one change on the new server... I upped the security substantially. One of the changes involved enforcing SFTP and discontinuing my FTP services.

    For me, all it took was one serious compromise to wake me up. I'm sure for a lot of other people it will be the same.
    • A rootkit compromises your entire OS by modifying system files and binaries and allowing remote root access. Mucking up the web server files is annoying but hardly in the same league. And more fool you if you ran apache (or whatever) as root. Also if you'd set it up properly you wouldn't have to "clean it up". You'd just rm -rf the web server directory tree and untar from the backup you made the previous night, right?

      • by ironicsky (569792)

        That does make sense and I agree. Apache doesn't run as root, it runs as nobody. But the person uploaded a php executable which broke out of the nobody and went gallivanting around the server. From there, it messed with my cPanel, renaming all index and php files
        And then it did indeed root the server, certain programs started acting strange, random processes would start, my w and who commands were coming back blank, etc...

        I learned early on from my windows days that once a server is compromised the best thi

  • by kenp2002 (545495) on Monday July 13, 2009 @11:39AM (#28677253) Homepage Journal

    SSH, SFTP, SCP, FTP, ZMODEM, KERMIT, AND ALL THAT CRAP MEANS NOTHING!

    Why? because moron employees surfing for p0rn at work will get a keylogger by accident installed and grab more information then packet sniffers EVER will. Regardless of how well the encryption is the keylogger and malware will trump all measure if employees are careless.

    You can get a silent VNC session going and lockout the physical keyboard and mouse and by the time they figure out what has happened you have enough control to grab what you need.

    Hell just track the next time they go to amazon.com or any onther online site. Who gives a rats ass about SSL when you are seeing them type in their info?!

    FTP vulnerable? No more then your home phone line or cell phone. The problem is and always will be PEOPLE. One they have control of the physical machine all bets are off for ANY security measure.

    Arguing protocols being secure or not is like arguing which unloaded gun is more dangerous....

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Two words: "ssh keys".

      Any passphrase associated with an ssh key is meaningless to keyloggers unless they also get the keys themselves. Far as I know, most modern keyloggers aren't that sophisticated yet. Granted, they could very well become so, but so long as Windows users are kept in the dark about SSH/SFTP and keep using Telnet/FTP, they probably won't...

      Waaaaaaait... THAT'S why FTP is still around! A decoy against users with keylogger'd machines! Keeps the rest of us safe! NOW I get it!

    • Re: (Score:3, Funny)

      by Hurricane78 (562437)

      Yeah! That's why I replaced all my employees by very small shell scripts. :P

    • get rid of the people

      all joking aside, people are people. they are a known quantity. as such, they are the yardstick against which we judge securability, not to which we assign blame. and since this whole intarwebs thing is relatively new, then the obvious answer is we have a long way to go to fix the TECHNOLOGY so that the people in the equation can't cause as much damage as they are now doing

      its very easy to blame the lusers. your post means nothing

      • Re: (Score:3, Insightful)

        by kenp2002 (545495)

        its very easy to blame the lusers

        That's because they are the largest contributor to an insecure system.

        your post means nothing

        My post means that you are better off spending more time training people then finding new technological ways to make things stupid-proof.

    • by Abcd1234 (188840)

      Arguing protocols being secure or not is like arguing which unloaded gun is more dangerous....

      Oh please, that's bullshit. Keyloggers a) need to get installed in the first place, b) need to not get detected by a virus scanner or malware detector, and then c) need to be installed on a machine where the user accesses a sensitive site. And most of those issues can be mitigated with a properly secured OS.

      A broken daemon configuration or protocol simply requires the hacker to exploit it.

      So you're telling me tho

      • Re: (Score:3, Insightful)

        by tibman (623933)

        I recently read about a keylogger that plugs into your powergrid and can read keypresses up to 15 feet away via groundwire. There are even physical keyloggers that sit between the keyboard and box.. how easy would it be for the wife or friend to do this while you take a bio break? Software keyloggers can be very benign and go undetected for long periods of time too. Lots of programs use "global hotkeys" and similar features which function in the background to monitor all keyboard input and trigger zero a

    • RTFA! (Score:3, Insightful)

      From TFA:

      I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer.... So, I assumed it made no difference whether I used FTP or SFTP.

      But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted

      Same goes for keyloggers, by the way. You can look at everything I type and hope you get a password, or you can just intercept FTP, where you know exactly where the password is being sent.

      Not that we shouldn't protect against keyloggers, but why would you make it easy?

      FTP vulnerable? No more then your home phone line or cell phone.

      Not true -- while eavesdropping is probably easier with a phone conversation, man-in-the-middle attacks are much harder. If you said something, I know it was you who said it, because it sounds like you -- whereas with FTP, the server

  • by BigJClark (1226554) on Monday July 13, 2009 @11:41AM (#28677287)

    Its an amazingly simple protocol, lightweight, and easy to setup and administrate. Concerned about security? Tunnel it with SSH. I think there is a packaged app out there somewhere (sftp?), but really, I tunnel all insecure protocols with SSH, using an incredibly simple, yet powerful app (putty).
    • Exactly. I remember that this modularity was called "the Unix philosophy".

      But now many people use Unix-like OSes (even if only indirectly), and do not understand this, because they are crippled by their tiny Windows world of big monolithic desktop apps.

    • by Abcd1234 (188840)

      I think there is a packaged app out there somewhere (sftp?),

      Ah, no. SFTP is a completely different protocol, a file transfer protocol layered over SSH that's separate and distinct from FTP. In fact, tunneling FTP over anything is non-trivial, thanks to FTP's dual-channel nature.

      Concerned about security? Tunnel it with SSH.

      But... if you're going to tunnel with SSH anyway, why wouldn't you just use (the real) SCP/SFTP? It's even more easily secured, and it's firewall friendly, too. For Gnome/KDE users, yo


      • Fair enough, I've just come to realize there is a distinction. The reason why I don't use SFTP probably is because I'm a creature of habit, and I'm quite used to firing up putty, then remoting in, or doing whatever business I have to do. To be honest, I might FTP only a couple times a month, so its not as though I'm losing any productivity.

        When I get some time (I'm way too busy reading slashdot articles, as you can tell ;) ), I'll give SFTP a thorough read-through.
  • ...user gets infected with spyware, is surprised when information is stolen as a result? Y'know, it's called spyware for a reason.

          --- Mr. DOS

  • The reality is, only the kind of people who read this site actually give a damn, and I bet for at least some, it's an academic concern.

    Hosting companies don't care.

    Server management software vendors (CPanel, etc) don't care.

    Other vendors whose software relies on FTP (Dreamweaver, etc) don't care.

    Why don't they care? Because retraining users and staff is something on which they can all put a reasonably certain dollar amount, which is almost certainly higher than maintaining the status quo of tedious disclai

  • SFTP...use it. That or make a torrent and set it so only those given the torrent can access it. Different torrnet programs have different privacy capabilities to allow you to utilize their program to transfer files, securely, from your computer to a specific recipient.
  • The security lie (Score:5, Insightful)

    by Lord Bitman (95493) on Monday July 13, 2009 @12:00PM (#28677595) Homepage

    Once you have discovered you are infected, the ONLY way to be safe is to assume that you have also been infected in at least 100 other, undiscovered, ways.
    Security companies like to sell the lie of "buy our product! Be safe! And if something slips through, just hit "delete" and be safe again!" but it really doesn't work like that: If there's one, there's three, and those three turn into a hundred very easily.

    The only way to be safe is not "buy some guy's security software" (you're machine's been compromised, how the hell is running something else on the same machine supposed to help??), it's "reformat, treat every backed-up file as compromised". Sad, annoying, true.

    In summary: when you found out you were infected, you did the equivalent of nothing at all, then were surprised when a password was stolen several months later.

  • by hackel (10452) on Monday July 13, 2009 @12:11PM (#28677789) Journal

    Amazing how this article (and so many people responding) seem to be missing the point entirely. The real problem is people using operating systems that are vulnerable to these types of attacks! I don't know about Vista, but even if Linux was ever targeted for this kind of attack/spyware, you would have to run the software as root to enable packet sniffing! And anyone who uses IE for regular browsing and not just local site development is clearly not a competent web developer and has no business working in this industry! Seriously--how can anyone still use IE, FTP, or anything like that in this day and age? I think I stopped using FTP, what...10 years ago now?

    The bottom line is that all hosting companies must disable all access to their services via insecure FTP. It's shameful how many companies still use it. I'm in such an isolated bubble, apparently, that I didn't even know this was still going on until recently I had to access a shared web service to migrate a particular client. I was shocked, to say the least! Secure-FTP (over SSL) is not sufficient as it only encrypts things without verifying the authenticity of the host you are connecting to. It's bad enough that people keep using Windows, but since we can't control this, competent sysadmins really need to take the initiative in disabling FTP. Likewise, unencrypted pop3, imap, telnet, or whatever unencrypted services they provide.

    • So your point is that you isolated yourself in an ivory tower surrounded by people who think like you do, and you're shocked and disgusted at what the great unwashed masses are doing? How can you live in such a small world? What are you, a journalist?
    • encrypting the connection isnt going to do you any good when the crapware is running *on* the client machine, which has to have the cleartext pasword and/or private key in order to establish the connection. Really 'packet sniffing' isn't really the big danger. ISP networks rarely have windows machines (at least not connected where they have access to sniff anything,) and the network routers and switches are rock solid.

  • Wrong debate (Score:2, Offtopic)

    by The Cisco Kid (31490)

    ftp vs sftp is not the issue.

    using windows to (ftp *or* sftp) vs using a secure platform to (ftp *or* sfp) is the issue.

    Switching to use sftp using going to do you any good if you are still working from a windows based client, and your stored passwords will still be stolen by the deluge of crapware that windows is specifically designed to support.

  • From TFA:

    And if an attacker managed to do that, then I assumed that the risk of passwords being stolen by spyware was about the same whether I used FTP or SFTP -- because either way, the spyware could just steal my password by reading it out of a configuration file where the password was stored. (Even though FTP and SFTP programs both store passwords in an encrypted format, the programs have to be able to decrypt the passwords in order to use them whenever the user wants to open a connection. So the spyware could just mimic whatever steps the client programs use to decrypt the stored passwords, in order to steal one of my passwords stored in a file.) So, I assumed it made no difference whether I used FTP or SFTP

    This is incorrect. A decently-written program will not store your password anywhere, either encrypted or as plaintext. What it will store is a one-way hash of your password. When someone connects, it will compute a hash of the password they entered and compare it to the stored hash. Nowhere in this process is the actual password decrypted.

    Rainbow tables allow one to attack these kinds of schemes, but adding salt to passwords basically makes even this impossible.

    This may seem to contradict the "

  • by gmuslera (3436) on Monday July 13, 2009 @12:27PM (#28678123) Homepage Journal
    No protocol is secure if your side aren't. A keylogger, in your pc, not in the remote site, defeats anything that is password based. Trojans that read or steal configurations of common clients (even ssh certificates) also defeats a lot of usually secure solutions. Even installing software that enables remote administration and not worrying ever about announces of remote vulnerabilities is wrong. When worrying about something that can be accesed in internet, remember that you are in internet too.

    Where you should start changing things? replacing the ftp protocol? the ssh protocol? tcp protocol? Start changing yourself, securing your desktop in effective ways (drastically lowering odds switching away from windows could be an start), and how you use it.
  • by Vellmont (569020) on Monday July 13, 2009 @12:55PM (#28678605)

    What I get from this overly long article is the author thinks that simply by not being the same as the herd (the herd being people who use FTP) that increases security.

    While there's some truth to this, it's a lot less than you think. Being different in one way doesn't save you from all the other ways you're the same. If someone can install malware on your machine, a keylogger would grab ANYTHING you type in. It's not too hard to parse out all of that for username/passwords. It's like saying having a strange non-standard layout to your house keeps you safe from really dumb burglars that've already broken in.

  • FTP, rsync+ssh (Score:3, Insightful)

    by dwheeler (321049) on Monday July 13, 2009 @01:04PM (#28678755) Homepage Journal

    FTP is still fine for providing big files that don't need to be protected by a password. But yes, if you're CHANGING data, raw ftp is usually a bad idea.

    If you're uploading files, I heartily recommend using rsync+ssh. It's incredibly fast, since only the files that CHANGED are uploaded, and ssh makes it all secure. It can be a pain to set up on some cheap hosting sites, but I've figured out how to make rsync+ssh work even on some cheap hosting sites [dwheeler.com]. Hope that helps.

Aren't you glad you're not getting all the government you pay for now?

Working...