Сколько мы ни говорим о необходимости использования флагов линкера и компилятора, нацеленных на идентификацию повреждений памяти и усложнения их эксплуатации — наши разработчики ДБО, АБС и различных сертифицированных продуктов, как правило, никак к этому не прислушиваются. И вот при написании pre-auth RCE server side exploit в очередной раз появилась идея написать об этом на основе наших последних работ.
Итак, в процессе одной из наших последних работ по анализу защищенности приложения без исходного кода (клиент-серверного приложения для ОС Windows) мы методом фаззинга нашли уязвимость. Нас сразу порадовал тот факт, что для ее срабатывания нет необходимости знать логин и пароль, так как данные, приводящие к падению приложения, содержались в первом же пакете, ответственном за аутентификацию (на дворе 2013 год).
В 2011 году нашим исследователем была найдена подобная уязвимость в Oracle PeopleSoft (данная уязвимость закрыта в CPU January 2011). Там уязвимость проявлялась при вводе пароля определенной длины. Но ничего, кроме DoS, нам из нее выжать не удалось, так как использовался флаг компиляции /GS (stack cookie), а наш переполняемый буфер до SEH не дотягивал, и мы не могли его перезаписать для передачи управления на наш код.
Но у нашей новой мишени такого не было. Единственным, что она использовала, был DEP. Так что написание удаленного эксплойта под Windows 7 было лишь формальностью. Задача стояла достаточно простая и скучная: переписать адрес возврата на цепочку ROP-гаджетов для отключения DEP и передать управление на наш shellcode, который лежал в этом же стеке.
Мы решили написать эксплойт и под Windows 8, в которой введен ряд дополнительных механизмов безопасности, из которых нас интересовал механизм, отвечающий за рандомизацию загрузки библиотек, которые скомпилированы без флага /DYNAMICBASE (ASLR). Называется эта фича ForceASLR. Она введена, как было сказано, в Windows 8, но доступна и для Windows 7 после установки апдейта KB2639308 и небольшой настройки реестра для интересующего нас приложения (смотри Image File Execution Option).
Добавив в
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options<executable>
а для WOW на x64 — в
HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionImage File Execution Options<executable>
ключ MitigationOptions и значение 0x100, можно принудительно включить ASLR для программы.
Так что даже последний фейл Dropbox можно самому (или системному администратору) быстро исправить для Firexox, Chrome для пользователей Windows 7/8 (у IE10 в этом плане все в порядке), включив ASLR для нужных программ – правда, только в Windows7/8, Windows Server 2008 R2, и то не всегда… Но об этом чуть позже.
Вернемся к нашей истории. Мы хотели почти искусственно ввести наличие ASLR для данной программы, что ломало бы наш план на этапе подготовки ROP-цепочки (так как теперь мы не знаем адреса наших ROP-гаджетов). Но и тут нас ждало разочарование, так как приложение было скомпилировано без таблицы релокаций (фиксированный базовый адрес), а именно на ней основана принудительная рандомизация загрузки исполняемого файла. Так что даже новомодная фича Windows 8 не помогала данному софту.
Чтобы хоть как-то развлечься и удивить заказчика, мы написали shellcode, который сам восстанавливал работу эксплуатируемого сервера, так что даже не было заметно, что он падал, и клиенты бесперебойно работали с ним (проблемы могли быть разве что у клиентов, которые только подключались к серверу) =) Для этого пришлось заново запустить поток и корректно переинициализировать все служебные структуры.
Справка. Техники обхода ASLR:
- Перебор
- Частичная перезапись EIP
- Утечка адреса
- Через уязвимость
- Через timing-атаку
- Через игры со строчками/объектами
- …
- Использование заранее известных адресов
- Библиотеки без ASLR
- Системные структуры (техника с _ KUSER_SHARED_DATA)
- Преднамеренное расположение
- JIT/Heap spray
- …
Помимо того, что такой софт просто эксплуатировать, это еще и возможность простой эксплуатации уязвимостей в других более защищенных программах, например в браузерах. Поясню. Одной из техник обхода ASLR является специальная инициируемая атакующим загрузка библиотеки без ASLR в адресное пространство атакуемого приложения (Последний широко известный случай использования данной техники — таргетированная атака использующая эксплуатацию CVE-2013-3893 в Internet Explorer). И вот злоумышленник решил атаковать клиентов/сотрудников банка (при этом, естественно, не секрет, какая ДБО-система используется) или государственное учреждение (при этом, естественно, секретом не является список сертифицированного ПО, разрешенного для работы в таких компаниях для шифрования, разграничения доступа, очистки памяти и т. д.). Злоумышленник, исследовав данное ПО, будет пытаться подгрузить их (если они не подгружаются самостоятельно), так как они в большинстве своем без ASLR. А еще при этом получается хорошая таргетированная атака. Ведь если в браузер не подгружается, например, ActiveX-элемент определенной ДБО-системы, то жертва, скорее всего, и не является клиентом данного банка, следовательно, и целью злоумышленника.
Данным примером хотелось показать, насколько сейчас гетерогенны системы и изысканны атаки. Не стоит забывать, что на компьютере пользователя одновременно живет огромное количество ПО. Слабое ПО может использоваться для компрометации вашего ПО, или ваше ПО – для компрометации чужого.
Историческая справка:
- GS появился в 2002 году
- SafeSEH появился в 2003 году
- DEP появился в 2004 году
- ASLR появился в 2006 году
- ForceASLR появился в 2012 году
Появление механизма не означает, что он стал по умолчанию включен в VisualStudio. Посмотрите, что используют из этого ваши проекты, и соотнесите, к какому году выпуска они относятся с точки зрения безопасности.
Помните, что с переходом в новую студию вы получаете не только новый графический интерфейс и программерские новинки, но и все новые фичи компилятора и линкера, из которых очень многие связаны с безопасностью. Для кого-то может оказаться новостью, но даже флаг /GS эволюционирует и к 2010 представляет собой 4 версию, не говоря уже о ряде улучшений, типа защиты указателей, защиты метаданных heap и порядка расположения переменных в стеке, которые даже порой не имеют специальных названий.
Полноты ради скажем, что ASLR и DEP могут быть настроены не только через флаги, но и с помощью реестра и специального API: MitigationOptions в IFEO (Image File Execution Option), UpdateProcThreadAttribute, SetProcessMitigationPolicy API, но флагами куда легче.
Для повышения безопасности пользователей, конечно, есть такая вещь, как EMET (Enhanced Mitigation Experience Toolkit), но мы, к сожалению, согласны с комментарием к статье по ссылке: “И все-таки эта штука для очень уж продвинутых пользователей”. Я имею в виду не сложность работы с программой, а слабую компьютерную грамотность большинства пользователей.
Потратьте несколько минут времени, выставьте флаги компилятора и линкера, и вы во много раз усложните, а в ряде случаев сделаете невозможным процесс написания стабильно работающего эксплойта. В итоге злоумышленник будет довольствоваться только DoS.
Да, аналогичные (и специфичные) флаги есть и для мобильных платформ:
iOS: –fPIE, –fstack-protector-all, -fobjc-arc
Android (для нативных библиотек): -fstack-protector, -Wformat-security, NX, ASLR, PIE
BlackBerry 10 (для нативных библиотек):-fstack-protector-all, -D_FORTIFY_SOURCE=2, -fPIE, -Wl,-z,relro, -Wl,-z,now, -pie
WindowsPhone 8 (для нативных библиотек): аналогично Windows 8
Не всем дано сразу писать безопасный код (нереально), не все могут позволить себе софт для анализа безопасности кода (бюджет не позволяет), не все могут быстро и безболезненно внедрить SDL в компанию (к этому надо, конечно, стремиться), но все могут выставить флаги. Так при минимальных трудозатратах можно значительно увеличить безопасность.
PS: Естественно, флаги компиляции никак не влияют на архитектурные, логические и конфигурационные уязвимости ;)
PPS: Есть еще песочницы и виртуализация, но это тоже не панацея. О них – уже на ZeroNights 2013!
Автор: d1g1
