Indicators of Man-in-the-middle attacks

The man-in-the-middle attack is a generic name for various techniques designed to gain access to traffic as an intermediary. Due to the wide variety of these techniques, it is problematic to implement a single tool for identifying these attacks, which would work for all possible situations. For example, when attacking a person in the middle on a local network, ARP spoofing is usually used. And many tools for "detecting a man-in-the-middle attack" monitor the change of pairs of Ethernet/IP addresses or report suspicious ARP activity by passive monitoring of ARP requests/responses. However, if this attack is used on a maliciously configured proxy server, VPN, or in other cases when ARP-spoofing is not used, then such tools are helpless.

The purpose of this article is to collect some techniques for detecting man-in-the-middle attacks, as well as some tools designed to determine if a MitM attack is taking place against you. Due to the variety of methodologies and implementation scenarios, it is impossible to guarantee 100% detection.

1. Identify the traffic manipulation

As already mentioned, in man-in-the-middle attacks, ARP spoofing is not always used. Therefore, although detecting activity at the ARP level is the most popular way to identify, a more universal way is to detect modification of traffic. The mitmcanary program can help us with this.

The principle of the program is that it makes "control" requests and stores the received responses. After that, it repeats the same requests at certain intervals and compares the received responses. The program is intelligent enough and it properly processes the dynamic elements in the responses to avoid false positives reveals. As soon as the program reveals traces of the activity of tools for MitM-attacks, it reports about that.

Examples of how some of the tools leave traces:

  • MITMf, by default, changes all HTTPS URLs in HTML code to HTTP. It is detected by comparison of HTTP content.
  • Zarp + MITMProxy, MITMProxy has the functionality that allows to clean HTTP compression, this is used for transparency of transmitted traffic, this trace is detected by the disappearance of the previously existing compression
  • Responder, is detected by sudden changes in the transformation of mDNS responses: an unexpected response; the answer is internal, but external is expected; the response is different from the expected IP

The author of the program has prepared several videos, which show how a man-in-the-middle attack is revealed:

  • MITMCanary vs MITMf: 

  • MITMCanary vs Responder:

  • MITMCanary vs Zarp + MITMProxy:

The mitmcanary program is currently not available in the Kali Linux and BlackArch repositories, but there is a simple installation guide. In all examples, I will conduct attacks from BlackArch, and identify attacks in Kali Linux. Therefore, I begin with mitmcanary installation in Kali Linux:

sudo pip install Cython
sudo apt-get install python-kivy python-dbus
sudo pip install plyer uuid urlopen analysis request simplejson datetime
git clone https://github.com/CylanceSPEAR/mitmcanary.git
cd mitmcanary/

mitmcanary installation on BlackArch

sudo pip2 install Cython
sudo pacman -S python2-kivy python2-dbus
sudo pip2 install plyer uuid urlopen analysis request simplejson datetime
git clone https://github.com/CylanceSPEAR/mitmcanary.git
cd mitmcanary/

As already mentioned, mitmcanary work should begin with requests. To do this, go to the directory

cd service/

And run setup_test_persistence.py:

python2 setup_test_persistence.py

This will take some time - wait until the end. There should be no error messages (if so, you do not have any dependencies).

It will output something like this:

python2 setup_test_persistence.py
[WARNING] [Config      ] Older configuration version detected (0 instead of 14)
[WARNING] [Config      ] Upgrading configuration in progress.
Purge log fired. Analysing...
Purge finished!
[INFO   ] [Logger      ] Record log in /home/mial/.kivy/logs/kivy_16-11-01_0.txt
[INFO   ] [Kivy        ] v1.9.1
[INFO   ] [Python      ] v2.7.12+ (default, Sep  1 2016, 20:27:38) 
[GCC 6.2.0 20160927]

After the end of this process, in the same directory execute (this will start the background process):

python2 main.py

After that, open a new terminal window and go to the target directory with mitmcanary. I have a bin/mitmcanary/ directory, so I type

cd bin/mitmcanary/

and execute there:

python2 main.py

The first window displays something like:

