Назад | Перейти на главную страницу

Если, используя только открытые ключи, SSH-клиент входит (или уже вошел) на скомпрометированный SSH-сервер, подвергается ли риску SSH-клиент?

Существуют ли условия, при которых злоумышленник с контролем над сервером может получить доступ к клиенту и инициировать действия на нем? Я понимаю, что злоумышленник может установить трояны на сервере в надежде, что пользователь, стоящий за клиентом SSH, вытащит их (вручную или с помощью скрипта), но есть ли и другие векторы атаки?

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

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

  1. Перенаправление удаленного порта (с участием -R). Человек / вредоносное ПО в удаленной системе получит доступ к локальному порту.
  2. Перенаправление туннельного устройства (с участием -w). Человек / вредоносное ПО в удаленной системе сможет отправлять трафик через туннель.
  3. Перенаправление соединения агента аутентификации (-A). Человек / вредоносное ПО в удаленной системе сможет использовать вашу связку ключей ssh-agent для аутентификации на других серверах SSH, для которых у вас есть ключи.
  4. X11 пересылка (-X или -Y). Как отмечали другие, протокол X11 был разработан с расчетом на доверенных клиентов. Вредоносное ПО может считывать содержимое других окон, отправлять нажатия клавиш или просто отображать окно с запросом пароля.

Еще одна вещь, которую следует учитывать, - это эмулятор терминала, который вы используете. Скорее всего, это графический интерфейс вроде konsole или Терминал GNOME. Если он уязвим, его также можно использовать с помощью программы на взломанном сервере (например, удаленный сервер может отправить последовательность символов, которая вызывает переполнение буфера и позволяет злоумышленнику выполнить код на вашем клиентском компьютере).

Я никогда не слышал о червях или программах для автоматической атаки, использующих эти векторы атаки, но если это целенаправленная атака, они (особенно переадресация агентов) могут быть использованы против вас.

Существуют (я считаю, только) теоретические атаки с использованием перенаправления X, которые могут это сделать.

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

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

По сути, это не представляет угрозы безопасности (за исключением случаев, когда вы используете скомпрометированный компьютер), если вы также не используете пересылку X (окна X не изолированы).

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

Это чисто теоретические вещи. Хотя что-то подобное, безусловно, возможно, я никогда об этом не слышал.

Я не совсем уверен, в чем именно заключается ваш вопрос, поэтому не стесняйтесь обновлять его, если это не тот ответ, который вы ищете.

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

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