БагБаунти с АстраЛинус или то, что нужно знать о защищённости защищённой ОС

Хочу поделиться своим опытом участия в программе баг-хантинга ГК Астра (да, да - именно той, которая недавно совершила каминг‑аут IPO) на платформе BI.ZONE Bug Bounty.

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

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

• представленная информация является личным мнением автора

• представленная информация служит целям информирования профессионального сообщества о деталях (моего) участия в программе

• представленная информация ни в коей мере НЕ служит целям дискредитации кого-либо и чего-либо

• представленная информация не содержит иных технических подробностей обнаруженных дефектов кроме тех, которые доступны (или были доступны) в описании публичных условий Программы ГК Астра, опубликованных на платформе BI.ZONE Bug Bounty.

Краткое описание программы

Итак, начну я с само-презентации ГК Астра в Программе:

ГК «Астра» (ООО «РусБИТех-Астра») — один из лидеров российской IT-индустрии, ведущий производитель программного обеспечения, в том числе защищенных операционных систем и платформ виртуализации. Разработка флагманского продукта, ОС семейства Astra Linux , ведется с 2008 года. На сегодня в штате компании более 1000 высококвалифицированных разработчиков и специалистов технической поддержки.

Интригующее начало. Разработка ОС ведётся с 2008 года, а штате компании трудится более 1000 высококвалифицированных разработчиков. Закрадывается первое сомнение: а стоит ли вообще пытаться? Ведь, скажем так, условная "убунта" разрабатывается не сильно больше (да, да - дериватив). И что получается, нам, исследователям, вот так вот просто и незатейливо предлагают "взломать" за копейки production-grade операционную систему?..

Но нет, в условиях Программы написано следующее:

Данная программа не является типичной с точки зрения поиска уязвимостей. Мы заинтересованы в поиске недостатков в механизмах защиты нашего ключевого продукта - операционной системы специального назначения «Astra Linux Special Edition» (ОС СН «Astra Linux SE»), эксплуатация которых может привести к наступлению недопустимых событий для наших Заказчиков. Перечень таких событий указан в блоке «Перечень задач» площадки (далее — недопустимые события).

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

Механизмы защиты ОС СН «Astra Linux SE» для тестирования:

• Мандатное управление доступом (МРД);

• Замкнутая программная среда (ЗПС).

... и далее, список недопустимых событий:

Далее немного сказано про условия оформления отчётов, условия признания отчётов дублями (принцип: кто первый встал, того и тапки), условия использования публичных CVE в качестве дефектов и, что интересно, отдельно упомянута возможность рассмотрения отчётов, связанных с использованием скрытых каналов:

Отчеты, связанные с реализацией уязвимостей через скрытые каналы (в соответствии с ГОСТ Р 53113.1-2008) могут быть рассмотрены в случае успешной реализации недопустимого события и высокой скорости канала.

Вилки выплат на старте программы составляли 150-250 тысяч рублей, что выглядит вполне вменяемо, в сравнении с другими программами.

Лиха беда - начало!

Накатив виртуалку с ОС СН Astra Linux SE (уровень защищенности: максимальный), любезно предоставленную ГК Астра, начинаю своё путешествие в Мир Защищённых Операционных Систем.

Будучи уверенным пользователем Linux, не составило труда залогиниться и запустить консоль. Читать документацию и разбираться в том, чего там наворотили особого желания у меня не было, поэтому решено было попытать счастье в поиске т.н. low-hanging fruits, то есть тех вещей, которые можно сравнительно быстро и без особых затрат найти. Под затратами мной понималось время, требуемое на анализ механизмов защиты путём изучения документации а также реверсинга соответствующих программных компонентов.

Анализ и пролистывание перечня недопустимых событий (задач) из Программы подсказывал, что стоит попробовать атаковать компонент ЗПС (в тот момент я ещё не знал про него ничего). Поэтому, первым реализованным мной событием стало исполнение shell-кода, что и было зафиксировано в трекере:

ДАТА: 11:40 PM 10/6/2023

ОТЧЁТ: Выполнение произвольного shell-кода с использованием доверенного процесса

ЗАДАЧА: Исполнение произвольного shell-кода с использованием системного и прикладного ПО, обладающего корректной подписью

Изи-пизи-лемон-сквизи! Потирая влажные ладошки, я попутно реализовал две разновидности данной атаки используя тот же самый вектор и также отправил отчёт вендору.

Мандаточка и скрытый канальчег

Исполнение шелл-кода было на столько тривиальным в исполнении, что я решил сместить фокус с ЗПС на МРД, о работе которого я также ничего не знал. Ну кроме того, что М в данной аббревиатуре соответствует прилагательному мандатный.

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

Скрытый канал. Почему же его упомянули отдельно? Очевидно, что есть какие-то требования к супер-защищённым системам (коей без сомнения является ОС СН Astra Linux SE) по части сертификации, а все мы знаем что сертификат даёт как минимум +100 к защите.

Мозг начал работать по теме раскрутки скрытого канала. А что - это вариант. Вон, они сами даже об этом пишут:

Отчеты, связанные с реализацией уязвимостей через скрытые каналы (в соответствии с ГОСТ Р 53113.1-2008) могут быть рассмотрены в случае успешной реализации недопустимого события и высокой скорости канала.

Помню, уже смеркалось. Руки дописывали код на perl-е, реализующий передачу файла с уровня конфиденциальности 1 на уровень конфиденциальности 0, то есть "вниз". Выходило достаточно быстро и надёжно, с возможностью "оптимизации" скорости, чему я был несомненно рад. В тот момент казалось: вот оно, счастье исследователя-первооткрывателя!

Описав проблему, приложив соответствующие скрипты и даже видео я с гордостью отправил свой отчёт, связанный с работой компонента МРД, о деталях работы которого я так ничего и не узнал:

ДАТА: 04:23 AM 10/11/2023

ОТЧЁТ: Нарушение принципа разграничения конфиденциальности с использованием скрытого канала

ЗАДАЧА: Изменение пользователем User уровня конфиденциальности защищаемого объекта доступа (флага)

Новое - забытое старое!

Побороть прокрастинацию не так просто. Однако, мне не давала покоя одна мысль:

Что же это ты такое - ЗПС, кто тебя сделал и как с-ка ты работаешь?

Итак, возвращаюсь к анализу ЗПС. Хочу реализовать исполнение неподписанного ELF-файла, т.к. на тот момент казалось, что эта задача выглядит более чем достойно.

Начинаю разбираться как же реализован этот механизм и через некоторое время выясняю следующее:

• ЗПС реализован в ядре

• ЗПС реализован на базе проекта digsig

Свежие исходники проекта digsig мне найти не удалось. Как оказалось, его развитие прекратилось 19 (!) лет назад. Не вопрос, по крайней мере не нужно реверсить (всё же пришлось).

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

... В то прекрасное утро я проснулся чуть раньше обычного, в районе 11 утра. Задача анализа вышла из фонового режима и дала мне вожделенный вектор, реализовать который не составило труда. И действительно, для исполнения неподписанного ELF-файла на защищённой ОС СН Astra Linux SE требовалось выполнить в консоли 3 команды!

ДАТА: 12:37 AM 10/16/2023

ОТЧЁТ: Запуск неподписанного elf-файла

ЗАДАЧА: Непосредственный запуск непривилегированным пользователем неподписанного (обладающего некорректной подписью) исполняемого файла формата ELF

Бинго!

Немного о том, как работает мозг

Фоновые задачи мозга - штука интересная. Казалось бы, цель достигнута, Халас, расходимся. Но нет, где-то там внутри идёт процесс...