python2 main.py
[INFO   ] [Logger      ] Record log in /home/mial/.kivy/logs/kivy_16-11-01_1.txt
[INFO   ] [Kivy        ] v1.9.1
[INFO   ] [Python      ] v2.7.12+ (default, Sep  1 2016, 20:27:38) 
[GCC 6.2.0 20160927]
[INFO   ] [OSC         ] using <multiprocessing> for socket
[INFO   ] [OSC         ] listening for Tuio on 127.0.0.1:3000
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds

That is, the program once a minute makes control requests and looks for signs of a man-in-the-middle attack in them.

In the second window there is also a conclusion + a dark window opens, the authors of the program call this window a "graphical interface":

You can wait a while; surf the Internet to make sure that the program does not make any false alerts.

Let us try the classic Ettercap program.

I am running a normal MitM attack with ARP spoofing. mitmcanary does not notice ARP-spoofing. mitmcanary tool itself generates traffic, that is, no user action is required. After a while, a single warning appears, which is not confirmed on subsequent close checks. But a similar warning appears in a few minutes. Without further analysis, I find it difficult to say whether this is an example of a false positive - very similar to this. It is possible that this warning is caused by a communication failure, or by the peculiarities of my poor-quality Internet connection.

Since the result is not obvious (rather "no" than "yes"), then let us try the Bettercap program, which has a variety of modules. I have no doubt that when using various Ettercap plug-ins and/or additional programs to expand the functionality, we would be visible for mitmcanary.

For the purity of the experiment, I restart the equipment, run mitmcanary on the target machine and Bettercap on the attacker’s machine. At the same time, it is not necessary to make control queries on the target machine - they are saved in a file inside the directory with the program. Therefore, just start the service and the graphical interface.

And in the attacker’s machine, we run Bettercap with the enabled sniffer:

sudo bettercap -X

Separate warnings appear, which are also more like false positives.

But the launch of such a command:

sudo bettercap -X --proxy

On the attacker’s machine causes a large number of warnings about a possible man-in-the-middle attack:

Therefore, the more functional a tool for a man-in-the-middle attack, the more traces it leaves in traffic. For the practical use of mitmcanary, the following conditions must be met:

  • make initial requests on the trusted network, when you are sure that there is no middleman for traffic transfer;
  • edit the resources to which verification requests are made, since a professional attacker can add default resources to the exceptions, which will make it invisible for this tool.

2. Detection of ARP spoofing

Very often, a man-in-the-middle attack on the local network starts with ARP spoofing. That is why many tools for detecting MitM attacks are based on the mechanism for monitoring the change in the ARP cache, in which the correspondences between Ethernet (MAC addresses) and IP addresses are attributed.

As an example of such programs, you can recall arpwatch, arpalert and a large number of new programs. The ArpON program not only monitors the changes in the ARP cache, but also protects against its changing.

As an example, run arpwatch in debug mode, without creating forks in the background and sending messages by mail. Instead, messages are sent to stderr (standard error output).

sudo /usr/sbin/arpwatch -d

On the attacker’s machine, start Ettercap and start ARP spoofing. On the target machine we observe:

The arpwatch program will help you quickly be aware of new connected devices on your local network, as well as about changes in your ARP cache.

Another tool for detecting ARP spoofing in real time is the plug-in of Ettercap, called arp_cop. On the target machine, run Ettercap as follows:

sudo ettercap -TQP arp_cop ///

And on the attacker’s computer, we'll start ARP poisoning. On the target machine warnings start to display immediately:

3. DNS spoofing detection

DNS spoofing indicates that there is an intermediary between you and the destination that can modify your traffic. How can I find out that DNS records have been spoofed? The easiest way to do this is to compare it to the responses of the name server that you trust. But if you use the same connection, your new lookups to the DNS server can be also spoofed…

That is, to perform controlling lookups it is necessary either the ciphered channel (for example, through Tor), or to use non-standard settings (other port, TCP instead of UDP). Approximately for this purpose the sans program from XiaoxiaoPu is designed (if I understood correctly). I managed to redirect DNS requests via Tor and through non-standard settings to my DNS server with this program. But I still could not make the tool to show messages about DNS responses spoofing. And without this, the meaning of the program is lost.

I could not find any more worthy alternatives.

