How to become an author
Search
Write a publication
Pull to refresh

Comments 79

так вроде проксировать SSH траффик (man in the middle) и раньше было можно… или я что-то недопонимаю?
мы ставили просто прокси в середине — клиент коннектился к нему, расшифровывали траффик и шифровали обратно, и отдавали настоящему серверу.
Total votes 4: ↑3 and ↓1+2
или это просто реклама новой фичи в данной программе?
Total votes 7: ↑6 and ↓1+5
что значит «просто прокси»? вы реализовали свой ссш сервер для этого?
Total votes 1: ↑1 and ↓0+1
ok, я с SSL перепутал, не проснулся еще…
Total votes 4: ↑2 and ↓20
Можно было и раньше и уже достаточно давно. С чего автор решил присвоить первенство в практической реализации решительно непонятно. Любой более менее серьёзно вращающийся в области ИБ специалист знает, что уже много времени как подобный функционал доступен в решениях корпоративного класса, например — BalaBit Shell Control Box.
Total votes 1: ↑1 and ↓0+1
куда нам, нищебродам-быдлокодерам, до аппаратных решений ценой 50-100 килоевро...:(
Total votes 1: ↑1 and ↓0+1
Вроде ettercap умеет mitm ssh, и тоже с warning о фингерпринт.
Total votes 5: ↑4 and ↓1+3
ettercap умеет делать ssh1 downgrade атаку.
Total votes 3: ↑3 and ↓0+3
То есть при авторизации ключами, можно спать спокойно?
Total votes 2: ↑2 and ↓0+2
до тех пор, пока я не сделал поддержку public ключей.
Total votes 9: ↑9 and ↓0+9
Но угнать сам ключ же не получится, соответственно авторизоваться отдельно — тоже.
Total votes 1: ↑1 and ↓0+1
совершенно верно, приватный ключ остается не доступным. но доступ к сессии будет получен.
Total votes 2: ↑2 and ↓0+2
А какие видимые пути решения проблемы перехвата сессии? выкидывать ssh на мороз? :)
Total votes 1: ↑0 and ↓1-1
Смотреть внимательно на предупреждения Putty
Total votes 1: ↑1 and ↓0+1
Это не решение проблемы в принципе, это тест на ССЗБ.
Total votes 1: ↑1 and ↓0+1
Насколько я понимаю абсолютного решения проблемы не существует впринципе. Так или иначе MiTM будет возможен. Что бы он был невозможен нужно будет как-то удостоверится что хост правильный. Все равно кому то приходится доверять и нужен безопасный канал. Ниже уже написали про SSH.

Лучше и безопаснее решения не будет.
Total votes 6: ↑6 and ↓0+6
Лучший выбор на мой взгляд — OpenVPN туннель (желательно с TLS) или похожее решение транспортного уровняю.
Total votes 1: ↑1 and ↓0+1
Я не понимаю, почему будет работать перехват в режиме аутентификации открытым ключом. По идее, открытый ключ вашего сервера можно опубликовать хоть здесь, на то он и открытый. Как тогда подсунуть жертве поддельный ключ?
Total votes 1: ↑1 and ↓0+1
Давайте поставим промежуточную точку в этом вопросе. Судя по всему, шифрование канала в ssh сессии
не завязано на публичный ключ. Публичный ключ это всего лишь один из способов аутентификации, т.е. удостоверения личности пользователя.

Работает этот механизм так:
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
2. клиент сообщает серверу, что собирается аутентифицироваться с помощью открытого ключа.
3. сервер (имея этот ключ) отсылает некий челендж клиенту.
4. клиент должен расшифровать челендж своим приватным ключом и дать понять серверу, что он действительно тот за кого себя выдает.
5. далее клиент может запросить терминал или другой тип сессии. но шифрование канала не зависит от способа аутентификации.

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

Теоретические выкладки относительно функционирование ассиметричного шифрования не имеют к этой теме никакого отношения. Речь ведется строго
о реализации ssh протокола. Пока что все видится именно так, как описано выше. Если кто-то обладает знаниями в этом вопросе — просьба отписаться.
Total votes 2: ↑2 and ↓0+2
Спасибо за проделанную работу. Есть несколько замечаний.

