Criminelen misbruikten Tesla-serverinfrastructuur voor cryptomining

Een beveiligingsbedrijf heeft ontdekt dat criminelen toegang hebben verkregen tot Tesla-servers, die ze misbruikten om cryptovaluta te minen. Ook hadden ze toegang tot gegevens in een AWS-S3-bucket, al bestrijdt Tesla dat het om gevoelige gegevens ging.

De ontdekking werd gedaan door het bedrijf RedLock, dat een blogpost eraan wijdde. Daarin schrijft het dat de criminelen toegang hadden tot een Kubernetes-interface, die niet van een wachtwoord was voorzien. De interface kan worden gebruikt om zogenaamde pods aan te sturen, dat zijn verzamelingen van containers zoals Docker. In een van deze pods zaten inloggegevens voor een Amazon S3-server, met een bucket waarin onder meer telemetriegegevens te vinden waren. De criminelen gebruikten een andere pod voor hun cryptominingactiviteiten.

Tesla heeft op de bevindingen gereageerd, onder meer tegenover Cyberscoop. Het bedrijf zegt dat het de melding van RedLock binnen enkele uren heeft opgepakt en maatregelen heeft genomen. Die melding deed RedLock op 30 januari, maar het is onduidelijk hoe lang de criminelen toegang hadden. Tesla bestrijdt dat het om gevoelige gegevens ging en zegt dat er geen risico was voor de privacy van klanten of de veiligheid van auto's, omdat het om data van interne testvoertuigen ging.

Het beveiligingsbedrijf vermeldt in zijn analyse dat de miningactiviteiten op verschillende manieren verborgen waren, zo maakten ze niet gebruik van een publieke miningpool om detectie op basis van ip of domein te omzeilen. Verder hadden ze het adres van hun pool achter Cloudflare geplaatst en was hun software geconfigureerd om op een poort te luisteren die niet standaard is. Ten slotte hadden ze hun miningsoftware zodanig geconfigureerd dat het cpu-gebruik niet ongebruikelijk hoog werd, wat zou leiden tot detectie. Het beveiligingsbedrijf stelt dat het soortgelijke incidenten heeft geïdentificeerd bij andere bedrijven, waaronder Aviva en Gemalto.

Sinds vorig jaar stijgt het aantal aanvallen waarbij criminelen toegang tot apparatuur misbruiken voor cryptomining, in veel gevallen gaat het daarbij om Monero, omdat die cryptomunt met cpu-kracht is te delven. Beveiligingsbedrijf Imperva claimde recentelijk dat bij 88 procent van de zelf gedetecteerde aanvallen waarbij misbruik werd gemaakt van een rce-lek, de aanvallers probeerden cryptominingmalware binnen te halen. Daarvoor was het populair om het apparaat in een ddos-botnet op te nemen, claimt het bedrijf.

De mining-pod, via RedLock

Reacties (58)

[Ro-Maniak2]

Mag er zo'n stippellijntje onder AWS bucket, voor de blijkbaar leken (al ben ik niet bepaald een ICT-leek)?

[Tweekzor]

AWS, Amazon Web Services. Een cloud dienst die je kan gebruiken om servers (en rekenkracht) te huren. Grootste voordeel is dat het makkelijk schaalbaar is en je voor bijvoorbeeld een dag extra rekenkracht kan bijschalen als je drukte verwacht (rondom een grote release o.i.d.).

[Reactie gewijzigd door Tweekzor op 29 juli 2024 04:00]

[ApexAlpha]

Als toevoeging nog: Het 'Bucket' deel van 'AWS Bucket' slaat op opslag. Deze dienst is een soort 'emmer' waar je al je bestanden in kan opslaan.

Je kan een Bucket aanmaken via een API, in bepaalde regio's (US of EU?) en het schaalt mee met wat je nodig hebt inderdaad en je hoeft je niet druk te maken om de hardware en backups etc.

https://docs.aws.amazon.c...test/dev/UsingBucket.html

[kcRogue]

