DROWN официально: сканируем 12 клиентов, находим 23 уязвимых сервера

Сегодня в 12:00 UTC исследователи опубликовали полный disclosure по DROWN. Мы знали, что это случится - в феврале проводили превентивную проверку по предупреждению из закрытого канала. Тогда прошлись по собственной инфраструктуре и части клиентов. Сегодня пришло время пройтись по всем двенадцати.

Официальные цифры в пресс-релизе выглядят неприятно: по оценке исследователей, 33% HTTPS-серверов в мире подвержены атаке. Механика: если хоть один сервер принимает SSLv2-соединения и использует тот же приватный ключ, что и TLS-сервер, - атакующий может с достаточным числом запросов расшифровать TLS-сессию. Тот самый «забытый почтовый сервер» из угла - полноценный вектор атаки на основной HTTPS.

Как выглядело утро

Публикация пришлась на первую половину дня. К 13:00 уже была полная картина по механике атаки, работающий PoC в academic-варианте и гора ссылок в профильных чатах. Клиенты начали писать примерно в то же время - кто-то сам прочитал, кому-то переслали коллеги.

Решили не ждать, пока поток вопросов станет неуправляемым, и запустили проверку по всем двенадцати клиентам сразу. Логика простая: лучше мы первые сообщим о проблеме с готовым планом исправления, чем клиент узнает из новостей и позвонит в панике.

Инвентаризация: что и как проверяли

Инструментарий - тот же, что и в феврале. Nmap с ssl-enum-ciphers по всем SSL-портам: 443, 8443, 465, 993, 995, 8080 где применимо. Параллельно - ansible-скрипт по серверам с ssh-доступом, который вытаскивает конфигурацию ssl_protocols из nginx и dovecot.

Порты выбраны не случайно. Веб на 443 обычно в порядке - его трогают чаще, конфигурация свежее. Почтовые порты - отдельная история: Dovecot и Postfix с дефолтными настройками образца 2011-2013 года, которые никто не пересматривал, потому что «почта работает, не трогай».

Полный прогон по двенадцати клиентам занял около двух часов - с учётом ручной проверки результатов и разбора пограничных случаев.

Что нашли

Итого 23 сервера с активным SSLv2. Распределение оказалось предсказуемым:

• Почтовые серверы - 14 штук. Dovecot без явного указания ssl_protocols, Postfix с дефолтным smtpd_tls_protocols. Одни и те же настройки, скопированные из одного и того же мануала несколько лет назад.
• Балансировщики и VPN-устройства - 5 штук. Железо с прошивками 2012-2014 года. Самая неудобная категория: обновить конфигурацию через web-интерфейс иногда недостаточно - протокол продолжает отвечать вне зависимости от настроек интерфейса.
• Старые Apache и IIS - 4 штуки. Apache с httpd.conf без явного SSLProtocol, Windows Server 2003/2008 без registry-патча для отключения SSLv2.

Веб-серверы на nginx с явным ssl_protocols - в порядке почти везде. Февральская работа не пропала зря: несколько серверов, которые мы исправили тогда, сегодня показали чисто.

Восемь часов реагирования

13:00 - 15:00. Сканирование и сортировка результатов. Приоритет расставили по критичности: сначала серверы, где SSLv2 включён на том же IP и с тем же сертификатом, что и основной HTTPS - это максимальный риск по модели DROWN. Потом - серверы с тем же ключом на другом порту. Потом - всё остальное.

15:00 - 17:00. Исправление Linux-серверов. Для Dovecot: ssl_protocols = !SSLv2 !SSLv3 в 10-ssl.conf, reload. Для Postfix: smtpd_tls_protocols = !SSLv2,!SSLv3 в main.cf, reload. Для Apache: SSLProtocol all -SSLv2 -SSLv3 в конфиге виртуального хоста. Рестарт, проверка nmap, следующий сервер. Рутина, но рутина с дедлайном.

17:00 - 19:00. Железо. Три из пяти устройств закрыли обновлением прошивки или правкой конфигурации через CLI - там это работало корректно в отличие от web-интерфейса. Два устройства - тупик: вендор не выпустил обновление, и web-интерфейс врёт о состоянии SSLv2. Временное решение: ограничить доступ к этим устройствам на уровне firewall, поставить задачу вендору на обновление прошивки, зафиксировать как открытый риск.

19:00 - 21:00. Отчёты клиентам. Для каждого - что нашли, что исправили, что осталось открытым и почему, что нужно сделать с оборудованием. Не шаблон, а конкретика по каждой позиции.

Что это значит на практике

23 уязвимых сервера на 12 клиентах - это не катастрофа и не халтура с нашей стороны. Это нормальный срез реальной инфраструктуры, которая накапливалась годами. SSLv2 никто специально не включал - он просто оставался включённым по умолчанию там, где конфигурацию не трогали.

Характерная деталь: ни один из 23 серверов не был «главным» веб-сервером клиента. Все - второй, третий эшелон: почта, мониторинг, vpn, резервный балансировщик. Именно там настройки безопасности обновляют реже всего, и именно там DROWN находит себе место.

Полный технический аудит инфраструктуры включает проверку всех ssl-портов, не только 443. Сегодняшний день хорошо показал, почему это важно.

По двум устройствам с железом без обновления - ждём ответа от вендоров. Это открытые позиции, которые придётся закрыть отдельно.