Як двійкове секретне сканування допомогло запобігти найгіршій supply chain атаці, яку тільки можна уявити

💡 Усі статті, обговорення, новини про Python — в одному місці. Приєднуйтесь до Python спільноти!

Команда JFrog Security Research нещодавно виявила і повідомила про витік токену доступу з правами адміністратора до репозиторіїв Python, PyPI і Python Software Foundation на GitHub, який стався в публічному контейнері Docker, розміщеному на Docker Hub.

Що було знайдено

Механізм сканування секретів виявив «класичний» токен GitHub в одному з публічних репозиторіїв Docker Hub. Ризик «класичних» токенів GitHub полягає в тому, що, на відміну від більш нових токенів, вони надають однакові дозволи для всіх репозиторіїв, до яких користувач має доступ.

У цьому випадку користувач мав доступ адміністратора до основних репозиторіїв інфраструктури Python, зокрема Python Software Foundation (PSF), PyPI, мову Python і CPython.

Що могло статися

У цьому сценарії можливі різні форми атак на ланцюжок поставок. Однією з таких можливих атак було б приховування шкідливого коду в CPython, який є репозиторієм деяких базових бібліотек, що лежать в основі мови програмування Python і компілюються з коду на мові C.

Зважаючи на популярність Python, вставка шкідливого коду, який зрештою потрапить до дистрибутивів Python, може означати поширення бекдору на десятки мільйонів комп’ютерів по всьому світу.

Іншим можливим сценарієм може бути вставка шкідливого коду в код сховища PyPI, який використовується для керування менеджером пакунків PyPI.

Чому токен був знайдений тільки в бінарному файлі

Токен аутентифікації було знайдено всередині Docker-контейнера, у скомпільованому файлі Python — __pycache__/build.cpython-311.pyc

Однак, та сама функція у відповідному файлі вихідного коду не містила токену.

Схоже, що автор оригіналу:

• ненадовго додав маркер авторизації до свого коду;
• запустив вихідний код (скрипт на Python), який було скомпільовано у двійковий файл .pyc з токеном авторизації;
• видалив маркер авторизації з коду, але не очистив .pyc;
• помістив у докер-образ як чистий вихідний код, так і нечистий .pyc-файл.

Ось порівняння декомпільованого файлу build.cpython-311.pyc з вихідним кодом, який фактично перебував в контейнері Docker.

Відновлено вихідний код з бінарника build.cpython-311.pyc

Фактичний вихідний код відповідного файлу в контейнері Docker

Декомпільований код з кеш-файлу .pyc був схожий на оригінал, але містив заголовок авторизації з дійсним токеном GitHub.

Кілька слів про виявлення секретів

Ось кілька порад щодо роботи з токенами доступу, на які наштовхує цей випадок:

📌 сканування секретів у вихідному коді та навіть текстових файлах просто недостатньо;
📌 варто замінювати токени GitHub старого зразка на нові, для кращої видимості;
📌 ваш токен повинен надавати доступ тільки до тих ресурсів, які потрібні застосунку, що його використовує.