Of je je druk moet maken over backups is een losstaande vraag lijkt me. Wel kan je versioning aanzetten om zo eventuele wijzigingen terug te draaien.

[ApexAlpha]

Ik bedoel meer ten opzichte van een situatie waar je zelf storage regelt in je eigen data center of locatie.

Hoe sla je het op? RAID5? Hoe vaak maak je een (off site) backup? Op tape of HDD? Hoeveel harde schijven heb je op locatie om direct te vervangen? Hoe vaak test je je backups? Hoeveel extra schijven koop je in voordat je je storage limiet bereikt en je organisatie niks meer kan opslaan? Hoe regel je versioning? Hoe zorg je ervoor dat je storage altijd via internet te bereiken is? Wat doe je met de HW die je niet meer nodig hebt? In hoeveel jaar schrijf je HDD's af? Welke merk gebruik je?

Al deze vragen lagen vroeger bij elke IT afdeling van elk klein-, midden- en grootbedrijf.

Nu huur je gewoon AWS of Azure en regelen zij dit allemaal voor je. Je hoeft alleen maar aan te geven hoeveel je wil en waar je het opgeslagen wil hebben. En zelfs dat kan gewoon automatisch met een API.

[kcRogue]

Redundantie is geen backup. Je bent nog steeds zelf verantwoordelijk voor je data te backuppen, voor het onwaarschijnlijke geval dat de hele S3 service eruit flikkert en je voor (on)bepaalde tijd niet aan je data kan. Als Fons van de marketing het verkeerde bestand verwijdert heb je verder niets aan je redundantie, want dan is die delete actie netjes gerepliceerd over het hele storage cluster.

[blinchik]

Op S3 buckets kan je natuurlijk ook wel versioning zetten. Fons van de marketing heeft in een correcte setup geen toegang tot een delete van die versions. Die oudere versions gaan als backup misschien zelfs achteraf naar glacier.

Maar je hebt natuurlijk 100% gelijk, dit is de denkwijze van AWS programmeurs - als systeembeheer wil je uiteraard je data offsite. Alleen wordt dat met AWS moeilijk, want een 2e cloud provider en al die traffiek over het internet kost pakken geld, en dan wordt het vaak afgedaan als nutteloos omdat je toch net versioning hebt. En uiteraard wil men ook nog eens alles online beschikbaar vanaf het internet, zonder VLAN, zonder IPS.

Dat zijn volgens mij de grote gevaren / uitdagingen aan cloud - programmeurs duidelijk maken dat de offsite/backup/vlanning/ips principes van vroeger nog steeds gelden, ook in de cloud wereld.

[CEx]

Backup's zowel on-site als off-site zijn gewoon onderdeel van de meeste cloud dienstverleners. Service level bepaalt de mate van 'bescherming'.

[Raymond Deen]

AWS bucket is meestal S3 storage, dus gewoon vergelijkbaar met een soort van FTP map.

edit: spelling...

[Reactie gewijzigd door Raymond Deen op 29 juli 2024 04:00]

[blinchik]

Het is wel iets moderner dan FTP, er zijn uitgebreidere permissies, versioning, tagging (en dus aparte lijsten met tagging aanmaken), etc

[sfranken]

Welk FS je gebruikt (permissies, versioning e.d) heeft niks met je toegangsmethode (FTP) te maken lijkt mij

[blinchik]

Het gaat verder dan alleen maar over het FS, dit is ingeintegreerd in de S3 bucket. Je kan aan de hand van gemaakte tags een aparte directorylijst opvragen. Als je geen permissie hebt op een bestand op het "filesysteem", wordt dat in de directorylijst ook niet getoond. Versioning kan je aansturen vanaf de bucket zelf, terwijl je via een ftp client niet zomaar een oudere versie kan opvragen van hetzelfde bestand.

[sfranken]

Dat snap ik, mijn reactie was meer om aan te geven dat het niet zo zwart/wit is als je in je eerste reactie deed vermoeden. Je hebt verder helemaal gelijk hoor, een FTP client zal niet veel kunnen met een S3 bucket

[Raymond Deen]

Probeerde op een beetje eenvoudige manier uit te leggen wat een s3 bucket is, maar je kunt er natuurlijk veel uitgebreidere uitleggen bij geven 🤯

[duqu]

zal ik toevoegen.

[Burgertrut]

Hoe komt het eigenlijk dat die stippellijn pop-overs niet werken op mijn iPad (heb het gevoel op touchscreen in zijn algemeen)?

[duqu]

het is een bekend euvel dat ze niet werken op mobiele apparaten. Ik kan helaas niet zeggen of dat in de toekomst wel zo gaat zijn.

[MsG]

Dat idee is afgeschoten helaas. Maar 1 regel CSS: (https://gathering.tweakers.net/forum/list_messages/1754385)

[biglia]

Het is goed mogelijk dat de aanvallers niet eens wisten dat ze te maken hadden met een server van Tesla. Ze scannen gewoon heel het Internet af.

[Pat-Juh]

Mogelijk ja, waarschijnlijk laten ze gewoon een sniffer alles afgaan tot ze beet hebben... Nu ben ik wel benieuwd hoeveel ze hebben gemined voordat ze opgemerkt werden... Dit zegt ook wat over het hele vermogen van het Tesla serverpark namelijk .

[SSDtje]

Kon dit erover vinden op wired.com:

This incident itself is just one example in an ever-growing list of high-profile cryptojacking compromises. Just last week, researchers from the security firm Check Point said that attackers made more than $3 million by mining Monero on the servers of the popular web development application Jenkins. The Tesla infection is particularly noteworthy, though, because it shows not only the brazenness of cryptojackers, but also how their attacks have become more subtle and sophisticated.

Red Lock's Kumar notes that the Tesla attackers were running their own mining server, making it less likely that it would land on malware-scanner black lists. The mining malware also communicated with the attacker's server on an unusual IP port, making it less likely that a port scanner would detect it as malicious. And the obfuscation techniques didn't stop there. The attack communications all happened over SSL web encryption to hide their content from security-monitoring tools, and the mining server also used a proxy server as an intermediary to mask it and make it less traceable.

En wat ik hier dan zoal uit begrijp, is dat het in dit geval weinig tot haast geen nut heeft gehad.
Ook niet heel vreemd natuurlijk, CPU's zijn immers niet heel erg geschikt voor het minen van cryptovaluta's.

[Origin64]

Sorry, maar je eigen server met non-blacklisted IP gebruiken, een onopvallende poort, en encryptie, is toch wel het minimum aan beveiliging wat ik verwacht van een cryptojacker. Anders ben je binnen 5 seconden gezien. Dat is niet subtle en sophisticated maar broodnodig. Je gaat niet inbreken om coinhive te draaien op iemand anders z'n server....

Het hangt van de crypto af die gemined wordt, of gpu acceleration veel nut heeft of niet.

[Reactie gewijzigd door Origin64 op 29 juli 2024 04:00]

[Rob Coops]

Nou nee niet echt, ze hadden niet toegang tot het hele server park en als je de post goed leest zie je dat ze gebruikmaken van AWS (Amazon Web Services) en Tesla dus vrijwel oneindig kan door groeien wat betreft processing power mochten ze dat nodig achten want cloud en zo...

Het enige waar dit iets over zou kunnen zeggen is hoe groot de pod is als je weet hoelang men toegang had en of hoelang men toegang had als je weet hoe groot de pod was. Omdat we hier over containers praten is het heel goed mogelijk dat Tesla simpel weg een paar containers had draaien in deze pod. Als de pod voldoende groot was zouden de de aanvallers tientallen containers kunnen gebruiken, of maar een of twee als het een kleine pod was, dat is simpel weg niet vast te stellen zonder toegang tot Tesla's AWS account.

Het zou me in het geheel niet verbazen als de aanvallers niet meer dan een hand vol containers gebruikte om geen argwaan te wekken. Immers in de cloud betaalt men voor gebruik niet voor rack space en dus maakt het nog al een verschil in de kosten als het verbruik omhoog schiet. Ook het laag houden van de CPU/memory footprint wijst er op dat men op zijn minst dacht dat een te hoog verbruik opgemerkt zou kunnen worden niet alleen als een CPU/Memory spike maar ook in de kosten voor de pod.

[Reactie gewijzigd door Rob Coops op 29 juli 2024 04:00]

[epdm2be]

Desondanks. Wordt het eens niet tijd om wat minder Cloud te doen en wat meer Local?
Want "vroeger" had je veel minder te maken met dit soort ongein en sinds dat iedereen maar "geconnecteerd" moet zijn en gegevens centraal verwerkt worden (door een handenvol supergrote bedrijven die dan uiteraard het mikpunt worden van criminelen) zijn er meer en meer van die problemen.

En als er lokaal iets fout gaat (al dan niet door criminelen) geeft dat minder last voor de omgeving dan wanneer het fout gaat bij een gecentraliseerd systeem waar teveel mensen afhankelijk van zijn.

Tesla kan toch evengoed hun upgrades doen bij het jaarlijkse onderhoud wanneer de auto toch in de garage staat, dus waarom hoeft dat nu persé over de Cloud?

[marco-ruijter]

Als jij een infrastructuur nodig hebt waarbij schaling belangrijk is. Dan heb je niks aan een lokale omgeving waarbij je totaal niet flexibel bent omtrent schaling. Ik denk dat je juist als bedrijf zijnde dat niet IT als core business heeft beter af bent bij een cloud oplossing dan een lokale infrastructuur te managen. Juist de "supergrote bedrijven" hebben IT (cloud) als core bussiness, je mag er dan over het algemeen vanuit gaan dat ze hun zaakjes beter op orde hebben qua beveiliging.

[Niet Henk]

Meh. Local kan net zo goed, als niet makkelijker verkeerd gaan. Daar moet je zelf je hele beveiligings- backup- en update-infrastructuur opzetten, en een fout zit in een klein hoekje. Met een IP/port scanner o.i.d. kan je het hele internet op een kwetsbaarheid proberen te scannen.

Daarnaast: AWS is zeker niet beïnvloed geweest, en heeft off-site backups (als je daarvoor betaald), dus is minder vaak beïnvloed.

Vroeger hadden we dit waarschijnlijk minder, omdat je vroeger lastiger miljoenen kon verdienen met een gehackte server. Nu dat wel kan, is er meer markt voor om die dingen te hacken.

[Mellow Jack]

Desondanks. Wordt het eens niet tijd om wat minder Cloud te doen en wat meer Local?
Want "vroeger" had je veel minder te maken met dit soort ongein

Niet mee eens... het enige verschil is dat er steeds meer noobs aan de knoppen zitten

Lokaal zou je nooit iets zonder firewall deployen... laat staan dat je clusters direct op het internet zou aansluiten

Nu het bij elkaar klikken van de services zo simpel is vergeten de eerder genoemde noobs om een fatsoenlijke architectuur te bouwen.... dus nee, lokaal is het net zo gevaarlijk alleen denken veel mensen dat de publieke cloud by default super veilig is

[PL JNS]

Leek vraagje, hoe komt een bedrijf als Redlock hier achter?

[Puch-Maxi]

Die zullen waarschijnlijk ook scannen naar onbeveiligde servers?

A few months ago, the RedLock Cloud Security Intelligence (CSI) team found hundreds of Kubernetes administration consoles accessible over the internet without any password protection.

Ja, dat lijkt het geval te zijn

[Reactie gewijzigd door Puch-Maxi op 29 juli 2024 04:00]

[LOTG]

Waarom is niemand bij Tesla dit opgevallen? Lijkt mij dat er toch iets van monitoring moet zijn voor hun infrastructuur, en gezien een miner waarschijnlijk veel resources vraagt zou ik denken dat iemand dat toch zou moeten zien als daar ineens een flinke spike optreed.

[Nha]

Omdat de heren criminelen daar ook wel aan gedacht hadden.
Uit dit artikel:

Het beveiligingsbedrijf vermeldt in zijn analyse dat de miningactiviteiten op verschillende manieren verborgen waren, zo maakten ze niet gebruik van een publieke miningpool om detectie op basis van ip of domein te omzeilen. Verder hadden ze het adres van hun pool achter Cloudflare geplaatst en was hun software geconfigureerd om op een poort te luisteren die niet standaard is. Ten slotte hadden ze hun miningsoftware zodanig geconfigureerd dat het cpu-gebruik niet ongebruikelijk hoog werd, wat zou leiden tot detectie.

Dan wordt het al iets lastiger om op te merken, en het is uiteindelijk toch opgemerkt.

[Mellow Jack]

Niet helemaal... het is bijv heel simpel om SSL offloading te doen op al het uitgaande verkeer, daarnaast verwacht ie een vorm van Identity & access management icm een Security Operations center die vreemd gedrag analyseert...

Daarnaast zouden er geen pods mogen draaien zonder onderdeel te zijn van een business value stream

[Nha]

Iets lastiger != onmogelijk.

Edit: dat er al geen wachtwoord nodig was zegt al veel over hun veiligheid he

[Reactie gewijzigd door Nha op 29 juli 2024 04:00]

[GodlikeGiles]

Dat wordt gemonitord. Wat denk je dat die RedLock er is komen doen? Dat die zelf zijn ingebroken bij Tesla om hun servers te screenen?

[jip_86]

Gebeurd niet alleen aan de serverkant. Moet gelijk denken aan dat bericht wat op internet circuleerde dat iemand een miningrig in zijn tesla had gebouwd om gratis te laden bij de superchargers
https://electrek.co/2017/...del-s-supercharger-power/

[RoestVrijStaal]

Interessante domein daar in die curl command. Dat zal wel van die crackers zijn

[anargeek]

Dat domein staat achter Cloudflare, dus zou best kunnen

[sam_vde]

Het is technisch allemaal wat verfijnder en complexer, maar van een bedrijf dat straks autonome wagens op de openbare weg loslaat lees je toch liever andere dingen.

Ik vraag me ook af in hoeverre dit soort technologie vandaag reeds een strategisch doelwit is. Controle over de wagens op de openbare weg overnemen, stel je even voor zeg.

[Finder]

Vreemd, maar mijn eerste gedacht was dat ze een manier hadden gevonden om stroom uit de 'gratis' Tesla-palen te gebruiken om crypto-currency te minen. Of breng ik nu een Tesla-rijder met een kofferbak vol AMD Radeon's op een idee...

[dbram]

• mmmm... afgaande op de screenshot domein naam xaxaxa.eu
• deze xaxaxa.eu gebruikt anti-ddos provider shovl.io die dan zelf weer bij OVH zit...

maarja de kans is groot dat ook deze gehacked was om sporen moeilijk traceerbaar te maken.

[Reactie gewijzigd door dbram op 29 juli 2024 04:00]

[GrooV]

Als de pool op een niet standaard poort zat dan ging deze niet via Cloudflare aangezien je daar alleen HTTP(s) verkeer kan doorsturen via poort 80 en 443. Dan werdt cloudflare alleen voor de dns gebruikt en was het IP gewoon zichtbaar en rechtstreeks

[Reactie gewijzigd door GrooV op 29 juli 2024 04:00]

[improperBunny]

De software luisterde op een poort die niet standaard was. Heeft dus verder niks met de pool te maken, alleen de aansturing van de mining software .

[GrooV]

Ah klopt, mijn fout. Maar zou juist een exotische poort niet moeten opvallen?

[leuk_he]

Draai eens "netstat -a" en vertel dan eens hoeveel connecties je ziet, en hoeveel er over een exotische poort gaan..

Bij mij zijn dat op mijn desktop er meer dan ik van plan ben uit te zoeken vandaag.