Как только обнаруживается серьезная уязвимость приложения, преимущество получают те, кто ее обнаружил; как и в любом конфликте, существенное преимущество получает тот, кто первым начал. Если это законный исследователь, он может связаться с разработчиками приложения-нарушителя, и информация не обязательно должна быть обнародована до тех пор, пока не будет произведен и отправлен патч.
Однако это редко бывает так просто. Исправление требует времени; отвлекает критически важные ресурсы от текущих проектов разработки; и предшествует огромному всплеску негативного пиара разработчика. Все эти факторы могут повлиять на то, что менее щепетильные разработчики просто проигнорируют новую уязвимость. Хотя многие исследователи изначально обращаются к ней в условиях полной конфиденциальности, полное раскрытие может быть необходимым ядерным вариантом. При полном раскрытии недавно обнаруженная уязвимость становится достоянием общественности. Путь атаки – и даже сам код эксплойта – становятся достоянием общественности. Такой подход оказывает сильное давление на разработчиков, которые не в состоянии серьезно относиться к безопасности своих клиентов.
Ответственное раскрытие пытается найти золотую середину между этими двумя полярно противоположными подходами. При ответственном раскрытии первоначальный отчет составляется в частном порядке, а полная информация публикуется после того, как исправление становится доступным. Как государственные, так и частные, разработчики по-прежнему могут информировать клиентов об основных уязвимостях через доски объявлений и социальные сети. Сложные уязвимости часто требуют отлаженной цепочки коммуникаций на протяжении всего процесса исправления. Грань между раскрытием слабости и мотивацией конечных пользователей к обновлению как можно скорее чрезвычайно тонка.
В этих лихорадочных процессах обмена сообщениями и исправления участвуют субъекты угрозы, желающие использовать эту информацию для собственной финансовой и политической выгоды.
The Patching Gap
Моменты между публикацией уязвимости и внедрением исправленных версий на клиентских устройствах являются периодами бешеной преступной активности. В недавнем отчете о реагировании на инциденты было обнаружено, что злоумышленники часто сканируют уязвимости в течение 15 минут после объявления об ошибке. Некоторые злоумышленники настолько быстры в розыгрыше, что их сканирование может быть практически мгновенным после публикации уязвимости.
Скорость, с которой преступники узнают об этих новых недостатках, оказывает невероятное давление на уязвимые системы – в конце концов, не исправленное приложение — легкая добыча. Сканирование на наличие этих ошибок требует очень низких навыков, и эти криминальные сборщики информации часто продают свои находки более способным киберпреступникам.
Усилия ищущих слабые места разведчиков и последующие атаки уже определили тенденции атак в 2022 году. Вместо того, чтобы полагаться исключительно на нишевые атаки нулевого дня, злоумышленники отдают предпочтение старым, широко применимым путям атаки. Вот почему в отчете было обнаружено, что на цепочку эксплойтов ProxyShell, обнаруженную в 2021 году, по–прежнему приходится 55% взломов в первом квартале 2022 года.
ProxyShell представляет собой неприятную комбинацию трех различных уязвимостей в сервере Microsoft Exchange. Комбинируя каждый шаг, злоумышленники могут полностью обойти правила, которые предоставляют или запрещают доступ к конфиденциальной информации. После этого они могут повысить привилегии и, по сути, аутентифицировать себя, открывая дверь для удаленного выполнения кода. Тот факт, что этот крупный бэкдор был обнаружен в системе Microsoft, означал, что attack surface был одной из крупнейших угроз, с которыми столкнулись в 2021 году.
Proxyshell подробно обсуждался на конференции Black Hat USA в 2021 году; это привело к широкому использованию его в криминальных кругах. Хотя исправления были в конечном итоге выпущены после двух месяцев напряженной работы, недостаток исправлений в Proxyshell по-прежнему представляет серьезную угрозу. Некоторые системы, такие как серверы с истекшим сроком службы (EoL), просто невозможно исправить. В том же отчете было обнаружено, что почти 32% подвергшихся атаке организаций используют веб-серверы Apache EoL-версий, уязвимых для не менее масштабной атаки Log4j.