12

Okay, we know the drill: don't use FTP, use SFTP or FTPS.

But what exactly is the risk being posed? The files themselves are sent unencrypted, and this may be fine, or disastrous, depending on what the code in them contains. But, if we're dealing with static HTML files (or similar), presumably this is fine?

What about a user's credentials, password, etc.? Are these guarded when using vanilla FTP? And if so, is it "adequate"?

I'm asking quite honestly as a quality of life measure. My alternative for updating basic files on a public server would otherwise be with a messy process of SSH keys, etc. using systems which, for the life of them, cannot remember my password when sent via SFTP.

Granted the particular network that one is on is also of importance. A secure office network is a bit different from an airport lounge.

DIDIx13
  • 125
  • 9
Stumbler
  • 503
  • 4
  • 7
  • 1
    Why not consider using orchestration to manage your SSH keys? – Mark Buffalo Aug 19 '18 at 20:06
  • 2
    static HTML files can just as well contain very sensitive information. – Teun Vink Aug 19 '18 at 20:35
  • 1
    In addition to security, FTP is a 40 year old protocol that should be avoided just on its networking merits. It's a absolute nightmare to work with, with passive mode, data channel, binary mode, ascii mode and what not. – vidarlo Aug 20 '18 at 05:21
  • The assertion that a 'secure office network' exists is unproven. Most all networks are connected in some way to the larger internet. You should assume that your local network is or will be compromised at some point. You should also consider the risks of inside threats. In a nutshell: the idea that you have implicit security because you are on a local network is dubious and outdated. – JimmyJames Aug 20 '18 at 15:16

5 Answers5

22

With plain FTP the credentials are passed in plain and thus can be easily sniffed. Also, the files are not only send in plain but they are also not protected against modifications, i.e. an active man in the middle might change the files on the fly. Insofar the risks are similar to plain HTTP, i.e. it might be fine within a trusted network but is a bad idea if you cannot fully trust the network.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 2
    While these are the big issues, its also worth noting that the default behaviour is to create a second socket connection for data (compared with control) on an arbitrary port which complicates defining firewall rules. This is also present in FTPS (FTP over SSL) – symcbean Jun 08 '19 at 15:43
  • 1
    @symcbean: Good point and even more relevant with FTPS: while it is possible to have some FTP helper which sniffs at the traffic and dynamically allocates ports (like `ip_conntrack_ftp`) such helper stops working if the control connection is encrypted. While FTPS in theory supports going back to plain control connection after having protected the login with TLS, this is not supported by all clients and even if supported it is usually not the default - which makes supporting strict port forwarding for FTPS in firewalls a nightmare and might often result in giving up and just opening all ports. – Steffen Ullrich Jun 08 '19 at 16:58
12

Credentials are transfered in clear text, but you know that from the other posts. But how easy is it to get those details?

As an example I ran tcpdump and connected to an FTP server. Lets take a look at the pcap with strings:

220 (vsFTPd 3.0.2)
6USER joe
CT'X
331 Please specify the password.
CTXY
PASS superSecretPassword
230 Login successful.

What about content of commands? Here is the output from the pcap: 

PASV
227 Entering Passive Mode (192,168,1,2,238,178).
LIST
150 Here comes the directory listing.
MNt@
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Desktop
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Documents
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Downloads
drwxr-xr-x    2 1000     1000         4096 Aug 28 20:27 Music
-rw-rw-r--    1 1000     1000        58677 Jun 12  2010 pic1.jpg

And if you wanted file content here is a get of the jpg. 

200 Switching to Binary mode.
PASV
227 Entering Passive Mode (192,168,1,2,64,224).
RETR pic1.jpg
150 Opening BINARY mode data connection for pic1.jpg (58677 bytes).
JFIF
http://ns.adobe.com/xap/1.0/
<?xpacket begin="
" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/"    
 x:xmptk="XMP Core 4.1.1"> <rdf:RDF 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
<rdf:Description rdf:about=""

So if someone could sniff packets on the client, server or network then you have a security issue. Mitigating the issue by moving the SFTP or similar is an easy and good idea.

Joe M
  • 2,997
  • 1
  • 6
  • 13
