OpenSSL — это широко используемая библиотека программного обеспечения с открытым исходным кодом для реализации безопасной связи через компьютерные сети. Насколько широко используется? Что ж, есть вероятность, что если вы когда-либо заходили на веб-страницу HTTPS, вы делали это с помощью шифрования OpenSSL. Библиотека предоставляет криптографические функции и протоколы для шифрования, дешифрования, аутентификации и проверки цифровой подписи данных. OpenSSL можно найти практически везде, где необходимо защитить веб-серверы, серверы электронной почты, виртуальные частные сети (VPN) и другие типы сетевых коммуникаций.
Глядя на приведенный выше абзац, должно быть ясно, насколько важен OpenSSL для правильной работы Интернета. Это важнейший компонент инфраструктуры безопасности для многих компьютерных систем и приложений. Это помогает защитить конфиденциальные данные от несанкционированного доступа и помогает обеспечить целостность и подлинность сетевых коммуникаций. Вот почему сопровождающие библиотеки очень серьезно относятся к уязвимостям и стараются их исправить как можно скорее. Представить себе, что злоумышленники получат доступ к защищенным линиям связи инфраструктуры всемирной паутины, практически немыслимо.
В этой статье мы рассмотрим уязвимости, которые привели к выпуску патча OpenSSL 3.0.7 в октябре 2022 года, и посмотрим, что мы можем узнать из того, как сопровождающие OpenSSL позаботились об этой проблеме.
Уязвимости
25 октября 2022 г. проект OpenSSL опубликовал консультативный предупреждаю, что скоро выйдет новый патч, исправляющий некоторые критической уязвимости. Тег «критический» подразумевает, что уязвимости могут быть использованы и что вероятна кража закрытых ключей и/или RCE на затронутых серверах.
Неделю спустя, 1 ноября 2022 года, проект OpenSSL выпустил новый патч 3.0.7 и конкретные уязвимости они стремились исправить. За это время рейтинг уязвимостей был понижен с критического до «высокого уровня серьезности».
Итак, что же это за уязвимости?
CVE-2022-3602 – Переполнение 509-байтового буфера адреса электронной почты X.4. При проверке сертификата X.509, особенно при проверке ограничения имени, может произойти переполнение буфера на четыре байта. Четыре байта в стеке, контролируемые злоумышленником, могут быть переполнены злоумышленником, использующим вредоносный адрес электронной почты. Переполнение буфера может вызвать сбой (приводящий к отказу в обслуживании) или потенциально удаленное выполнение кода. Первоначально проблема была отнесена к категории критических, но дополнительное тестирование показало, что многие платформы используют защиту от переполнения стека, чтобы снизить риск удаленного выполнения кода.
CVE-2022-3786 – Переполнение буфера переменной длины адреса электронной почты X.509. – При проверке сертификата X.509, особенно при проверке ограничений имени, может произойти переполнение буфера. Злоумышленник может создать вредоносный адрес электронной почты в сертификате, чтобы заполнить стек любым количеством байтов, содержащих символ «.», который представляет собой десятичное число 46. В результате этого переполнения буфера может произойти сбой (вызвав отказ в обслуживании).
Просто хочу еще раз подчеркнуть, насколько серьезны эти уязвимости.В частности, CISA, Агентство кибербезопасности и безопасности инфраструктуры США, выпустило консультативный в тот же день, что и OpenSSL, призываемпобуждение пользователей и администраторов просмотреть Документация OpenSSL и обновление, если применимо, до нового патча 3.0.7.
Как обсуждалось ранее, RCE (удаленное выполнение кода) в операционных системах или почтовых серверах, работающих под управлением OpenSSL, было бы очень плохо, поэтому имеет смысл раскрывать только уязвимости после того, как будет найден и предложен подходящий патч.
Что будет дальше
Как только было опубликовано первоначальное предупреждение, люди начали карабкаться. «Не паникуйте» — была распространенная фраза в то время показывая, насколько серьезно люди восприняли новость о том, что OpenSSL имеет критическое значение. уязвимости.
Как только рекомендация была опубликована, все соответствующие заинтересованные стороны пытались выяснить, какая версия OpenSSL использовалась на их сервере, в ОС, приложении, пакете и т. д. Помимо внутреннего использования OpenSSL, людям также нужно было выяснить, используется ли какая-либо из их третьих сторон. Сторонние поставщики или поставщики услуг использовали уязвимую версию OpenSSL. В то время, если вы не были уверены, какую версию вы используете, или вы не были уверены, какую версию используют ваши поставщики и поставщики услуг, считалось безопаснее перевести приложение в автономный режим, чем рисковать потенциальным RCE.
Поскольку в рекомендациях заранее были указаны сроки выхода патча, это дало людям время разобраться в своей собственной инфраструктуре, а также в инфраструктуре своих поставщиков и поставщиков услуг. Идея заключалась в том, чтобы спланировать все необходимое с точки зрения задействованной инфраструктуры так, чтобы как только патч будет выпущен, при необходимости можно было бы провести обновление.
Как бы вы с этим справились?
Теперь предположим, что вы инженер в компании, которая, насколько вам известно, использует OpenSSL на своих серверах. Как только рекомендация исчезнет, вам необходимо выяснить, какая версия библиотеки где используется (включая любой устаревший код, если он все еще выполняется), а затем выяснить то же самое для любого из ваших поставщиков или поставщиков услуг.
Вот где СБОМ действительно может пригодиться. SBOM означает «Спецификация программного обеспечения» и представляет собой список всех компонентов и зависимостей программного обеспечения, составляющих конкретный программный продукт. SBOM обычно включает в себя такую информацию, как имена и версии всех компонентов программного обеспечения (см., к чему я клоню), их источники и лицензии, а также любые известные уязвимости или проблемы безопасности, связанные с каждым компонентом.
Если бы вы, как ответственный инженер, позаботились о наличии обновленного SBOM для каждого из ваших продуктов, то выяснить, где вы использовали OpenSSL и какая версия использовалась, было бы простым поиском по файлу SBOM. . Если вы также обязательно запросили обновленные SBOM у любого поставщика или поставщика услуг, с которым работала ваша компания, вы могли бы выполнить тот же поиск и там.
Поскольку вам сказали, что уязвимости затрагивают только версии между 3.0.0 и 3.0.6, все, что вам нужно сделать, это проверить, какие версии вы используете, чтобы узнать, какие приложения необходимо удалить или обновить с помощью нового патча — 3.0.7. XNUMX.
Чтобы показать, насколько обширен список известных операционных систем и корпоративных приложений, использующих OpenSSL, посмотрите это список опубликовано как общественная услуга, чтобы люди знали, насколько им следует беспокоиться.
Чем может помочь Центр доказательной безопасности?
В рамках меняющегося ландшафта кибербезопасности, включая такие далеко идущие уязвимости, в настоящее время мы являемся свидетелями эволюция безопасности приложений к безопасности цепочки поставок программного обеспечения. Чтобы попытаться решить эти проблемы, было разработано новое поколение инструментов и технологий. Предлагая основанную на фактических данных платформу непрерывного обеспечения безопасности кода, которая может гарантировать надежность жизненного цикла разработки программного обеспечения и компонентов программного обеспечения, автоматизированные инструменты и решения помогают организациям достичь нового уровня безопасности. Постоянное выявление зависимостей и уязвимостей упрощает исправление или применение исправлений по мере их появления.
Писец — это центр безопасности цепочки поставок программного обеспечения. Он собирает доказательства и представляет их для каждой сборки, проходящей через ваш конвейер CI/CD. Целью решения Scribe было облегчить соблюдение правил ЕС и США, а также передовых методов повышения прозрачности программного обеспечения и укрепления доверия между разработчиками программного обеспечения и пользователями. Платформа позволяет создавать и обмениваться комплексными SBOM, а также другими аналитическими данными по безопасности. Кроме того, платформа может подтвердить, что просматриваемая вами сборка соответствует как структуре SSDF NIST, так и требованиям SLSA уровня 3. Вам больше не придется возиться, пытаясь выяснить, где и какую версию какой библиотеки вы используете, поскольку у вас есть хранилище доказательств с SBOM для каждой из ваших сборок. Теперь разобраться в этом так же просто, как найти конкретное предложение в текстовом документе.
Заключительное слово: будьте готовы к следующему большому раскрытию уязвимости
История проекта OpenSSL с патчем 3.0.7 предлагает нам две, одинаково важные точки зрения на то, как бороться с потенциально критическими уязвимостями.
С пострадавшей стороны — компании или проекта, которые потенциально были скомпрометированы этими уязвимостями, мы информировали прозрачность. Они не раскрывают немедленно информацию, которая может причинить вред, но раскрывают все, что могут, как только узнают о проблеме. Мало того, что они также предлагают график устранения проблемы в дополнение к как можно большему количеству информации о проблеме. Как только патч или исправление появилось, они не стеснялись раскрывать, что именно было не так и как это потенциально можно было использовать. Такая прозрачность способствует доверию. Пользователи и клиенты хотят знать и чувствовать, что компания заботится о них больше или, по крайней мере, так же, как о прибыли или совете директоров.
В 2014 году проект OpenSSL стал жертвой критической ошибки, получившей название «HeartBleed' – критическая ошибка в реализации TLS/DTLS OpenSSL, которая позволяла злоумышленнику получить секреты, такие как материалы ключей шифрования, пароли и другую конфиденциальную информацию, с затронутых серверов. Heartbleed показал, на что способна критическая уязвимость в OpenSSL, поскольку она затрагивает широкий спектр программ и дистрибутивов Linux. Попытки выявить и исправить каждую уязвимую систему доставили командам безопасности месяцы головной боли. Внедрение такого инструмента, как SBOM, который мог бы ускорить и упростить обновление и исправление вашего программного обеспечения, было бы благом для команды кибербезопасности любой компании.
С точки зрения исправления – точное знание того, с чем вам придется работать – какую версию пакетов вы используете и где важно для возможности справиться с любой такой потенциальной чрезвычайной ситуацией. Возьмем в качестве примера Log4J: некоторые компании все еще пытаются выяснить, затронуты ли они этой уязвимостью, спустя более года после ее обнаружения.
Тот факт, что вам нужно беспокоиться не только о вашем программном обеспечении и серверах, но и о программном обеспечении любых сторонних поставщиков, которых вы используете, или любых поставщиков услуг, с которыми вы работаете, даже используя соединения API, означает, что мы, все из нас действительно необходимо построить сеть доверия между нами. Такое доверие должно в максимальной степени зависеть от веских доказательств. Создавайте и отслеживайте свои собственные SBOM и SBOM любой компании, с которой вы сотрудничаете, делитесь этими SBOM и добросовестно объявляйте и устраняйте любые уязвимости, о которых вам станет известно.
Нам всем потребуется работать вместе, чтобы попасть в мир, в котором делиться такими доказательствами будет таким же обычным явлением, как и делиться последним пиаром компании в социальных сетях. Без этого доверия мы просто готовим почву для следующей большой критической уязвимости, которая разрушит взаимосвязанную инфраструктуру, которую мы все так усердно поддерживаем.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
