О флагах в 0x41414141 раз

    Сколько мы ни говорим о необходимости использования флагов линкера и компилятора, нацеленных на идентификацию повреждений памяти и усложнения их эксплуатации — наши разработчики ДБО, АБС и различных сертифицированных продуктов, как правило, никак к этому не прислушиваются. И вот при написании 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).

    Добавив в
    HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable>
    

    а для WOW на x64 — в
    HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable>
    

    ключ MitigationOptions и значение 0x100, можно принудительно включить ASLR для программы.

    Так что даже последний фейл Dropbox можно самому (или системному администратору) быстро исправить для Firefox, Chrome для пользователей Windows 7/8 (у IE10 в этом плане все в порядке), включив ASLR для нужных программ – правда, только в Windows7/8, Windows Server 2008 R2, и то не всегда… Но об этом чуть позже.

    Вернемся к нашей истории. Мы хотели почти искусственно ввести наличие ASLR для данной программы, что ломало бы наш план на этапе подготовки ROP-цепочки (так как теперь мы не знаем адреса наших ROP-гаджетов). Но и тут нас ждало разочарование, так как приложение было скомпилировано без таблицы релокаций (фиксированный базовый адрес), а именно на ней основана принудительная рандомизация загрузки исполняемого файла. Так что даже новомодная фича Windows 8 не помогала данному софту.

    Чтобы хоть как-то развлечься и удивить заказчика, мы написали shellcode, который сам восстанавливал работу эксплуатируемого сервера, так что даже не было заметно, что он падал, и клиенты бесперебойно работали с ним (проблемы могли быть разве что у клиентов, которые только подключались к серверу) =) Для этого пришлось заново запустить поток и корректно переинициализировать все служебные структуры.

    Справка. Техники обхода ASLR:

    Помимо того, что такой софт просто эксплуатировать, это еще и возможность простой эксплуатации уязвимостей в других более защищенных программах, например в браузерах. Поясню. Одной из техник обхода 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!
    Digital Security
    172,00
    Безопасность как искусство
    Поделиться публикацией

    Комментарии 7

      +5
      Для Linux (и Android в частности) нужно ещё указывать -Wa,--noexecstack чтобы запретить выполнение кода на стэке.
        +7
        Решил прогуляться по своим процессам.



        Позорище.
          0
          В домене EMET легко конфигурируется через групповые политики. Давно развернул у себя всем юзерам. Остаётся, впрочем, открытым вопрос, насколько оттестировано и безопасно его широкое применение на серверном виндовом софте, особенно опубликованном наружу — TMG, IIS, Exchange, Lync, терминал.
            +1
            EMET на сервер сайд — ребят, вам заняться нечем? Он для клиентского софта хоть как-то полезен бывает даже, несмотря на то, что и EMET обходится иногда ;) Но на сервер сайд — не стоит тратить время.
              0
              А, собственно, расскажите — почему нет? На сервер-сайд атаки такого типа, который прикрывается EMET'ом, тоже весьма актуальны.
                +2
                Сугубо потому, что сервер-сайд атак такого типа (именно на Апачи, IIS, Exchange, Terminal, ССШ и серверный софт) уже лет как 5-6 нету. Последняя актуальная атака была на службу ОС — конфликер был, а на сервер-сайд аппы — Lotus сплойты, которые работали и так тяжко, без всяких ЕМЕТ. Учитывая сложность эксплуатации таких уязвимостей в удаленных сервисах и слабый контроль над кучей (для проведения атак на ASLR или банального HeapSpray), большинство уязвимостей остаются DoS или очень трудно-эксплуатируемыми (в новом софте). В итоге мы имеем, что таких атак в дикой природе нет фактически, а значится нет смысла мучать софт и усложнять себе и админам жизнь.

                EMET имеет смысл ставить под софт, который старый и с известными уязвимостями, но который пропатчить незя. А просто так вешать на все ЕМЕТ — зачастую просто лишняя работа, которая снижает и без того низкие риски.
            0
            NDK'шный дефолтный компилятор, если мне не изменяет память, по умолчанию проставляется -fstack-protector

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое