От программиста до pwner: мой путь нулевого дня к Pwn2Own
Исследователь по безопасности Вера Менс и ее коллеги из Claroty's Team82 взяли на себя некоторые из самых сложных задач в области промышленной кибербезопасности на Pwn2Own Miami в начале этого года, выискивая уязвимости нулевого дня в программном обеспечении, обнаруженном в критической инфраструктуре по всему миру. . Она рассказывает о своем собственном опыте удаленного участия в хакерских соревнованиях с высокими ставками.
Мой путь к исследованию уязвимостей начался четыре года назад; это был конкретный момент, и я отчетливо его помню. Это был мой второй год после окончания университета по специальности информатика. Я был младшим инженером-программистом в компании, специализирующейся на сетевом оборудовании. У меня было мало опыта, но моя жажда изучения и понимания этого нового мира, казалось, никогда не была удовлетворена.
Это все еще не так.
Это было до пандемии COVID, когда открытые и бесплатные конференции по информационной безопасности были обычным явлением. Один из них был достаточно большим, чтобы его рекламировали в более широких кругах, не только среди исследователей, но и среди разработчиков. На этом мероприятии было два трека: один для хакерских сессий, а другой — мастер-класс по оборудованию.
Я влюбился в обоих. Это был момент.
Поначалу казалось, что такой переход к исследованию уязвимостей невозможен. Мои знакомые исследователи родились с раковиной в руках. К тому времени мне исполнилось 30, у меня не было ни опыта, ни знаний в области хакерства. К счастью для меня, я так этого хотел, что мне было все равно. Я пошел ва-банк.
Я оставил свою должность программиста и направил всю свою энергию и свободное время на достижение этой цели. Три с половиной года спустя я оказался в составе команды Claroty’s Team82 по исследованию уязвимостей и принял участие в одном из самых престижных хакерских соревнований Pwn2Own.
Внутри Pwn2Own
Для тех, кто не знаком с серией соревнований, проводимых Инициативой нулевого дня, лучшим сравнением может быть соревнование по захвату флага. Но вместо того, чтобы искать известные уязвимости в ПО разной степени сложности, заложенные авторами CTF, участникам Pwn2Own нужно найти ранее неизвестные уязвимости в реальном коммерческом ПО — иными словами: нулевые дни.
Цели конкурса публикуются примерно за три месяца до мероприятия. После объявления те, кто хочет участвовать — команды и отдельные лица — начинают исследование этих целей. Цель — найти не только эксплуатируемые уязвимости, но и неочевидные. Например, если другая команда или отдельный человек находит такую же уязвимость, это называется столкновением, и есть большая вероятность, что вы получите меньше очков за свое обнаружение.
Я и мои коллеги соревновались в Pwn2Own Miami, версии Pwn2Own, ориентированной на промышленные системы управления, которая является фаворитом Team82. Для группы по исследованию уязвимостей, ориентированной на АСУ ТП, было вполне логично проверить свои навыки на этом соревновании.
Это была отличная возможность для меня не только профессионально, но и как командный опыт. Хотя обычно каждый работал над своими задачами индивидуально, мы продвигались вперед как команда, помогая друг другу путем мозгового штурма и да, вместе празднуя победы. Это было чувство включенности и достижения общей цели, и я давно жаждал такого опыта.
Технический акцент
Несмотря на то, что платформы были знакомы команде, соревнование было непростым. Два месяца мы работали круглосуточно, подготовкой к соревнованиям руководил руководитель команды Шарон Бризинов.
На соревнованиях было четыре номинации:
● Сервер управления:эти серверы контролируют и управляют различными программируемыми логическими контроллерами (ПЛК) и другими полевыми системами. Это критически важные системы для обеспечения безопасности, поскольку злоумышленник, имеющий доступ к управляющему серверу, может изменить производственные процессы, ограничиваясь только своими инженерными навыками и навыками автоматизации. В частности, мы должны были нацеливаться на управляющие серверы от Iconics и Inductive Automation.
● Сервер OPC UA: Унифицированная архитектура OPC (UA) — это структура, объединяющая все спецификации OPC Classic в расширяемую сервисно-ориентированную структуру. Думайте об OPC UA как о протоколе трансляции между устройствами ICS в сети OT (операционная технология); он используется почти всеми продуктами ICS для отправки данных между системами разных поставщиков. OPC UA был разработан, чтобы быть более безопасным, чем ранее использовавшийся DCOM, и набирает популярность. В этой категории мы искали нулевые дни в демонстрационном сервере Unified Automation C++, стандартном SDK OPC Foundation OPC UA .NET, SDK Prosys OPC UA SDK для Java и сервере безопасной интеграции Softing.
● Шлюз данных. Эти устройства соединяют устройства, обменивающиеся данными по разным протоколам. Нам было дано указание ориентироваться на продукт Triangle Microworks SCADA Data Gateway и сервер Kepware KEPServerEx. Triangle Microworks создает наиболее широко используемый стек протоколов DNP3, а KEPServerEX — это платформа для подключения, которая предоставляет данные автоматизации нескольким приложениям.
● Категория человеко-машинный интерфейс (HMI):HMI — это интерфейс, который оператор ICS использует для мониторинга и управления различными устройствами уровня 1 и 0 в Модели Purdue для ICS. Злоумышленники, захватившие HMI, могут помешать оператору увидеть проблемы процесса в ICS, пока не станет слишком поздно. В категории HMI мы должны были превзойти AVEVA Edge и Schneider Electric EcoStruxure Operator Terminal Expert.
В каждой категории были разные классы уязвимостей, каждый из которых имел разное количество баллов: отказ в обслуживании (5 баллов), удаленное выполнение кода (20) и обход проверки доверенных приложений (40).
Хотя никому не запрещалось работать над любой целью, которую они хотели, каждый исследователь сосредоточился в основном на одной категории. Ноам Моше взял на себя контрольные серверы, а Ури Кац и я взяли категории OPC UA Server и Data Gateway. Шэрон начала с HMI и вскоре присоединилась ко мне и Ури.
Категории OPC UA Server и Data Gateway включали шесть приложений. Четыре из них содержали все возможные типы уязвимостей (отказ в обслуживании, удаленное выполнение кода, обход проверки доверенных приложений), а категория Data Gateway содержала только тип удаленного выполнения кода. Нашей целью было найти уязвимости, которые до этого никто не находил на самой последней версии таргета.
Уязвимости в категории серверов OPC UA необходимо было активировать путем отправки специально созданной полезной нагрузки по сети, что приводило к неожиданной работе целевого приложения. Первое, что нам нужно было сделать, особенно мне, потому что это было мое первое знакомство с OPC UA, — это понять протокол.
Протокол OPC UA используется в мире OT, охватывая все промышленное оборудование, которое вы можете себе представить. включая небольшие термодатчики на заводах, которые измеряют тепло от машин, ПЛК, управляющих процессами, до программного обеспечения на компьютерах административного персонала, который управляет этим заводом из другой части мира.
Отсутствие функциональной совместимости между протоколами ICS/SCADA и использующими их ПЛК является проблемой. Каждый протокол является проприетарным, и часто продукты разных производителей не могут обмениваться данными. Разработка протокола OPC должна была решить эту проблему. Идея состояла в том, чтобы создать стандартизированный протокол для управления процессами, чтобы упростить обслуживание с одного сервера, способного обмениваться данными со всеми конечными устройствами в сети OT.
Каждое сообщение OPC UA начинается с трехбайтового кода ASCII, определяющего тип сообщения. Четыре основных типа сообщений:
● HEL: приветственное сообщение.
● Сообщение OPN: OpenSecureChannel
● MSG: универсальный контейнер сообщений (защищенный ключами канала).
● Сообщение CLO: CloseSecureChannel
Сам протокол довольно сложен, и мы не сможем охватить его все здесь. (Если вам интересно, ознакомьтесь с белой книгой, которую Ури и Шэрон написали об OPC после первого командного соревнования Pwn2Own в 2020 году.)
Поэтому нам нужно было активировать уязвимость с помощью специально созданной полезной нагрузки по сети. Казалось логичным решать проблему с двух сторон: фаззинг и ручное исследование уязвимостей.
Фаззинг охватывает сетевое и статическое тестирование. Сетевой фаззер отправляет случайные данные по сети на серверы OPC UA на различных этапах создания сеанса OPC UA. Этот метод создается один раз и развертывается на всех серверах одновременно.
Мы создали наш фаззер с нуля на базе отличной сетевой среды фаззера под названием boofuzz.
Для статического фаззера мы использовали как стек протоколов OPC UA ANSI C, так и стек протоколов .NET OPC UA, поскольку у нас был их исходный код. Мы скомпилировали их с помощью известных фаззеров, таких как AFL, libfuzzer и sharpfuzz. Мы развернули все фаззеры на более чем 50 машинах, построили и написали некоторые инструменты и мониторы покрытия кода, чтобы отслеживать все фаззеры.
Второй подход заключался в ручном исследовании уязвимостей, что означает углубленное изучение протокола и попытку доступа к определенным потокам, которые потенциально могут вызвать ошибку. Например, сосредоточиться на эзотерических особенностях спецификации протокола OPC UA и подумать о том, что разработчики могли забыть проверить при написании своей реализации стека протоколов.
Я воспользовался подходом сетевого фаззера OPC UA, в то время как Ури и Шэрон начали исследовать цели вручную. У каждой из целей была своя реализация OPC UA, поэтому, если уязвимость была обнаружена в одной цели, это не означало, что эксплойт «сработает» на других целях.
Не буду врать, я был очень напряжен.
Это было мое первое подобное соревнование, и я был в команде всего около семи месяцев. Каждый хотел стать частью успеха. В то время фаззеры работали уже пару недель, но без особого успеха. Мы меняли стратегию фаззинга каждые несколько дней, надеясь увеличить охват, и были времена, когда это выглядело как победа, но оказывалось ложным срабатыванием, потому что поток был недостижим в реальных сценариях.
Однажды ночью мы заметили еще один сбой в одном из наших сетевых фаззеров. Мы научили себя не прыгать от радости, пока не убедились на 100%, что ошибка реальна. На этот раз так и было.
Я проверял снова и снова. Фаззер обнаружил сбой в Kepware KEPServerEx. После нескольких дней интенсивной работы мы смогли использовать сбой для полноценного удаленного выполнения кода перед аутентификацией на цели Kepware! У нас был надежный эксплойт, и мы были уверены, что он сработает на сцене (спойлер: он сработал!).
Со временем у нас было больше эксплойтов против большинства целей, и мы чувствовали себя сильными в отношении конкуренции. Шэрон и Ури физически присутствовали на соревнованиях в Майами, а мы с Ноамом остались дома в Израиле [BS1] и следили за соревнованиями онлайн. Не все попытки транслировались, но мы были в курсе ребят на месте в Майами. Тот, который транслировался в Интернете, был нашей попыткой против KEPServerEx.
У каждой команды было три попытки в течение пяти минут активировать уязвимость. Мы с Ноамом прилипли к экрану. Покушение началось. Эксплойт был сложным, и потребовалось некоторое время, чтобы сработать. Первые две минуты я прошел спокойно, но потом мы увидели, что Шэрон выглядит взволнованной, и мое сердце начало биться чаще. Прошла еще минута, и мы увидели, как один из официальных лиц указал на экран. Приложение MS Paint появилось на экране из ниоткуда, и только путем отправки наших созданных пакетов на сервер без аутентификации. Демонстрация нашего эксплойта прошла успешно, и мы получили за это полный балл!
Мы выполнили три атаки типа отказ в обслуживании и три атаки с удаленным выполнением кода, которые принесли нам 45 баллов (45 000 долларов США) и третье место в соревновании. В дополнение к основному событию был постоянный CTF, в котором мы заняли первое место.
Прошло больше месяца с момента соревнований, и только сейчас мы можем сделать глубокий вдох и сосредоточиться на наших регулярных исследованиях, пока не будут опубликованы цели для Pwn2Own Miami 2023.
Путь от младшего разработчика C++ до участия в соревнованиях высшего уровня, таких как Pwn2Own, был долгим. Для меня было рискованно уйти с работы программиста ради исследования уязвимостей, и оно того стоило не только потому, что у меня была возможность исследовать и находить нулевые дни в Pwn2Own, но и потому, что я занимаюсь любимым делом, и (я думаю) я делаю это хорошо.
