Здравствуйте, уважаемые читатели моего блога!
Сегодня мы поговорим о конкретном примере, когда в силу обстоятельств приходится изучать работу приложения, используя метод «чёрного ящика».
Хочу отметить, что статья предназначена для ознакомления с одним из методов изучения “черного ящика” (системы, принципы работы которой нам неизвестны). Не стоит использовать полученные здесь знания для отключения системы сканирования контейнеров “навсегда”. Она не просто так придумана. Другое дело, если польза от данного действия превышает потенциальный вред.
Начну, как всегда, издалека. Задача стояла простая – обновить Astra Linux с версии 1.7.5 на 1.7.6.15.
Особенностью обновляемой системы был docker контейнер с gitlab на борту.
Так как обновляемая система была установлена на виртуальной машине Proxmox (Альт Виртуализация 10), особого беспокойства у меня эта задача не вызывала.
Обновил свой сетевой репозиторий, удалив содержимое диска с 1.7.5, и заменил его на 1.7.6.15.
В обновляемой системе открыл консоль и выполнил команды:
apt update
apt install astra-update
astra-update -a -r -T
Система штатно обновилась, и всё бы ничего, но Zabbix сервер подсказал, что после перезагрузки виртуальной машины контейнер с gitlab не стартовал.
«Хм, может запрет исполняемого бита появился после обновления (ранее с ним и gitlab уже были проблемы)?» – подумал я. Но нет. Посмотрев статус контейнера, увидел, что он не запущен.
А в журнале увидел, почему (выдержка из журнала не моя, но суть та же).
'/var/lib/docker/overlay2/1471fddc5e59346d1a7700eecf622048521b268d0ac0880b4c4b684a6e6885df/diff' contains vulnerabilities!
[{oval:astra:def:998211469985311911975469512480323 true Astra Linux - уязвимость в krb5 }
{oval:astra:def:998132550094159282885445873391171 true Astra Linux - уязвимость в krb5 }
{oval:astra:def:977929060381660241551522261194307 true Astra Linux - уязвимость в krb5 }
{oval:astra:def:4531229522001128947937725208131 true Astra Linux - уязвимость в openssl }
{oval:astra:def:4454479638527608668673748063811 true Astra Linux - уязвимость в curl }
Как стало известно позже, данный инцидент произошёл из-за того, что в очередном обновлении безопасности разработчики добавили сканер уязвимостей (что очень правильно, так как контейнеры Docker могут регулярно не обновляться).
Единственное, в чём я могу их упрекнуть, так это в отсутствии предупреждения при запуске astra-update. Было бы не плохо увидеть что-то типа «ВНИМАНИЕ! В Вашей системе используется docker. В очередном обновлении запускаемые контейнеры автоматически сканируются на известные уязвимости. В случае, если в контейнере будет найдена уязвимость, его запуск будет запрещён!».
Я уверен, что в описании обновления на веб-сайте есть информация о сканере, но всё же.
Разработчики операционной системы предвидели сценарий, когда уязвимые контейнер должен продолжить работу (мало ли, что работает в контейнере).
Для продолжения работы с Docker необходимо выполнить действия, изложенные ниже.
Перейти в каталог /etc/docker и создать файл daemon.json:
cd /etc/docker
sudo mcedit daemon.json
Привести его к виду:
{
"astra-sec-level" : 6
}
Перезапустить службу Docker командой:
sudo systemctl restart docker
Инструкций на эту тему штук 20 в интернете, и создавать очередную я не хочу, ведь цель этой статьи совсем в другом – рассказать, как решить проблему в условиях, когда доступ в сеть «Интернет» невозможен.
Так как моя работа как раз и проходит в таких условиях – мне пришлось разбираться на месте и изучать работу сканера уязвимостей, чтобы временно его отключить.
Что я понял из ситуации:
1) Есть список уязвимостей, уязвимости имеют номера – стало быть, есть какая-то база.
2) Вряд ли база в бинарном файле – это совсем не масштабируется (значит, это текстовый файл).
3) Если уязвимости в базе, то теоретически их можно временно оттуда изъять.
4) Если скинуть хоть 100 рублей донатов, автору будет приятно Ваше внимание.
Приступим! Есть слово oval с номерами уязвимостей. По нему и будем искать.
Начнем поиски с места, которое больше всего подходит для хранения такой базы.
grep -R oval /usr/share
Вывод команды будет следующим:
/usr/share/oval/db.xml:
definition class="vulnerability" id="oval:astra:def:4453547556720541674391973746243" version="1"
Как видим – сразу в яблочко. Файл с базой уязвимостей /usr/share/oval/db.xml. Если с ним ознакомиться, то мы увидим, что база имеет ссылку на OpenSCAP – это ещё что такое?
man -k openscap
apt search openscap
Угу, понятно – система для поиска уязвимостей. Поищем бинарный файл и найдём его в /usr/sbin/oscap.
Но как он работает во взаимодействии с Docker?
Переименуем оригинальный файл.
mv /usr/sbin/oscap{,.bak}
Заменим бинарный файл скриптом-ловушкой, который перехватит параметры запуска и сохранит в файл.
#!/bin/bash
cat $@ > /tmp/result
Теперь заставим Docker запустить уязвимы контейнер ещё раз.
docker start gitlab
Посмотрим в наш файл result и увидим, что делает docker с бинарником oscap перед запуском контейнера.
oscap oval eval --report /usr/share/docker.io/reports/sha256:c3747d47072ba8ee5975dc2c65f5b368c99812a89c430e2e1558baeb10e02dc2_2025-08-28T11:28:59+03:00_13920d9a.html /usr/share/oval/db.xml
Оказывается, он проверяет файлы содержимого контейнера с генерацией отчёта в каталог /usr/share/oval/.
Логично предположить, что далее результаты этого отчёта обрабатываются другой подсистемой.
Таким образом, варианта ровно два, подделать отчёт, либо просто урезать базу сканеру.
Мы выберем второе – так проще.
Делаем резервную копию базы, ведь наша задача временно запустить контейнер и заняться скачиванием свежего образа для того, чтобы устранить уязвимости.
cp /usr/share/oval/db.xml{,.bak}
Редактируем файл базы, удалив информацию об уязвимостях.
Запускаем контейнер. Всё работает.
Если вы любите искать уязвимости в рамках BugBounty, то этот метод изучения «черного ящика» поможет лучше понять принцип работы операционной системы.
Ну а мне он помог быстро оправиться от сюрприза и пойти скачивать свежий образ туда, где есть интернет.
Всем хорошего времени суток и до новых встреч!
