Улитки 🐌🐌

Уязвимость в OpenSSH и musl позволяет обойти SSH-аутентификацию в Linux

Независимый ИБ-исследователь Озгюн Кюльтекин
(Özgün Kültekin) обнаружил уязвимость *sshhole,
которая возникает при взаимодействии OpenSSH и библиотеки musl libc. При определенной конфигурации Linux-системы баг позволяет войти в учетную запись с отключенной парольной аутентификацией, просто отправив через SSH слишком длинный пароль.
Уязвимость, которой еще не присвоили идентификатор CVE, затрагивает Linux-системы с musl libc, где OpenSSH работает без РАМ и разрешена парольная аутентификация. То есть в первую очередь речь идет об Alpine Linux, однако проблема может затрагивать и другие системы, собранные с использованием musl, в том числе решения на базе Buildroot и Yocto. Отдельно Кюльтекин упоминает OpenWrt, если вместо штатного Dropbear там установлен OpenSSH.
Корень проблемы заключается в том, как sshd осуществляет проверку паролей. В Linux для учетной записи можно заблокировать вход по паролю, указав * вместо хеша в /etc/shadow. В результате такой аккаунт, например, может использовать только SSH-ключи, и никакой пароль для него подходить не должен.

Однако в 2016 году разработчики OpenSSH исправили уязвимость CVE-2016-6210, которая позволяла определять существующие имена пользователей по времени ответа сервера. Для этого sshd стал выполнять хеширование пароля даже для тех учетных записей, для которых вход по паролю фактически отключен. То есть атакующие более не могли определить имена пользователей по разнице во времени ответа.
Как выяснилось теперь, в системах с musl после выхода этого патча возник неожиданный побочный эффект: при использовании SHA-256 crypt или
SHA-512 crypt функция crypt() отказывается обрабатывать пароли длиннее 256 байт и возвращает * как признак ошибки. Однако то же значение может храниться в /etc/shadow для учетной записи с отключенной парольной аутентификацией. В результате sshd сравнивает полученную * со значением * в /etc/shadow и считает проверку успешной.
Кюльтекин объясняет, что для осуществления атаки нужно соблюсти ряд условий:
OpenSSH работает без РАМ;
включена парольная аутентификация (PasswordAuthentication yes);
для целевого аккаунта в /etc/shadow указано * вместо хеша;
в системе должна быть хотя бы одна активная учетная запись с паролем в формате SHA-256

Если все условия соблюдены, атакующему достаточно знать имя целевой учетной записи и при подключении через SSH ввести пароль длиной от 257 до 1024 байт.
Новая проблема особенно опасна для Alpine Linux, где пакет openssh-server собран без РАМ, И разработчики подтверждают, что атака на *sshhole срабатывает с одной попытки.
Более того, отдельный риск связан с официальными облачными образами Alpine Linux для AWS и Azure. В некоторых из них присутствует учетная запись alpine, которой разрешено выполнять команды через doas без пароля, и компрометация такого аккаунта может привести к получению root-прав. При этом напрямую войти через SSH под root по умолчанию нельзя: стандартная настройка OpenSSH PermitRootLogin prohibit-password запрещает парольную аутентификацию для этой учетной записи.
Следует отметить, что разработчики OpenSSH и musl расходятся во мнениях о том, на чьей именно стороне находится ошибка. В OpenSSH считают, что первопричина возникновения бага лежит за пределами sshd, хотя эксплуатацию уязвимости можно предотвратить на его стороне. В свою очередь, разработчик musl Рич Фелкер (Rich Felker) заявил, что корень проблемы заключается не в работе musl, а в том, как вызывающая программа обрабатывает значение, которое crypt() возвращает при ошибке.

Защиту от *sshhole добавили в OpenSSH 10.6p2, а разработчики Alpine уже выпустили исправленные версии пакетов. Если установить обновления пока по какой-то причине невозможно, рекомендуется отключить парольную аутентификацию
(PasswordAuthentication no) и перезапустить sshd.

29 views01:43