How to Prevent Sniffer Attacks with Encrypted FTP | JSCAPE

Overview

A lot of people who often send files love FTP. The File Transfer Protocol allows users to transmit volumes of files over the Internet through uncomplicated FTP clients, some of which are already built-in in the two popular operating systems, Windows and Mac OS X. Sadly, this well-loved technology is not very secure. That's why people who craft regulations like PCI DSS are wary of it. They know that an attacker armed with a packet sniffer can easily obtain usernames and passwords just by sniffing an FTP connection.

In this post, I'll help you understand what a packet sniffer is and how it can be used in a Man-in-the-Middle (MITM) attack known as ARP poisoning. After that, I'll show you exactly what an attacker sees on a packet sniffer when they carry out such an attack on both regular and encrypted FTP connections.

How packet sniffers manage to grab passwords

In spite of its negative connotations, a packet sniffer (a.k.a. network analyzer, packet analyzer, protocol analyzer, or sniffer) is supposed to be used by network administrators to perform network diagnostics. But, as indicated in this post's overview, some people use it for exploitative purposes.

And if you're looking to see how we can help protect your sensitive data from exploitation through JSCAPE MFT Server get a demo to see how our encrypted solutions can safeguard your transfers. 

Some of the popular sniffers are Cain and Abel, Carnivore, dSniff, Ettercap, Fiddler, tcpdump, and Wireshark. For this post, I will use Ettercap, a free sniffer that runs on Linux.

A sniffer basically works by first capturing packets it receives from the network, including those packets intended for other hosts. This can easily be done in a LAN that connects hosts via a hub. That's because a hub simply forwards all packets entering it to all connected hosts regardless of those packets' destination addresses.

All you'll need then to grab packet information is a sniffer running on a connected host equipped with a NIC (network interface card) set to promiscuous mode.

'Promiscuous' is a mode that some NICs can assume would allow them to receive any packet that comes their way regardless of that packet's destination address. By default, NICs are supposed to discard all packets not addressed to them. Obviously, you'll want your NIC to be set to 'promiscuous' if you want to do any sniffing.

Once the packets are passed on to your sniffer, you can obtain lots of information about them. For instance, you can grab usernames and passwords from FTP packets.

However, that feat won't be as easy if you're operating in a switched network (i.e. a LAN that uses a switch instead of a hub). You see, a switch is smarter than a hub. It only forwards packets to machines they are destined for. Therefore, you won't be able to view the contents of certain packets that aren't addressed to your machine because you will never receive them in the first place.

But there are workarounds to this. One of it entails impersonating the legitimate recipient, thereby tricking the sender into sending packets to you instead of the host those packets were originally intended for. The specific technique we're referring to here is known as ARP poisoning or ARP spoofing, a very common type of MITM.

ARP Poisoning

What is a Man-in-the-Middle Attack?

This is a form of active eavesdropping wherein an attacker intercepts communications between at least two machines and dupes the victims into thinking they are still communicating directly with one another. But in actuality, the communication packets flow through the attacker's machine, thus allowing the attacker to eavesdrop on them.

ARP poisoning is one example of an MITM and is what we will talk about shortly. It takes advantage of a vulnerability in ARP, the protocol used to convert IP addresses into physical network (MAC) addresses.

IP addresses and MAC addresses

When you initiate a connection to another machine, say an FTP server, you normally enter that destination machine's IP address or hostname (hostnames like ftp.somedomain.com are automatically mapped to IP addresses) into your client application.

However, the hardware devices themselves do not use IP addresses to distinguish themselves from one another. Instead, hardware devices belonging to the same network use the MAC addresses that are uniquely assigned to their NICs. Hence, before messages can be exchanged between an FTP client and an FTP server, for example, IP addresses have to be resolved into MAC addresses.

This is ARP's job, which stands for Address Resolution Protocol.

Normal ARP communication

To translate an IP address into its corresponding MAC address, ARP looks it up in a table known as the ARP cache. You can view the contents of a host's ARP cache by typing arp -a in that host's terminal. Here's a screenshot of what was displayed when I ran arp -a on the router (a Linux machine running pfsense) in my virtual lab.

Notice how there are only two items in this host's ARP cache: IP address 192.168.100.125, whose corresponding MAC address is 08:00:27:75:9d:48, and IP address 10.0.0.2 whose corresponding MAC address is 08:00:27:b5:5d:52.

Now, if the MAC address that's needed isn't found in the ARP cache, the host sends out what is known as an ARP request. An ARP request is basically a shout-out to all machines in the network, asking who owns a particular IP address. When the IP address owner receives the ARP request, it responds with an ARP reply, which would then include its MAC address. When the requesting host receives the ARP reply, it adds the IP/MAC address pair to its ARP cache.

Here's another look at the same host's ARP cache after I executed arp -a right after pinging a host in the network bearing IP address 192.168.100.102. Notice how that host's IP and MAC addresses were added to the router's ARP cache.

Each ARP request also includes the sender's IP and MAC address. Thus, all machines who receive the request will know the IP address and MAC address of the requester. Once two machines already know each other's IP and MAC address, they can start communicating.

Taking advantage of ARP

Unfortunately, ARP accepts updates at any time. This means that a device may send an ARP reply to another device even without receiving an ARP request, and the second device will promptly update its ARP cache. Herein, the vulnerability of ARP lies. That unsolicited ARP reply can easily come from an attacker.

An attacker may impersonate a legitimate host by sending an ARP reply to a machine with which that host is supposed to communicate. In fact, the attacker can send unsolicited ARP replies to the two machines to fool them both!

This is basically how ARP poisoning works. After carrying out ARP poisoning, the attacker would then be able to establish itself as the man-in-the-middle.

Oftentimes, FTP clients aren't found in the same network as the FTP server. Hence, an ARP poisoning MITM attack intended to sniff FTP packet information can be carried out by positioning the attacker between either the FTP client and its network's router or between the FTP server and its network's router. In this experiment, I implemented the former.

What a sniffer can see on an FTP connection

Some packet sniffers can carry out ARP Poisoning before sniffing the connection. When performed on a connection like FTP, which sends out information in plaintext, packet sniffing can allow the attacker to see things he's not supposed to see - for example, usernames and passwords.

Here's a screenshot of Ettercap running on the attacker machine that's positioned as shown in the diagram above. Notice how clearly the username and password is displayed (username: user1; password: demo).

To prevent a packet sniffer from viewing your users' usernames and passwords while they are carrying out file transfers, we suggest you let them use encrypted FTP protocols like FTPS or SFTP instead of regular FTP. These two secure file transfer protocols encrypt the information sent, rendering them unreadable.

Here's a screenshot of the same packet sniffer sniffing on an FTPS connection.

And here's a screenshot of it sniffing an SFTP connection:

As you can see, both FTPS and SFTP connections are incomprehensible when viewed on a packet sniffer. An attacker would not be able to retrieve usernames and passwords this way.

Recommended Downloads

To prevent packet sniffers from obtaining sensitive information from your file transfer sessions, employ encrypted file transfer protocols like FTPS or SFTP. Both protocols are supported by JSCAPE MFT Server, a platform-independent managed file transfer server that supports multiple secure file transfer protocols.

JSCAPE MFT Server has a free, fully-functional evaluation edition which you can download below.

Note that not all file transfer clients support FTPS and SFTP. To ensure full compatibility with JSCAPE's managed file transfer server, use clients like AnyClient, which supports a wide range of secure file transfer protocols.

Download the always free AnyClient. Download Now