Basically, taking into account that DNS spoofers usually spy only port 53, and only UDP protocol, it is even easy to manually verify the fact of DNS spoofing, although this requires your own DNS server/proxy with a non-standard configuration. For example, on the attacker’s machine, I created a dns.conf file with the following content:

local mi-al.ru

That is, when a DNS lookup is performed for the mi-al.ru site, instead of the real IP, the IP address of the attacker machine will be sent.

I launch on the attacker’s machine:

sudo bettercap --dns dns.conf

And on the target I do two checks:

dig mi-al.ru
# and
dig mi-al.ru -p 4560 @185.117.153.79

Output:

dig mi-al.ru
 
; <<>> DiG 9.10.3-P4-Debian <<>> mi-al.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51993
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
 
;; QUESTION SECTION:
;mi-al.ru.          IN  A
 
;; ANSWER SECTION:
mi-al.ru.       86400   IN  A   192.168.1.48
 
;; Query time: 2 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Nov 02 09:25:20 MSK 2016
;; MSG SIZE  rcvd: 42
 
dig mi-al.ru -p 4560 @185.117.153.79
 
; <<>> DiG 9.10.3-P4-Debian <<>> mi-al.ru -p 4560 @185.117.153.79
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 401
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mi-al.ru.          IN  A
 
;; ANSWER SECTION:
mi-al.ru.       3799    IN  A   185.26.122.50
 
;; Query time: 304 msec
;; SERVER: 185.117.153.79#4560(185.117.153.79)
;; WHEN: Wed Nov 02 09:25:27 MSK 2016
;; MSG SIZE  rcvd: 53

It is seen that for a "normal" DNS lookup, a local IP 192.168.1.48 is sent, and when a DNS request is sent on an untypical port, the correct IP of the server is sent.

If the server were configured to work with the TCP protocol (not UDP), then the command would look like this:

dig mi-al.ru -p 4560 + tcp @ 185.117.153.79

Obviously, there is not enough tools which would itself track DNS responses in traffic, double-check them on an alternative source and raise the alarm in case of spoofing.

To do without configuring your own remote DNS, you can make queries to the name server via Tor. Since all the traffic of Tor is encrypted, the received DNS answers in this way are not vulnerable to the attack. If Tor is not already installed, then install it.

In Kali Linux:

sudo apt install tor

In BlackArch:

sudo pacman -S tor

Start the service:

sudo systemctl start tor

If you need it, add this service to startup:

sudo systemctl enable tor

Open the /etc/tor/torrc file and add the following lines:

DNSPort 530
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

Pay attention to 530. This is the port number, instead of 530 you can specify any other (unbound) port.

Again doing the checks:

dig mi-al.ru
# and
dig mi-al.ru -p 530 @localhost

Now, as the server, we specify localhost, and write the port number that was specified in the settings of /etc/tor/torrc.

As can be seen from the following screenshot, against the machine on which the check is made, a DNS spoofing attack is performed:

4. Searching for network interfaces in promiscuous mode

If there is (and especially if suddenly appeared) equipment in promiscuous mode inside your local network, this is very suspicious, although it does not clearly indicate a man-in-the-middle attack.

In this mode, the network card allows you to receive all packets, regardless of whom they are addressed to.

In the normal state, the Ethernet interface uses the filtering of the link layer packets and if the MAC address in the destination header of the received packet does not match the MAC address of the current network interface and is not broadcast, the packet is discarded. In the "promiscuous" mode, filtering on the network interface is disabled and all packages, including not assigned to the current node, are passed to the system.

Most operating systems require administrator privileges to enable the "promiscuous" mode. That is, setting a network card to promiscuous mode is a conscious action that can pursue the purpose of sniffing.

To search for network interfaces in promiscuous mode, there is an Ettercap plugin, called search_promisc.

Example of launching the plugin:

sudo ettercap -TQP search_promisc ///

The work of the plugin is not completely reliable, there may be errors in determining the mode of the network interface.

Conclusion

Some man-in-the-middle attack methods leave a lot of traces, and some (for example, passive searches for credentials on a proxy) are impossible or almost impossible to detect.

Recommended for you:

Leave a Reply

Your email address will not be published. Required fields are marked *