Комментарии 79
так вроде проксировать SSH траффик (man in the middle) и раньше было можно… или я что-то недопонимаю?
мы ставили просто прокси в середине — клиент коннектился к нему, расшифровывали траффик и шифровали обратно, и отдавали настоящему серверу.
мы ставили просто прокси в середине — клиент коннектился к нему, расшифровывали траффик и шифровали обратно, и отдавали настоящему серверу.
или это просто реклама новой фичи в данной программе?
ok, я с SSL перепутал, не проснулся еще…
Можно было и раньше и уже достаточно давно. С чего автор решил присвоить первенство в практической реализации решительно непонятно. Любой более менее серьёзно вращающийся в области ИБ специалист знает, что уже много времени как подобный функционал доступен в решениях корпоративного класса, например — BalaBit Shell Control Box.
Вроде ettercap умеет mitm ssh, и тоже с warning о фингерпринт.
То есть при авторизации ключами, можно спать спокойно?
до тех пор, пока я не сделал поддержку public ключей.
Но угнать сам ключ же не получится, соответственно авторизоваться отдельно — тоже.
совершенно верно, приватный ключ остается не доступным. но доступ к сессии будет получен.
А какие видимые пути решения проблемы перехвата сессии? выкидывать ssh на мороз? :)
Смотреть внимательно на предупреждения Putty
Это не решение проблемы в принципе, это тест на ССЗБ.
Насколько я понимаю абсолютного решения проблемы не существует впринципе. Так или иначе MiTM будет возможен. Что бы он был невозможен нужно будет как-то удостоверится что хост правильный. Все равно кому то приходится доверять и нужен безопасный канал. Ниже уже написали про SSH.
Лучше и безопаснее решения не будет.
Лучше и безопаснее решения не будет.
Лучший выбор на мой взгляд — OpenVPN туннель (желательно с TLS) или похожее решение транспортного уровняю.
Я не понимаю, почему будет работать перехват в режиме аутентификации открытым ключом. По идее, открытый ключ вашего сервера можно опубликовать хоть здесь, на то он и открытый. Как тогда подсунуть жертве поддельный ключ?
Давайте поставим промежуточную точку в этом вопросе. Судя по всему, шифрование канала в ssh сессии
не завязано на публичный ключ. Публичный ключ это всего лишь один из способов аутентификации, т.е. удостоверения личности пользователя.
Работает этот механизм так:
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
2. клиент сообщает серверу, что собирается аутентифицироваться с помощью открытого ключа.
3. сервер (имея этот ключ) отсылает некий челендж клиенту.
4. клиент должен расшифровать челендж своим приватным ключом и дать понять серверу, что он действительно тот за кого себя выдает.
5. далее клиент может запросить терминал или другой тип сессии. но шифрование канала не зависит от способа аутентификации.
Будучи по-середине, все шаги могут быть повторены атакующим. Т.е. атакующий не имея приватного ключа, получает доступ к авторизованной сессии
и способен выполнять команды от лица пользователя.
Теоретические выкладки относительно функционирование ассиметричного шифрования не имеют к этой теме никакого отношения. Речь ведется строго
о реализации ssh протокола. Пока что все видится именно так, как описано выше. Если кто-то обладает знаниями в этом вопросе — просьба отписаться.
не завязано на публичный ключ. Публичный ключ это всего лишь один из способов аутентификации, т.е. удостоверения личности пользователя.
Работает этот механизм так:
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
2. клиент сообщает серверу, что собирается аутентифицироваться с помощью открытого ключа.
3. сервер (имея этот ключ) отсылает некий челендж клиенту.
4. клиент должен расшифровать челендж своим приватным ключом и дать понять серверу, что он действительно тот за кого себя выдает.
5. далее клиент может запросить терминал или другой тип сессии. но шифрование канала не зависит от способа аутентификации.
Будучи по-середине, все шаги могут быть повторены атакующим. Т.е. атакующий не имея приватного ключа, получает доступ к авторизованной сессии
и способен выполнять команды от лица пользователя.
Теоретические выкладки относительно функционирование ассиметричного шифрования не имеют к этой теме никакого отношения. Речь ведется строго
о реализации ssh протокола. Пока что все видится именно так, как описано выше. Если кто-то обладает знаниями в этом вопросе — просьба отписаться.
Спасибо за проделанную работу. Есть несколько замечаний.
1. Насколько мне известно, шифрованный канал создается не на основе rsa/dsa ключа сервера, а при помощи алгоритма Диффи — Хеллмана. Отсюда следует интересный факт, что от длины ключа сервера не зависит вероятность успешной прослушки.
2. Насколько я понял из статьи, нет возможности «увести» сессию (чтобы работать на сервере от имени жертвы). В этом случае более надежным и простым решением кажется атака на уровень шифрования (алгоритм Диффи — Хеллмана и подмена публичного ключа сервера), при которой открытый текст, включая изменения размеров терминала, SFTP, туннелирование и т. д., передавался бы как есть, а его копия записывалась бы сервером атакующего. Такой режим не даст атакующему вмешаться и что-то сделать на сервере от имени пользователя, зато будут работать SFTP и туннели и меньше будет риск глюков (при той же работе с терминалом), которые могут выдать прослушку.
3. Пожалуйста, не делайте ошибку в слове «асимметричный», оно происходит от слова «symmetry», а не от слова «ass». К сожалению, ошибка очень популярна в материалах по криптографии, поэтому я обращаю на неё внимение.
1. Насколько мне известно, шифрованный канал создается не на основе rsa/dsa ключа сервера, а при помощи алгоритма Диффи — Хеллмана. Отсюда следует интересный факт, что от длины ключа сервера не зависит вероятность успешной прослушки.
2. Насколько я понял из статьи, нет возможности «увести» сессию (чтобы работать на сервере от имени жертвы). В этом случае более надежным и простым решением кажется атака на уровень шифрования (алгоритм Диффи — Хеллмана и подмена публичного ключа сервера), при которой открытый текст, включая изменения размеров терминала, SFTP, туннелирование и т. д., передавался бы как есть, а его копия записывалась бы сервером атакующего. Такой режим не даст атакующему вмешаться и что-то сделать на сервере от имени пользователя, зато будут работать SFTP и туннели и меньше будет риск глюков (при той же работе с терминалом), которые могут выдать прослушку.
3. Пожалуйста, не делайте ошибку в слове «асимметричный», оно происходит от слова «symmetry», а не от слова «ass». К сожалению, ошибка очень популярна в материалах по криптографии, поэтому я обращаю на неё внимение.
Замечательно. Только подскажите в каком пункте (из тех, что я описал выше) допущена ошибка и почему нельзя увести сессию? И почему вы разделяете возможность выполнения команд и от возможности создания sftp сессий, либо перефразируйте весь второй пункт. Спасибо.
Ошибка в пункте 1:
Прежде чем пояснять по моему второму пункту, я уточню принцип работы Intercepter-NG. Как я понял, он работает как ssh-сервер, принимает команды и вызывает их на настоящем сервере, подключившись к нему как ssh-клиент. Если я неправильно этот момент уяснил, то дальнейший мой ответ, скорее всего, неверен.
Дополнительный вопрос: работают ли программы, интенсивно использующие возможности терминала: vim, screen (tmux)?
Пользуясь Вашим подходом, сессию как раз можно было бы увести (то есть начать в живую вводить команды за пользователя), однако, как я понял из статьи, такой возможности нет. Поэтому, раз её всё равно нет, я предложил не «влезать» в открытый текст (будь то команды, SFTP, туннели и остальные «надстройки»), а передавать его как есть, сохраняя себе копию. Анализ этой копии (выполняемый постфактум) выявит всё, что передавалось, будь то команды, файлы или туннели. Причем можно сначала реализовать только извлечение команд, а возможность извлечения SFTP добавить потом, при этом SFTP можно будет извлекать и из старых дампов тоже, так как в них записывается всё, а не только то, что текущая версия умеет извлекать.
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
Прежде чем пояснять по моему второму пункту, я уточню принцип работы Intercepter-NG. Как я понял, он работает как ssh-сервер, принимает команды и вызывает их на настоящем сервере, подключившись к нему как ssh-клиент. Если я неправильно этот момент уяснил, то дальнейший мой ответ, скорее всего, неверен.
Дополнительный вопрос: работают ли программы, интенсивно использующие возможности терминала: vim, screen (tmux)?
Пользуясь Вашим подходом, сессию как раз можно было бы увести (то есть начать в живую вводить команды за пользователя), однако, как я понял из статьи, такой возможности нет. Поэтому, раз её всё равно нет, я предложил не «влезать» в открытый текст (будь то команды, SFTP, туннели и остальные «надстройки»), а передавать его как есть, сохраняя себе копию. Анализ этой копии (выполняемый постфактум) выявит всё, что передавалось, будь то команды, файлы или туннели. Причем можно сначала реализовать только извлечение команд, а возможность извлечения SFTP добавить потом, при этом SFTP можно будет извлекать и из старых дампов тоже, так как в них записывается всё, а не только то, что текущая версия умеет извлекать.
С ключами и диффи-хеллманом понятно, на обсуждаемый вопрос это не влияет. Принцип работы уяснили правильно. Вот только ничего сохранить или ввести не получится, потому что аутентификация не пройдет, и никакого терминального сеанса установлено не будет. Точно так же не будут работать и SFTP и прочие возможности SSH. Все что можно сделать, это выступить в качестве сервера самому (без привлечения оригинального сервера), но тут огромная куча ограничений. Если жертва зааплодит файл, то мы его сможем принять, но в последствии он его не обнаружит на своем сервере. Если жертва захочет скачать файл со своего сервера, то у нас его и вовсе не окажется.
Ниже уже разобрались, что с публичными ключами ничего сделать не удастся.
ps: vi\tmux и любой другой терминальный софт работают.
Ниже уже разобрались, что с публичными ключами ничего сделать не удастся.
ps: vi\tmux и любой другой терминальный софт работают.
Вы имели ввиду ситуацию, когда атакующий говорит клиенту, что якобы аутентификация прошла успешно (хотя на самом деле доступа никуда мы не получили) и клиент начинает, к примеру, пересылать файлы по sftp, которые мы деть никуда не сможем, но сможем «перехватить» для себя, этакий минимальный профит. Я вас правильно понял?
Как шаги могут быть повторены атакующим, если он не знает приватных ключей?
В процессе создания сессии и обмена ключами создается идентификатор сессии, подделать который атакующий не в состоянии, не зная закрытого ключа сервера. Он может предоставить клиенту только другой, зависящий от своего закрытого ключа. То есть между клиентом и атакующим и атакующим и сервером идентификаторы сессии будут гарантированно разные. Затем при аутентификации клиент посылает подпись этого идентификатора своим закрытым ключом. Если атакующий просто передаст эту подпись без изменений, то сервер увидит, утрируя, что не совпадают идентификаторы сессии. Если подпишет своим закрытым ключом идентификатор сессии между собой и сервером, то сервер увидит, что не совпадают открытые ключи атакующего и клиента. В обоих случаях он реджекнет атакующего.
Это, конечно, если я правильно разобрался с механизмом формирования идентификатора сессии и он содержит данные, известные только серверу и проверяемые его публичным ключом, а значит атакующий не сможет предоставить такой же идентификатор клиенту, т. к. он подменяет публичный ключ сервера на свой. В случае парольной аутенфикации это не имеет значение, потому что атакующий может подменять идентификатор сессии в обе стороны, а в случае с подписью он этого сделать не может, потому что клиент подписывает его свои закрытым ключом, а подпись проверяется публичным ключом клиента, хранящимся на сервере.
В процессе создания сессии и обмена ключами создается идентификатор сессии, подделать который атакующий не в состоянии, не зная закрытого ключа сервера. Он может предоставить клиенту только другой, зависящий от своего закрытого ключа. То есть между клиентом и атакующим и атакующим и сервером идентификаторы сессии будут гарантированно разные. Затем при аутентификации клиент посылает подпись этого идентификатора своим закрытым ключом. Если атакующий просто передаст эту подпись без изменений, то сервер увидит, утрируя, что не совпадают идентификаторы сессии. Если подпишет своим закрытым ключом идентификатор сессии между собой и сервером, то сервер увидит, что не совпадают открытые ключи атакующего и клиента. В обоих случаях он реджекнет атакующего.
Это, конечно, если я правильно разобрался с механизмом формирования идентификатора сессии и он содержит данные, известные только серверу и проверяемые его публичным ключом, а значит атакующий не сможет предоставить такой же идентификатор клиенту, т. к. он подменяет публичный ключ сервера на свой. В случае парольной аутенфикации это не имеет значение, потому что атакующий может подменять идентификатор сессии в обе стороны, а в случае с подписью он этого сделать не может, потому что клиент подписывает его свои закрытым ключом, а подпись проверяется публичным ключом клиента, хранящимся на сервере.
Если такая привязка к уникальному ID сессии действительно существует, то все вопросы снимаются. Но я сходу не могу найти детального описания этого процесса. Не подкините ссылку?
Вот из рфц нашлось
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string «publickey»
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string «publickey»
boolean TRUE
string public key algorithm name
string public key to be used for authentication
теперь надо выяснить, может ли атакующий выдать произвольный id сессии, равный тому, что выдал
оригинальный сервер.
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string «publickey»
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string «publickey»
boolean TRUE
string public key algorithm name
string public key to be used for authentication
теперь надо выяснить, может ли атакующий выдать произвольный id сессии, равный тому, что выдал
оригинальный сервер.
Описано тут по идее ools.ietf.org/html/rfc4253
Если у атакующего данные эти все есть, то сможет дать тот же id клиенту.
The hash H is computed as the HASH hash of the concatenation of the
following:
string V_C, the client's identification string (CR and LF
excluded)
string V_S, the server's identification string (CR and LF
excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
Если у атакующего данные эти все есть, то сможет дать тот же id клиенту.
Проблема в том, что session id генерируется клиентом самостоятельно, на основе данных обмена ключами.
Интересно и то, что по сути, однажды созданный id больше ни за что не отвечает, он используется только при проверке подписи. Так что, если бы сервер мог выдать клиенту произвольный идентификатор все бы завершилось успешно.
Спасибо, вопрос закрыт.
Интересно и то, что по сути, однажды созданный id больше ни за что не отвечает, он используется только при проверке подписи. Так что, если бы сервер мог выдать клиенту произвольный идентификатор все бы завершилось успешно.
Спасибо, вопрос закрыт.
openssh-шный клиент просто не даст подключиться, если с ключами не всё в порядке. Никаких вопросов, просто не даст и всё.
мак шлюза хотя бы статиком прописать, но кроме арп пойзона есть и другие способы перехвата управления.
по ключам внизу еще важное дополнение. вполне возможно они есть спасение.
К счастью это должно быть не очень опасно для пользующихся publickey авторизацией. Неуверен можно ли вмешатся в обмен со своими командами (теоритически)?
Это единственный подозрительный момент который возникает при проведении атаки.
Подозрительный? Да тот же putty черным по белому пишет, что это ппц и дальше нельзя:
Покажите мне хотя бы одного человека который не обратит внимания.
Подозрительный? Да тот же putty черным по белому пишет, что это ппц и дальше нельзя:
Покажите мне хотя бы одного человека который не обратит внимания.
таких людей гораздо больше чем вам кажется.
Первый вариант, что это штатная ситуация и лишь второй, что это атака.
Как часто вам приходилось менять ключи сервера и зачем?
Смотря что считать сервером. Если то, что идентифицируется по DNS, то банальная смена хостинга или переход на другой тарифный план обычные ситуации.
Ну и речь явно о многопользовательских системах, где есть администратор, который по каким-то своим причинам, простым смертным неизвестным, может сменить ключ.
Ну и речь явно о многопользовательских системах, где есть администратор, который по каким-то своим причинам, простым смертным неизвестным, может сменить ключ.
При обновлении Убунты на сервере до версии 12.04 у меня «полетели» настройки ssh-сервера. Пришлось его заново ставить. Как следствие — поменялись ключи. Увидел такое вот предупреждение и очень долго пытался отогнать навязчивую идею о Большом Брате, пока не вспомнил об этом обновлении ОС. А мои коллеги вообще на предупреждение никак не отреагировали и продолжили работать с сервером без задней мысли. Так что плюсую коммент выше:
таких людей гораздо больше чем вам кажется.
Почему обязательно сервера? SSH и на сетевом железе используется. Ситуация «один из сотен роутеров/свитчей был заменен на другой с тем же конфигом» вполне обыденна. Конфиг передается под копирку (то есть адрес будет как у старой железки), а пара ключей генерируется заново.
Так что да, видя подобное сообщение, я предположу, что железка была заменена, на всякий случай перепроверю, и приму новый ключ. Не впервой.
Так что да, видя подобное сообщение, я предположу, что железка была заменена, на всякий случай перепроверю, и приму новый ключ. Не впервой.
При обновлении openssh-сервера (по крайней мере на Debian) происходит перегенерация ключа.
В первом варианте (и при первом соединении) тоже нельзя слепо принимать ключ. Надо получить настоящий отпечаток ключа по другому, безопасному каналу, и сравнить его с имеющимся. GitHub, например, публикует свой отпечаток ключа на HTTPS-странице: help.github.com/articles/generating-ssh-keys. Ну а если это свой сервер, то можно получить настоящий отпечаток через локальную консоль.
Консольный OpenSSH в явном виде запрещает подсоединение при измении ключа — чтобы подсоединиться, нужно пойти и удалить из known_keys прошлый ключ. Так как это действие происходит не за пару секунд и его нельзя выполнить, не подумав, а что, собственно, происходит.
Проксификация соединения, авторизация которого производится при помощи PKI (сертификаты или пара RSA-ключей) — да на здоровье, с тем же успехом вы можете чужие SSL-сессии записывать. Т.е. записывать-то можете, но толку мало — кроме факта соединения (т.е. того, что и так не представляет секрета) никакой дополнительной информации извлечь не удастся.
Проксификация соединения, авторизация которого производится при помощи PKI (сертификаты или пара RSA-ключей) — да на здоровье, с тем же успехом вы можете чужие SSL-сессии записывать. Т.е. записывать-то можете, но толку мало — кроме факта соединения (т.е. того, что и так не представляет секрета) никакой дополнительной информации извлечь не удастся.
да, в юниксе с этим более безопасно.
по поводу pki и пользы перехвата. скорее всего вы правы, я не вдавался в детали реализации этого алгоритма в ссш.
но возможно есть шанс, что паблик ключ нужен только в момент авторизации, а дальше устанавливается сессия, в которой атакующий сможет исполнять команды. скорее всего это не так, но и полностью отбрасывать эту мысль не стану.
по поводу pki и пользы перехвата. скорее всего вы правы, я не вдавался в детали реализации этого алгоритма в ссш.
но возможно есть шанс, что паблик ключ нужен только в момент авторизации, а дальше устанавливается сессия, в которой атакующий сможет исполнять команды. скорее всего это не так, но и полностью отбрасывать эту мысль не стану.
The SSH-2 protocol has an internal architecture (defined in RFC 4251) with well-separated layers. These are:
The transport layer (RFC 4253). This layer handles initial key exchange as well as server authentication, and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets with sizes of up to 32,768 bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever is sooner.
The user authentication layer (RFC 4252). This layer handles client authentication and provides a number of authentication methods.
т.е. шифрование канала происходит независимо от типа аутентификации. нам важно получить доступ к серверу, это можно сделать не владея приватным ключом, и согласно архитектуре никаких проблем с исполнением команд быть не должно.
если не прав, поправьте.
The transport layer (RFC 4253). This layer handles initial key exchange as well as server authentication, and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets with sizes of up to 32,768 bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever is sooner.
The user authentication layer (RFC 4252). This layer handles client authentication and provides a number of authentication methods.
т.е. шифрование канала происходит независимо от типа аутентификации. нам важно получить доступ к серверу, это можно сделать не владея приватным ключом, и согласно архитектуре никаких проблем с исполнением команд быть не должно.
если не прав, поправьте.
По идее, если вы смогли перехватить SSH-сессию, то чисто теоретически у вас будет доступ к соответствующему серверу на всё время жизни соединения (само соединение можно не закрывать после того, как клиент отсоединился). Именно потому, что авторизация играет роль только для первичного получения доступа к серверу, но не для последующего обмена информацией между сервером и клиентом.
В принципе, можно заставить OpenSSH коннектиться к серверу, даже если не совпадает fingerpint, но тогда авторизация по паролю отключается и выдается следующее сообщение:
При этом, нужно вручную отключить StrictHostKeyChecking, что тоже является дополнительным барьером к тому, чтобы подключиться к чужому серверу, не заметив этого.
$ ssh -o StrictHostKeyChecking=no srv
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 RSA key sent by the remote host is
<...>.
Please contact your system administrator.
Add correct host key in /home/yuriy/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/yuriy/.ssh/known_hosts:28
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.При этом, нужно вручную отключить StrictHostKeyChecking, что тоже является дополнительным барьером к тому, чтобы подключиться к чужому серверу, не заметив этого.
В моем понимании это не атака, это просто проксирование SSH со всеми вытекающими последствиями. К криптографической стойкости протокола этот процесс никакого отношения не имеет.
Я всегда использую OpenVPN (PKCS12-сертификат/TLS) туннель с сервером.
Великолепно :)
Скоро вас похитят и заставят писать Russian DPI :)
Скоро вас похитят и заставят писать Russian DPI :)
При MITM атаках, почти всегда, почти, срабатывает предупреждение.
По крайней мере, я встречаю подобную защиту во всех анализируемых программах, НО человеческий фактор я бы тоже не отрицал, в данной ситуации.
По крайней мере, я встречаю подобную защиту во всех анализируемых программах, НО человеческий фактор я бы тоже не отрицал, в данной ситуации.
Спасибо, конечно, за полезную приблуду, но это в стиле вируса для UNIX, для работы которого надо во-1, его собрать, во-2, пропатчить ядро для совместимость, в-3 собственно запустить.
Основные программы, работающие с SSH при авторизации и несовпадении сохраненного отпечатка сервера закатывают истерику, на которую не обратит внимание только уже совсем упоротый пользователь. Имхо проще и незаметнее пользователю putty трояна подкинуть пароль\ключи увести. Про никсы вообще молчу.
Основные программы, работающие с SSH при авторизации и несовпадении сохраненного отпечатка сервера закатывают истерику, на которую не обратит внимание только уже совсем упоротый пользователь. Имхо проще и незаметнее пользователю putty трояна подкинуть пароль\ключи увести. Про никсы вообще молчу.
А перехват ключей таит в себе какие-то дополнительные сложности, или это просто вопрос времени?
Я так понимаю трафик пойдет через ваши сервера, посему использовать эту функцию с целью пентестинга своих серверов небезопасно.
Я так понимаю трафик пойдет через ваши сервера, посему использовать эту функцию с целью пентестинга своих серверов небезопасно.
У меня авторизация по ключам, перехватывайте, пожалуйста, мне не жалко.
Как настоящий параноик, храню распечатанные фингерпринты ключей всех серверов, с которыми работаю.
Атака?
Где здесь атака-то?
Это просто демонстрация работы фингерпринтов в SSH. Не морочьте людям голову.
Где здесь атака-то?
Это просто демонстрация работы фингерпринтов в SSH. Не морочьте людям голову.
Итак. Атака офигенно подходит для админа который… не вкуривает что такое открытие портов для конкретного ипа или динамическое открытие порта по требованию, спал на уроках по впн и по этой причине не реализовал это у себя в сети, настолько нищий что не может реализовать логирование на стороннем сервисе с правами только на чтение, и автоинформированием о разных событиях связанных с этим(в виде смс или письма на мыло). Обладает столь незаурядным умом что рут открыл для ссш и дал ему все права в сети, которые только возможно. И свято верит что его ксенон круче какойнибудь ботнет системы. А такие люди еще остались????? =)
Атака на удачу. Человек, понимающий суть подмены ключа — не купится. Не понимающий — в большинстве случаев не получит доступ к ssh.
Стоит помнить, что при проксировании ssh соединения, атакующий неминуемо оставляет свой ip адрес в логах сервера.
В режиме экспертных настроек можно установить соответствующую опцию, которая заставит ssh сервер разрывать соединение сразу после перехвата логина и пароля. После этого желательно остановить атаку и позволить жертве спокойно соединиться с нужным сервером.
в таком случае человек получит целых 2 сообщения о неверном фингерпринте, ой какое страшное палево…
Ждём первых инцидентов с реальным применением.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MiTM атака на SSH