Kubernetes stał się zdecydowanie najpopularniejszym systemem kontenerów w chmurze. A więc właściwie odkrycie pierwszej poważnej luki w zabezpieczeniach było tylko kwestią czasu.
I tak było, bo ostatnio Pierwsza poważna luka w zabezpieczeniach Kubernetes została wydana pod numerem CVE-2018-1002105, znany również jako błąd eskalacji uprawnień.
Ta główna wada Kubernetes jest problemem, ponieważ jest krytyczną luką w zabezpieczeniach CVSS 9.8. W przypadku pierwszej poważnej luki w zabezpieczeniach Kubernetes.
Szczegóły błędu
Dzięki specjalnie zaprojektowanej sieci żądań każdy użytkownik może nawiązać połączenie z serwera interfejsu programowania aplikacji (API) Kubernetes do serwera zaplecza.
Po ustaleniu atakujący może wysyłać dowolne żądania przez połączenie sieciowe bezpośrednio do tego zaplecza w którym przez cały czas celem jest ten serwer.
Te żądania są uwierzytelniane przy użyciu poświadczeń TLS (Transport Layer Security) z serwera Kubernetes API.
Co gorsza, w konfiguracji domyślnej wszyscy użytkownicy (uwierzytelnieni lub nie) mogą uruchamiać wywołania wykrywania interfejsu API, które pozwalają na eskalację uprawnień przez atakującego.
Zatem każdy, kto zna tę dziurę, może skorzystać z okazji, aby przejąć kontrolę nad swoim klastrem Kubernetes.
W tej chwili nie ma łatwego sposobu na wykrycie, czy ta luka była wcześniej używana.
Ponieważ nieautoryzowane żądania są wysyłane przez ustanowione połączenie, nie pojawiają się w dziennikach kontroli serwera Kubernetes API ani w dzienniku serwera.
Żądania pojawiają się w dziennikach kubelet lub na serwerze zagregowanego interfejsu API, ale różnią się od odpowiednio autoryzowanych i proxy żądań przez serwer Kubernetes API.
Nadużycie ta nowa luka w Kubernetes nie pozostawiłoby to oczywistych śladów w dziennikach, więc teraz, gdy błąd Kubernetes został ujawniony, użycie go jest tylko kwestią czasu.
Innymi słowy, Red Hat powiedział:
Luka w eskalacji uprawnień umożliwia każdemu nieautoryzowanemu użytkownikowi uzyskanie pełnych uprawnień administratora na dowolnym węźle obliczeniowym działającym w pod Kubernetes.
Nie jest to tylko kradzież lub otwarcie na wstrzyknięcie złośliwego kodu, ale może również zmniejszyć liczbę aplikacji i usług produkcyjnych w zaporze sieciowej organizacji.
Każdy program, w tym Kubernetes, jest podatny na ataki. Dystrybutorzy Kubernetes już wydają poprawki.
Firma Red Hat informuje, że problem dotyczy wszystkich produktów i usług opartych na Kubernetes, w tym platformy Red Hat OpenShift Container, Red Hat OpenShift Online i Red Hat OpenShift Dedicated.
Firma Red Hat zaczęła dostarczać poprawki i aktualizacje usług użytkownikom, których dotyczy problem.
O ile wiadomo, nikt jeszcze nie wykorzystał naruszenia bezpieczeństwa do ataku. Darren Shepard, główny architekt i współzałożyciel laboratorium Rancher, odkrył błąd i zgłosił go za pomocą procesu zgłaszania luk w zabezpieczeniach Kubernetes.
Jak naprawić ten błąd?
Na szczęście poprawka tego błędu została już wydana. W którym tylko są proszeni o wykonanie aktualizacji Kubernetes więc mogą wybrać niektóre z poprawionych wersji Kubernetes v1.10.11, v1.11.5, v1.12.3 i v1.13.0-RC.1.
Jeśli więc nadal używasz którejkolwiek z wersji Kubernetes v1.0.x-1.9.x, zalecamy uaktualnienie do wersji poprawionej.
Jeśli z jakiegoś powodu nie mogą zaktualizować Kubernetes i chcą temu zapobiec, konieczne jest przeprowadzenie następującego procesu.
Należy zaprzestać korzystania z interfejsu API agregacji serwera lub usunąć uprawnienia pod exec / attach / portforward dla użytkowników, którzy nie powinni mieć pełnego dostępu do interfejsu API kubelet.
Jordan Liggitt, inżynier oprogramowania Google, który naprawił błąd, powiedział, że te środki będą prawdopodobnie szkodliwe.
Tak więc jedynym prawdziwym rozwiązaniem tej luki w zabezpieczeniach jest wykonanie odpowiedniej aktualizacji Kubernetes.