Nieuwe malware probeert via Windows-containers cloudomgevingen binnen te dringen

Een nieuw soort malware richt zich specifiek op het aanvallen van Windows-containers om toegang te krijgen tot Kubernetes-clusters van cloudomgevingen. Het is de eerste malware in zijn soort die zich specifiek richt op Windows-containers.

De malware werd in maart ontdekt door onderzoekers van het bedrijf Palo Alto Networks. De malware, die door de onderzoekers Siloscape genoemd wordt, is volgens hen uniek in zijn soort, omdat de meeste andere malware gericht op cloudomgevingen zich focust op Linux.

In een blogpost schrijven de onderzoekers dat de malware op zoek gaat naar slecht geconfigureerde Kubernetes-clusters via Windows-containers, om vervolgens in het cluster een achterdeur te openen om een geïnfecteerde container te kunnen draaien. De malware gebruikt bekende kwetsbaarheden in cloud-apps en webservers om toegang te krijgen, en probeert vervolgens via de Windows-container te ontsnappen.

Als de aanvallers binnen zijn en de malware is ontsnapt, voert de malware een remote code execution via de achterdeur uit op de onderliggende nodes van het cluster. Siloscape doet er alles aan om ongezien te blijven, onder andere door vervolgens via een tor-proxy en een .onion-domein anoniem verbinding te maken met de command-and-control-server van de malware, vanwaaruit de aanvallers data kunnen stelen en commando's kunnen versturen naar de malware.

Volgens Palo Alto Networks is de malware er al zeker 23 keer in geslaagd om succesvol toegang te krijgen tot een cloudomgeving. De onderzoekers kregen toegang tot de command-and-controlserver van de malware met in totaal 313 gebruikers. Daardoor denken de onderzoekers dat Siloscape maar een klein onderdeel is van een grootschalige malwareaanval. Die aanval is al zeker een jaar aan de gang.

In eerste instantie zag Microsoft na melding van de onderzoekers niet hoe de malware een kwetsbaarheid was in Windows Server, waar de containers in draaien. Daarom hebben de onderzoekers contact opgenomen met Google, als eigenaar van Kubernetes. Na 'geheen-en-weer tussen Google en Microsoft' heeft Microsoft de malware wel als kwetsbaarheid beoordeeld, onder CVE-2021-24096.

Door Stephan Vegelien

Redacteur

09-06-2021 • 15:35

21 Linkedin Whatsapp

Reacties (21)

21
21
10
3
0
6
Wijzig sortering
Toont maar weer eens aan dat zero trust niet zo'n gek concept is. Blind vertrouwen op de perimeter-beveiliging van je netwerk is niet meer van deze tijd.
Uiteindelijk is alles wat online staat niet veilig.

Mooi voorbeeld is de Hacking Team hack, deze hackers die er toch wel een staaltje van konden, hadden hun eigen netwerkbeveiliging gedaan en waren meer voorbereidt op een hack dan basically wie dan ook op het internet.

Het nam een persoon met net iets teveel vrije tijd om een nieuwe zero-day te vinden in de embedded netwerkapparaten die ze gebruikte, 3 weken later lag alles op straat.
Er is niets wat hacking team hieraan had kunnen doen, behalve als je verwacht dat iedereen spontaan van al zijn apparaten gaat checken of er 0-days op zitten, wat zeer onrealistisch is.

Enige oplossing: go offline, en dat wordt steeds en steeds moeilijker hedendaags, vooral nu corona iedereen heeft verplicht vanuit thuis te werken en alle hardware etc aan het internet is verbonden voor de thuiswerkers.


https://arstechnica.com/i...t-hacked-phineas-phisher/
Hoezo er is niets wat hacking team hier had aan kunnen doen? Uit je eigen link

"Once inside, the hacker says he took a slow look around, and discovered an insecure MongoDB install"
"But, according to the hacker, it was Hacking Team's backups that proved the company's undoing. Their iSCSI devices were available on the local subnet"
"that's what got him access to backups—and in those backups he found the BES and admin credentials, and those credentials were a domain admin—so as soon as he found that out, it was game over. He was domain admin on their network."

Slecht beveiligde databases, backups waar hij aangeraakt maar vooral dat het blijkbaar heel eenvoudig was, wat zeg ik, zelf mogelijk was om domain admin wachtwoorden uit de backups te halen. Dat zijn major red flags dat de security op veel vlakken fout zat.

Bovendien geeft de hacker zelf aan dat zijn attack surface beperkt was en dus dat hij voor een "unnamed embeded device" ging

" attack surface—only an up-to-date version of Joomla, "a mail server, a couple routers, two VPN appliances, and a spam filtering appliance. So, the hacker explains, three options presented themselves: "look for a zero-day in Joomla, look for a zero-day in postfix, or look for a zero-day in one of the embedded devices.

A zero-day in an embedded device seemed like the easiest option"

De hacker heeft niet laten weten wat voor unnamed embeded device dit ging maar dit zal wel iets in de trend van een koffiemachine of iets dergelijks zijn. Dergelijke embeded devices zijn untrusted en horen niet op je gewoon netwerk te zitten, dat gooi je op een untrusted volledig afgescheiden netwerk dat enkel naar buiten kan. Dat zijn security eisen waaraan een doorsnee kmo wel aan mag voldoen dus we zitten bijlange nog niet op het niveau van een high risk scenario zoals een bank.

Daarnaast is het idee dat je veilig bent als je niet aan het internet hangt compleet achterhaald, 1 usb stick is voldoende om je afgesloten netwerk onderuit te halen. En als je maar belangerijk genoeg bent dan geraken ze toch binnen op je niet internet aangesloten netwerk, lees anders nog eens hoe Stuxnet een hermetisch afgesloten installatie kon binnen dringen.

Als je denkt dat niets aan internet koppelen een oplossing is, dan weet je simpelweg niet waarover je spreekt.

[Reactie gewijzigd door sprankel op 9 juni 2021 22:26]

Huh, je eigen quotes spreken je tegen:

"But, according to the hacker, it was Hacking Team's backups that proved the company's undoing. Their iSCSI devices were available on the local subnet"

Duidelijk niet offline, hadden ze wel offline gestaan (compleet buiten het netwerk) dan was hier geen probleem geweest.


Ja, het stuxnet verhaal is me bekend, maar dat is een miljoen $+ CIA/NSA operatie geweest en met die resources kan je overal uiteindelijk wel binnenkomen, daar maak ik me ook niet echt zorgen over omdat ik niet echt een enemy of the state ben naar mijn idee ;)
Zoals de Russen altijd zeggen: Trust, but verify.
Доверяй, но проверяй
Zoals Peter Gillis zegt ! Vertrouwen is goed, controleren is beter.
Gewoon niet alles in een netwerk gooien ;)
Dat garandeert niks. Naast de high-profile Stuxnet usb-stick hack zijn er veel social engineering aanvallen die om een airgap heen kunnen werken. Ja, het is een stuk moeilijker maar met een potentieel losgeld van miljoenen willen mensen wel wat moeite doen.
Hahaha grappig. Je hebt natuurlijk helemaal gelijk.

Ik hinte meer op de enterprise cloud trend om 1 groot netwerk te creëren zowel onpremise als public. In feite hoeft een kubernetes cluster niet zodanig connected te zijn dat een breach v/d container is issue is. In feite kan je tegenwoordig zelfs zonder alteveel effort meerdere clusters deployen ipv 1 monolitische omgeving waar alle containers draaien. Communicatie kan gewoon via HTTPS (zoals interfacing met data opgeslagen in S3 buckets of Azure storage accounts)

[Reactie gewijzigd door Mellow Jack op 10 juni 2021 11:06]

Ik begrijp de tijdlijn niet helemaal. De malware is in maart ontdekt, daarna hebben de onderzoekers contact gehad met microsoft en google waarna microsoft het heeft geaddresseerd. Alleen is de cve en patch al uitgegeven in februari.
Of is het zo geweest dat doordat deze patch er is gekomen aanvallers via reverse engineering dit gat actief zijn gebruiken en is dat in maart ontdekt door palo alto ?
Anoniem: 1322
@McBurger9 juni 2021 16:46
Zie de bron:
On July 15, 2020, I released an article about Windows container boundaries and how to break them. In that article, I presented a technique for escaping from a container and discussed some potential applications that such an escape can have in the hands of an attacker. The most significant application, and the one I chose to focus on, was an escape from a Windows container node in Kubernetes in order to spread in the cluster.

Microsoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server containers are not a security boundary, and therefore each application that is being run inside a container should be treated as if it is executed directly on the host.
Wat een antwoord ook.... Ik ben benieuwd of ze ook zo over Hyper-V hosts denken....

A few weeks after that discussion, I reported the issue to Google because Kubernetes is vulnerable to those issues. Google contacted Microsoft, and after some back and forth, it was determined by Microsoft that an escape from a Windows container to the host, when executed without administrator permissions inside the container, will in fact be considered a vulnerability.
Microsoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server containers are not a security boundary, and therefore each application that is being run inside a container should be treated as if it is executed directly on the host.
Wat een antwoord ook.... Ik ben benieuwd of ze ook zo over Hyper-V hosts denken....
Ik kan je vertellen dat ze in elk geval wel zo denken over UAC.

Dat leuke mechanisme dat om bevestiging vraagt voordat een account admin-permissies kan activeren en van gewone user naar admin-power kan gaan? Die UAC?
Ja; dat is dus geen security boundary.

Maw als er een bypass gevonden wordt die toestaat om zonder gebruikersbevestiging de admin permissies te activeren en gebruiken, dan is dat geen security vulnerability en resulteert dat in principe - zeer zware uitzonderingen uitgezonderd, mag ik toch wel hopen - noch in de registratie van een CVE, noch in een security patch.

Microsoft: leuker kunnen we het voor malafide hackers niet maken, wel makkelijker.

[Reactie gewijzigd door R4gnax op 9 juni 2021 17:25]

Dit lijkt me vooral een probleem voor thuisgebruikers; in omgevingen waar Windows professioneel wordt gebruikt kan je over het algemeen prima werken zonder dat je normale gebruiker lokale beheersrechten heeft (en zo niet, dan zijn er talloze applicaties van derden die zogenaamde 'privilege elevation' kunnen verzorgen).
Anoniem: 508592
9 juni 2021 16:22
Benieuwd of hier een patch voor komt, of een alternatief buiten een patch om, om dit te dichten.
Zie de onderste link. Is gefixed op 9 februari.
Is er al sinds feb 9. Zie de cve link in het artikel.
Anoniem: 508592
@jelle8109 juni 2021 19:38
Ow haha :P niet verder gekeken dan mijn neus lang is.
Wie draait er nou k8s met windows containers. Praktisch alles draait op linux tegenwoordig, php, .net etc.

[Reactie gewijzigd door JustFogMaxi op 10 juni 2021 08:48]

Vanuit nieuwe applicaties gezien wel ja. In de onderzoekswereld zie je nog wel dat legacy de adoptie van containers lastig kan maken. Kan me voorstellen dat die situatie op meerdere plekken zo is

[Reactie gewijzigd door Mellow Jack op 10 juni 2021 11:12]

Anoniem: 610852
10 juni 2021 09:07
Je zou ook sowieso geen Windows containers moeten willen gebruiken, in the first place.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee