Debian OpenSSL Предсказуемый PRNG

Ссылки

Оригинальный URL: http://metasploit.com/users/hdm/tools/debian-openssl/ (Зеркало)

Эксплоит:

Рекомендуемый инструмент: Crowbar (способен на брутфорс SSH-ключей)

Метод тестирования: ssh-vulnkey & dowkd.pl

CVE (CVE-2008-0166):

Информация

Ошибка

13 мая 2008 года проект Debian объявил, что Лучано Белло обнаружил интересную уязвимость в распространяемом ими пакете OpenSSL. Ошибка была вызвана удалением следующей строки кода из md_rand.c

	MD_Update(&m,buf,j);
	[ .. ]
	MD_Update(&m,buf,j); /* purify complains */

Эти строки были удалены, поскольку они вызывали предупреждения от инструментов Valgrind и Purify об использовании неинициализированных данных в любом коде, связанном с OpenSSL. Один из таких отчётов команде OpenSSL можно увидеть здесь. Удаление этого кода имело побочный эффект — нарушение процесса инициализации PRNG в OpenSSL. Вместо смешивания случайных данных для начального seed-значения использовалось только одно «случайное» значение — текущий идентификатор процесса. На платформе Linux максимальный идентификатор процесса по умолчанию составляет 32 768, что приводит к очень малому количеству seed-значений для всех операций PRNG.

Влияние

Все ключи SSL и SSH, сгенерированные на системах на базе Debian (Ubuntu, Kubuntu и т.д.) в период с сентября 2006 года по 13 мая 2008 года, могут быть затронуты. В случае SSL-ключей все сгенерированные сертификаты необходимо будет пересоздать и отправить в центр сертификации для подписи. Любые ключи центра сертификации, созданные на системе на базе Debian, потребуется перегенерировать и отозвать. Всем системным администраторам, которые разрешают пользователям доступ к своим серверам по SSH с аутентификацией по открытому ключу, необходимо проверить эти ключи на предмет того, не были ли они созданы на уязвимой системе. Любые инструменты, полагавшиеся на PRNG OpenSSL для защиты передаваемых данных, могут быть уязвимы для атаки в офлайн-режиме. Любой SSH-сервер, использующий хост-ключ, сгенерированный на уязвимой системе, подвержен расшифровке трафика, и атака «человек посередине» останется незамеченной для пользователей. Эта уязвимость неприятна тем, что даже системы, не использующие программное обеспечение Debian, необходимо проверять на предмет использования ключей, созданных на системе Debian. Проекты Debian и Ubuntu выпустили набор инструментов для идентификации уязвимых ключей. Их можно найти в разделе ссылок ниже.

Игрушки

Чёрные списки, опубликованные Debian и Ubuntu, показывают, насколько мало пространство ключей. При создании нового ключа OpenSSH существует всего 32 767 возможных исходов для данной архитектуры, размера ключа и типа ключа. Причина в том, что единственными «случайными» данными, используемыми PRNG, является идентификатор процесса. Для генерации фактических ключей, соответствующих этим чёрным спискам, нам нужна система с правильными бинарными файлами для целевой платформы и способ генерировать ключи с определённым идентификатором процесса. Чтобы решить проблему идентификатора процесса, я написал разделяемую библиотеку, которую можно предзагрузить и которая возвращает заданное пользователем значение для вызова getpid() libc.

Следующим шагом было создание chroot-окружения, содержащего фактические бинарные файлы и библиотеки из уязвимой системы. Я сделал снимок с системы Ubuntu в локальной сети. Всё chroot-окружение можно найти здесь. Чтобы сгенерировать ключ OpenSSH с определённым типом, разрядностью и идентификатором процесса, я написал shell-скрипт, который можно выполнять внутри chroot-окружения. Этот скрипт можно найти здесь. Он помещается в корневой каталог извлечённой файловой системы Ubuntu. Для генерации ключа этот скрипт вызывается следующей командной строкой:

# chroot ubunturoot /dokeygen.sh 1 -t dsa -b 1024 -f /tmp/dsa_1024_1

