W

procesie budowy obrazów kontenerów wykorzystywanych do uruchamiania aplikacji lub serwerów najbardziej czasochłonną częścią jest instalacja zależności w postaci paczek systemowych. Proces ten jest z reguły powolny, ponieważ menedżery pakietów są stworzone w taki sposób, aby przedkładać stabilność instalacji nad jej wydajnością. I to ma sens: jeśli podczas instalacji wydarzy się niezapowiedziana awaria zasilania lub zawieszenie procesu, system musi pozostać w stanie nadającym się do użytku. Jednak w przypadku budowania obrazów kontenerów stabilność nie stanowi priorytetu. Jeśli proces instalacji pakietów lub kompilacji źródeł się nie powiedzie – system budujący obraz go odrzuci, zakończy proces błędem i będziemy musieli zacząć od nowa. Dlatego gdybyśmy mogli zasugerować menedżerowi pakietów, że nie przejmujemy się zbytnio integralnością danych, moglibyśmy przyspieszyć nasze kompilacje.
[ czytaj całość… ]

P

rzesiąkanie płynu z małych naczyń krwionośnych do otaczających tkanek wymaga natychmiastowego leczenia, aby zapobiec spadkowi ciśnienia krwi i innym poważnym powikłaniom. Identycznie jest w przypadku zespołu podatności o nazwie Leaky Vessels, które wykryto w środowisku wykonawczym kontenerów, w szczególności runC (CVE-2024-21626) oraz w BuildKit (CVE-2024-23651, CVE-2024-23652 i CVE-2024-23653) używanym przez takie projekty jak: Docker, Kubernetes i inne platformy konteneryzacji. Luki te umożliwiają ucieczkę z kontenera, a osobie atakującej, która posiada dostęp do takiego kontenera, wykonanie dowolnego kodu na maszynie hosta, narażając w ten sposób cały system.
[ czytaj całość… ]

alias containerstorm='docker stop $(docker ps -aq) && docker rm $(docker ps -aq) && docker rmi $(docker images -q)'

W

yobraźmy sobie następujący scenariusz. Wyciekł klucz SSH umożliwiający zalogowanie się do zwykłego konta platformy wdrożeniowej. Był on używany do wdrażania i aktualizacji repozytoriów za pomocą ansible. Umożliwia on zalogowanie się na powłokę systemową grupy serwerów, na której są budowane i uruchamiane kontenery Docker. Samo konto nie posiada żadnych dodatkowych uprawnień ani grup. Zastanówmy się teraz w jaki sposób możemy dokonać eskalacji uprawnień wykorzystując jedną z przestrzeni nazw (ang. namespace) kontenera Docker oraz rozszerzonej zdolności Linuksa (ang. capabilities).
[ czytaj całość… ]

S

erwis NewsBlur 3 godziny po zakończeniu migracji swojej infrastruktury MongoDB na kontenery Docker doświadczył usunięcia danych. Otóż sam serwer miał włączoną zaporę sieciową UFW (ang. Uncomplicated Firewall) z ścisłą listą dozwolonych adresów IP. Co takiego się stało? Otóż okazało się, że decydując się na publikację portu MongoDB na kontenerze – Docker w standardzie robi swoją sztuczkę (znaną od 2014 roku) pod postacią dziury w zaporze otwierając dany port (tutaj: 27017) na świat. Proces ten jest opisany w dokumentacji:

This creates a firewall rule which maps a container port to a port on the Docker host to the outside world.

Wielu użytkowników jest zdziwiona takim zachowaniem – spodziewając się raczej odwrotnej polityki: świadomego włączenia funkcji otwierania portów niż konieczności ich wyłączenia (--iptables=false), czy potrzebę definiowania reguł iptables na poziomie łańcucha mangle, a nie filter. Oczywiście cała ta sytuacja nie tłumaczy uruchomienia niezabezpieczonej bazy NoSQL w kontenerze.

Więcej informacji: How a Docker footgun led to a vandal deleting NewsBlur’s MongoDB database, Docker Network bypasses Firewall, no option to disable

W

pierwszej części poznaliśmy możliwości zaatakowania niezabezpieczonych API REST daemonów Docker. W tej części dokończymy kilka aspektów powiązanych z poprzednimi metodami. Po pierwsze nie musimy wykonywać wszystkich poleceń za pomocą stricte żądań HTTP – były one wykonane, aby przekazać Czytelnikowi widzę, jak to wygląda z niższego poziomu. Docker posiada własną wersję klienta przeznaczoną do takiej komunikacji. Dlaczego jeśli wskażemy mu zdalny host możemy wydawać wszystkie polecenia za pomocą lokalnego klienta.
[ czytaj całość… ]

D

ocker jako jedno z rozwiązań dla tworzenia kontenerów zyskał ogromną popularność w ciągu kilku ostatnich lat i stał się nowym sposobem pakowania, dostarczania i wdrażania aplikacji. Niestety, jeśli dana technologia się szybko rozwija i jest szeroko adoptowana przez społeczność, staje się również cennym celem dla adwersarzy. Na początku pojawiły się złośliwe obrazy. Były one umieszczane w publicznych rejestrach. Jeśli użytkownik sam lub za namową cyberprzestępcy skłonił się do skorzystania z takiego obrazu w rzeczywistości pobierał i wykonywał złośliwe ładunki (np. koparki kryptowalut), umożliwiał wejście przez tylną furtkę (ang. backdoor), przeszukiwanie logów dla poufnych informacji, czy dostęp do systemu plików hosta z kontenera.
[ czytaj całość… ]

P

oważna luka w zabezpieczeniach została odkryta w głównym kodzie kontenera – runC, która wpływa na kilka systemów open source do zarządzania kontenerami. Umożliwia ona atakującemu potencjalną ucieczkę z kontenera systemu Linux i uzyskanie nieautoryzowanego dostępu na poziomie administratora systemu do systemu operacyjnego hosta. Luka, która otrzymała numer CVE-2019-5736 została odkryta przez badaczy bezpieczeństwa Adama Iwaniuka i Borysa Popławskiego i ujawniona publicznie przez Aleksa Sarai, starszego inżyniera oprogramowania i opiekuna runC w SUSE.
[ czytaj całość… ]

J

eśli nie używasz dockera z pomocą docker-machine (standardowo na systemie OSX oraz Windows) to może dojść do sytuacji, gdy polecenia dockera doprowadzą do przejęcia hosta na którym zostały uruchomione. Jeśli dodamy naszego użytkownika systemu do grupy dockera lub zmienimy uprawnienia do gniazda sieciowego – to Twój użytkownik lub szkodliwe oprogramowanie będzie mógło uzyskać uprawnienia administratora bez konieczności podawania hasła.
[ czytaj całość… ]

M

ój administrator idzie z duchem po(d)stępu i podzielił nasz wielki serwer na mniejsze byśmy mogli robić te…, jak one mają… – mikroserwisy. Jako najprostszy i najszybszy sposób dla systemu Ubuntu 16.04 LTS wybrał szybującą w rozwoju technologię, czyli Dockera. Po szybkiej i sprawnej instalacji najnowszej wersji 1.13.1 mój zwykły użytkownik (darkstar) uzyskał możliwość posługiwania się tą technologią poprzez dopisanie go do grupy docker:
[ czytaj całość… ]