Gdzie są wszystkie naruszenia kontenerów?

W jaki sposób ugrupowania zagrażające będą atakować i wykorzystywać kontenery? To pytanie, o którym ciągle myślę. Pracuję w tej dziedzinie od ponad dwudziestu lat i czuję, że powinienem znać odpowiedź. Ale ja nie.

Zamiast tego mam mnóstwo różnych pomysłów i żadnego z nich nie jestem w stanie wskazać jako prawidłowego. Częścią tego niezdecydowania jest to, że cały czas spędziłem na uczeniu się bezpieczeństwa w „starym” świecie. Kontenery tak naprawdę nie mają analogii. Jasne, maszyny wirtualne (VM) są często łączone z kontenerami, ale nigdy nie były w stanie skalować się jak kontenery. Wykorzystuje się je także do zupełnie innych celów niż kontenery. Dostosowanie myślenia i zrozumienie, gdzie pojemniki faktycznie mieszczą się na powierzchni ataku, zajęło trochę czasu.

Publiczne przykłady ataków na środowiska kontenerowe są bardzo ograniczone. Naruszenia prawie zawsze są związane z wydobywaniem kryptowalut, co stanowi poważne ataki, ale osoba reagująca na incydent uważa je za rozczarowujące. Inną wspólną cechą jest to, że są one najczęściej wynikiem błędnej konfiguracji, niezależnie od tego, czy dotyczy to Kubernetesa, czy konta w chmurze. Połączenie motywów i taktyki nie było jak dotąd zbyt inspirujące.

Stara droga

Luki w zabezpieczeniach umożliwiające zdalne wykonanie kodu (RCE) od dawna stanowią główny problem bezpieczeństwa komputerów. Nadal są, ale jak ten sposób myślenia przekłada się na kontenery? Łatwo jest od razu przejść do RCE jako głównego zagrożenia, ale nie wydaje się, aby był to właściwy sposób podejścia do kontenerów. Po pierwsze, kontenery są często bardzo krótkotrwałe – 44% kontenerów żyje krócej niż pięć minut – więc intruz musiał się spieszyć.

Podejście to zakłada również, że kontener jest wystawiony na działanie Internetu. Z pewnością niektóre kontenery są skonfigurowane w ten sposób, ale często są one bardzo proste i wykorzystują dobrze przetestowane technologie, takie jak NGINX. W przypadku tych aplikacji może nie być żadnych dni wolnych, ale byłyby one niezwykle cenne i trudne do zdobycia. Moje doświadczenie pokazało mi, że wiele kontenerów jest używanych wewnętrznie i nie łączy się bezpośrednio z Internetem. W tym przypadku scenariusz RCE staje się znacznie trudniejszy. Powinienem wspomnieć log4j, chociaż tego rodzaju luki mogą zostać wykorzystane zdalnie, nawet jeśli podatny na ataki system nie znajduje się na krawędzi.

Nowa droga

Jeśli RCE nie jest największym zagrożeniem dla kontenerów, to co nim jest? Czy kontenery w ogóle znajdują się na radarze podmiotów stwarzających zagrożenie? Tak, kontenery i towarzysząca im infrastruktura są zbyt ważne, aby je ignorować. Oprogramowanie do orkiestracji kontenerów umożliwiło skalowanie skonteneryzowanych obciążeń do niewyobrażalnych liczb. Trend użytkowania również rośnie, więc możesz być pewien, że będą celem. Po prostu nie można ich traktować jak serwerów, do których można dotrzeć poprzez luki w zabezpieczeniach RCE.

Zamiast tego jest odwrotnie. Zamiast atakować kontenery od zewnątrz, należy je zaatakować od środka. Zasadniczo właśnie do tego służą ataki na łańcuch dostaw. Łańcuch dostaw jest niezwykle skutecznym wektorem ataku na kontenery, gdy zaczniesz rozumieć, jak są zbudowane. Kontener zaczyna się od pliku definicji, takiego jak Dockerfile, który definiuje wszystko, co będzie w kontenerze po jego uruchomieniu. Po zbudowaniu jest przekształcany w obraz, który można wykorzystać w obciążeniu niezliczoną ilość razy. Jeśli cokolwiek w tym pliku definicji zostanie naruszone, zagrożone będzie każde uruchomione obciążenie.

Kontenery są często, ale nie zawsze, tworzone specjalnie z aplikacją, która coś robi i kończy działanie. Aplikacje te mogą obejmować niemal wszystko — ważne jest, aby zrozumieć, w jakim stopniu aplikacje są zbudowane przy użyciu bibliotek, zarówno o zamkniętym, jak i otwartym kodzie źródłowym, napisanych przez inne osoby. GitHub ma miliony projektów i nie jest to jedyne dostępne repozytorium kodu. Jak widzieliśmy w przypadku SolarWinds, zamknięte źródło jest również podatne na ataki w łańcuchu dostaw.

Atak na łańcuch dostaw to dla cyberprzestępców świetny sposób na przedostanie się do środowiska kontenerowego celu. Mogą nawet pozwolić infrastrukturze klienta skalować atak za nich, jeśli kompromis pozostanie niezauważony. Tego typu scenariusz już się realizuje, jak widzieliśmy w przypadku Naruszenie Codecov. Trudno to jednak wykryć ze względu na to, jak bardzo jest to wszystko nowe i jak nasze myślenie jest wciąż zakorzenione w problemach z przeszłości.

Krok naprzód

Podobnie jak w przypadku rozwiązywania większości problemów, dobrym punktem wyjścia jest zazwyczaj widoczność. Trudno naprawić to, czego nie widać. Aby zabezpieczyć kontenery, musisz mieć wgląd w same kontenery, a także w cały rurociąg, który je buduje. Zarządzanie lukami w zabezpieczeniach to jeden rodzaj widoczności, który należy zintegrować z potokiem kompilacji. Dodałbym także inne narzędzia do analizy statycznej, takie jak te, które również szukają ujawnionych sekretów. Ponieważ nie da się przewidzieć, jak będzie wyglądać atak na łańcuch dostaw, monitorowanie czasu wykonania staje się krytyczne, aby dokładnie wiedzieć, co robią Twoje kontenery.