Supply chain attack 👨💻
Недавно попался очень классный ресерч двух багхантеров.
Зачастую, атака на цепочку поставок воспринимается как нечто труднореализуемое и практически недостижимое. Если честно, я и сам с некоторым недоверием относился к таким сценариям. Но эта работа полностью изменила мое представление.
Ссылку приложу в конце поста, а от себя приведу разбор того, что удивило лично меня.
Изначально бросилось в глаза, как ребята подошли к выбору цели. Вместо того, чтобы взяться за основной скоуп большой компании, они предпочли поискать недавно приобретенный бизнес, который еще не успел стать частью основы и жил старыми процессами.
Далее, автор упоминает о том, что уже имеет опыт атак на цепочку поставок. Это лишний раз подтверждает реалистичность данной угрозы.
И, наконец, насколько элегантной и одновременно устрашающей получилась итоговая атака. Предлагаю кратко разобрать основные этапы:
1. Обнаружили в открытых источниках информацию о приобретении бизнеса.
2. Обнаружение зависимостей. Реализовали скрипт на Rust, который построил AST для JS-файлов и далее инвентаризовали зависимости. (Классное решение! Уверен, что есть и open-source, который поможет сделать то же самое. Стоит изучить.)
3. Изучили зависимости, погуглили и нашли открытый DockerHub, из которого подтягиваются образы контейнеров.
4. "Inside, we found the complete proprietary back-end source code."... Блин, серьезно? Образ контейнера, который содержит в себе сразу все исходники?
5. Ну, конечно же и .git оказался здесь. В .git/config был Github Actions Token, который обычно используется для автоматизации некоторых действий в рамках CI/CD. (Для меня модель угроз, которую описывает автор в этот момент, кажется неочевидной, есть что изучить).
6. В обнаруженном package.json есть пакет из npm. Однако, для доступа к npm нужен токен.
7. Изучили слои Docker-образа. (А что так можно было?) В итоге, на одном из уровней был обнаружен токен от npm, а исследовали получили возможность загрузки вредоносной зависимости, которая будет использована при сборке, так как конфиг допускает минорные обновления пакета.
Примечательно (и ребята это отметили), что их действия были абсолютно неуловимы для SOC и команды ИБ. В общем, делюсь.
Меня впечатлила как сама последовательность действий исследователей, так и широкий кругозор, который потребовался на каждом этапе. В конечном счете, удалось собрать крупицы артефактов, которые привели к критической уязвимости.
Hack IT Easy - Explore. Discover. Hack.
Недавно попался очень классный ресерч двух багхантеров.
Зачастую, атака на цепочку поставок воспринимается как нечто труднореализуемое и практически недостижимое. Если честно, я и сам с некоторым недоверием относился к таким сценариям. Но эта работа полностью изменила мое представление.
Ссылку приложу в конце поста, а от себя приведу разбор того, что удивило лично меня.
Изначально бросилось в глаза, как ребята подошли к выбору цели. Вместо того, чтобы взяться за основной скоуп большой компании, они предпочли поискать недавно приобретенный бизнес, который еще не успел стать частью основы и жил старыми процессами.
Далее, автор упоминает о том, что уже имеет опыт атак на цепочку поставок. Это лишний раз подтверждает реалистичность данной угрозы.
И, наконец, насколько элегантной и одновременно устрашающей получилась итоговая атака. Предлагаю кратко разобрать основные этапы:
1. Обнаружили в открытых источниках информацию о приобретении бизнеса.
2. Обнаружение зависимостей. Реализовали скрипт на Rust, который построил AST для JS-файлов и далее инвентаризовали зависимости. (Классное решение! Уверен, что есть и open-source, который поможет сделать то же самое. Стоит изучить.)
3. Изучили зависимости, погуглили и нашли открытый DockerHub, из которого подтягиваются образы контейнеров.
4. "Inside, we found the complete proprietary back-end source code."... Блин, серьезно? Образ контейнера, который содержит в себе сразу все исходники?
5. Ну, конечно же и .git оказался здесь. В .git/config был Github Actions Token, который обычно используется для автоматизации некоторых действий в рамках CI/CD. (Для меня модель угроз, которую описывает автор в этот момент, кажется неочевидной, есть что изучить).
6. В обнаруженном package.json есть пакет из npm. Однако, для доступа к npm нужен токен.
7. Изучили слои Docker-образа. (А что так можно было?) В итоге, на одном из уровней был обнаружен токен от npm, а исследовали получили возможность загрузки вредоносной зависимости, которая будет использована при сборке, так как конфиг допускает минорные обновления пакета.
Примечательно (и ребята это отметили), что их действия были абсолютно неуловимы для SOC и команды ИБ. В общем, делюсь.
Меня впечатлила как сама последовательность действий исследователей, так и широкий кругозор, который потребовался на каждом этапе. В конечном счете, удалось собрать крупицы артефактов, которые привели к критической уязвимости.
Hack IT Easy - Explore. Discover. Hack.