3

How insecure… really… is FTP?

As insecure as any other application layer protocol that is not encrypted, for example HTTP.

But what exactly is the risk being posed?

The major risk is exposure (to eavesdroppers on the network) of all the data sent over FTP.

What about a user's credentials, password, etc.?

Yes, those are exposed too. They are sent using the application layer commands USER and PASS.

hft
  • 4,910
  • 17
  • 32
  • Even less secure than HTTP – curiousguy Aug 20 '18 at 00:02
  • Why less than HTTP? Is this a nitpick or is there something substantial? I'm using HTTP as an example since it is it well-known application layer protocol. – hft Aug 20 '18 at 15:56
  • HTTP has zero protection against tempering of the content of the IP connection is not secure; IP can be made secure (IPsec) or inherently secure (the loopback interface for local connections). FTP is deeply insecure because anyone can try to connect, knowing only the port, which has limited entropy (or no entropy on many systems. Slowing down another program that is about to open a data connection allows you to inject data. Difficult to do but if you have a way slow down other programs and retry many times, probably doable. – curiousguy Aug 20 '18 at 22:48
2

How insecure… really… is FTP

It's as insecure as your network is. If the network can be sniffed (WiFi, rogue ISP, etc), finding the password and data is as trivial as running wireshark. Given a point to listen on, you could train a bright 10 year old to get the password and data in under an hour.

What about a user's credentials, password, etc.?

All completely in the clear, with very easy tools available to snarf them.

Granted the particular network that one is on is also of importance. A secure office network is a bit different from an airport lounge.

True. As I said, FTP is as secure as the network is, and no more. It's also a matter of the threat model. Who's going to try to get your FTP data, and why?

These days with sftp and other ways of transferring data securely, it's more of a question of why you would use ftp than why you'd use the secure alternatives.

I think what you should keep in mind is that these types of scenarios only tend to balloon with time. You start out not particularly caring about the data and having your credentials be snarfed, but what you're doing can morph over time into something you really wish you had spent the time to just do it right in the first place. Many a IT professional has been told "it's only ever going to do X, and it'll never be used for Y" only to have that same person come back 18 months later and say "I know I said it'd never do Y... buy we really need it now. Can you fix it?"

If you have any choice in the matter, it's almost never a good idea to start out insecure, and just assume "we'll add security later when we need it.". The secure alternatives aren't really any more difficult to use and maintain, so why wouldn't you use them?

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • "_FTP is as secure as the network_" That's true with HTTP and false with FTP: FTP is even less secure than the network. – curiousguy Aug 19 '18 at 22:05
  • @curiousguy I don't understand this comment. Both are equally insecure, and equally susceptible to interception. – Steve Sether Aug 20 '18 at 00:39
  • HTTP is not "insecure", it offers no integrity and no secrecy not offered by the IP network; it can be argued that security is best provided at the IP level (morally, practically it isn't generalized). HTTP over a secure network is secure. FTP is insecure even in the naively implemented FTP/TLS as there is no guarantee that the data is coming (for a put command) or going to (get command) from the logged user. – curiousguy Aug 20 '18 at 22:54
2

While your question and Steffen's answer address capture of data in transit, a lot of the problems with FTP have to do with the server side configuration and implementation. Many FTP servers (including SFTP and FTPS) have had serious vulnerabilities that have allowed for both read and write access to data. Here's an article from last year about how hundreds of thousands of FTP servers are regularly configured for anonymous access.

The risks of ease in misconfiguration are also present with the secured versions of FTP. For example, many people don't realize that SFTP accounts are SSH accounts. Once logged into SFTP, you can exit into normal SSH. If you haven't considered this, you are may have granted more access to SFTP users than intended.

There are a lot of issues such as directory traversal attacks that are not specific to FTP but because of the nature of its original design and intended usage tend to present more often. Finding information and assistance in securing FTP hosts can be difficult to come by due to their increasing obscurity.

It's for these reasons you will find that a lot of security standards around SFTP requiring separate encryption of data files to help prevent exposure from access of data 'at rest'.

JimmyJames
  • 2,956
  • 2
  • 16
  • 25