Ну что, пришло время попробовать себя в жанре книжного обзора. Книга Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon журналистки Ким Зеттер, наиболее известной благодаря своим статьям в журнале Wired, вышла достаточно давно, в ноябре 2014 года, но с тех пор так и не была переведена на русский язык (на английском доступна, например, в Amazon в электронном виде). Впрочем, дело не в переводе: историю Stuxnet можно изучать и по открытым публикациям и исследованиям специалистов по безопасности, но в этом случае вы получите ассортимент технических фактов о вредоносном коде, из которых не так-то просто сложить паззл всей истории.
«Обратный отсчет» — это удачная попытка подняться выше строчек кода, свести воедино все, что известно о первой и по сей день наиболее масштабной специализированной атаке на индустриальные системы. При этом книга не подменяет факты драмой и максимально далека от беллетристики. Ценность ее еще и в том, что она показывает процесс исследования вредоносного кода чуть более подробно, чем обычно: примерно половина текста посвящена именно этому: от обнаружения кода и идентификации атаки, до анализа уязвимостей нулевого дня и, наконец, анализа модулей, модифицирующих работу промышленных контроллеров.
С момента обнаружения Stuxnet прошло шесть лет, семь — с момента начала атаки, больше десяти, предположительно, с начала разработки. Это не единственная кибератака, направленная на саботаж в индустриальных системах, но она по-прежнему не имеет себе равных по сложности. Отчасти это хорошие новости, но причиной является не повышенная защищенность промышленных систем, а скорее смена ориентиров у заказчиков. «Обратный отсчет» — это книга об атаке, названной в свое время «блокбастером» инфобезопасности, но это еще и книга о работе исследователей — тех, кто анализирует вредоносный код и проектирует защиту от него, вне зависимости от источника атаки и намерений.
Формат
Ким Зеттер практически сразу переходит от описания событий на иранской фабрике по обогащению урана, на основе данных международной организации МАГАТЭ, к обнаружению вредоносной программы экспертами из белорусской компании «ВирусБлокАда», и здесь Ким Зеттер пришлось определяться с форматом повествования. Невозможно рассказать историю Stuxnet, не прибегая к техническим терминам, но если совсем глубоко уйти в технологии, есть шанс потерять читателя, не имеющего отношения к индустрии ИБ (то есть почти всех читателей). Как минимум в начале книги жертву воображаемому божеству киберпанка все же приходится принести, и выглядит это примерно так:
Stuxnet использовал уязвимость нулевого дня в Microsoft Windows, благодаря чему мог распространяться на USB-носителях. А уязвимость нулевого дня это…
Чтобы скрыть зараженные файлы на флешке, на систему устанавливался руткит, а руткит — это…
Вредоносный код был подписан легитимными на тот момент цифровыми сертификатами, чтобы установка проходила максимально незаметно для пользователя. А цифровые сертификаты, это…
И так далее. Так как книга основана на многочисленных интервью с исследователями, Ким Зеттер в итоге переносит значительную часть фактов в сноски, они подчас занимают не меньше места, чем относящаяся к ним глава. В дальнейшем в книге практически вся зубодробительная фактология находится там: вам предоставляется выбор, читать целиком или пропускать уточнения. В последнем случае восприятие сюжета не страдает, а благодаря сноскам с огромным количеством ссылок на источники книга оказывается одинаково привлекательной и для технарей, и для, кхм, гуманитариев.
Зиро-дей
Для заражения Stuxnet использовал уязвимость нулевого дня в операционных системах Windows — на момент обнаружения (июль 2010 года, бюллетень на Technet) ей были подвержены все актуальные версии от XP до 7, 32-х и 64-битные (Stuxnet атаковал только 32-битные ОС). Уязвимость позволяла запустить вредоносный код с помощью подготовленного файла .LNK или .PIF — если таковой был помещен на флешку, то уязвимость активировалась автоматически. Именно такой тип уязвимости позволил атаковать индустриальную систему критической важности, которая как правило (но не в обязательном порядке) изолирована от сети. Впоследствии наши эксперты опубликовали анализ первых жертв Stuxnet, через которые вероятно были проведены успешные попытки добраться до главной цели. Анализ стал возможен благодаря сохранению внутри вредоносного кода информации о ранее атакованных системах.
Уязвимость была обнаружена только благодаря обнаружению и исследованию Stuxnet. Использование уязвимостей нулевого дня стало характерной чертой сложных атак. Но за прошедшее время ситуация изменилась — далеко не каждая успешная таргетированная атака использует zero-days. Эффективная разведка и изучение потенциальной жертвы делают использование подобных, очень дорогих и быстро раскрываемых инструментов необязательным. Собственно, в расследовании Stuxnet факт использования уязвимости нулевого дня был установлен в первую очередь, гораздо больше времени и сил понадобилось на анализ «полезной нагрузки».
Помимо LNK-уязвимости, Stuxnet использовал уязвимость MS08-067 и еще один зиродей — дыру в системе Print Spool Service (MS10-061). Примечательно, что первая уязвимость также использовалась червем Conficker, вызвавшим серьезную эпидемию в 2008 году. Непонятное предназначение этой вредоносной программы в свете Stuxnet даже привели к предположениям, что это был некий тест-драйв технологий в реальных условиях, но на самом деле связь между этими двумя атаками выглядит сомнительной.
Аттрибуция
Кто стоял на атакой Stuxnet — достоверно не известно. Значительная часть книги Ким Зеттер посвящена аттрибуции в двух ее смыслах: когда связь с какими-то людьми, событиями или другими атаками выводится из вредоносного кода, и когда авторство атаки подтверждают «лица, причастные к событию». Со вторым на самом деле все не очень хорошо: несмотря на массу заявлений и доводов разных сторон, причастность к разработке Stuxnet какой-либо страны достоверно доказать невозможно, и, скорее всего, еще много лет ситуация не изменится. Здесь повествование «Обратного отсчета» несколько теряет ритм, несмотря на столь же кропотливую работу по сбору данных из различных источников, проведенную автором.
А вот аттрибуция в процессе анализа кода — штука интересная. В качестве одного из первых примеров приводится строчка из кода Stuxnet:
b:myrtussrcobjfre_w2k_x86i386guava.pdbЕсли на время отвлечься от реверс-инжиниринга и изучить (для разнообразия) Ветхий Завет, то можно увидеть в этой строчке отсылку к еврейскому празднику Пурим, а значит это может быть некий прозрачный намек на авторство кода. Чем только не приходится заниматься исследователям. На самом деле присутствие в коде строки с изначальным путем к одному из файлов на машине разработчика могло быть оставлено и намеренно, чтобы спутать следы. Другая версия, что «myrtus» — это вовсе не «мирт» и намек, а всего лишь сокращение от «my remote terminal units».
Последователи
А вот доказательств связи между Stuxnet и обнаруженными позднее атаками Duqu и Flame нашлось предостаточно. В случае с Duqu явно использовалась та же платформа, что и для Stuxnet. Flame не связан с Stuxnet/Duqu кодовой базой, но использовал те же уязвимости, включая дыру в Print Spool Service. Обе атаки были максимально подробно проанализированы специалистами «Лаборатории», а в книге в соответствующих главах используется информация из интервью с нашими экспертами. Любопытно, что Duqu и Flame не имели деструктивных функций и использовались преимущественно для кибершпионажа. Учитывая направленность почти всех сложных атак с момента обнаружения Stuxnet, информация ценится выше саботажа. Это впрочем совершенно не означает, что промышленные объекты теперь в безопасности.
Мнимая сложность критической инфраструктуры
Понять, что именно является основной целью Stuxnet было непросто — у исследователей просто не было опыта работы со SCADA-системами. В книге подробно описывается, как именно анализировалась эта часть кода: Stuxnet в случае заражения системы с определенным ПО мог управлять контроллерами строго указанной модели, и таким образом изменял скорость вращения центрифуг (предположительно) на объекте в Иране так, что они выходили из строя от чрезмерной нагрузки. Подробно логика работы Stuxnet в этом направлении была исследована специалистами компании Symantec (отчет в PDF). Интересно, что для детектирования атаки и защиты компьютеров даже в условиях отсутствия (в течение нескольких недель) патча для уязвимостей от Microsoft, знать, что именно делает Stuxnet, было не обязательно. Такая информация важна только в контексте подготовки к отражению будущих атак подобного типа.
Ким Зеттер посвящает отдельную главу безопасности промышленных IT-систем в целом. Приводятся примеры, хотя и несравнимые по масштабу со Stuxnet, саботажа подобных объектов с помощью вредоносного кода или путем перехвата систем управления. О том, что индустриальная инфраструктура уже достаточно компьютеризирована, чтобы быть уязвимой, но все еще недостаточно защищена, было известно давно. Увы, нельзя сказать, что Stuxnet радикально и бесповоротно изменил ситуацию к лучшему: очень часто операторы критически важных объектов полагаются на изоляцию систем управления, и на сложность проприетарных протоколов. Есть и объективные сложности: длительный цикл работы оборудования, специфические требования к железу и софту, принадлежность промышленных IT-систем и традиционной компьютерной инфраструктуры к разным командам в рамках одной компании, и неизбежные проблемы на стыках. Впрочем, Stuxnet явно привлек внимание исследователей в области кибербезопасности к проблеме: начиная с 2012 года, по данным нашего отчета, число обнаруженных и закрытых уязвимостей в специализированном ПО значительно выросло. С другой стороны, в том же отчете показано, как поиск через Shodan в этом году позволяет обнаружить более 180 тысяч хостов с элементами SCADA-систем, напрямую доступных через сеть.
Выводы
На мой взгляд, история Stuxnet, максимально разносторонне описанная в книге «Countdown to Zero Day», позволяет сделать несколько важных выводов, актуальных и для атак (и для защиты от них) дня сегодняшнего:
— Авторы даже самых совершенных кибератак делают ошибки. Скорее всего в результате ошибочного действия на определенном этапе произошло массовое заражение тысяч систем в разных странах, которое и позволило заметить и проанализировать вредоносный код (впрочем, есть версия, что это было сделано намеренно). Более того, впервые сэмпл Stuxnet был обнаружен благодаря жалобе на компьютер, который постоянно перезагружался — в процессе заражения что-то пошло не так. Здесь кроется и опасность разработки опасного кибероружия: методы атаки рано или поздно становятся широко известными, а инструменты могут попасть не в те руки.
— Нельзя полагаться на сложность систем и протоколов. Концепция security through obscurity (безопасности через неизвестность) была окончательно признана неэффективной как раз благодаря Stuxnet. Да, для разработки этой атаки потребовалось много сил и средств (по некоторым оценкам — от 5 до 30 разработчиков и минимум 6 месяцев работы), и да, поначалу исследователи столкнулись со сложностями в анализе специализированного кода для АСУТП. Параллельный опыт анализа атак на финансовые системы начиная с прошлого года показывает, что даже самые сложные системы могут быть взломаны, а контроль над ними — использован для нанесения ущерба.
— Индустрия информационной безопасности максимально эффективно борется со сложными атаками только при совместной работе. В исследовании Stuxnet, а также Duqu и Flame участвовали многие вендоры защитных решений и независимые исследователи. Анализ чужого кода — дело сложное и длительное даже для высококлассных специалистов. Stuxnet стал одним из первых примеров, когда кооперация и публичный обмен результатами позволил ускорить исследование и разработку защиты. К счастью, это не последний пример, но над взаимодействием «безопасников всего мира» еще требуется поработать.
— История сложных и максимально деструктивных кибератак с обнаружением Stuxnet не закончилась, а только началась. Наша карта продвинутых атак является наглядным тому доказательством. Хотя кража информации является приоритетной целью атакующих, забывать о защите индустриальных систем и критической инфраструктуры нельзя — хотя бы потому, что даже единичные успешные операции на таких объектах могут привести к огромному ущербу. Несмотря на сложность промышленных систем, нужны ресурсы для их исследования с точки зрения безопасности и адекватные методы защиты.
— И, наконец, быть исследователем киберугроз — это круто. Книга Ким Зеттер — редкий случай, когда помимо строчек кода и выводов в доступной форме показана работа экспертов по безопасности на примере вполне реальной атаки. Такую деятельность очень трудно описать популярно, но, учитывая количество угроз и их сложность, максимальное проникновение цифровых систем в нашу повседневную жизнь, нужно это делать больше и чаще.
Disclaimer: Данная колонка основана на реальных событиях, но все еще отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Автор: «Лаборатория Касперского»