Это сгенерирует новый ключ OpenSSH DSA 1024 бита со значением getpid(), всегда возвращающим число «1». Теперь у нас есть первый предварительно сгенерированный SSH-ключ. Если продолжить этот процесс для всех PID до 32 767 и затем повторить его для 2048-битных RSA-ключей, мы покроем допустимые диапазоны ключей для x86-систем с ошибочной версией библиотеки OpenSSL. С этим набором ключей мы можем скомпрометировать любую учётную запись пользователя, у которой в файле authorized_keys указан уязвимый ключ. Этот набор ключей также полезен для расшифровки ранее перехваченной SSH-сессии, если SSH-сервер использовал уязвимый хост-ключ. Ссылки на предварительно сгенерированные наборы ключей для 1024-битных DSA и 2048-битных RSA (x86) приведены в разделе загрузок ниже.

Интересная особенность этих ключей — их привязка к идентификатору процесса. Поскольку большинство систем на базе Debian используют последовательные идентификаторы процессов (увеличивающиеся от загрузки системы и зацикливающиеся по мере необходимости), идентификатор процесса данного ключа также может указывать, как скоро после загрузки системы этот ключ был сгенерирован. Если взглянуть на обратное, мы можем определить, какие ключи использовать при брутфорсе в зависимости от цели атаки. При попытке угадать ключ, сгенерированный во время загрузки (например, хост-ключ SSH), наиболее подходящими будут ключи со значением PID менее 200. При атаке на ключ, созданный пользователем, можно предположить, что большинство действительных пользовательских ключей были созданы с идентификатором процесса больше 500 и меньше 10 000. Эта оптимизация может значительно ускорить атаку брутфорсом на удалённую учётную запись пользователя по протоколу SSH.

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

 / Алгоритм / Биты / Отпечаток-ИдентификаторПроцесса
   и
 / Алгоритм / Биты / Отпечаток-ИдентификаторПроцесса.pub

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

 $ ssh-keygen -l -f targetkey.pub
 2048 c6:7b:14:fa:ae:b6:89:e6:67:17:ee:04:17:b0:ec:4e targetkey.pub

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

 rsa/2048/**c67b14faaeb689e66717ee0417b0ec4e-26670**

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

 $ ssh -i rsa/2048/c67b14faaeb689e66717ee0417b0ec4e-26670 root@targetmachine

Часто задаваемые вопросы

В: Сколько времени заняла генерация этих ключей?

О: Я использовал 31 ядро Xeon с частотой 2.33 ГГц. Генерация 1024-битных DSA и 2048-битных RSA-ключей для x86 заняла два часа. Генерация 4096-битных RSA-ключей заняла около 6 часов. Генерация 8192-битных RSA-ключей при текущей скорости заняла бы около 100 часов и, вероятно, будет остановлена до завершения.

В: Вы поделитесь своим кодом для распределения генерации ключей на несколько процессоров?

О: Нет. Код жёстко привязан к этому конкретному кластеру и слишком плохо написан, чтобы его стоило чистить.

В: Сколько времени занимает взлом учётной записи SSH с использованием этих ключей?

О: Это зависит от скорости сети и конфигурации SSH-сервера. Должно быть возможно перебрать все 32 767 ключей как DSA-1024, так и RSA-2044 в течение пары часов, но остерегайтесь анти-брутфорс скриптов на целевом сервере.

В: Я использую 16384-битные RSA-ключи, можно ли их взломать?

О: Да, это лишь вопрос времени и вычислительной мощности. Генерация набора 8192-битных RSA-ключей заняла бы около 3100 часов процессорного времени для создания всех 32 767 ключей (100 часов на 31 ядре, которые я использую сейчас). Полагаю, что для набора 16384-битных RSA-ключей потребуется около 100 000 часов процессорного времени. Стоит помнить, что большинство ключей находятся в гораздо меньшем диапазоне (основанном на seed-значении идентификатора процесса), и для покрытия большинства пользовательских ключей не нужно генерировать весь набор (большинство ключей находятся в пределах первых 3 000 идентификаторов процесса).

debian-ssh

Популярное