Authentication bypass что это
Критическая уязвимость. Максимальный уровень угрозы.
Authentication Bypass может быть выполнен эксплуатируя уязвимости кода сайта, ошибки публикации ресурса, а так же из-за ошибок в настройках и уязвимостями программного обеспечения сервера.
Возможность обхода аунтификации (Authentication Bypass) на сайте всегда приводит к его взлому, так как:
- Атакующий проходит в административный раздел сайта с максимальным уровнем доступа Атакующий получает доступ к закрытым разделам сайта, или файлам, напрямую взаимодействующим с базой данных или файловой системой сервера
Несколько примеров Authentication Bypass:
SQL injection Authentication Bypass
Обход аутентификации с помощью SQL инъекции
- Атакующий изменяет запрос, нарушая логику его выполнения Запрос возвратит все строки таблицы пользователей сайта, вне зависимости от условия валидации парольной пары Атакующий получает доступ к административному разделу сайта Сайт взломан
XPath injection Authentication Bypass
Обход аутентификации с помощью XPath инъекции
Часть кода XML базы данных пользователей сайта: base.xml
1
admin
Код аутентификации пользователей / администраторов сайта
String username = req.getParameter(«username’);
String password = req.getParameter(«password’);
XPathFactory factory = XPathFactory.newInstance();
Xpath xpath = factory.newXPath();
File file = new File(«/usr/webappdata/users.xml’);
InputSource src = new InputSource(new FileInputStream(file));
XPathExpression expr = xpath.compile(«//users[username/text()=’ » + username + » ‘ and password/text()=’ » + password + ‘ ‘]/id/text()’);
String
Легальный XPath запрос на аутентификацию пользователя:
users[username/text()=’admin’ and password/text()=’adminpass’] /id/text()
XPath инъекция:
‘ or ‘1’=’1′
Измененный в результате эксплуатации XPath инъекции запрос:
users[username/text()=’admin’ and password/text()=» or ‘1’=’1′ ]/id/text()
Результат:
Аутентификация атакующего на сайте
Запрос вернет ID для пользователя admin с пустым паролем при условии 1=1 является истиной.
Ошибки разграничения прав доступа к БД
Критические ошибки разработки сайта, при определенных условиях, могут приравнять обычных пользователей сайта к их администраторам или контент менеджерам.
В нашей практике случались обращения клиентов с взломанными сайтами из-за такого рода ошибок.
Такой взлом сайта реализуется крайне просто. Атакующий регистрируется на сайте (или форуме) как обычный пользователь, а затем, используя свою учетную запись проходит в административный раздел сайта.
Защита от Authentication Bypass
Ограничение доступа к административному разделу сайта по IP. Кроме этого, можно рассмотреть вариант с установкой дополнительной парольной пары на системные директории сайта. В случаях, когда нельзя использовать вышеописанные варианты защиты, следует исключить эксплуатацию любых уязвимостей, т.к. получение несанкционированного доступа к административному разделу это не только SQL и XPath инъекции но и сотни вариаций самых разнообразных атак, таких как XSS и им подобных.
Сканер уязвимостей сайтов онлайн Проверьте, наколько устойчив к взлому Ваш сайт
Security testing
По статистике, за последнюю пару лет число киберпреступлений, связанных с утечками информации и взломом различных приложений, как веб, так и мобильных, увеличилось на 27% и, примерно, треть организаций по всему миру столкнулась с кибератаками. Глядя на эту статистику, невольно задумываешься о тестировании безопасности, или же Security Testing. Security testing — это, фактически, отдельный мир внутри области тестирования программного обеспечения и на его изучение может потребоваться немалое количество времени. Цель этой статьи — познакомить Вас с наиболее популярными подходами к тестированию безопасности и дать общее представление о направлении, в котором нужно смотреть.
Если рассматривать по определению, то Security testing или тестирование безопасности — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным (звучит нагромождённо, не так ли?).
Если сказать простыми словами, то тестирование безопасности — это проверка программного продукта на наличие уязвимостей, которыми могут воспользоваться злоумышленники, чтобы получить доступ к закрытой информации или навредить продукту и его пользователям.
В наше время, деятельность практически любого предприятия так или иначе связана с применением ПО, требующего подключения к интернету, что позволяет существенно упростить и ускорить выполнение требуемой работы. Однако, именно всемирная сеть открывает путь злоумышленникам, которые хотят получить доступ к конфиденциальным данным пользователей и компании.
Программисты, естественно, готовят оборонительные рубежи и преграды, которые нужно преодолеть. Нам же, как тестировщикам, требуется поставить себя на место «плохих парней» и попытаться найти неплотно закрытую дверь. Это можно делать несколькими способами:
Для каждого из приведенных выше способов есть соответствующий вид атаки.
Далее, каждый вид будет рассмотрен немного подробнее.
Authorization Bypass
Самая маловероятная из уязвимостей, зачастую отсекаемая еще на стадии разработки. Но несмотря на это проверять такую возможность все же стоит, ведь иногда самые очевидные варианты проверок и оказываются верными.
Итак, какая же структура у подобных ошибок в безопасности? Все сводится к тому, что пользователь А может получить доступ к документам и данным пользователя Б. Допустим, есть реализация, где при просмотре своего профиля, содержащего конфиденциальную информацию, в URL страницы передается userID. В данном случае есть смысл попробовать подставить вместо своего userID номер другого пользователя. И если вы увидите его данные, значит вы нашли дефект.
Другими словами, например, есть некоторый сайт:
и ссылка на личный кабинет пользователя6
Если при подстановке другого номера id, например:
происходит вход в другую учетную запись, значит уязвимость обнаружена.
SQL and Code injection
Пожалуй, сейчас это самый распространенный способ взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.
Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.
В общих чертах поиск уязвимости с помощью SQL инъекций будет выглядеть следующим образом:
Форма входа в систему имеет 2 поля — имя и пароль. Обработка происходит в базе данных через выполнение SQL запроса:
WHERE Name = ‘tester’
AND Password = ‘testpass’;
Следует ввести корректное имя ’tester’, а в поле пароль ввести строку:
В итоге, если поле не имеет соответствующих валидаций или обработчиков данных, может вскрыться уязвимость, позволяющая войти в защищенную паролем систему, т.к. SQL запрос примет следующий вид:
WHERE Name = ‘tester’
AND Password = ‘testpass’ OR ‘1’ = ‘1’;
Условие ‘1’ = ‘1’ всегда будет истинным и поэтому SQL запрос всегда будет возвращать много значений.
Как было сказано ранее, SQL Injection — один из самых популярных подходов, как раз благодаря ему в 2019 году в украинской платформе по управлению IPTV/OTT-проектами Ministra TV обнаружена критическая уязвимость. Эксперты из CheckPoint нашли логическую уязвимость в функции авторизации платформы Ministra, которая выражается в неспособности подтверждения запроса, что позволяет удаленному злоумышленнику обойти авторизацию и выполнить SQL-инъекцию через отдельную уязвимость, которую в противном случае мог бы использовать лишь злоумышленник, прошедший авторизацию (полную версию можно посмотреть https://www.youtube.com/watch?v=jqXPePSefss).
XSS (Cross-Site Scripting)
Вкратце, XSS или CSS (Cross-site Scripting, аббревиатура, которая также означает Cascading Style Sheets — таблицы каскадных стилей) является довольно распространенной уязвимостью среди Web-приложений. XSS позволяет атакующему внедрить вредоносный код на страницу и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных.
Существует два типа XSS уязвимостей — пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пример пассивной уязвимости выглядит следующим образом:
Зачастую, в этом моменте вступает социальная инженерия, например, ссылка маскируется под важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме.
В этом году компания по информационной безопасности Sucuri сообщила, что обнаружила новый способ кражи денег с банковских карт, при котором пользователям в браузере загружают фейковую форму для ввода карточных данных притом, что ничего не подозревающий покупатель в адресной строке видит реальный адрес интернет-магазина. По их словам “Злоумышленники нашли в системе управления интернет-магазинами CMS Magento уязвимость, возникшую из-за некорректной фильтрации кода, которая позволяет провести атаку типа XSS.” При условии что CMS Magento пользуется чуть меньше 20% интернет-магазинов в мире, то уязвимость достаточно критичная.
XSRF / CSRF (Request Forgery)
Согласно Википедии XSRF / CSRF (Request Forgery) — это вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника).
Наиболее частыми CSRF атаками являются атаки использующие HTML тэг или Javascript объект image. Чаще всего атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт, таким образом, что при загрузке страницы осуществляется запрос, выполняющий вредоносный код.
Javascript объект Image
В 2017 году была обнаружена критическая уязвимость обхода аутентификации в одной из крупнейших платформ идентификации с сервисом Auth0, которая могла позволить злоумышленнику получить доступ к любому порталу или приложению, которые используют сервис Auth0 для аутентификации.
При тестировании приложения еще в сентябре 2017 года исследователи из охранной фирмы Cinta Infinita обнаружили недостаток ( CVE-2018–6873 ) в Auth0 Legacy Lock API, который связан с неправильной проверкой параметра аудитории JSON Web Tokens (JWT).
Исследователи успешно воспользовались этой проблемой, чтобы обойти аутентификацию при входе в систему с помощью простой подделки межсайтовых запросов (CSRF / XSRF) на приложения, работающие с аутентификацией Auth0. (саму атаку можно увидеть здесь: https://www.youtube.com/watch?v=9E7kfdGN1eY)
Распределенные сетевые атаки часто называются распределенными атаками типа «отказ в обслуживании» (Distributed Denial of Service, DDoS). Что же данная атака из себя представляет?
Представьте себе небольшой магазинчик с одеждой, который вмещает максимум 10–15 человек, в котором работает всего один продавец и охранник. Злоумышленники захотели ограбить этот магазин, подали объявление на популярном ресурсе, что у данного магазина будет распродажа со скидками в 99%, после чего в данный магазин приходит больше тысячи покупателей, среди которых есть и злоумышленники. Пока продавец и охранник не справляются с нагрузкой и не могут уследить за всеми покупателями разом, злоумышленники спокойно проходят под видом обычных покупателей и крадут одежду. Бизнес заходит в тупик.
Это и есть DDoS, или «распределенный отказ в обслуживании», который представляет собой злонамеренную сетевую атаку, в которой хакеры заставляют многочисленные устройства, подключенные к Интернету, отправлять запросы на сетевое соединение одному конкретному сервису или веб-сайту с целью подавления ложного трафика или запросов. Это приводит к тому, что все доступные ресурсы связываются с этими запросами, и происходит сбой веб-сервера или его отвлечение настолько, что обычные пользователи не могут создать соединение между своими системами и сервером.
Для проверки устойчивости на DDoS атаки можно воспользоваться The Low Orbit Ion Cannon (LOIC) или «Низкоорбитальная ионная пушка» Возможно самая популярная DDOS программа. Она может рассылать массовые запросы по протоколам ICMP, UDP тем самым забивая канал к серверу жертвы. Самая известная атака с помощью LOIC была совершена группой Anonymous в 2009 году и направлена против PayPal, Visa, MasterCard в отместку за отключение WikiLeaks от системы сбора пожертвований.
Атаки, организованные с помощью LOIC могут утилизироваться с помощью блокировки UDP и ICMP пакетов на сетевом оборудовании интернет провайдеров. Вы можете скачать саму программу LOIC бесплатно на сайте SourceForge. Этот инструмент на базе Windows и работа с ним очень проста, указываете сайты жертвы и нажимаете всего одну кнопку (не рекомендуется использовать дома).
Mobile and Client–server Security testing
Тестирование безопасности мобильных и клиент-серверных приложений стоит немного особняком, поскольку отличается подходом и инструментами от тестирования безопасности веб-приложений. В 2016 году OWASP (Open Web Application Security Project) составили финальную версию категорий уязвимостей для проверки подобных приложений. Список выглядит следующим образом:
Для проверки на уязвимости мобильных и клиент-серверных приложений зачастую используются сторонние программы, такие как Apktool (программа для распаковки apk-файлов, которая используется для локализации программного обеспечения, анализа структуры приложения), Drozer (фреймворк, который содержит инструменты, позволяющие искать уязвимости мобильных устройств и программ.) и т.д.
Заключение: Все вышеупомянутое является только верхушкой айсберга под названием Security testing. Углубляясь в данную область можно перечислить еще много видов атак и уязвимостей, на которые стоит обратить внимание. Но проверив хотя бы самые простые и часто встречающиеся виды атак можно добиться того, что злоумышленнику будет намного сложнее проникнуть в конфиденциальные данные проекта.
[Советы] EDL Authorization Bypass-игра времени
Всем привет, с вами как всегда  |
avatar.png (47.08 KB, Downloads: 72)
2019-07-18 22:36:16 Upload
Сегодня наткнулся на один способ для обхода авторизаций аккаунта для восстановления «невключаек». В общем, я пишу эту тему, но имейте ввиду, всё это надо быстро делать! В противном случае вы потеряете шанс и снова надо будет повторить процесс.
Итак, давайте немножко литературы.
Как нам известно, Xiaomi внедрила защиту против неофицильных прошивок, а также Bypass Mi Аккаунта. Всем уже известно что защита находится в бинарике Firehose FHLoader, отвечающем за память. Но для запуска процесса, бинарик должен запускать протокол под названием Sahara, который в свою очередь и начинает заливку прошивки и смартфон из главного загрузчика (PBL=Primary Bootloader), который последовательно через дампер, переходит в второй загрузчик (SBL=Secondary Bootloader), который в свою очередь и является тоннелем, через который проходит прошивка (грубо говоря, тот же Fastboot). Дальше. Чудо творится: восстановление! Но нас мучает вопрос, как обойти этот корявый аккаунт?!
Изначально скачаем Mi Flash v.2018.5.28.0 и прошивку под Fastboot.
И ждём окончания теста (тестовый режим протокола), у вас должна появится надпись «OKAY».
После чего переподключите смартфон через EDL и начинайте прошивку. Имейте ввиду,что прошивку надо начинать как можно быстрее, у вас при этом есть всего лишь 15-20 секунд. Потом черный ход закроется!
UAC Bypass или история о трех эскалациях
На работе я исследую безопасность ОС или программ. Ниже я расскажу об одном из таких исследований, результатом которого стал полнофункциональный эксплоит типа UAC bypass (да-да, с source-code и гифками).
История
GUI UAC bypass
Наверняка существует множество способов найти уязвимость. Один из самых простых — это воспроизведение уже существующей атаки, выбрав другую цель. Так и я решил поставить опыт — через меню выбора файла (для сохранения или открытия) запустить какое-нибудь приложение.
Гифка показывает, как такая атака выглядела в Windows 98. Атакующий хитрыми манипуляциями вызывает окно открытия файла и через него запускает explorer.
Сначала проведем простой тест, чтобы посмотреть, что происходит — запускаем блокнот. Выбираем в меню пункт «Открыть», а в появившемся окне переходим в папку C:\Windows\system32\. В окне отображаются только файлы txt и папки. Это легко поправить — достаточно вместо имени файла написать *.* и будут отображены все файлы (в случае блокнота можно проще — выбрать фильтр «Все файлы», но такой фильтр будет доступен не всегда, а звездочки будет работать всегда). Находим notepad.exe и запускаем его через контекстное меню.
Process Explorer показывает вполне ожидаемую картину:
Один процесс стартовал другой. Чаще всего при таком наследовании дочерний процесс имеет тот же уровень привилегий, что и родительский. Значит, если мы хотим запустить процесс с высокими привилегиями, то и воспользоваться нужно процессом, у которого уже есть эти привилегии.
Тут я вспомнил о приложениях с автоматически поднимаемыми привилегиями. Речь идет о программах, у которых в манифесте прописано поднятие привилегий без запроса UAC (элемент autoElevate). Для первого эксперимента я выбрал многострадальный eventwvr.exe (он уже пару раз засветился в обходах UAC).
Все оказалось очень просто, в меню «Действие» есть пункт «Открыть сохраненный журнал…» — этот пункт выводит окно открытия файла, что мы и хотим получить.
После запуска мы увидим такую ситуацию:
Мы запустили консоль с правами администратора без появления окна UAC.
Такой вид уязвимостей называется UAC bypass (обход запроса UAC). Важно отметить существенное ограничение — автоматическое поднятие прав работает, только если пользователь входит в группу администраторов. Поэтому с помощью такой уязвимости нельзя поднять права с уровня пользователя. Но все же уязвимость довольно опасна — очень много пользователей Windows использует аккаунт администратора для повседневной работы. Вредоносная программа, которую запустит пользователь такого аккаунта, без внешних проявлений получит сначала административные привилегии, а затем, если ей надо, то может получить хоть NT AUTHORITY\SYSTEM. С привилегиями администратора это очень легко.
На гитхабе есть отличный проект https://github.com/hfiref0x/UACME, где собраны, наверное, все имеющиеся в открытом доступе уязвимости такого рода, причем с указанием с какой версии Windows уязвимость начала работать, и в какой ее поправили, если поправили.
Я далеко не первый, кто подумал об уязвимости такого плана. Ниже я прикладываю два анимационных изображения, которые наглядно показывают обход UAC еще двумя способами.
Я прошелся по разным приложениям и ниже прикладываю еще 18 способов реализации такого обхода.
Внимание! Возможно, в разных версиях и редакциях некоторые приложения не будут иметь автоматическое поднятие привилегий — их список периодически меняется.
Кроме того, если у вас установлен принтер, то с большой вероятностью в окошках, связанных с печатью, вы найдете много дополнительных способов вызвать окно выбора файла.
cliconfg.exe
1) Кнопка «Справка», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Просмотр HTML-кода», в появившемся окне Блокнота выбрать в меню «Файл», пункт «Открыть».
2) Кнопка «Справка», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Печать», в появившемся окне «Найти принтер…», в окне поиска выбрать меню «Файл», пункт «Сохранить условия поиска».
compMgmtLauncher.exe
3) Меню «Действие», пункт «Экспортировать список…».
4) Меню «Справка», пункт «Вызов справки», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Просмотр HTML-кода», в появившемся окне Блокнота выбрать в меню «Файл», пункт «Открыть».
5) Меню «Справка», пункт «Вызов справки», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Печать», в появившемся окне «Найти принтер…», в окне поиска выбрать меню «Файл», пункт «Сохранить условия поиска».
dcomcnfg.exe
6) В списке слева выбрать «Службы (локальные)», в контекстном меню выбрать пункт «Экспортировать список…».
eudcedit.exe
7) После старта, программа предложит выбрать код. Выбираем любой и нажимаем ОК; В меню «Файл» выбираем пункт «Связи шрифтов…», в появившемся окне отмечаем «Установить связь с выбранными шрифтами», это разблокирует кнопку «Сохранить как…».
eventvwr.exe
8) Меню «Действие», пункт «Открыть сохраненный журнал…».
9) Меню «Справка», пункт «Вызов справки», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Просмотр HTML-кода», в появившемся окне Блокнота выбрать в меню «Файл», пункт «Открыть».
10) Меню «Справка», пункт «Вызов справки», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Печать», в появившемся окне «Найти принтер…», в окне поиска выбрать меню «Файл», пункт «Сохранить условия поиска».
netplwiz.exe
11) Выбрать вкладку «Дополнительно», в группе «Дополнительное управление пользователями» нажать кнопку «Дополнительно». Будет запущена оснастка lusrmgr.msc. Меню «Действие», пункт «Экспортировать список…».
odbcad32.exe
12) Кнопка «Справка», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Просмотр HTML-кода», в появившемся окне Блокнота выбрать в меню «Файл», пункт «Открыть».
13) Кнопка «Справка», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Печать», в появившемся окне «Найти принтер…», в окне поиска выбрать меню «Файл», пункт «Сохранить условия поиска».
14) Выбрать вкладку «Трассировка», кнопка «Обор…»
15) Выбрать вкладку «Трассировка», кнопка «Выбор DLL…»
perfmon.exe
16) В списке слева выбрать группу «Отчеты», в ней «Особые», в контекстном меню выбрать пункт «Экспортировать список…».
17) Меню «Справка», пункт «Вызов справки», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Просмотр HTML-кода», в появившемся окне Блокнота выбрать в меню «Файл», пункт «Открыть».
18) Меню «Справка», пункт «Вызов справки», в появившемся окне справки вызвать контекстное меню в рабочей области, выбрать «Печать», в появившемся окне «Найти принтер…», в окне поиска выбрать меню «Файл», пункт «Сохранить условия поиска».
Хоть мы и получили консоль администратора с правами администратора, но назвать это уязвимостью или эксплоитом сложно — нужны осознанные действия пользователя. Чтобы данную уязвимость считать практической, а не теоретической — нужно автоматизировать действия.
UIPI bypass
Автоматизация? Да легко! Берем AutoIt и быстро клепаем приложение, которое эмулирует нажатие клавиатуры.
Все оказывается довольно просто — Майкрософт использует технологию UIPI (User Interface Privilege Isolation). Если коротко, то многие интерфейсные взаимодействия блокируются, если Integrity Level (IL) инициатора ниже, чем у целевого приложения. Процессы с привилегиями администратора имеют High IL и выше, а приложение, запускаемое пользователем без поднятия привилегий, имеет Medium IL. Нельзя слать большинство сообщений, эмулировать мышь, клавиатуру.
Как же обойти UIPI? Майкрософт указывает, что есть еще один интересный параметр, который можно указать в манифесте — UIAccess. При выполнении ряда суровых условий приложение получит возможность взаимодействовать с интерфейсом других программ. Собственно, сами условия:
Появляется идея попробовать скопировать Osk.exe куда-то, где он все еще будет считаться расположенным по «безопасному» пути. Тогда мы сможем контролировать это приложение, но все равно выполнять условия для обхода UIPI.
Я написал простой поисковик по директориям C:\Windows, C:\Program Files, C:\Program Files (x86), который бы искал места, куда можно копировать без прав администратора. На удивление, таких директорий нашлось немало. К сожалению, большая часть из них либо входит в исключения C:\Windows, либо является директориями, куда можно писать, но откуда нельзя запускать приложения. И все равно, нашлось две подходящих папки:
А вот вторая папка уже лучше — за исключением того, что она появляется при установке Microsoft Visual Studio (2017 в данном случае, у других студий будут другие числа вместо 130, например 120 у MSVS 2015).
Копируем osk.exe в папку C:\Program Files\Microsoft SQL Server\130\Shared\ErrorDumps. Смотрим таблицу импорта приложения. Среди библиотек в импорте я выбрал osksupport.dll — это библиотека, экспортирующая всего 2 функции, поэтому можно быстро сделать поддельную.
Собираем dll и копируем по тому же пути — будет dll-инъекция. Запускаем, проверяем — скопированный osk.exe запускается с High IL, код из dll исполняется.
Дописываем в dll автоматизацию клавиатурных нажатий (уже не AutoIt, а быстро все перекинутое на плюсовый код keybd_event). Убеждаемся, что все работает. Теперь у нас уже почти готов эксплоит. Надо провести чистый тест.
Подготавливается виртуальная машина, куда установлена только Visual Studio и пишется простая программа — она копирует osk.exe и библиотеку с полезной нагрузкой. Все отлично работает. Запускаем бинарный файл и спустя мгновение на экране творится магия автоматизации.
Вот это уже можно назвать эксплоитом — все-таки программа без участия пользователя обходит UAC. Пользователь, конечно, все это видит, но не беда — это мелочи.
Это была первая версия эксплоита — две эскалации (autoElevate и UIAccess), но пользователь видит, что происходит что-то не то.
Я отправился перечитывать Windows Internals Руссиновича в тех главах, где упоминается UIAccess и UIPI. Внезапно, русским по белому там было написано, что UIPI предотвращает использование SetWindowsHookEx. Но я как раз обошел UIPI, а значит мог использовать эту функцию — так стало еще лучше! Я смог провести инъекцию кода, вместо отправки клавиатурных нажатий. Вот и вторая версия эксплоита — те же эскалации, но теперь без заметных действий на экране. Почти сразу после запуска эксплоита запускалась привилегированная консоль.
Directory bypass
На этом этапе я написал письмо с описанием уязвимости, кодом эксплоита и пошаговым объяснением в Майкрософт. Реакция саппорта немного удивила — они спрашивали: «Получается, что для запуска вашего эксплоита нужны права администратора?». Попытка объяснить, что это не эскалация привилегий с пользователя до администратора, а обход UAC, успехом не увенчалась.
Последнее, что можно было улучшить — убрать требование директории, доступной на запись. Для начала я решил попробовать старый способ с WUSA.
Сначала я попробовал «распаковать» произвольный файл в C:\windows\system32. Получил ошибку отказа в доступе. Логично, я давно читал, что вроде бы этот способ убрали. Но на всякий случай решил проверить с путем в Program Files. Утилита отработала, файл скопировался. Вот теперь запахло жареным — необходимость папки с правами на запись в Program Files постепенно пропадала.
Но от способа с WUSA я решил отказаться. В Windows 10 (10147) у приложения убрали опцию /extract. Тем не менее я не унывал. На примере WUSA я понял, что не всегда защита C:\Windows означает защиту C:\Program Files. Кроме WUSA был еще способ копировать файлы без запроса UAC — интерфейс IFileOperation.
Дальше было несложно. Я написал код, использующий этот метод (вот она, третья автоматическая эскалация), и он отлично отработал. Для надежности я взял чистую виртуальную машину с максимальным количеством установленных обновлений последней версии Windows 10 (RS2, 15063). Это было особенно важно, поскольку RS2 как раз исправлял часть обходов UAC. И вся моя цепочка прекрасно отработала на этой версии. Это и есть третья версия эксплоита, с 3 эскалациями, без каких-либо специальных требований.
Техническое описание
Работоспособность эксплоита тестировалась на Windows 8, Windows 8.1 и Windows 10 (RS2, 15063) — техника работает. С вероятностью в 99% будет работать и в младших версиях, начиная с Windows Vista, но потребуются правки (другое имя и таблица экспорта для dll на 2 и 3 шагах). Настройки UAC должны быть выставлены по-умолчанию, и пользователь, от которого происходит запуск инициирующей программы, должен входить в группу администраторов ПК.
Шаг 1. Программа запускается без запроса предоставления привилегий. IL программы Medium, что позволяет сделать инъекцию кода в процесс explorer.exe (например, через SetWindowsHookEx).
Шаг 2. Код, работающий в контексте explorer.exe, инициирует файловую операцию копирования через IFileOperation. Происходит первая автоматическая эскалация привилегий — explorer.exe считается доверенным процессом, поэтому ему позволяется копировать файлы в Program Files без запроса подтверждения UAC. В любую папку в Program Files копируется системный файл osk.exe, изначально расположенный C:\Windows\system32\osk.exe. Рядом копируется библиотека с полезной нагрузкой под именем osksupport.dll.
Шаг 3. Запускается только что скопированный osk.exe. Поскольку выполняются все требования для предоставления UIAccess, то файл имеет High IL — происходит вторая автоматическая эскалация привилегий (поднят только IL, но прав администратора все еще нет). Сразу после старта срабатывается Dll-инъекция и в контексте данного процесса исполняется код из osksupport.dll. Полезная нагрузка этой библиотеки ожидает старта привилегированного процесса, чтобы провести инъекцию кода в него.
Шаг 4. Запускается любой процесс, который автоматически поднимается в правах до администратора (например, многострадальный eventvwr.exe, это третья эскалация). В него происходит инъекция кода. В данный момент код будет исполняться с привилегиями администратора.
Proof of Concept
PoC состоит из двух частей — dll (написана на c++) и exe (написан на c#). Сначала необходимо собрать dll и подключить эту библиотеку как ресурс для кода приложения. Обязательно обратите внимание на комментарии в коде.
Готовый к эксплуатации бинарный файл не выкладывается осознанно. Не менее осознанно исходные коды не выкладываются на гитхаб.