Kubernetes Network Attacks
Inleiding
In Kubernetes word daar waargeneem dat 'n verstekgedrag die vestiging van verbindings tussen alle houers wat op dieselfde nodus woon toelaat. Dit geld ongeag die namespace-onderskeidings. Hierdie konnektiwiteit strek tot Laag 2 (Ethernet). Gevolglik stel hierdie konfigurasie die stelsel bloot aan kwesbaarhede. Spesifiek maak dit die moontlikheid oop vir 'n boosaardige houer om 'n ARP-spoofing-aanval uit te voer teen ander houers wat op dieselfde nodus geleë is. Tydens so 'n aanval kan die boosaardige houer bedrieglik netwerkverkeer wat bedoel is vir ander houers, onderskep of wysig.
ARP-spoofing-aanvalle behels dat die aanvaller vervalsde ARP (Address Resolution Protocol) boodskappe oor 'n plaaslike area-netwerk stuur. Dit lei daartoe dat die aanvaller se MAC-adres gekoppel word aan die IP-adres van 'n legitieme rekenaar of bediener op die netwerk. Na suksesvolle uitvoering van so 'n aanval kan die aanvaller data wat in-transit is, onderskep, wysig of selfs stop. Die aanval word uitgevoer op Laag 2 van die OSI-model, daarom veroorsaak die verstek-konnektiwiteit in Kubernetes op hierdie laag sekuriteitskwessies.
In die scenario word 4 masjiene geskep:
ubuntu-pe: Bevoorregte masjien om na die nodus te ontsnap en metriek te kontroleer (nie nodig vir die aanval nie)
ubuntu-attack: Boosaardige houer in die verstek namespace
ubuntu-victim: Slagoffer masjien in die kube-system namespace
mysql: Slagoffer masjien in die verstek namespace
Basiese Kubernetes-netwerking
As jy meer besonderhede oor die netwerkonderwerpe wat hier aangebied word, wil hê, gaan na die verwysings.
ARP
Oor die algemeen is pod-to-pod-netwerking binne die node beskikbaar via 'n brug wat al die pods verbind. Hierdie brug word "cbr0" genoem. (Sommige netwerkplugins sal hul eie brug installeer.) Die cbr0 kan ook ARP-oplossing hanteer (Address Resolution Protocol). Wanneer 'n inkomende pakkie by cbr0 arriveer, kan dit die bestemmings-MAC-adres oplos deur ARP te gebruik.
Hierdie feit impliseer dat, standaard, elke pod wat op dieselfde node loop, in staat sal wees om te kommunikeer met enige ander pod in dieselfde node (onafhanklik van die namespace) op ethernetvlak (laag 2).
Daarom is dit moontlik om ARP-spoofing-aanvalle tussen pods in dieselfde node uit te voer.
DNS
In Kubernetes-omgewings sal jy gewoonlik 1 (of meer) DNS-dienste vind wat hardloop in die kube-system-namespace:
In die vorige inligting kan jy iets interessant sien, die IP van die diens is 10.96.0.10, maar die IP van die houer wat die diens uitvoer is 172.17.0.2.
As jy die DNS-adres binne enige houer nagaan, sal jy iets soos hierdie vind:
Echter, die pod weet nie hoe om na daardie adres te gaan nie, omdat die pod-reeks in hierdie geval 172.17.0.10/26 is.
Daarom sal die pod die DNS-versoeke na die adres 10.96.0.10 stuur wat deur die cbr0 na 172.17.0.2 vertaal sal word.
Dit beteken dat 'n DNS-versoek van 'n pod altyd deur die brug sal gaan om die diens-IP na die eindpunt-IP te vertaal, selfs as die DNS-bediener in dieselfde subnetwerk as die pod is.
Met hierdie kennis, en wetende dat ARP-aanvalle moontlik is, sal 'n pod in 'n node in staat wees om die verkeer tussen elke pod in die subnetwerk en die brug te onderskep en die DNS-antwoorde van die DNS-bediener te verander (DNS-spoofing).
Verder, as die DNS-bediener in dieselfde node as die aanvaller is, kan die aanvaller alle DNS-versoeke van enige pod in die groep onderskep (tussen die DNS-bediener en die brug) en die antwoorde verander.
ARP-spoofing in pods in dieselfde Node
Ons doel is om ten minste die kommunikasie van die ubuntu-slachtoffer na die mysql te steel.
Scapy
ARPSpoof
ARPSpoof is 'n tegniek wat gebruik word om 'n ARP (Address Resolution Protocol) aanval uit te voer. Hierdie aanval maak gebruik van vervalsing van ARP-pakette om die ARP-tabel van 'n doelwitrekenaar te manipuleer. Die doel van hierdie aanval is om die kommunikasie tussen twee rekenaars te onderskep en te onderskep.
Die aanvaller stuur vervalsde ARP-pakette na die doelwitrekenaar en die standaardroeteerder. Hierdie vervalsde pakette bevat valse IP- en MAC-adresse. As die aanval suksesvol is, sal die ARP-tabel van die doelwitrekenaar opgedateer word met die valse inligting. Hierdie valse inligting sal veroorsaak dat die doelwitrekenaar sy kommunikasie na die aanvaller stuur in plaas van na die regte bestemming.
Hier is 'n voorbeeld van hoe 'n ARPSpoof-aanval uitgevoer kan word:
Identifiseer die doelwitrekenaar en die standaardroeteerder in die netwerk.
Stel 'n valse ARP-pakket op met die IP-adres van die doelwitrekenaar as die bron-IP-adres en die MAC-adres van die aanvaller as die bron-MAC-adres.
Stuur die valse ARP-pakket na die doelwitrekenaar en die standaardroeteerder.
As die aanval suksesvol is, sal die ARP-tabel van die doelwitrekenaar opgedateer word met die valse inligting.
Die doelwitrekenaar sal sy kommunikasie na die aanvaller stuur in plaas van na die regte bestemming.
Dit is belangrik om te verstaan dat ARPSpoof 'n aanvalstegniek is wat gebruik kan word om netwerkverkeer te onderskep en te onderskep. Dit kan egter ook gebruik word vir kwaadwillige doeleindes, soos die onderskep van gevoelige inligting soos wagwoorde en kredietkaartinligting.
DNS Spoofing
Soos reeds genoem, as jy 'n pod in dieselfde node as die DNS-bediener pod kompromitteer, kan jy MitM met ARPSpoofing die brug en die DNS pod en verander al die DNS-antwoorde.
Jy het 'n baie mooi instrument en handleiding om dit te toets by https://github.com/danielsagi/kube-dnsspoof/
In ons scenario, laai die instrument af in die aanvaller pod en skep 'n **lêer genaamd hosts
** met die domeine wat jy wil spoof soos:
Voer die aanval uit op die ubuntu-slagsoffer masjien:
As jy probeer om jou eie DNS-spoofing skrip te skep, as jy net die DNS-antwoord wysig, gaan dit nie werk nie, omdat die antwoord 'n src IP gaan hê, die IP-adres van die skadelike pod, en dit sal nie aanvaar word nie. Jy moet 'n nuwe DNS-pakket genereer met die src IP van die DNS waar die slagoffer die DNS-versoek stuur (wat iets soos 172.16.0.2 is, nie 10.96.0.10 nie, dit is die K8s DNS-diens IP en nie die DNS-bediener IP nie, meer hieroor in die inleiding).
Vang Verkeer
Die instrument Mizu is 'n eenvoudige maar kragtige API-verkeerskyker vir Kubernetes wat jou in staat stel om alle API-kommunikasie tussen mikrodienste te sien om jou te help met die opspoor en oplos van regressies. Dit sal agente in die gekose pods installeer en hul verkeersinligting versamel en aan jou wys in 'n webbediener. Jy sal egter hoë K8s-permissies nodig hê hiervoor (en dit is nie baie heimlik nie).
Verwysings
Last updated