Я осведомлен о том, что на моем ресурсе никаких инфекций нет и быть не может. Для успокоения скачайте этот джепег и посмотрите wireshark'ом что отдает сервер.
С ключами и диффи-хеллманом понятно, на обсуждаемый вопрос это не влияет. Принцип работы уяснили правильно. Вот только ничего сохранить или ввести не получится, потому что аутентификация не пройдет, и никакого терминального сеанса установлено не будет. Точно так же не будут работать и SFTP и прочие возможности SSH. Все что можно сделать, это выступить в качестве сервера самому (без привлечения оригинального сервера), но тут огромная куча ограничений. Если жертва зааплодит файл, то мы его сможем принять, но в последствии он его не обнаружит на своем сервере. Если жертва захочет скачать файл со своего сервера, то у нас его и вовсе не окажется.
Ниже уже разобрались, что с публичными ключами ничего сделать не удастся.
ps: vi\tmux и любой другой терминальный софт работают.
Проблема в том, что session id генерируется клиентом самостоятельно, на основе данных обмена ключами.
Интересно и то, что по сути, однажды созданный id больше ни за что не отвечает, он используется только при проверке подписи. Так что, если бы сервер мог выдать клиенту произвольный идентификатор все бы завершилось успешно.
Спасибо, вопрос закрыт.
Вы имели ввиду ситуацию, когда атакующий говорит клиенту, что якобы аутентификация прошла успешно (хотя на самом деле доступа никуда мы не получили) и клиент начинает, к примеру, пересылать файлы по sftp, которые мы деть никуда не сможем, но сможем «перехватить» для себя, этакий минимальный профит. Я вас правильно понял?
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 сессии, равный тому, что выдал
оригинальный сервер.
Если такая привязка к уникальному ID сессии действительно существует, то все вопросы снимаются. Но я сходу не могу найти детального описания этого процесса. Не подкините ссылку?
Замечательно. Только подскажите в каком пункте (из тех, что я описал выше) допущена ошибка и почему нельзя увести сессию? И почему вы разделяете возможность выполнения команд и от возможности создания sftp сессий, либо перефразируйте весь второй пункт. Спасибо.
Давайте поставим промежуточную точку в этом вопросе. Судя по всему, шифрование канала в ssh сессии
не завязано на публичный ключ. Публичный ключ это всего лишь один из способов аутентификации, т.е. удостоверения личности пользователя.
Работает этот механизм так:
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
2. клиент сообщает серверу, что собирается аутентифицироваться с помощью открытого ключа.
3. сервер (имея этот ключ) отсылает некий челендж клиенту.
4. клиент должен расшифровать челендж своим приватным ключом и дать понять серверу, что он действительно тот за кого себя выдает.
5. далее клиент может запросить терминал или другой тип сессии. но шифрование канала не зависит от способа аутентификации.
Будучи по-середине, все шаги могут быть повторены атакующим. Т.е. атакующий не имея приватного ключа, получает доступ к авторизованной сессии
и способен выполнять команды от лица пользователя.
Теоретические выкладки относительно функционирование ассиметричного шифрования не имеют к этой теме никакого отношения. Речь ведется строго
о реализации ssh протокола. Пока что все видится именно так, как описано выше. Если кто-то обладает знаниями в этом вопросе — просьба отписаться.
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.
т.е. шифрование канала происходит независимо от типа аутентификации. нам важно получить доступ к серверу, это можно сделать не владея приватным ключом, и согласно архитектуре никаких проблем с исполнением команд быть не должно.
если не прав, поправьте.
называть можно как угодно. суть в том, что есть возможность перехватить данные. да собственно она была всегда, и проблема эта касается практически любого протокола, просто не было рабочей реализации.
по поводу pki и пользы перехвата. скорее всего вы правы, я не вдавался в детали реализации этого алгоритма в ссш.
но возможно есть шанс, что паблик ключ нужен только в момент авторизации, а дальше устанавливается сессия, в которой атакующий сможет исполнять команды. скорее всего это не так, но и полностью отбрасывать эту мысль не стану.
Ниже уже разобрались, что с публичными ключами ничего сделать не удастся.
ps: vi\tmux и любой другой терминальный софт работают.
Интересно и то, что по сути, однажды созданный 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 сессии, равный тому, что выдал
оригинальный сервер.
не завязано на публичный ключ. Публичный ключ это всего лишь один из способов аутентификации, т.е. удостоверения личности пользователя.
Работает этот механизм так:
1. клиент соединяется с сервером и устанавливает шифрованый канал, на основе rsa\dsa ключей сервера.
2. клиент сообщает серверу, что собирается аутентифицироваться с помощью открытого ключа.
3. сервер (имея этот ключ) отсылает некий челендж клиенту.
4. клиент должен расшифровать челендж своим приватным ключом и дать понять серверу, что он действительно тот за кого себя выдает.
5. далее клиент может запросить терминал или другой тип сессии. но шифрование канала не зависит от способа аутентификации.
Будучи по-середине, все шаги могут быть повторены атакующим. Т.е. атакующий не имея приватного ключа, получает доступ к авторизованной сессии
и способен выполнять команды от лица пользователя.
Теоретические выкладки относительно функционирование ассиметричного шифрования не имеют к этой теме никакого отношения. Речь ведется строго
о реализации ssh протокола. Пока что все видится именно так, как описано выше. Если кто-то обладает знаниями в этом вопросе — просьба отписаться.
ни через какие «мои» сервера ничего не пойдет. ссш сервер встроен в сам интерцептер.
пример товарища mwizard про SSL не корректен, потому что там сертификаты отвечают за шифрование самого канала. в ссш с этим иначе.
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.
т.е. шифрование канала происходит независимо от типа аутентификации. нам важно получить доступ к серверу, это можно сделать не владея приватным ключом, и согласно архитектуре никаких проблем с исполнением команд быть не должно.
если не прав, поправьте.
по поводу pki и пользы перехвата. скорее всего вы правы, я не вдавался в детали реализации этого алгоритма в ссш.
но возможно есть шанс, что паблик ключ нужен только в момент авторизации, а дальше устанавливается сессия, в которой атакующий сможет исполнять команды. скорее всего это не так, но и полностью отбрасывать эту мысль не стану.