Postmortem OpenSSL 3: три сервера, про которые все забыли, и почему SBOM теперь обязателен
CVE-2022-3786/3602 оказались менее страшными, чем Heartbleed. Но инцидент вскрыл пробел: три сервера клиента не были в реестре. Разбираем, что пошло не так и зачем теперь SBOM при онбординге.
Итоги инцидента OpenSSL 3.x: CVE-2022-3786 и CVE-2022-3602 оказались менее критическими, чем ожидалось, однако инвентаризация при подготовке к патчу выявила три сервера клиента, не входившие в реестр инфраструктуры
Прошло три недели после выхода OpenSSL 3.0.7. Самое время сделать честный postmortem - не про то, насколько страшным оказался CVE, а про то, что встряска показала изнутри.
Коротко: CVE-2022-3786 и CVE-2022-3602 не стали вторым Heartbleed. CVSS в районе 7.5-8, эксплойт требует специфических условий - враждебный TLS-сервер, клиент, который верифицирует сертификат с Punycode в Subject Alternative Name. Не тривиально. Индустрия выдохнула, некоторые даже поворчали, что подняли лишнюю панику.
Мы не согласны с «лишней». Объясним почему.
Три сервера, которых не было в реестре
В конце октября, когда команда OpenSSL объявила о предстоящем критическом патче без деталей, мы начали инвентаризацию OpenSSL 3.x по всей клиентской базе. Один клиент - организация с объектом КИИ - предоставил нам список серверов для сканирования. Мы прошлись Syft-ом по всем указанным хостам, составили карту покрытия, всё чисто.
А потом кто-то из их сетевых инженеров, работая параллельно с другой задачей, упомянул в общем чате «старый билд-сервер в стойке». Мы уточнили - оказалось, есть три сервера, которые в список никто не включил. Просто потому что про них никто не вспомнил. Один из трёх - как раз с Ubuntu 22.04, и там OpenSSL 3.0.x.
Вот это и есть настоящая находка инцидента.
Сервер не был заброшен в полном смысле. На нём крутилась CI-инфраструктура - внутренний сборочный агент. Просто он стоит с 2021 года, никто его не трогает, он работает, вот и выпал из мысленного реестра. Поставили и забыли.
Почему это системная проблема, а не разгильдяйство
Можно списать на невнимательность. Но это было бы нечестно. Вот что реально происходит:
Реестр инфраструктуры живёт в головах или в табличке, которая обновляется раз в квартал. Новый сервер поставили - в таблицу внесли не сразу или не внесли вообще, потому что «временно, до конца проекта», а потом он остался. Так работает большинство организаций, у которых нет специальной роли или процесса под это.
Onboarding новых объектов инфраструктуры не формализован. Когда поднимают новый хост - есть чеклист по настройке, по безопасности, по мониторингу. Но нет обязательного шага «добавь в CMDB и прогони Syft». Поэтому состав инфраструктуры расходится с реальностью постепенно и незаметно.
Аудит выявляет то, о чём попросили. Мы сканировали то, что нам дали. Это честно, но недостаточно - как мы сами поняли по факту.
Что мы меняем у себя в протоколе
По итогу этой истории мы зафиксировали несколько изменений в том, как ведём аудит защищённости.
Первое - сетевое сканирование как часть начального аудита. Прежде чем работать со списком серверов от клиента, делаем nmap по диапазонам IP - хотя бы быстрый sweep. Это не заменяет полноценное сканирование, но позволяет выявить грубые расхождения между тем, что декларировано, и тем, что реально отвечает в сети.
Второе - SBOM как обязательный шаг онбординга. Когда берём нового клиента на сопровождение или расширяем периметр, Syft-скан теперь обязательный пункт - до начала любой другой работы. Не после, не «когда руки дойдут», а до. Потому что без понимания состава мы не знаем, что именно защищаем.
Третье - периодический reconciliation. Раз в квартал сверяем список хостов в нашей документации с тем, что видим в сети у клиента. Расхождение - повод для разговора. Это не сложно, но требует дисциплины.
Про CVE честно
Да, не Heartbleed. Но вот что интересно: именно потому, что за две недели до деталей всё называлось «критическим», у нас было время нормально подготовиться. Мы провели инвентаризацию, согласовали с командами разработки процедуру пересборки образов, договорились кто за что отвечает. Когда 1 ноября вышел патч, закрыть всё за двое суток было реально - потому что работа была сделана заранее.
Если бы CVE оказался настоящим Heartbleed-уровня - мы были бы готовы. Это не мелочь.
Другое дело, что три сервера-призрака - это был бы серьёзный прокол при реальной катастрофе. И вот это надо было исправить независимо от итогового CVSS.
Итог
CVE-2022-3786/3602 закрыты, клиентские инфраструктуры обновлены. Но главный результат этой истории - не патч, а три найденных сервера и изменённый протокол онбординга. Это те вещи, которые без встряски не всплывают. Жаль, что для этого нужна паника уровня «возможно, Heartbleed» - но лучше так, чем никак.
SBOM при онбординге - это теперь не рекомендация, а обязательное условие. Мы писали про подход с Syft и Grype ещё в сентябре. Теперь у нас есть живой аргумент в пользу того, почему это важно.