Компания Google представи фреймворк SLSA (Supply-chain Levels for Software Artifacts), в който обобщен е съществуващият опит в защитата на инфраструктурата за разработка от атаки, осъществявани в етапите на писане на код, тестване, компилиране и разпространение на продукта.
Процесите на разработка стават все по-сложни и зависими от външни инструменти, което създава благоприятни условия за атаки, свързани не с открития и експлоатация на уязвимости в крайния продукт, а с компрометиране на самия процес на разработка (атаки „supply chain“, които обикновено са насочени към внедряване на злонамерени промени в процеса на писане на код, подмяна на разпространявани компоненти и зависимости).
Фреймворкът взема предвид 8 вида атаки, свързани с заплахи от внедряване на злонамерени промени в етапа на разработка на код, компилиране, тестване и разпространение на продукта.
- A. Включване в изходния код на промени, съдържащи бекдори или скрити грешки, водещи до уязвимости.
Пример за атака: „Hypocrite Commits“ — опит за внедряване на пачове с уязвимости в ядрото на Linux.
Предлаганият метод за защита: независимо рецензиране на всяка промяна от двама разработчици.
- B. Компрометиране на платформата за управление на изходния код.
Пример за атака: внедряване на злонамерени комити с бекдор в Git репозитория на проекта PHP след изтичане на паролите на разработчиците.
Предлаганият метод за защита: повишаване на защитата на платформата за управление на кода (в случая на PHP, атаката е извършена чрез малко използван HTTPS интерфейс, който допускаше изпращане на промени при влизане с парола без проверка на SSH ключа, като за хеширане на паролите е използван ненадеждният MD5).
- C. Внасяне на промени в етапа на предаване на кода на системата за компилиране или непрекъсната интеграция (компилира се код, който не отговаря на кода от репозитория).
Пример за атака: внедряване на бекдор в Webmin чрез промени в изградната инфраструктура, довели до използването на файлове с код, различаващи се от файловете в репозитория.
Предлаганият метод за защита: проверка на целостта и идентификация на източника на получавания код на изградната система. сървър.
- D. Компрометиране на платформата за компилиране.
Пример на нападение: нападението SolarWinds, при което по време на етапа на изграждане е осигурено внедряването на бекдор в продукта SolarWinds Orion.
Предложен метод за защита: внедряване на разширени мерки за сигурност на платформата за изграждане.
- E. Разпространение на злонамерен код чрез некачествени зависимости.
Пример на нападение: внедряване на бекдор в популярната библиотеки event-stream чрез добавяне на безобидна зависимост, с последващо включване на злонамерен код в едно от обновленията на тази зависимост (злонамереното изменение не е отразено в git-репозитория, а присъства само в готовия MNP пакет).
Предложен метод за защита: рекурсивно приложение на изискванията SLSA за всички зависимости (в случая с event-stream проверката би разкрила изграждането на код, несъответстващ на съдържанието на основния Git репозиторий).
- F. Изтегляне на артефакти, които не са създадени в CI/CD системата.
Пример на нападение: добавяне на злонамерен код в скрипта CodeCov, което позволява на нападателите да извлекат информация, съхранявана в средите на клиентските системи за непрекъсната интеграция.
Предложен метод за защита: контрол над източника и целостта на артефактите (в случая с CodeCov би могло да бъде установено, че скриптът Bash Uploader, предоставен от сайта codecov.io, не отговаря на кода от репозитория на проекта).
- G. Компрометиране на репозиториите на пакети.
Пример на нападение: изследователите успяха да създадат огледала на някои популярни репозитории на пакети с цел разпространение на злонамерени пакети чрез тях.
Предложен метод за защита: Проверка, че разпространяваните артефакти са събрани от обявените изходни текстове.
- H. Сбъркване на потребителя да инсталира неправилен пакет.
Пример на нападение: използване на типсквотинг (NPM, RubyGems, PyPI) за публикуване в репозиторите на пакети, които изглеждат подобно на популярни приложения (напр. coffe-script вместо coffee-script).
За блокиране на отбелязаните заплахи SLSA предлага набор от препоръки, както и инструменти за автоматизация на създаването на метаданни за одит. SLSA обобщава типичните методи на атаки и въвежда понятието нива на защита. Всяко ниво поставя определени изисквания към инфраструктурата, които гарантират целостта на артефактите, използвани при разработката. Колкото по-високо е поддържаното ниво на SLSA, толкова повече средства за защита са внедрени и толкова по-добре е инфраструктурата защитена от типични атаки.
- SLSA 1 — изисква сборния процес да бъде изцяло автоматизиран и да генерира метаданни („provenance“) относно това как артефактите са събрани, включително информация за изходния код, зависимости и процеса на събиране (за GitHub Actions е предложен пример за генератор на метаданни за одит). SLSA 1 не включва елементи на защита от въвеждане на злонамерени изменения, а само идентифицира кода по най-простия начин и предоставя метаданни за управление на уязвимостите и анализ на рисковете.
- SLSA 2 — разширява първото ниво с изискването за използване на система за управление на версии и сборни услуги, генериращи автентифицирани метаданни. Приложението на SLSA 2 позволява проследяване на произхода на кода и предотвратява въвеждането на несанкционирани изменения в кода, при условие че се прилагат надеждни сборни услуги.
- SLSA 3 — потвърдил, че изходните кодове и сборната платформа отговарят на изискванията на стандартите, гарантиращи възможността за провеждане на одит на кода и осигуряване на целостта на предоставените метаданни. Предполага се, че одиторите могат да сертифицират платформите по отношение на съответствието с изискванията на стандартите.
- SLSA 4 — най-високо ниво, допълващо предишните нива с следните изисквания:
- Задължително преглеждане на всички промени от двама различни разработчици.
- Всички стъпки на събиране, код и зависимости трябва да бъдат напълно декларирани, всички зависимости трябва да бъдат отделно извлечени и проверени, а процесът на събиране трябва да се извършва без достъп до мрежата.
- Прилагане на процеса на повторяемо събиране — възможност да се повтори процесът на събиране самостоятелно и да се уверите, че изпълнимият файл е събран от предоставените изходни кодове.
Източник: opennet.ru