И вот, в какой-то момент, приходит новая идея - новый вектор атаки на ЗПС, а именно становится понятно, что у digsig образца 2006 года есть ещё один дефект, позволяющий вызвать отказ в обслуживании. О чудо, такое событие также является одним из недопустимых!

ДАТА: 01:55 AM 10/20/2023

ОТЧЁТ: Отказ в обслуживании, вызванный [skip]

ЗАДАЧА: Реализация деструктивного воздействия со стороны непривилегированного пользователя, приводящего к невозможности запуска исполняемого файла формата ELF и/или использованию разделяемой библиотеки, обладающих корректной подписью

Реакция вендора. Начало.

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

В другом комментарии любезно была предоставлена ссылка на отчёт, в котором в переписке с исследователем сотрудниками ГК Астра была проведена гениальная по своей сути спецоперация:

Сославшись на то, что о данной проблеме в ГК Астра в общем-то известно, приложив в качестве пруфов скрины с отчётами с внутреннего трекера (JIRA), сотрудники ГК Астра аккуратно убедили человека в том, что выплаты в 150-250тр ему не положено. Но дабы, так сказать, поощрить первопроходца, волевым решением всё-таки заплатили ему копеечку.

Ну собственно, @drakylar остался этому рад, т.к. в реальности вектор атаки механизма защиты этой защищённой системы представлял собой 3 простых команды.

Мне же не оставалось ничего другого, как смиренно согласиться. Братишка, @drakylar, можно я буду считать, что из нас двоих я "пришёл вторым", а ты - "предпоследним"?

Реакция вендора. Становится интересно.

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

Добрый день! Представленный вектор атаки относится к классу скрытых информационных каналов по времени, для которого характерна необходимость кооперации между пользователями, имеющими, соответственно, высокий и низкий уровень доступа к конфиденциальной информации, с целью синхронизации их действий при передаче защищаемой информации, а также возможность передачи такой информации только малыми частями с течением времени, модулируя ее на некоторый изменяющийся во времени процесс ([snip]). В рамках программы исследований в качестве недопустимых событий приведены нарушения МРД, связанные с организацией запрещенных информационных потоков по памяти, когда пользователь, обладающий низким уровнем конфиденциальности, может получить непосредственный доступ к секретной информации. Таким образом, предложенный Вами вектор атаки не в полной мере соответствует заявленным НС, а уровень опасности продемонстрированной уязвимости не столь велика в связи с ограничениями, накладываемыми необходимостью кооперации между пользователями. Вместе с тем, мы признаем факт возможности реализации скрытого информационного канала по времени предложенным Вами способом, запланируем работы по его устранению и готовы выплатить Вам вознаграждение в размере 10 000 рублей. Если обоснование данной суммы у Вас не вызывает сомнений, прошу ответить в комментарии для перевода отчета в статус "Уязвимость подтверждена" и назначения размера вознаграждения.

Как видно из данного комментария, сотрудники ГК Астра признали наличие скрытого канала, однако при оценке работы воспользовались своей (расширенной) трактовкой условий Программы. Лёгким движением руки 150-250тр превратились в тыкву.

Реакция вендора. Первый!

Задача исполнения неподписанного ELF-файла в три команды имела шансы быть дублем, но в этот раз я оказался первым! Однако, вендор определил её ценность по минимальной границе предложив за неё лишь 150000 рублей.

Разумеется, я попытался уточнить, почему же не было выплачено 250тр? Однако, мне было сообщено что ранее схожую атаку произвёл другой исследователь:

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

Ну и на том спасибо. Выплата через платформу прошла без проблем.

Реакция вендора. Обновление виртуалки.

Тем временем, ГК Астра вносит обновление в условия Программы, а именно обновляет образ виртуальной машины публично отмечая при этом, что изменения коснулись следующего:

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

Очевидно, что вал однотипных отчётов заставил организаторов программы включить дополнительные механизмы защиты. Интересно, а на что они рассчитывали с самого начала?

