Kubernetes Network Attacks
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
W Kubernetes zaobserwowano, że domyślne zachowanie pozwala na nawiązywanie połączeń między wszystkimi kontenerami znajdującymi się na tym samym węźle. Dotyczy to niezależnie od różnic w przestrzeniach nazw. Taka łączność sięga Warstwy 2 (Ethernet). W konsekwencji ta konfiguracja potencjalnie naraża system na luki w zabezpieczeniach. Konkretnie, otwiera możliwość, aby złośliwy kontener przeprowadził atak ARP spoofing przeciwko innym kontenerom znajdującym się na tym samym węźle. Podczas takiego ataku złośliwy kontener może oszukańczo przechwycić lub zmodyfikować ruch sieciowy przeznaczony dla innych kontenerów.
Ataki ARP spoofing polegają na tym, że napastnik wysyła fałszywe wiadomości ARP (Address Resolution Protocol) w lokalnej sieci. Skutkuje to powiązaniem adresu MAC napastnika z adresem IP legalnego komputera lub serwera w sieci. Po pomyślnym przeprowadzeniu takiego ataku napastnik może przechwytywać, modyfikować lub nawet zatrzymywać dane w tranzycie. Atak jest realizowany na Warstwie 2 modelu OSI, dlatego domyślna łączność w Kubernetes na tej warstwie budzi obawy dotyczące bezpieczeństwa.
W scenariuszu zostaną utworzone 4 maszyny:
ubuntu-pe: Maszyna uprzywilejowana do ucieczki do węzła i sprawdzania metryk (niepotrzebna do ataku)
ubuntu-attack: Złośliwy kontener w domyślnej przestrzeni nazw
ubuntu-victim: Ofiara maszyna w przestrzeni nazw kube-system
mysql: Ofiara maszyna w domyślnej przestrzeni nazw
Jeśli chcesz uzyskać więcej szczegółów na temat tematów sieciowych wprowadzonych tutaj, przejdź do odniesień.
Ogólnie rzecz biorąc, sieciowanie podów wewnątrz węzła jest dostępne za pośrednictwem mostu, który łączy wszystkie pody. Ten most nazywa się “cbr0”. (Niektóre wtyczki sieciowe zainstalują własny most.) cbr0 może również obsługiwać ARP (Protokół Rozwiązywania Adresów). Gdy przychodzący pakiet dociera do cbr0, może rozwiązać docelowy adres MAC za pomocą ARP.
Fakt ten implikuje, że domyślnie każdy pod działający w tym samym węźle będzie mógł komunikować się z każdym innym pod w tym samym węźle (niezależnie od przestrzeni nazw) na poziomie ethernetowym (warstwa 2).
Dlatego możliwe jest przeprowadzenie ataków ARP Spoofing między podami w tym samym węźle.
W środowiskach kubernetes zazwyczaj znajdziesz 1 (lub więcej) usług DNS działających zazwyczaj w przestrzeni nazw kube-system:
W poprzednich informacjach możesz zobaczyć coś interesującego, IP usługi to 10.96.0.10, ale IP poda uruchamiającego usługę to 172.17.0.2.
Jeśli sprawdzisz adres DNS wewnątrz dowolnego poda, znajdziesz coś takiego:
Jednak pod nie wie, jak dotrzeć do tego adresu, ponieważ zakres podów w tym przypadku to 172.17.0.10/26.
Dlatego pod wyśle żądania DNS do adresu 10.96.0.10, które zostaną przetłumaczone przez cbr0 na 172.17.0.2.
Oznacza to, że żądanie DNS poda zawsze będzie kierowane do mostu, aby przetłumaczyć adres IP usługi na adres IP punktu końcowego, nawet jeśli serwer DNS znajduje się w tej samej podsieci co pod.
Znając to i wiedząc, że ataki ARP są możliwe, pod w węźle będzie w stanie przechwycić ruch między każdym podem w podsieci a mostem oraz zmodyfikować odpowiedzi DNS z serwera DNS (DNS Spoofing).
Ponadto, jeśli serwer DNS znajduje się w tym samym węźle co atakujący, atakujący może przechwycić wszystkie żądania DNS dowolnego poda w klastrze (między serwerem DNS a mostem) i zmodyfikować odpowiedzi.
Naszym celem jest ukraść przynajmniej komunikację z ubuntu-victim do mysql.
Jak już wspomniano, jeśli skompromitujesz pod na tym samym węźle co pod serwera DNS, możesz MitM z ARPSpoofing mostu i podu DNS oraz zmodyfikować wszystkie odpowiedzi DNS.
Masz naprawdę fajne narzędzie i samouczek, aby to przetestować w https://github.com/danielsagi/kube-dnsspoof/
W naszym scenariuszu, pobierz narzędzie w podzie atakującego i stwórz plik o nazwie hosts
z domenami, które chcesz spoofować, takie jak:
Wykonaj atak na maszynę ubuntu-victim:
Jeśli spróbujesz stworzyć własny skrypt do spoofingu DNS, jeśli po prostu zmodyfikujesz odpowiedź DNS, to nie zadziała, ponieważ odpowiedź będzie miała src IP adres IP złośliwego podu i nie będzie zaakceptowana. Musisz wygenerować nowy pakiet DNS z src IP DNS, do którego ofiara wysyła zapytanie DNS (coś w rodzaju 172.16.0.2, a nie 10.96.0.10, to jest adres IP usługi DNS K8s, a nie adres IP serwera DNS, więcej na ten temat w wprowadzeniu).
Narzędzie Mizu to prosty, ale potężny wyświetlacz ruchu API dla Kubernetes, który umożliwia oglądanie całej komunikacji API między mikroserwisami, aby pomóc w debugowaniu i rozwiązywaniu problemów. Zainstaluje agenty w wybranych podach i zbierze informacje o ich ruchu, a następnie wyświetli je na serwerze internetowym. Jednak będziesz potrzebować wysokich uprawnień K8s do tego (i nie jest to zbyt dyskretne).
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)