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

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

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

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

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

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

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

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

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

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

ГК «Астра» (ООО «РусБИТех-Астра») — один из лидеров российской 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 к защите.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бинго!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какое-то время пытаюсь бодаться с вендором на тему того, что не согласен со статусом дубля по задаче с исполнением 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 ^[9]. Но у них тоже конец года, так что ждём.

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