1. Насколько мне известно, шифрованный канал создается не на основе rsa/dsa ключа сервера, а при помощи алгоритма Диффи — Хеллмана. Отсюда следует интересный факт, что от длины ключа сервера не зависит вероятность успешной прослушки.

2. Насколько я понял из статьи, нет возможности «увести» сессию (чтобы работать на сервере от имени жертвы). В этом случае более надежным и простым решением кажется атака на уровень шифрования (алгоритм Диффи — Хеллмана и подмена публичного ключа сервера), при которой открытый текст, включая изменения размеров терминала, SFTP, туннелирование и т. д., передавался бы как есть, а его копия записывалась бы сервером атакующего. Такой режим не даст атакующему вмешаться и что-то сделать на сервере от имени пользователя, зато будут работать SFTP и туннели и меньше будет риск глюков (при той же работе с терминалом), которые могут выдать прослушку.

3. Пожалуйста, не делайте ошибку в слове «асимметричный», оно происходит от слова «symmetry», а не от слова «ass». К сожалению, ошибка очень популярна в материалах по криптографии, поэтому я обращаю на неё внимение.
Total votes 1: ↑1 and ↓0+1
Замечательно. Только подскажите в каком пункте (из тех, что я описал выше) допущена ошибка и почему нельзя увести сессию? И почему вы разделяете возможность выполнения команд и от возможности создания sftp сессий, либо перефразируйте весь второй пункт. Спасибо.
This comment wasn’t rated yet0
Ошибка в пункте 1:
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.

Прежде чем пояснять по моему второму пункту, я уточню принцип работы Intercepter-NG. Как я понял, он работает как ssh-сервер, принимает команды и вызывает их на настоящем сервере, подключившись к нему как ssh-клиент. Если я неправильно этот момент уяснил, то дальнейший мой ответ, скорее всего, неверен.

Дополнительный вопрос: работают ли программы, интенсивно использующие возможности терминала: vim, screen (tmux)?

Пользуясь Вашим подходом, сессию как раз можно было бы увести (то есть начать в живую вводить команды за пользователя), однако, как я понял из статьи, такой возможности нет. Поэтому, раз её всё равно нет, я предложил не «влезать» в открытый текст (будь то команды, SFTP, туннели и остальные «надстройки»), а передавать его как есть, сохраняя себе копию. Анализ этой копии (выполняемый постфактум) выявит всё, что передавалось, будь то команды, файлы или туннели. Причем можно сначала реализовать только извлечение команд, а возможность извлечения SFTP добавить потом, при этом SFTP можно будет извлекать и из старых дампов тоже, так как в них записывается всё, а не только то, что текущая версия умеет извлекать.
This comment wasn’t rated yet0
С ключами и диффи-хеллманом понятно, на обсуждаемый вопрос это не влияет. Принцип работы уяснили правильно. Вот только ничего сохранить или ввести не получится, потому что аутентификация не пройдет, и никакого терминального сеанса установлено не будет. Точно так же не будут работать и SFTP и прочие возможности SSH. Все что можно сделать, это выступить в качестве сервера самому (без привлечения оригинального сервера), но тут огромная куча ограничений. Если жертва зааплодит файл, то мы его сможем принять, но в последствии он его не обнаружит на своем сервере. Если жертва захочет скачать файл со своего сервера, то у нас его и вовсе не окажется.

Ниже уже разобрались, что с публичными ключами ничего сделать не удастся.

ps: vi\tmux и любой другой терминальный софт работают.
This comment wasn’t rated yet0
Вы имели ввиду ситуацию, когда атакующий говорит клиенту, что якобы аутентификация прошла успешно (хотя на самом деле доступа никуда мы не получили) и клиент начинает, к примеру, пересылать файлы по sftp, которые мы деть никуда не сможем, но сможем «перехватить» для себя, этакий минимальный профит. Я вас правильно понял?
This comment wasn’t rated yet0
Как шаги могут быть повторены атакующим, если он не знает приватных ключей?

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

Это, конечно, если я правильно разобрался с механизмом формирования идентификатора сессии и он содержит данные, известные только серверу и проверяемые его публичным ключом, а значит атакующий не сможет предоставить такой же идентификатор клиенту, т. к. он подменяет публичный ключ сервера на свой. В случае парольной аутенфикации это не имеет значение, потому что атакующий может подменять идентификатор сессии в обе стороны, а в случае с подписью он этого сделать не может, потому что клиент подписывает его свои закрытым ключом, а подпись проверяется публичным ключом клиента, хранящимся на сервере.
Total votes 1: ↑1 and ↓0+1
Если такая привязка к уникальному ID сессии действительно существует, то все вопросы снимаются. Но я сходу не могу найти детального описания этого процесса. Не подкините ссылку?
This comment wasn’t rated yet0
Вот из рфц нашлось

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 сессии, равный тому, что выдал
оригинальный сервер.
This comment wasn’t rated yet0
Описано тут по идее ools.ietf.org/html/rfc4253

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 клиенту.
Total votes 1: ↑1 and ↓0+1
Проблема в том, что session id генерируется клиентом самостоятельно, на основе данных обмена ключами.
Интересно и то, что по сути, однажды созданный id больше ни за что не отвечает, он используется только при проверке подписи. Так что, если бы сервер мог выдать клиенту произвольный идентификатор все бы завершилось успешно.
Спасибо, вопрос закрыт.
This comment wasn’t rated yet0
openssh-шный клиент просто не даст подключиться, если с ключами не всё в порядке. Никаких вопросов, просто не даст и всё.
Total votes 3: ↑1 and ↓2-1
мак шлюза хотя бы статиком прописать, но кроме арп пойзона есть и другие способы перехвата управления.
Total votes 1: ↑1 and ↓0+1
по ключам внизу еще важное дополнение. вполне возможно они есть спасение.
Total votes 1: ↑1 and ↓0+1
К счастью это должно быть не очень опасно для пользующихся publickey авторизацией. Неуверен можно ли вмешатся в обмен со своими командами (теоритически)?
This comment wasn’t rated yet0
про ключи ответ выше. в обмен вмешаться естественно можно.
Total votes 1: ↑1 and ↓0+1
Это единственный подозрительный момент который возникает при проведении атаки.

Подозрительный? Да тот же putty черным по белому пишет, что это ппц и дальше нельзя:



Покажите мне хотя бы одного человека который не обратит внимания.
Total votes 30: ↑25 and ↓5+20
таких людей гораздо больше чем вам кажется.
Total votes 41: ↑40 and ↓1+39
Ну подобные диалоги выдают все программы, работающие с SSL. Эффектнее всего это сделано в хроме (а затем в других браузераз) — на красном фоне.

Что еще можно придумать для такой ситуации? Выдавать тест-экзамен по информационной безопасности для активации кнопки «Да»?
Total votes 5: ↑5 and ↓0+5
Выдавать тест-экзамен по информационной безопасности для активации кнопки «Да»?

Патентуйте, пока не поздно :)!
Total votes 3: ↑2 and ↓1+1
Первый вариант, что это штатная ситуация и лишь второй, что это атака.
Total votes 7: ↑4 and ↓3+1
Как часто вам приходилось менять ключи сервера и зачем?
Total votes 3: ↑3 and ↓0+3
Смотря что считать сервером. Если то, что идентифицируется по DNS, то банальная смена хостинга или переход на другой тарифный план обычные ситуации.

Ну и речь явно о многопользовательских системах, где есть администратор, который по каким-то своим причинам, простым смертным неизвестным, может сменить ключ.
Total votes 3: ↑3 and ↓0+3
который по каким-то своим причинам
Например, при переходе на ECDSA ключи.
This comment wasn’t rated yet0
Вот опять. Когда вы меняете сами ключи, то вы ожидаете это сообщение. Когда я работалю на своем сервере, и тут мне внезапно говорят, что отпечаток изменился — это явно не штатная ситуация.
Total votes 1: ↑1 and ↓0+1
А вот если вы мне предоставили доступ на свой сервер, а потом поменяли ключи, то мне остается только монетку бросать — штатное это изменение или MitM — если вы меня не предупредили заранее о смене и/или не попросили лично уведомлять о сообщениях о смене и до ответа никаких мер не предпринимать.
This comment wasn’t rated yet0
При обновлении Убунты на сервере до версии 12.04 у меня «полетели» настройки ssh-сервера. Пришлось его заново ставить. Как следствие — поменялись ключи. Увидел такое вот предупреждение и очень долго пытался отогнать навязчивую идею о Большом Брате, пока не вспомнил об этом обновлении ОС. А мои коллеги вообще на предупреждение никак не отреагировали и продолжили работать с сервером без задней мысли. Так что плюсую коммент выше:
таких людей гораздо больше чем вам кажется.
Total votes 3: ↑3 and ↓0+3
Почему обязательно сервера? SSH и на сетевом железе используется. Ситуация «один из сотен роутеров/свитчей был заменен на другой с тем же конфигом» вполне обыденна. Конфиг передается под копирку (то есть адрес будет как у старой железки), а пара ключей генерируется заново.

