Yeah, of course you can use a VPS, but then you could have used FTPS-only mode in your own FTP server in the first place...
So I guess our conclusion is that most shared webhosts' security is simply crap because they only offer upload via FTP (plain) and HTTP/webdav (plain) and that you should use your own VPS.
If you only care about the integrity of your server FTP is (can be) perfectly fine. If you actually care about people downloading your software, add GPG signatures (note that SSL+certificates doesn't work well if you want to have many mirrors, which is common). Where exactly is the issue?
The FTP protocol uses plain text. Taking into account that it is most frequently deployed by web hosting companies, that lack of encryption implies a real risk for everyone.
It's not a rocket science to launch a network sniffer in an airport, a Starbucks or any other shared network, and capture the FTP credentials of a designer making quick changes to client's ecommerce site.
What makes it really bad is that nearly all web apps today include full database credentials, enabling an attacker to either wipe out the data or just copy it.
As we have already learned many times, the passwords are rarely stored securely, and users tend to routinely reuse their passwords. A database of any moderately succesful service makes it really easy to get access to hundreds of email, or Facebook, accounts.
Of course, this is just an example. There are few other attack vectors relying on that inherent weakness of the FTP protocol.
While it is not a backdoor technically, it comes pretty close to it, as it provides an effortless method to gain an unauthorized access.
In the past, FTP daemons were buggy and used to run as a root, making them pretty handy to exploit. Now, with privilege separation enabled, it's much better for the administrators but regular users are still at risk.
FTP tweaks, like FTP-SSL, are nice in theory but, in practice, they are provided as an option, some FTP clients do not support them, and they do not work well with many standard firewall configurations, due to the secondary data connection port.
Yes, the secondary data connection port is a weakness/annoyance of the FTP protocol, I agree. The other points don't have anything to do with the protocol itself, just with how it is implemented in specific cases.
Verifying the signature wouldn't have been that helpful. A different attacker might generate a similar key with the same name and sign the archive with that. How many of you check signature fingerprints (and how?) or have a chain of trust that leads to the maintainer?
In this case pretty low, because the maintainer's key is not in the "strong set" of the web of trust.
However there are more than 40k keys in that strongest set (see http://pgp.cs.uu.nl/plot/ for example), and if you care, you can easily get into that set by attending a key signing party a big open source conference. (I participated at a DebConf and LinuxTag, but I'm pretty sure OSCON also has one...)
Boohoo. FTP is by design an insecure and overly complex protocol, and any firewall-admins nightmare to handle.
Anyone using FTP in this time and age should be prepared for pain. That the pain is now related to a bug in a software-implementation instead of a bug in the base protocol-design doesn't really shift the pain that much. It's FTP and FTP is pain. You do get what you asked for.
If you want security and something simple to administer, just go for SSH and SCP. Granted, it wont allow anonymous downloads, but if that's all you need, why not just go with HTTP in the first place?
14 comments
[ 4.0 ms ] story [ 19.6 ms ] threadYeah, of course you can use a VPS, but then you could have used FTPS-only mode in your own FTP server in the first place...
So I guess our conclusion is that most shared webhosts' security is simply crap because they only offer upload via FTP (plain) and HTTP/webdav (plain) and that you should use your own VPS.
The FTP protocol uses plain text. Taking into account that it is most frequently deployed by web hosting companies, that lack of encryption implies a real risk for everyone.
It's not a rocket science to launch a network sniffer in an airport, a Starbucks or any other shared network, and capture the FTP credentials of a designer making quick changes to client's ecommerce site.
What makes it really bad is that nearly all web apps today include full database credentials, enabling an attacker to either wipe out the data or just copy it.
As we have already learned many times, the passwords are rarely stored securely, and users tend to routinely reuse their passwords. A database of any moderately succesful service makes it really easy to get access to hundreds of email, or Facebook, accounts.
Of course, this is just an example. There are few other attack vectors relying on that inherent weakness of the FTP protocol.
While it is not a backdoor technically, it comes pretty close to it, as it provides an effortless method to gain an unauthorized access.
In the past, FTP daemons were buggy and used to run as a root, making them pretty handy to exploit. Now, with privilege separation enabled, it's much better for the administrators but regular users are still at risk.
FTP tweaks, like FTP-SSL, are nice in theory but, in practice, they are provided as an option, some FTP clients do not support them, and they do not work well with many standard firewall configurations, due to the secondary data connection port.
Yes, the secondary data connection port is a weakness/annoyance of the FTP protocol, I agree. The other points don't have anything to do with the protocol itself, just with how it is implemented in specific cases.
Would be interesting to see how the site was compromised.
This is interesting for two reasons:
i) I thought he owned the place he hosted
ii) This won't help if he had a weak password
However there are more than 40k keys in that strongest set (see http://pgp.cs.uu.nl/plot/ for example), and if you care, you can easily get into that set by attending a key signing party a big open source conference. (I participated at a DebConf and LinuxTag, but I'm pretty sure OSCON also has one...)
Anyone using FTP in this time and age should be prepared for pain. That the pain is now related to a bug in a software-implementation instead of a bug in the base protocol-design doesn't really shift the pain that much. It's FTP and FTP is pain. You do get what you asked for.
If you want security and something simple to administer, just go for SSH and SCP. Granted, it wont allow anonymous downloads, but if that's all you need, why not just go with HTTP in the first place?