В мае мы цитировали отчет об уязвимостях нулевого дня, подготовленный командой Google Project Zero. Тогда была обнародована статистика за 2021 год, и в целом специалисты по безопасности Google планируют и далее выпускать годовые отчеты. Но на прошлой неделе была выпущена внеочередная публикация за 2022 год, с данными по состоянию на 15 июня. Повод для нее интересный: специалисты Project Zero хотели показать, что 9 из 18 уязвимостей нулевого дня ранее уже были пропатчены в каком-то виде.
В целом первое полугодие 2022 года принесло меньше уязвимостей типа zero-day: за прошлый год всего было найдено 58 критических багов, а за первое полугодие 2021 года — 34. Список уязвимостей Google Project Zero ведет к регулярно обновляемой таблице. Чтобы попасть в нее, согласно определению zero-day, уязвимость должна активно эксплуатироваться в реальных атаках до выпуска соответствующего патча. В новой публикации компания Google приводит и рекомендации по «правильному» исправлению ошибок в ПО.
В список «повторно эксплуатируемых» уязвимостей попали следующие:
В списке недолеченных багов от Project Zero также присутствуют уязвимости в Atassian Confluence и в zero-day в смартфоне Google Pixel. В последнем случае эксплуатировалась закрытая ранее уязвимость в ядре Linux, которую вовремя не исправили в прошивке смартфона.
Рекомендации команды Project Zero соответствуют характеру «повторов». Хотя при обнаружении активной атаки проще всего закрыть известный вектор эксплуатации, желательно все же найти первопричину. Иначе есть риск, что до ошибки в коде доберутся иными путями. Пример уязвимости Follina и бага в движке MSHTML показывает, что нужно исследовать обнаруженный паттерн атаки, чтобы исключить эксплуатацию других уязвимостей через ту же «точку входа». Если уязвимость обнаружил white-hat-исследователь, рекомендуется обсудить с ним метод решения проблемы, убедиться, что он работает для всех возможных сценариев. Наконец, предлагается идея систематизации знаний об эксплойтах, так чтобы в будущем можно было превентивно исправлять ошибки в коде — если заранее знать о том, что с наибольшей вероятностью будет атаковано. Здесь Google Project Zero вновь говорит об открытом обмене информацией между исследователями.
В публикации Google Project Zero хорошо сформулирован смысл работы по поиску zero-day. Обнаружение рабочего эксплойта, о котором разработчик решения может быть даже не в курсе, это самый плохой сценарий для атакующего. Своевременное закрытие эксплуатируемых уязвимостей повышает стоимость атаки и улучшает защищенность потребителей и бизнеса. Новые данные показывают, что важно не только обнаружение атак, но и исправление ошибок с первого раза.
Платформа для ответственного раскрытия уязвимостей HackerOne сообщает о работе инсайдера, который «сливал» непубличный обмен информацией об уязвимостях на сторону. Точнее, он пытался продать информацию о багах разработчикам ПО еще раз, вне платформы. См. также подробный пересказ истории на Хабре.
Разработчики платформы Jenkins опубликовали информацию об уязвимостях в 25 плагинах.
Подробный отчет рассказывает об уязвимостях в драйверах для графики Intel в Mac OS, которые могли использоваться для сценария «побега из песочницы» браузера Safari.
Специалисты «Лаборатории Касперского» опубликовали анализ вредоносного модуля для веб-сервера Microsoft IIS, используемого в таргетированных атаках на бизнес. Еще одно исследование рассказывает о деятельности ранее неизвестной APT-группировки ToddyCat.
В целом первое полугодие 2022 года принесло меньше уязвимостей типа zero-day: за прошлый год всего было найдено 58 критических багов, а за первое полугодие 2021 года — 34. Список уязвимостей Google Project Zero ведет к регулярно обновляемой таблице. Чтобы попасть в нее, согласно определению zero-day, уязвимость должна активно эксплуатироваться в реальных атаках до выпуска соответствующего патча. В новой публикации компания Google приводит и рекомендации по «правильному» исправлению ошибок в ПО.
В список «повторно эксплуатируемых» уязвимостей попали следующие:
- Уязвимость в Windows CVE-2022-21882, приводящая к эскалации привилегий и являющаяся вариантом обнаруженной в прошлом году CVE-2021-1732.
- Уязвимость в Apple iOS CVE-2022-22587, являющаяся вариантом прошлогодней CVE-2021-30983. По мнению Google Project Zero, здесь эксплуатируется один и тот же баг, патч для которого в 2021 году был неполным.
- Несколько спорная связь была обозначена между уязвимостями CVE-2022-30190 (aka Follina) и CVE-2021-40444. Эти уязвимости относятся к разным компонентам Windows, в первом случае это движок MSHTML, во втором — сервис Microsoft Support Diagnostic Tool. Общим для них является способ эксплуатации через «подготовленные» документы Microsoft Office. В отчетах экспертов «Лаборатории Касперского» (для "старой" уязвимости и для новой) подробно описывается типичный метод эксплуатации, а один из типовых вердиктов защитных решений «Лаборатории Касперского» — общий для обоих багов.
- Уязвимости в движке Javascript в браузере Chromium — CVE-2022-1364 и CVE-2021-21195. По мнению Мэдди Стоун, представителя Google Project Zero, здесь имели место патчи, закрывающие конкретный путь эксплуатации, но не ключевую уязвимость. В результате атакующие находили иной способ добраться до недолеченной ошибки в коде.
- Другой вариант возвращения уязвимости показан на примере проблемы в браузерном движке WebKit. Эксплуатируемый zero-day CVE-2022-22620 был закрыт еще в 2013 году, но патч 2016 года вернул его обратно. Об этом у Project Zero есть отдельная публикация. Аналогичная ситуация произошла с уязвимостью CVE-2022-26925 в Windows (также известна как PetitPotam, позволяет перехватить управление контроллером домена), которую уже закрывали в 2021 году под идентификатором CVE-2021-36942.
В списке недолеченных багов от Project Zero также присутствуют уязвимости в Atassian Confluence и в zero-day в смартфоне Google Pixel. В последнем случае эксплуатировалась закрытая ранее уязвимость в ядре Linux, которую вовремя не исправили в прошивке смартфона.
Рекомендации команды Project Zero соответствуют характеру «повторов». Хотя при обнаружении активной атаки проще всего закрыть известный вектор эксплуатации, желательно все же найти первопричину. Иначе есть риск, что до ошибки в коде доберутся иными путями. Пример уязвимости Follina и бага в движке MSHTML показывает, что нужно исследовать обнаруженный паттерн атаки, чтобы исключить эксплуатацию других уязвимостей через ту же «точку входа». Если уязвимость обнаружил white-hat-исследователь, рекомендуется обсудить с ним метод решения проблемы, убедиться, что он работает для всех возможных сценариев. Наконец, предлагается идея систематизации знаний об эксплойтах, так чтобы в будущем можно было превентивно исправлять ошибки в коде — если заранее знать о том, что с наибольшей вероятностью будет атаковано. Здесь Google Project Zero вновь говорит об открытом обмене информацией между исследователями.
В публикации Google Project Zero хорошо сформулирован смысл работы по поиску zero-day. Обнаружение рабочего эксплойта, о котором разработчик решения может быть даже не в курсе, это самый плохой сценарий для атакующего. Своевременное закрытие эксплуатируемых уязвимостей повышает стоимость атаки и улучшает защищенность потребителей и бизнеса. Новые данные показывают, что важно не только обнаружение атак, но и исправление ошибок с первого раза.
Что еще произошло:
Платформа для ответственного раскрытия уязвимостей HackerOne сообщает о работе инсайдера, который «сливал» непубличный обмен информацией об уязвимостях на сторону. Точнее, он пытался продать информацию о багах разработчикам ПО еще раз, вне платформы. См. также подробный пересказ истории на Хабре.
Разработчики платформы Jenkins опубликовали информацию об уязвимостях в 25 плагинах.
Подробный отчет рассказывает об уязвимостях в драйверах для графики Intel в Mac OS, которые могли использоваться для сценария «побега из песочницы» браузера Safari.
Специалисты «Лаборатории Касперского» опубликовали анализ вредоносного модуля для веб-сервера Microsoft IIS, используемого в таргетированных атаках на бизнес. Еще одно исследование рассказывает о деятельности ранее неизвестной APT-группировки ToddyCat.