Recent a devenit cunoscut prin o postare pe blog, rezultatele testării instrumentelor pentru identificarea vulnerabilităților nepattchizate și identificați problemele de securitate în imagini izolate ale containerelor Docker.
Testul a arătat că 4 din cele 6 scanere a imaginilor Docker cunoscute aveau vulnerabilități critice ceea ce a permis ca scanerul în sine să fie atacat și codul său executat pe sistem, în unele cazuri (de exemplu, când se folosește Snyk) cu privilegii de root.
Pentru un atac, un atacator trebuie doar să inițieze verificarea Dockerfile sau manifest.json, care include metadate formatate special, sau plasați fișierele Podfile și gradlew în interiorul imaginii.
Am reușit să pregătim prototipuri de exploatare pentru WhiteSource, Snyk, Fossa și sisteme de ancorare.
El paquete Claire, care a fost scris inițial având în vedere securitatea, a arătat cea mai bună securitate.
Nu au fost identificate probleme în pachetul Trivy și, ca urmare, s-a ajuns la concluzia că scanerele de containere Docker ar trebui să fie rulate în medii izolate sau utilizate numai pentru a-și verifica propriile imagini și, de asemenea, să fie atenți atunci când se conectează astfel de instrumente la sisteme automate de integrare continuă.
Aceste scanere fac lucruri complicate și predispuse la erori. Ei au de-a face cu docker, trag straturi/fișiere, interacționează cu managerii de pachete sau analizează diferite formate. Apărarea acestora, în timp ce încercăm să găzduiești toate cazurile de utilizare pentru dezvoltatori, este foarte dificilă. Să vedem cum încearcă și reușesc diferitele instrumente să o facă:
Scorul de dezvăluire responsabilă reflectă opinia mea personală: cred că este important ca furnizorii de software să răspundă la problemele de securitate raportate, să fie sinceri și transparenti cu privire la vulnerabilități, să se asigure că oamenii care își folosesc produsele sunt informați corespunzător pentru a lua decizii. despre actualizare. Acestea includ cele mai importante informații conform cărora o actualizare are modificări relevante pentru securitate, deschiderea unui CVE pentru a urmări și comunica despre problemă și, potențial, notificând clienții. Cred că este deosebit de rezonabil să presupunem acest lucru dacă produsul este despre CVE, oferind informații despre vulnerabilitățile din software. În plus, sunt liniștit de răspunsul rapid, timpii rezonabili de remediere și comunicarea deschisă cu persoana care a raportat atacul.
În FOSSA, Snyk și WhiteSource, vulnerabilitatea a fost legată cu chemarea către un manager de pachete extern pentru a determina dependențe și pentru a vă permite să organizați execuția codului dvs. prin specificarea comenzilor tactile și de sistem în fișierele gradlew și Podfile.
En Snyk și WhiteSource au găsit și o vulnerabilitate, asociată cu comenzile sistemului de lansare al organizației care a analizat Dockerfile (de exemplu, în Snyk prin Dockefile ar putea înlocui utilitarul ls (/bin/ls), cauzat de scaner și în WhiteSurce ar putea înlocui codul prin argumentele sub formă de 'echo' ; atingeți /tmp/hacked_whitesource_pip;=1.0' «).
În Anchore, vulnerabilitatea a fost cauzată de utilizarea utilitarului skopeo pentru a lucra cu imagini docker. Operația s-a redus la adăugarea parametrilor de forma „»os»: «$ (touch hacked_anchore)»’ la fișierul manifest.json, care sunt înlocuiți la apelarea skopeo fără evadare adecvată (numai caracterele «; & < au fost eliminate > ", dar construcția "$ ( ) ").
Același autor a realizat un studiu privind eficiența detectării vulnerabilităților nepetice prin scanere de securitate de containere docker și nivelul de fals pozitive.
Mai mult, autorul susține că mai multe dintre aceste instrumente utilizați direct managerii de pachete pentru a rezolva dependențe. Acest lucru le face deosebit de dificil de apărat. Unii manageri de dependențe au fișiere de configurare care permit includerea codului shell.
Chiar dacă aceste moduri simple sunt gestionate cumva, apelarea acestor manageri de pachete va însemna inevitabil să plătiți bani. Acest lucru, pentru a spune ușor, nu ușurează apărarea aplicației.
Rezultatele testelor pentru 73 de imagini care conțin vulnerabilități cunoscut, precum și o evaluare a eficacității de a determina prezența aplicațiilor tipice în imagini (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), poate fi consultat în cadrul publicaţiei realizate În următorul link.