У меня ушло больше времени на то, чтобы скачать обновлённую виртуалку, нежели реализовать исполнение шелл-кода с обходом ЗПС, включая вновь добавленные "дополнительные" защитные механизмы:

ДАТА: 11:53 PM 10/17/2023

ОТЧЁТ: Обход блокировки интерпретаторов и запуск shell-кода

ЗАДАЧА: Исполнение произвольного shell-кода с использованием системного и прикладного ПО, обладающего корректной подписью

Реакция вендора. 4 минуты 33 секунды.

С этого момента начинается интересное.

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

Набираюсь наглости и нахожу сперва в гугле, затем в Телеграмм Романа Мылицына. В его bio указано: "Astra Linux, руководитель направления перспективных исследований". Кажется, то, что нужно. Кроме того, он есть на хабре: @cogniter.

Туда-сюда, выясняю:

Через какое-то время снова интересуюсь, как обстоят дела. Роман отмечает что на "на задержку триажа по вашим репортам повлияла повышенная загруженность специалистов, ответственных за багбаунти в связи с окончанием года", благодарит за то, что я написал о проблеме и обещает сегодня проставить статусы.

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

• отчет по атаке типа отказ в обслуживании на ЗПС - принят и подтвержден

• исполнение шелл-кода с обходом дополнительных механизмов защиты - дубль

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

Реакция вендора. Рыба!

Какое-то время пытаюсь бодаться с вендором на тему того, что не согласен со статусом дубля по задаче с исполнением shell-кода при новых вводных, а именно - включённых дополнительных механизмах защиты, но в итоге получаю комментарий, который говорит сам за себя:

Заключение

В данной статье я описал свой первый опыт участия в баг-баунти программах, а именно в баг-баунти программе ГК Астра, проводимой на платформе BI.ZONE BugBounty.

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

• выполнение произвольного shell-кода в контексте доверенного процесса - дубль

• выполнение произвольного shell-кода в контексте доверенного процесса (при включённых дополнительных механизмах защиты) - дубль (не согласен)

• запуск неподписанного ELF-файла - выплата 150000р

• отказ в обслуживании ЗПС - проводится оценка

• выявлен скрытый канал, реализована передача конфиденциальных данных в обход механизмов защиты - выплата 10000р (отказался)

Реализованные мной недопустимые события показали, что базовые механизмы защиты ОС СН Astra Linux SE содержат дефекты, эксплуатация которых может привести к трагическим последствиям, ведь данная ОС является сертифицированной, а значит примеряется в тех местах, где вопросам защиты информации и информационной безопасности отводится важнейшая роль.

Особо стоит отметить механизм ЗПС, который фактически был заимствован из публичных источников (проект digsig) и не претерпел существенных изменений, по крайней мере в части защищённости, аж с 2006 года (!!!111).

То есть ещё раз. Базовый механизм защиты - замкнутая программная среда - взят из Интернета в 2006 году и с того времени функционально не изменился и более того, кажется что аудит безопасности данного компонента вовсе не проводился! Хотя, может и проводился, кто его знает...

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

Отдельно хочу отметить "оперативность", с которой сотрудники ГК Астра реагируют на отчёты. Ну оно понятно - конец года, IPO, котировки, стаканы. Да, кстати, акции Астры (ASTR) на момент публикации торгуются по цене 517,00.

Что касается самой платформы BI.ZONE BugBounty. В целом не могу выделить ничего особенного. Реализован минимально необходимый функционал, нет поддержки мобильников (Responsible Design - не, не слыхали), кое-где тупит редактор markdown. Выплаты через платформу проходят безболезненно.

Касательно спорных моментов свои вопросы я задал сотрудникам BI.ZONE BugBounty через чат в Телеграмм @BizoneBugBountySupport. Но у них тоже конец года, так что ждём.

Всем добра, иншАлла, машАлла, альхамдуЛилля, по милости Аллаха.