Наскоро стана известно чрез публикация в блог, резултатите от инструментите за тестване за идентифициране на уязвимости без корекция и идентифициране на проблеми със сигурността в изолирани изображения на контейнер на Docker.
Тестът показа, че 4 от 6 скенера известни изображения на Docker имаше критични уязвимости което позволяваше да атакува самия скенер и да стартира неговия код в системата, в някои случаи (използвайки например Snyk) с root права.
За атака, нападателят просто трябва да започне да проверява своя Dockerfile или manifest.json, който включва специално форматирани метаданни, или поставете файловете podfile и gradlew вътре в изображението.
Успяваме да подготвим експлойт прототипи за WhiteSource, Snyk, Fossa и анкерни системи.
пакет Клер, първоначално написано с мисъл за безопасност, показа най-добрата сигурност.
Няма проблеми, идентифицирани в пакета Trivy и в резултат се стигна до заключението, че скенерите за контейнери на Docker трябва да се изпълняват в изолирана среда или да се използват само за проверка на собствените им изображения, а също така да бъдат внимателни при свързването на такива инструменти към автоматизирани системи за непрекъсната интеграция.
Тези скенери правят сложни и предразположени към грешки неща. Те се занимават с докера, извличат слоеве / файлове, взаимодействат с мениджъри на пакети или анализират различни формати. Защитата им, въпреки че се опитва да приспособи всички случаи на употреба за разработчиците, е много трудна. Нека да видим как различните инструменти се опитват и успяват да го направят:
Резултатът за отговорно разкриване отразява личното ми мнение: Мисля, че е важно доставчиците на софтуер да реагират на съобщените им проблеми със сигурността, да бъдат честни и прозрачни относно уязвимостите, за да се уверят, че хората, които използват техните продукти са правилно информирани да вземат решения относно актуализацията. Това включва най-важната информация, че актуализацията има промени, свързани със сигурността, отваряне на CVE за проследяване и комуникация за проблема и потенциално уведомяване на вашите клиенти. Мисля, че това е особено разумно да се предположи, ако продуктът е за CVE, предоставящ информация за уязвимости в софтуера. Също така съм успокоен от бързата реакция, разумно време за корекция и отворената комуникация с лицето, съобщаващо за нападението.
Във FOSSA, Snyk и WhiteSource уязвимостта е свързана с обаждане към външен мениджър на пакети за да определите зависимостите и да ви позволи да организирате изпълнението на вашия код, като посочите командите за докосване и системата във файловете gradlew и Podfile.
En Snyk и WhiteSource също откриха уязвимост, свързана с командите на системата за стартиране организация, която анализира Dockerfile (например в Snyk чрез Dockefile можете да замените помощната програма ls (/ bin / ls), причинена от скенера, а в WhiteSurce можете да замените кода чрез аргументите под формата на "ехо" ; докоснете /tmp/hacked_whitesource_pip;=1.0 '«).
В Anchore уязвимостта е причинена от използването на помощната програма skopeo за работа с изображения на докер. Операцията беше сведена до добавяне на параметри на формата '»os»: «$ (touch hacked_anchore)»' към файла manifest.json, които се заменят при извикване на skopeo без подходящо екраниране (само символите «; & <бяха премахнати > ", Но конструкцията" $ () ").
Същият автор проведе проучване за ефективността на откриването на уязвимост не се закърпва чрез скенери за сигурност на докер контейнерите и нивото на фалшивите положителни резултати.
Освен автора твърди, че няколко от тези инструменти използвайте директно мениджъри на пакети за разрешаване на зависимости. Това ги прави особено трудни за защита. Някои мениджъри на зависимости имат конфигурационни файлове, които позволяват включването на черупков код.
Дори ако тези прости начини се справят по някакъв начин, извикването на тези мениджъри на пакети неизбежно ще означава изхвърляне на пари. Това, меко казано, не улеснява защитата на жалбата.
Резултати от теста на 73 изображения, съдържащи уязвимости известен, както и оценка на ефективността за определяне на присъствието на типични приложения в изображения (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), може да се консултира в рамките на направената публикация В следващия линк.