Привет, Хабровчане!
В конце августа в OTUS запускается 2 мощных курса по обратной разработке кода (реверс-инжиниринг). В связи с этим приглашаем вас на День Открытых дверей, где Артур Пакулов (Ex-вирусный аналитик в Kaspersky Lab.) расскажет подробнее о программах, особенностях онлайн-формата, навыках, компетенциях и перспективах, которые ждут выпускников после обучения. А также приглашаем вас принять участие в бесплатных открытых уроках: «Анализ буткита» и «Анализ банковского трояна».
Предпосылки
Все описанное здесь основано на проекте, который я завершил в начале 2011 года, спустя аж несколько лет после его начала. Принимая участие в CanSecWest в 2009 году, Анибал Сакко и Альфредо Ортега из Core Security провели презентацию «Persistent BIOS Infection», где продемонстрировали, как можно пропатчить BIOS, чтобы совершить некоторые неприятные/удивительные вещи. Можете ознакомится с их докладом здесь. На то время это действительно впечатляло, но мне так и не выпал шанс попробовать это на практике. Год спустя мне нужно было подготовить групповой проект для учебы, поэтому я решил вернуться к взлому BIOS и самостоятельно реализовать что-нибудь из этого.
За последние несколько лет в мире BIOS для ПК многое изменилось, и теперь подписанный встроенный BIOS является стандартом, а архитектура UEFI внесла множество изменений по сравнению с традиционным дизайном BIOS. Менее чем через год после того, как я завершил этот проект, были обнаружены первые признаки того, что вредоносные программы действительно заражают BIOS в несколько похожей манере (ссылка). Простые меры, такие как подпись обновлений BIOS, легко предотвратили бы модификации BIOS такого типа. Также уже были проведены некоторые исследования для поиска путей решения этой проблемы (например, презентация «Attacking Intel BIOS» Рафаля Войчука и Александра Терешкина). Поэтому стоит отметить, что ничего из того, что описано здесь, не предназначено для представления миру какой-либо новой уязвимости, а скорее является демонстрацией концепции, которую можно легко проверить и изменить.
Моя первоначальная цель в этом проекте состояла в том, чтобы оценить реальную возможность атак и существования программ нацеленных на BIOS, и продемонстрировать их, если я что-нибудь обнаружу. Я думаю, что эта тема все еще актуальна и по сей день, несмотря на то, что новые технологии неуклонно делают этот тип атак менее релевантным. Но даже абстрагировавшись от цели, знание того, как делать интересные модификации BIOS в ассемблере, само по себе уже чего-то стоит, так что я решил опубликовать этот проект в интернете, чтобы другие тоже могли его оценить!
Если вы не горите желанием читать все это, а просто хотите поработать с результатами, жмите сюда, чтобы перейти в заключительную часть статьи, где вы найдете ссылку на образец BIOS и некоторые краткие инструкции.
Подход
В настоящее время существует весьма ограниченное количество примеров кода, подходящих для создания BIOS-руткитов. В публичном доступе можно найти только один из них, представленный миру на первой демонстрации BIOS-руткитов в марте 2009 года (насколько я знаю). Моей изначальной целью было воспроизвести находки, сделанные Core Security в 2009 году, а затем выяснить, как я могу их модифицировать. Моей конечной целью было создание своего рода BIOS-руткита, который можно было бы легко развернуть.
В 2009 году было проведено исследование в смежной области безопасности, которая занимается руткитами загрузочного сектора. В отличие от BIOS-руткитов, разработки в этой области развивались очень быстрыми темпами, что привело к созданию и выпуску ряда различных MBR(master boot record)-руткитов. Этот тип руткитов был назван «Bootkit», и, подобно BIOS-руткиту, он стремится загрузить себя до загрузки ОС. Это сходство побудило многих разработчиков буткитов отметить, что данная атака должна быть осуществимой непосредственно из BIOS, а не из MBR. Несмотря на комментарии и предложения о том, что код буткита можно было перенести для выполнения в BIOS, пока не было опубликовано ни одного примера такого кода.
Первым этапом реализации этого проекта было создание среды тестирования и разработки, в которой можно было бы вносить и отлаживать модификации BIOS. В своей статье об устойчивом заражении BIOS Сакко и Ортега подробно описывают, что они обнаружили, что VMware содержит BIOS ROM, а также GDB сервер, который можно использовать для отладки приложений, начиная с самого BIOS. После успешной работы в VMware была проделана работа по переносу модификаций BIOS VMware на другие подобные BIOS — это будет описано во второй половине этой статьи.
Конфигурация VMware BIOS
Ладно, достаточно предыстории, займемся!
Первый необходимый шаг — извлечь BIOS из самой VMware. В Windows это можно сделать, открыв исполняемый файл vmware-vmx.exe с помощью любого экстрактора ресурсов, например, Resource Hacker. В этом приложении объединено несколько различных двоичных ресурсов, и BIOS хранится в ресурсе с идентификатором 6006 (по крайней мере, в VMware 7). Это может разниться от версии к версии, но ключевым моментом является размер файла ресурса 512 КБ. На следующем изображении показано, как это выглядит в Resource Hacker:
Хотя этот BIOS-образ связан с приложением vmware-vmx.exe, его также можно использовать отдельно, без необходимости вносить правки в исполняемый файл VMware после каждого изменения. VMware позволяет указывать ряд «скрытых» параметров в файле настроек образа VMX. В какой-то момент я планирую документировать некоторые их них на вкладке Tools этого сайта, потому что они действительно очень полезны! Вот те, которые пригодятся для модификации и отладки BIOS:
bios440.filename = "BIOS.ROM"
debugStub.listen.guest32 = "TRUE"
debugStub.hideBreakpoint = "TRUE"
monitor.debugOnStartGuest32 = "TRUE"Первая настройка позволяет BIOS ROM загружаться не из приложения vmware-vmx, а из файла. Следующие две строки подключают встроенный GDB сервер. Этот сервер прослушивает соединения через порт 8832, когда образ работает. Последняя строка указывает VMware остановить выполнение кода в первой строке гостевого образа BIOS. Это очень полезно, так как позволяет определять точки останова и проверять память до того, как произойдет какое-либо выполнение BIOS. Тестирование было выполнено с использованием IDA Pro в качестве GDB клиента. Пример гостевого образа VMware, остановленного на первой инструкции BIOS, можно увидеть на скриншоте ниже:
При первом использовании этой тестовой среды у меня были значительные проблемы с подключением IDA к GDB серверу. После долгих проб, ошибок и тестирования с различными GDB клиентами было выявлено, что виновата моя версия VMware. Версии 6 и 6.5, похоже, не очень хорошо работают с IDA, поэтому для большинства испытаний мной использовалась VMware 7. BIOS состоит из 16-битного кода, а не 32-битного кода по умолчанию для IDA, поэтому было необходимо определить «Manual Memory Regions» в параметрах отладки IDA. Это позволило адресам памяти быть определенным как 16-битный код, чтобы они правильно декомпилировались.
Воссоздание готовых наработок — модификация VMware BIOS
Как уже отмечалось, Сакко и Ортега провели две презентации по модификации BIOS, наряду с презентацией Войчука и Терешкина. Из этих трех презентаций только Сакко и Ортега включили какой-либо исходный код или пример, демонстрирующий описанные ими методы. Поскольку это был единственный доступный пример, он использовался в качестве отправной точки для этого проекта.
Работа Сакко и Ортега довольно подробно описывает их сетап и методы тестирования. Установка VMware была завершена, как описано выше, и следующим шагом было внедрение кода модификации BIOS, который они предоставили. Предоставленный код требовал извлечения BIOS ROM в отдельные модули. BIOS ROM, входящий в комплект VMware, является Phoenix BIOS. Исследование говорит, что существует два основных инструмента для работы с этим типом BIOS, инструмент с открытым исходным кодом «phxdeco», и коммерческий «Phoenix BIOS Editor», который предоставляется непосредственно Phoenix. В работе Сакко и Ортега рекомендовано использовать приложение Phoenix BIOS Editor — они разрабатывали свой код для использования под ним. Пробная версия была загружена мной из интернета, и, похоже, она обладает всеми функциями, необходимыми для этого проекта. Разыскивая ссылку для скачивания снова, я не могу найти ничего, что кажется даже наполовину легитимным, но Google предлагает большой список вариантов. Я просто предположу, что найти какую-нибудь легитимную пробную версию не составит труда. После того, как инструменты установлены, следующим шагом будет создание пользовательского BIOS.
Сначала я убедился, что небольшая модификация образа BIOS вступит в силу в VMware, что и произошло (изменился цвет логотипа VMware). Затем я запустил скрипт сборки на Python, предоставленный Сакко и Ортега для модификации BIOS. Помимо одной опечатки в питоновском скрипте сборки BIOS все работало отлично, и новый BIOS был сохранен на диск. Однако загрузка этого BIOS в VMware не привела к тому же самому успеху: VMware выдает сообщение о том, что в виртуальной машине что-то пошло не так и что оно закрывается. Отладка этой проблемы совершалась в IDA и GDB, но проблему было трудно отследить (плюс в IDA были проблемы с версией). В целях ускорения работы была загружена другая версия VMware, чтобы тестовая среда соответствовала среде Сакко и Ортега. После некоторых поисков была найдена и установлена точная версия VMware, которую они использовали. Это, к сожалению, не решило проблему, VMware сообщила о той же ошибке. Хотя я видел, как эта модификация BIOS работала, когда демонстрировалась как часть их презентации, теперь было ясно, что их пример кода потребует дополнительной модификации, прежде чем он сможет работать на какой-либо тестовой системе.
В результате отладки кода Сакко и Ортега было изучено много разных моментов, и в итоге проблема была в инструкции на ассемблере, которая выполняла far вызов абсолютного адреса, который не был правильным для используемой BIOS. После ввода правильного адреса код BIOS был успешно выполнен, и руткит начал искать на жестком диске файлы для изменения. Этот код требовал очень много времени для сканирования на жестком диске (который был всего 15 ГБ), и он запускался несколько раз до запуска системы. Код подтверждения концепции включал в себя возможность исправления notepad.exe, чтобы он отображал сообщение при запуске, или изменения файла /etc/passwd в системе Unix, чтобы root пароль был установлен на фиксированное значение. Это показало, что руткиты могут функционировать как в Windows системах, так и в Linux, даже если они используются только в простых целях.
Тестирование буткита
Значительно позже, в процессе работы над проектом, мной была также протестирована функциональность различных буткитов, и результаты были пересмотрены, чтобы определить, какой из них будет работать лучше не только в качестве буткита, но и как BIOS-руткит. Были исследованы четыре разных буткита: Stoned, Whistler, Vbootkit и Vbootkit2. Буткиты Stoned и Whistler были разработаны для того, чтобы функционировать в большей степени как вредоносные программы, нежели руткиты, и не отличались простотой структуры исходного кода. Vbootkit2 сильно выделялся, так как он в меньшей степени предполагал из себя вредоносное ПО и имел (относительно) хорошо документированный исходный код. Этот буткит предназначался для запуска с CD, но был протестирован только с бета-версией Windows 7. При использовании с коммерческой копией Windows 7, буткит просто не загружался, так как Windows использовала другие сигнатуры файлов. Я потратил некоторое время на определение новых сигнатур файлов, чтобы можно было протестировать этот буткит, но он все равно не загружался. В целях тестирования, я нашел бета-версию Windows 7. Когда Vbootkit2 запускался на бете Windows 7, все работало, как и ожидалось. Vbootkit2 включал в себя возможность повысить процесс до привилегий уровня системы (выше уровня администратора), чтобы захватывать нажатия клавиш и сбрасывать пароли пользователей. Все эти элементы были бы полезны для включения в руткит, но для переноса этого приложения в стандартный Windows 7 требовалась значительная работа. Далее был рассмотрен Vbootkit; он был разработан для работы с Windows 2003, XP и 2000. Хотя он не был собран так, чтобы его можно было запускать с компакт-диска, для добавления этой функциональности потребовались лишь незначительные изменения. Это программное обеспечение включало только возможность повышения привилегий процесса, но даже само по себе это уже очень ценная функция. Так этот программный пакет был выбран для использования с BIOS-руткитом, который описан в следующем разделе. NVLabs являются авторами этого буткита, который по большому счету представляет основную функциональность этого проекта, поэтому большое спасибо им за то, что они опубликовали свой код! Похоже, что исходный код больше не доступен на их веб-сайте, но его все еще можно скачать с Archive.org здесь.
Внедрение кода в BIOS посмотрим в следующей части. Следите за новостями!
Узнать подробнее о курсах: «Реверс-инжиниринг. Продвинутый», «Реверс-инжиниринг»
