Podczas skanowania kontenerów Dockera wykryto kilka luk w zabezpieczeniach

zhakowany przez docker

Niedawno stał się znany przez post na blogu, wyniki testów narzędzi do identyfikacji podatności bez poprawki i zidentyfikuj problemy z bezpieczeństwem w izolowanych obrazach kontenerów Docker.

Test wykazał, że 4 z 6 skanerów znane obrazy Dockera miał krytyczne luki Pozwoliło to na zaatakowanie samego skanera i uruchomienie jego kodu w systemie, w niektórych przypadkach (na przykład przy użyciu Snyka) z uprawnieniami roota.

Do ataku atakujący musi tylko zacząć sprawdzać swój plik Dockerfile lub manifest.json, który zawiera specjalnie sformatowane metadane, lub umieść pliki podfile i gradlew wewnątrz obrazu.

Udaje nam się przygotować prototypy exploitów dla systemów WhiteSource, Snyk, Fossa i anchore.

El Paquete Clair, oryginalnie napisane z myślą o bezpieczeństwie, pokazał najlepsze zabezpieczenia.

W pakiecie Trivy nie zidentyfikowano żadnych problemów w rezultacie stwierdzono, że skanery kontenerów Dockera powinny być uruchamiane w środowiskach izolowanych lub używane tylko do weryfikacji własnych obrazów, a także zachować ostrożność przy podłączaniu takich narzędzi do zautomatyzowanych systemów ciągłej integracji.

Te skanery wykonują skomplikowane i podatne na błędy rzeczy. Zajmują się dokerem, wyodrębnianiem warstw / plików, interakcją z menedżerami pakietów lub analizowaniem różnych formatów. Obrona ich, próbując uwzględnić wszystkie przypadki użycia dla programistów, jest bardzo trudna. Zobaczmy, jak różne narzędzia próbują to zrobić:

Odpowiedzialny wynik ujawniania informacji odzwierciedla moją osobistą opinię: uważam, że ważne jest, aby dostawcy oprogramowania byli otwarci na zgłaszane im problemy z bezpieczeństwem, uczciwi i przejrzyście informowali o lukach w zabezpieczeniach, aby mieć pewność, że ludzie używający ich produktów są należycie poinformowani, aby podejmować decyzje dotyczące aktualizacji. Obejmuje to najważniejsze informacje, że aktualizacja zawiera zmiany związane z bezpieczeństwem, otwieranie CVE w celu śledzenia i informowania o problemie oraz potencjalnie powiadamiania klientów. Myślę, że szczególnie rozsądne jest założenie, że produkt dotyczy CVE i zawiera informacje o lukach w oprogramowaniu. Zapewnia mnie także szybka reakcja, rozsądne czasy korekty i otwarta komunikacja z osobą zgłaszającą atak.

W FOSSA, Snyk i WhiteSource luka była powiązana z powołaniem do zewnętrznego menedżera pakietów do określenia zależności i umożliwienia organizacji wykonania kodu przez określenie poleceń dotykowych i systemowych w plikach gradlew i Podfile.

En Snyk i WhiteSource również znaleźli lukę w zabezpieczeniach związaną z poleceniami systemu uruchamiania organizacja, która przeanalizowała plik Dockerfile (na przykład w Snyk za pośrednictwem pliku Dockefile można zastąpić narzędzie ls (/ bin / ls) spowodowane przez skaner, aw WhiteSurce można zamienić kod na argumenty w postaci „echo” ; dotknij /tmp/hacked_whitesource_pip;=1.0 '«).

W Anchore luka została spowodowana użyciem narzędzia skopeo do pracy z obrazami dockera. Operacja została zredukowana do dodania parametrów postaci '»os»: «$ (touch hacked_anchore)»' do pliku manifest.json, które są zastępowane przy wywołaniu skopeo bez odpowiedniego wyjścia (tylko znaki «; & <zostały usunięte > ”, Ale konstrukcja„ $ () ”).

Ten sam autor przeprowadził badanie dotyczące skuteczności wykrywania podatności nie załatany za pomocą skanerów bezpieczeństwa kontenerów dockera i poziom fałszywych alarmów.

Oprócz autora twierdzi, że kilka z tych narzędzi bezpośrednio używaj menedżerów pakietów do rozwiązywania zależności. To sprawia, że ​​są szczególnie trudni do obrony. Niektóre menedżery zależności mają pliki konfiguracyjne, które umożliwiają dołączenie kodu powłoki. 

Nawet jeśli te proste sposoby zostaną w jakiś sposób rozwiązane, dzwonienie do tych menedżerów pakietów będzie nieuchronnie oznaczać wyrzucenie pieniędzy. To, delikatnie mówiąc, nie ułatwia obrony aplikacji.

Wyniki testów 73 obrazów zawierających luki w zabezpieczeniach znany, a także ocena skuteczności określenia obecności typowych aplikacji na obrazach (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), można się skonsultować w ramach wykonanej publikacji W poniższym linku.


Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.