Так что да, видя подобное сообщение, я предположу, что железка была заменена, на всякий случай перепроверю, и приму новый ключ. Не впервой.
Total votes 2: ↑2 and ↓0+2
При обновлении openssh-сервера (по крайней мере на Debian) происходит перегенерация ключа.
Total votes 2: ↑2 and ↓0+2
В первом варианте (и при первом соединении) тоже нельзя слепо принимать ключ. Надо получить настоящий отпечаток ключа по другому, безопасному каналу, и сравнить его с имеющимся. GitHub, например, публикует свой отпечаток ключа на HTTPS-странице: help.github.com/articles/generating-ssh-keys. Ну а если это свой сервер, то можно получить настоящий отпечаток через локальную консоль.
Total votes 1: ↑1 and ↓0+1
В теории — да, на практике очень мало кто этим занимается, а иной раз это практически невозможно.
This comment wasn’t rated yet0
Консольный OpenSSH в явном виде запрещает подсоединение при измении ключа — чтобы подсоединиться, нужно пойти и удалить из known_keys прошлый ключ. Так как это действие происходит не за пару секунд и его нельзя выполнить, не подумав, а что, собственно, происходит.

Проксификация соединения, авторизация которого производится при помощи PKI (сертификаты или пара RSA-ключей) — да на здоровье, с тем же успехом вы можете чужие SSL-сессии записывать. Т.е. записывать-то можете, но толку мало — кроме факта соединения (т.е. того, что и так не представляет секрета) никакой дополнительной информации извлечь не удастся.
Total votes 13: ↑12 and ↓1+11
да, в юниксе с этим более безопасно.

по поводу pki и пользы перехвата. скорее всего вы правы, я не вдавался в детали реализации этого алгоритма в ссш.
но возможно есть шанс, что паблик ключ нужен только в момент авторизации, а дальше устанавливается сессия, в которой атакующий сможет исполнять команды. скорее всего это не так, но и полностью отбрасывать эту мысль не стану.
Total votes 3: ↑3 and ↓0+3
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.

т.е. шифрование канала происходит независимо от типа аутентификации. нам важно получить доступ к серверу, это можно сделать не владея приватным ключом, и согласно архитектуре никаких проблем с исполнением команд быть не должно.
если не прав, поправьте.
Total votes 1: ↑1 and ↓0+1
По идее, если вы смогли перехватить SSH-сессию, то чисто теоретически у вас будет доступ к соответствующему серверу на всё время жизни соединения (само соединение можно не закрывать после того, как клиент отсоединился). Именно потому, что авторизация играет роль только для первичного получения доступа к серверу, но не для последующего обмена информацией между сервером и клиентом.
Total votes 1: ↑1 and ↓0+1
именно это я и хочу сказать.

пример товарища mwizard про SSL не корректен, потому что там сертификаты отвечают за шифрование самого канала. в ссш с этим иначе.
Total votes 1: ↑1 and ↓0+1
В принципе, можно заставить OpenSSH коннектиться к серверу, даже если не совпадает fingerpint, но тогда авторизация по паролю отключается и выдается следующее сообщение:

