Een golf van nieuwe aanvallen richtte zich in 2023 op Kubernetes: de cryptominers van Dero en Monero, Scarleteel en RBAC-Buster. Een eerste houvast vinden met een webapp kwetsbaarheid, dan is zijdelings bewegen het kenmerk van een Kubernetes-aanval. Als u de realiteit van deze aanvallen begrijpt, kunt u uw organisatie beschermen tegen huidige en toekomstige aanvallen op Kubernetes.

Hier volgt een overzicht van hoe de aanvallen zich ontvouwen en wat u kunt doen om u ertegen te beschermen – of op zijn minst de schade te minimaliseren zodra u wordt aangevallen.

Scarleteel aanvalsplan

Een Jupyter-notebookwebapplicatie gehost in Kubernetes was het toegangspunt voor Scarleteel, met als doel toegang te krijgen tot gecodeerde, gevoelige gegevens in cloudopslag en cryptomining. Om open toegang tot de AWS-cloudomgeving te vinden, moet de aanvallers gebruikte ook een open-source Kubernetes-penetratietesttool genaamd Peirates, samen met een soortgelijke device genaamd Pacu.

Scarleteel liet zien hoe soepel een aanvaller zich door een cloudomgeving kan bewegen. De aanvaller sprong van een webapplicatie gehost in Kubernetes rechtstreeks naar de cloud naar Kubernetes en vervolgens weer terug. Verdedigers hebben geen vergelijkbaar samenhangend beeld van hun omgeving, maar kijken in plaats daarvan afzonderlijk naar cloudbeveiliging, webapp-beveiliging en Kubernetes-beveiliging, en worstelen vervolgens met het samenstellen van de volledige beweging en doelstellingen van de aanvaller.

Wat u kunt doen om u tegen Scarleteel te beschermen

Als u geen Jupyter-notebooks gebruikt, bent u hier mogelijk niet vatbaar voor aanval. Maar er zijn nog veel meer kwetsbaarheden in webapps. U kunt ervoor zorgen dat u zich beschermt tegen de zeer specifieke misconfiguratie in de cloud waarvan de aanvallers misbruik hebben gemaakt. Als u EKS uitvoert, kijk dan naar plaatsen waar u IMDSv1 versus IMDSv2 hebt geïnstalleerd en laat een blauw staff Peirates en Paco tegen uw omgeving uitvoeren voordat een aanvaller dat doet.

Runtime-mogelijkheden zouden mogelijk de Pandora-malware kunnen detecteren, maar zouden dit niet verbinden met de bredere aanval en activiteit die plaatsvindt in de cloud- en Kubernetes-omgevingen, zodat het de hele aanval niet kan stoppen.

Dero en Monero Cryptocurrency-mijnwerkers

Bij de Dero-aanval heeft de slechterik eerst gescand op Kubernetes-API’s waarbij authenticatie is ingesteld om iedereen anonieme toegang te verlenen. Om dit te laten werken had het cluster ook een RBAC-configuratie nodig die het maken van peulen in dat cluster mogelijk maakte. Toen aan deze voorwaarden was voldaan, implementeerde de aanvaller een Daemonset, waarmee hij zijn eigen pods maakte van kwaadaardige afbeeldingen in het hele cluster.

Het eerste deel van de Monero-aanval is hetzelfde als Dero. Vervolgens verwijderden aanvallers, met toegang tot de Kubernetes API, de Dero-pods en implementeerden ze hun eigen geprivilegieerde pod by way of Daemonset. De geprivilegieerde pod probeerde vervolgens de hostmap te koppelen om uit de container te ontsnappen en downloadde een rootkit die de mijnwerker kon verbergen. Daarna installeerde de aanvaller een aangepaste mining-service op de host.

In tegenstelling tot Dero omvat de Monero-aanval escalatie van privileges en ontsnappingstechnieken voor containers. Het toestaan ​​van geprivilegieerde containers is een van de meest kritieke Kubernetes-beveiligingsproblemen die u moet vermijden. Kubernetes staat bevoorrechte pods niet toe in het basisbeleid voor Pod-beveiligingsnormenwaardoor het minder waarschijnlijk is dat dit standaard gebeurt.

Als u echter EKS en Kubernetes v1.13 en hoger gebruikt, is het standaard pod-beveiligingsbeleid bevoorrecht. In EKS moet u dit beleid verwijderen om uw klantbeleid in te schakelen. Dit is een further stap die mogelijk de kans vergroot dat u het maken van geprivilegieerde pods toestaat.

In Monero vinden er veel runtime-activiteiten plaats nadat hackers misbruik hebben gemaakt van de aanvankelijke verkeerde configuratie van Kubernetes. Als u dit vergrendelt, wordt voorkomen dat kwaadaardig runtimegedrag zich naar andere peulen en clusters verspreidt. Het stoppen van niet-toegestane op de host gemonteerde paden en verkeerde configuraties van geprivilegieerde pods is het belangrijkste preventieve maatregel. Als u KSPM uitvoert met polling-intervallen, mist u alle activiteit van aanvallers die daartussenin plaatsvindt.

Hoe te beschermen tegen de Dero / Monero-aanvallen

Indien blootgesteld, is uw voornaamste zorg het verkleinen van de explosieradius, aangezien de aanval in realtime plaatsvindt in Kubernetes, en niet tijdens runtime. Als uw runtime-mogelijkheden een regel rond Monero-cryptomining omvatten, kunt u de laatste stap stoppen, maar niet de eerste fasen van het compromis.

Hoewel u uw API waarschijnlijk niet zou instellen om anonieme toegang toe te staan, zijn er andere manieren waarop ditzelfde toegangspunt kan worden bereikt uitgebuit. Een kwaadwillende insider kan backdoors of cryptocurrency-mijnwerkers plaatsen die vergelijkbaar zijn met die bij deze aanvallen. Een ontwikkelaar kan onbewust een serviceaccounttoken of kubeconfig-bestand inchecken in een openbare git-repository, wat een cluster kwetsbaar kan maken.

De belangrijkste beschermende maatregel is het voorkomen van het creëren van kwaadaardige workloads door Daemonsets. Er is ook een pleidooi voor observatietools, aangezien veel crypto-jacking-operaties worden ontdekt door onverwachte verkeerspieken.

Omdat bij deze aanval een afbeelding werd gebruikt om de kwaadaardige pods te maken, zou het opzetten van een beleid voor toegangscontrole dat voorkomt dat er werklasten worden aangemaakt die afkomstig zijn van niet-vertrouwde afbeeldingsbronnen. U moet het beleid echter breed afdwingen of een realtime KSPM-detectieoplossing gebruiken om precies te begrijpen waar u problemen ondervindt, en vervolgens de toegangscontroller operatief gebruiken terwijl u de configuraties in code repareert.

RBAC-Buster-aanvalsplan

De aanvaller probeert voet aan de grond te krijgen in een Kubernetes-omgeving door te zoeken naar een verkeerd geconfigureerde API-server die niet-geverifieerde verzoeken van gebruikers met bevoegdheden zou toestaan. Aanvallers gebruikten bevoorrechte toegang om geheimen op te sommen en de naamruimte van het kube-systeem te ontdekken.

Ze creëerden een nieuwe ClusterRole met beheerdersrechten en een nieuw serviceaccount in de naamruimte, waardoor de twee aan elkaar werden gekoppeld om de beheerdersrechten van de ClusterRole aan het serviceaccount te geven. De aanvaller zocht naar AWS-sleutels om toegang te krijgen tot de cloudserviceprovider. Vervolgens gebruikten ze een Daemonset om kwaadaardige pods voor cryptomining in het hele cluster te implementeren, met behulp van een containerimage.

Bij de eerste stap in deze aanval wordt ervan uitgegaan dat uw Kubernetes API-server niet alleen open is, maar dat deze ook verzoeken accepteert van bevoorrechte gebruikers. De relaxation van de aanval werkt met deze bevoorrechte toegang.

Wat u kunt doen om te beschermen tegen RBAC-Buster

Om zich lateraal te verspreiden, gebruikten de aanvallers dezelfde Daemonset-techniek als in de Dero-campagne: een herinnering om het creëren van kwaadaardige werklasten door Daemonsets te voorkomen. Controleer uw API-serverconfiguraties en controleer uw RBAC-machtigingen om u tegen deze aanval te beschermen.

Het voorkomen van toekomstige aanvallen

Het staff dat RBAC-Buster ontdekte, zei dat 60% van de gevonden blootgestelde clusters een actieve campagne actief. Dit betekent niet dat 60% van alle clusters zichtbaar zijn. Maar aanvallers zoeken naar fouten, verkeerde configuraties en een toegang tot uw Kubernetes-omgeving.

De meeste clusters waren slechts een paar uur toegankelijk, wat de kortstondige aard van Kubernetes-clusters benadrukt en hoe wat vandaag wijst op uitbuiting en blootstelling morgen misschien afgesloten kan zijn voor aanvallers. Dit betekent een nachtmerrie bij het herstel als u werkt met polling-intervallen die deze veranderingen in de loop van de tijd niet kunnen weergeven.

Als u uitsluitend vertrouwt op toegangscontrole of reverse-engineering-detectie op runtime-gebeurtenissen wanneer de volgende aanval plaatsvindt, wordt deze helemaal niet of te laat gedetecteerd. U hebt een realtime, gecombineerd beeld van de Kubernetes-risico’s nodig. Diepteverdediging is de beste praktijk. Maar als diepgaande verdediging geen zicht geeft op hoe alle verschillende componenten samenwerken, loop je nog steeds een stap achter op de aanvaller.

Jimmy Mesta is CTO en mede-oprichter van KSOC.