$ 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, что тоже является дополнительным барьером к тому, чтобы подключиться к чужому серверу, не заметив этого.
Total votes 4: ↑4 and ↓0+4
В моем понимании это не атака, это просто проксирование SSH со всеми вытекающими последствиями. К криптографической стойкости протокола этот процесс никакого отношения не имеет.
Total votes 17: ↑13 and ↓4+9
называть можно как угодно. суть в том, что есть возможность перехватить данные. да собственно она была всегда, и проблема эта касается практически любого протокола, просто не было рабочей реализации.
Total votes 8: ↑5 and ↓3+2
Я всегда использую OpenVPN (PKCS12-сертификат/TLS) туннель с сервером.
This comment wasn’t rated yet0
Великолепно :)
Скоро вас похитят и заставят писать Russian DPI :)
This comment wasn’t rated yet0
При MITM атаках, почти всегда, почти, срабатывает предупреждение.
По крайней мере, я встречаю подобную защиту во всех анализируемых программах, НО человеческий фактор я бы тоже не отрицал, в данной ситуации.
This comment wasn’t rated yet0
Спасибо, конечно, за полезную приблуду, но это в стиле вируса для UNIX, для работы которого надо во-1, его собрать, во-2, пропатчить ядро для совместимость, в-3 собственно запустить.

Основные программы, работающие с SSH при авторизации и несовпадении сохраненного отпечатка сервера закатывают истерику, на которую не обратит внимание только уже совсем упоротый пользователь. Имхо проще и незаметнее пользователю putty трояна подкинуть пароль\ключи увести. Про никсы вообще молчу.
Total votes 15: ↑5 and ↓10-5
3 раза кликнуть мышкой это тоже самое, что собрать сорц и пропатчить ядро?:)
Total votes 4: ↑2 and ↓20
А перехват ключей таит в себе какие-то дополнительные сложности, или это просто вопрос времени?
Я так понимаю трафик пойдет через ваши сервера, посему использовать эту функцию с целью пентестинга своих серверов небезопасно.
This comment wasn’t rated yet0
Дополнительные сложности, преодоление которых это просто вопрос времени.

ни через какие «мои» сервера ничего не пойдет. ссш сервер встроен в сам интерцептер.
Total votes 2: ↑1 and ↓10
У меня авторизация по ключам, перехватывайте, пожалуйста, мне не жалко.
Total votes 9: ↑0 and ↓9-9
Как настоящий параноик, храню распечатанные фингерпринты ключей всех серверов, с которыми работаю.
Total votes 1: ↑1 and ↓0+1
Атака?
Где здесь атака-то?
Это просто демонстрация работы фингерпринтов в SSH. Не морочьте людям голову.
Total votes 5: ↑2 and ↓3-1
Вы сами поняли, что сказали топиком?
Total votes 2: ↑0 and ↓2-2
Итак. Атака офигенно подходит для админа который… не вкуривает что такое открытие портов для конкретного ипа или динамическое открытие порта по требованию, спал на уроках по впн и по этой причине не реализовал это у себя в сети, настолько нищий что не может реализовать логирование на стороннем сервисе с правами только на чтение, и автоинформированием о разных событиях связанных с этим(в виде смс или письма на мыло). Обладает столь незаурядным умом что рут открыл для ссш и дал ему все права в сети, которые только возможно. И свято верит что его ксенон круче какойнибудь ботнет системы. А такие люди еще остались????? =)
Total votes 2: ↑1 and ↓10
Описанные вами «супермены» скорее исключение, чем правило :)
This comment wasn’t rated yet0
А кто говорит, что речь обязательно про атаку через интернет? ;)
Само собой открытый наружу ssh, особенно если без ограничений по адресам — признак идиотизма и даже не рассматривается.
This comment wasn’t rated yet0
Атака на удачу. Человек, понимающий суть подмены ключа — не купится. Не понимающий — в большинстве случаев не получит доступ к ssh.
Total votes 4: ↑1 and ↓3-2
Почему этот -1 такой темный, жирный и угнетающий? Надо делать розовыми и маленькими цифры с минусами. В этом причина недовольства людьми минусами, а не в карме.
Total votes 2: ↑0 and ↓2-2
Стоит помнить, что при проксировании ssh соединения, атакующий неминуемо оставляет свой ip адрес в логах сервера.
В режиме экспертных настроек можно установить соответствующую опцию, которая заставит ssh сервер разрывать соединение сразу после перехвата логина и пароля. После этого желательно остановить атаку и позволить жертве спокойно соединиться с нужным сервером.

в таком случае человек получит целых 2 сообщения о неверном фингерпринте, ой какое страшное палево…
This comment wasn’t rated yet0
Ждём первых инцидентов с реальным применением.
Total votes 2: ↑1 and ↓10
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr