Beveiligingsfirma's demonstreren overnemen EA Origin-account na subdomeinkaping

De beveiligingsbedrijven Check Point en CyberInt tonen hoe ze accounts van EA Origin kunnen overnemen via een reeks technieken. Onder andere wisten ze een subdomein van ea.com in te zetten, waarmee doelwitten makkelijker in de val te lokken zijn.

Check Point en CyberInt gebruikten bij hun proof-of-concept voor het overnemen van een Origin-account een keten van methodes die vaker ingezet worden zoals phishing, session hijacking en cross-site scripting. In de video is te zien hoe ze via WhatsApp een doelwit verleiden om op een link te klikken, met de belofte van een week lang gratis Origin Acces Basic-toegang.

Meestal is dit een zwak punt in een aanval, omdat de persoon op wie de aanval gericht is kan zien dat het niet om een url van EA gaat, maar om een url voor een al dan niet gelijkende subdomein. De beveiligingsbedrijven wisten slachtoffers echter naar een daadwerkelijk subdomein van EA te lokken: eaplayinvite.ea.com.

Ze wisten het subdomein te kapen door een type dns-records, de CNAME-records, te analyseren. Ontwikkelaars gebruiken een CNAME-record, oftewel Canonical Name Record, om een subdomein te koppelen aan het domein waarin de content wordt gehost. In het geval van EA zou het om de naam van een marketingcampagne kunnen gaan die in de url wordt weergegeven, waarbij dat subdomein gekoppeld is aan een plek van bijvoorbeeld hostingprovider AWS.

Via de tool dig konden Check Point en CyberInt zien hoe eaplayinvite.ea.com via de CNAME-record was gehost. Toen die marketingcampagne was afgelopen, konden ze zelf de achterliggende AWS-record aanvragen. Bij de hostingprovider konden ze zelf een kwaadaardige site op die plek hosten waarna eaplayinvite.ea.com daar naartoe verwees. Zo wisten ze ook EA-cookies van gebruikers te onderscheppen en authenticatietokens te bemachtigen.

Check Point en CyberInt melden aan Ars Technica dat subdomeinen van grote bedrijven op deze wijze vaak te kapen zijn, omdat de devops-ontwikkelteams lang niet altijd goed met de beveiligingsteams communiceren. Cyberint heeft een tool online staan waarmee bedrijven kunnen controleren of ze kwetsbaar zijn.

Reacties (50)

[djwice]

NOTE FOR AWS USERS

Gebruik jij AWS net als in het voorbeeld van deze Hack?
Gebruik dan de speciale feature van Route 53 om een A-record (en AAAA-record) aan te maken naar hostnames binnen AWS.

Dus in je huidige configuratie CNAME vervangen door A en een kopie met AAAA.
Hiermee wordt de CNAME die je intern gebruikt niet gepubliceerd in het DNS record van je domein.

---
Voor DNS guru's: ja, dit klinkt absurd een A record naar een Host name, zeker voor een TLD, maar zelfs dat werkt bij AWS. In mijn geval zie ik dit resulteren in zo'n 12 simultane publieke IP-adressen voor mijn host (IPv4 & IPv6 gecombineerd).

__
Als je dan toch bezig bent, kun je direct ook DNS-based certificaat validatie instellen; dan worden je certificaten automatisch hernieuwd en vervangen zolang de records er in staan én je certificaten worden ingetrokken als je het record verwijderd.

[Reactie gewijzigd door djwice op 23 juli 2024 07:04]

[Erik1]

Praktisch gezien hebben ze dus de marketingcampagne niet goed opgeruimd. Wel de hosting bij AWS verwijderd maar niet het DNS record dat er naartoe verwijst. En omdat het een public cloud is kan iedereen die vrije hostnaam of IP adres in handen krijgen met wat moeite. Goed dat ze het onder de aandacht brengen want EA is vast niet het enige bedrijf waar dit soort foutjes voorkomen.

[Douweegbertje]

Dit is eigenlijk een vrij common attack methode die al vaak is toegepast. Genoeg tooltjes tot je beschikking zoals:

https://github.com/michenriksen/aquatone
en
https://github.com/OWASP/Amass

Het blijft helaas, net zoals vele andere zaken, een stuk bewustwording wat mist.

[Eagle Creek]

Kun je eens toelichten hoe het kan dat blijkbaar iedereen een subdomein behorende bij een actief domein kan registreren? Ik zou zeggen dat *.ea.com in dit geval volledig onder de autoriteit van EA valt. Dat is me ook na het lezen van het artikel en de gelinkte pagina mij niet duidelijk.

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 07:04]

[2cents]

Het gaat hier niet specifiek om wijzigen van het subdomein, maar van de target van het CNAME record.
bv. actie.ea.com verwijst met een CNAME DNS record rnaar een AWS hostnaam sp1248562.aws.com
Op deze server draait de actie website.
Na de actie wordt de website met de host door het marketingteam verwijderd, maar de CNAME niet uit de DNS gehaald.
Nu kan een ander dus een host bij AWS aanmaken die specifiek deze hostnaam sp1248562.aws.com gebruikt.
Dus de website die ze hier hosten is via de DNS naam actie.ea.com beschikbaar. Met alle gevolgen van dien.

[sjettepetJR.]

Dus eigenlijk het enige wat gedaan moet worden om dit op te lossen is het verwijderen van de link tussen actie.ea.com en sp1248562.aws.com?

[twjdeboer]

Exact! EA heeft en houdt controle over hun DNS-record voor het subdomein. Als ze in eerste instantie dat record hadden weggehaald, voordat de aws host vrijkwam, was er niks aan de hand geweest.

[Jay-v]

Behalve dan dat dat op aws niet kan.

if you create a load balancer named my-loadbalancer in the US West (Oregon) region, your load balancer receives a DNS name such as my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com.

Je hebt geen controle over het dik gedrukte deel.

If you'd prefer to use a friendly DNS name for your load balancer, such as www.example.com, instead of the default DNS name, you can create a custom domain name and associate it with the DNS name for your load balancer.

Dit kan alleen met domeinen waar je controle over hebt. Dat kan door bijvoorbeeld eacampaign.com te kopen wanneer ea het domein laat verlopen maar de oude cname niet opgeruimd heeft

[comecme]

Op die manier kan een hacker toch geen https verbinding opzetten? De browser verwacht op https://example.ea.com een certificaat dat bij de dns-naam hoort.

[2cents]

Een certificaat is makkelijk aangevraagd.
Ook met die naam.

[ronkerz]

Heel toevallig, is mijn account enkele dagen geleden gebreached. Niet door phishing maar door een brute force aanval. Ik heb al jaren geen gebruik meer gemaakt van mijn Origin account en ik was al vergeten dat ik het had. Ondertussen al weer toegang gekregen tot mijn account en beveiligd met 2fa.

Later heb ik even met EA help gesproken om te achterhalen hoe het was mis gegaan. In dit geval ging het dus om een brute force aanval die enkele maanden geleden in gang was gezet door middel van een botnet. Hij vertelde ook dat het relatief veel voorkomt waarbij het doel meestal het overzetten van FIFA coins of spelers is. Wat mij het meest shoqueerde is dat de medewerker van EA mij bedankte dat ik niet boos ben geworden op hem. Schijnbaar hebben de support medewerkers van EA het er maar zwaar mee.

[Cerberus_tm]

Hmm maar hoe kan dat dan? Brute force zou alleen mogelijk moeten zijn als je een heel makkelijk wachtwoord hebt?

[ronkerz]

Laat ik het zo zeggen, 12 jarige ik was zich niet zo bewust van de risico's. Was mij ook niet meer bewust dat ik dat account nog had.

[Dutch_CroniC]

En destijds waren er ook nog geen strengere password policies.
Je kon in principe gewoon hoi als wachtwoord gebruiken.

[Cerberus_tm]

O, aha!

[ViperXL]

Give me some time..... het is echt een kwestie van tijd maar inderdaad een makkelijk wachtwoord helpt veel

[Cerberus_tm]

Maar alleen als je toegang hebt tot de versleutelde database, en dat hadden de hackers toch niet? Ze konden alleen proberen in te loggen op afstand net als gewone gebruikers. Dan schiet brute force niet op.

[temp00]

Dat lijkt me eerlijk gezegd onzin. Als EA vatbaar zou zijn voor een brute force-aanval heb je alle reden om boos te zijn want zoiets is heel simpel tegen te gaan en ik kan mij ook niet voorstellen dat EA geen soft of hard limit heeft op foutieve inlogpogingen. Ik denk eerder dat je gewoon slachtoffer bent van the usual suspects: zelfde wachtwoord op meerdere diensten gebruiken of malware of vergeten ergens uit te loggen etc.

[ronkerz]

Uiteindelijk is het je eigen verantwoordelijk om een sterk wachtwoord icm 2fa in te stellen. EA heeft een hard limit bij meerdere foutieve inlogpogingen maar er werd dus gebruik gemaakt van een botnet. Wellicht zal hier en daar wat te verbeteren zijn kwa beveiliging. Heb zover ik heb kunnen zien geen captcha of iets dergelijks gehad.

[supersnathan94]

Dat er gebruik wordt gemaakt van een botnet zou het alleen maar makkelijker moeten maken om te achterhalen dat de inlogpogingen niet legit zijn. Heel snel achter elkaar requests met een andere hash vanaf een ander ip adres ergens random op de wereld zal never nooit een daadwerkelijk valide inlogpoging zijn. Zeker niet als je account dus al een tijdje inactief is en er ineens heeeeeel veel activiteit van rondom de wereld is.

[ronkerz]

Hier en daar is er dus ruimte voor verbetering bij EA. Heb er zelf geen vertrouwen in dat daar wat aan word gedaan.

[BryanD]

Als ex EA first-line call-center medewerker kan ik je vertellen dat het meestal wel mee valt met hoe boos Nederlanders en Belgen worden dat hun account gehackt is. Meestal is iedereen gewoon blij om het überhaupt terug te hebben en zijn ze blij dat EA nog best veel doet om hun verloren dingen terug te halen. Als het herhaaldelijk gebeurt is het natuurlijk wel kut en er zijn ook zat manieren waarop accounts "gehackt" worden waar mensen wel boos over worden (chatsupport uit India wil bijvoorbeeld nog wel eens de controle van de account gegevens niet zo heel serieus nemen....).

Maar als het inderdaad gaat om een legitieme hack poging via brute-force of gelekte passwords oid dan zijn de meeste mensen, in ieder geval aan de telefoon, wel redelijk relaxt en blij dat ze hun account terug krijgen. Heb je misschien via de Engelse chat gesproken met een medewerker? Die krijgen het namelijk wel best zwaar te verduren met de hele Amerikaanse / Engelse "klant is koning" mentaliteit.

[ronkerz]

Was dus een engelse/amerikaanse/indische Help Agent, was mij er niet van bewust dat EA Benelux ook zulke requests oppakken. De persoon sprak gebrekkig engels maar duidelijk te volgen, ook een typisch Indische naam. Ik ben inmiddels bezig om mijn origin te laten sluiten gezien ik hier niets meer mee doe.

[BlikHeineken]

"Hackers hadden de mogelijkheid om persoonlijke informatie van gamers te bemachtigen, aankopen te doen via de gehackte accounts en andere gebruikers in een soortgelijke val te lokken"

Klinkt nou niet echt als een storm in een glas water.
Als dit een veelvoorkomende hack zou zijn geweest zou EA, Origin toch behoorlijk in verlegenheid zijn gebracht.

[SunnieNL]

Het is ook niet direct een probleem wat bij EA alleen kan, dit kan bij alle niet goed opgeruimde marketing of development zaken die via cname gekoppeld worden aan aws en waar de cname achterblijft met een verwijzing naar een ip bij aws.

Met steam zou je dit net zo goed kunnen doen of met Amazon zelf, mits die opruiming niet goed gebeurd.

Kwestie van netjes opruimen. Degenen die de dns beheren horen gewoon te vragen tot wanneer die nodig is en het op die datum opruimen (of beter: de aanvraag en opruiming automatiseren)

[rko4u]

Deze actie wordt gedaan door zogenaamde ‘ethische hackers’ om een ‘proof-of-concept’ te geven. Dit misbruik kan leiden tot veel meer ellende. Voor je het weet heeft de klant zijn PC vol met malware staan en kan een hacker zijn hele netwerk overnemen. Fishing is een probleem, waarbij het zwakste punt de identificatie van de afzender is! De link wijst naar een ander domein!
Met deze optie kan de hacker dat probleem tackelen. Als de gebruiker overtuigd is dat hij met het juiste bedrijf te maken heeft, is fishing niet meer te onderscheiden. Het gevolg kan zijn dat er een hoop bedrijven besmet raken op deze manier (denk aan inbraak, ransomware). Dus nee, geen storm in een glas water!

[BlikHeineken]

Precies wat ik zeg, géén storm in een glas water.

[Verwijderd]

In de video zie je dat de hacker snel een aankoop doet met een vooraf goedgekeurde betaal mogelijkheid (paypal / creditcard), en alleen al daarom moet moet je dus geen snelle betaalopties linken aan je online accounts.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:04]

[Jay-v]

Ik heb vraagtekens bij deze source:

- "Next, the attacker uses an account of their own at the same cloud provider and requests the same provider-internal DNS name originally used by the campaign."
Dat kan helemaal niet, er zit altijd een stukje randomness in de DNS naam bij AWS. Zelfs in het artikel zie je dat terug:
sim-campfire-prod-alb-<RANDOM>.us-east-1.elb.amazonaws.com

De aanval zoals beschreven kan alleen werken als de CNAME naar een domein verwijst waar de aanvaller controle over kan krijgen. De andere pagina waar naar gelinkt wordt: https://takeover.cyberint.com/ legt het middels plaatjes dus wel juist uit.

Overigens is het best practice om een ALIAS record te gebruiken: https://aws.amazon.com/pr...-53-create-alias-records/

[Reactie gewijzigd door Jay-v op 23 juli 2024 07:04]

[seapip]

Volgensmij kan ik gewoon een https certificaat krijgen van letsencrypt voor een subdomein door deze op zich staand te valideren, volgens mij is het dan niet nodig om ook het hoofddomein te valideren.

Meer info: https://community.letsenc...in-owners-permission/4205

[Reactie gewijzigd door seapip op 23 juli 2024 07:04]

[Jay-v]

Je hebt gelijk, dat kan via http validation. (Middels een file op je webserver). Aangepast.

[Webgnome]

Gelukkig heb ik nog niet gehoord van mensen die hijacking hebben ondervonden.

Dat iets nog nooit is gemeld wil nog niet zeggen dat het niet gebeurd. Maar om heel eerlijk te zijn denk ik dat dit soort dingen echt een storm in een glas water zijn.

[Verwijderd]

Ze tonen hoe ze .... het is dus een proof of concept dat nog niet in het wild gespot of geexploiteerd was.

[xxxneoxxx]

..bij EA en deze url.

Buiten deze specifieke url gebeurt dit vast wel vaker.

[SuperDre]

Wel pas nadat EA het probleem heeft opgelost gelukkig. Dat lijkt wel even te missen in het artikel.

[Dutch_CroniC]

Jawel hoor, pas nog met Epic/Fortnite.
Dan wel niet via whatsapp volgens mij maar eigelijk precies t zelfde

[robvanwijk]

Maar om heel eerlijk te zijn denk ik dat dit soort dingen echt een storm in een glas water zijn.

Dat dacht ik ook toen ik voor de eerste keer hoorde over SQL injectie en XSS en CSRF en ... Je moet aan zoveel randvoorwaarden voldoen om het écht te misbruiken, dat zal in de praktijk toch nauwelijks voorkomen? Wel dus... :-o

Aangezien iedereen zijn klanten een "mooi" (en makkelijk te onthouden) domein wil laten zien, maar tegelijkertijd allerlei zooi "in de cloud" wil gooien, zou het wel handig zijn als we even een standaard ("industry best practice") bedenken om dat dan ook goed te doen. Dus nee, het zit er dik in dat dit een "echte storm" is en SDH het nieuwste acroniem wordt waarvan iedereen denkt "oh god, niet weer, ik word hier zo moe van!".

[djwice]

Die zijn er al lang hoor :-)
En de meeste managers geloven niet dat hun site zo iets überhaupt overkomt.
Na jaren lobbyen heb ik op een vrijdag gewoon de stoute schoenen aangedaan en content security monitoring aangezet.
Binnen 1 week vonden we iemand die de API aan het hacken was om gegevens van een andere klant te achterhalen. De persoon is juridisch aangepakt.

Dus mijn tip: haal A+ in observatory scanner van Mozilla (rechts boven krijg je na een scan steeds de meest urgente verbetertip). En zet active monitoring in van csp atrack reports.

De OWASP geeft inzicht in mogelijke aanvallen, gesoorteerd op meest voorkomende en impact. De site heeft ook een pdf met uitleg hoe je voor de meest populaire programmeertalen die aanvallen nutteloos maakt.

En de gratis training site https://www.certifiedsecure.com/ helpt je begrijpen hoe aanvallers te werk gaan en hoe je dit kunt afweren.

[Reactie gewijzigd door djwice op 23 juli 2024 07:04]

[supersnathan94]

Jeez. Wij hebben net alle security headers aangepakt. Volgens securityheaders.com nu op A en sommige domeinen zelfs A+. Via mozilla observatory kom ik nu uit op D rating. Iets met csp headers en unsafe-inline en unsafe-eval.

Ja die dingen wil je niet hebben, maar het kan gewoon niet anders. Als je gebruikt maakt van moderne Javascript frameworks dan zijn er altijd dependencies die eval gebruiken. Helaas zijn er vaak geen alternatieven of wordt het onwerkbaar traag (dat is dan ook vaak de reden waarom ze evaluation gebruiken). Wij zijn nog steeds op zoek naar manieren om dit te kunnen mitigeren, maar het lijkt vrijwel onmogelijk om dit te kunnen doen als je iets als react of angular gebruikt.

[djwice]

Je kunt vaak in je build die eval al uitvoeren en de css en javascript die geïnjecteerd moet worden als losse files publiceren, op die manier heb je geen eval meer nodig in de client. Mijn ervaring is dat het ontwikkelaars ongeveer 2 dagen tijd kost om te doorgronden hoe dat moet en het ook door te voeren in de build. Het meest lastigste is om hen er van te overtuigen dat het moet gebeuren. Als ze zo ver zijn en ze hebben het doorgevoerd, zijn ze vaak juist blij omdat de applicatie minder complex is geworden en het een stuk makkelijker is geworden om de bugs die in de client applicatie gevonden worden op te sporen en te relateren aan je bron code.

[Reactie gewijzigd door djwice op 23 juli 2024 07:04]

[supersnathan94]

Ook als je het als losse files aanbied wordt er nog steeds een eval gedaan toch? Daarnaast is het idee van eval toch juist dat het runtime dynamische code oplevert? Als je het buildtime kunt evalueren heeft het geen nut om het op deze manier op te schrijven aangezien je dan net zo goed normale code had kunnen schrijven.

Als jij een manier weet om het eruit te krijgen dan houd ik me aanbevolen aangezien ik nu een CMS heb wat het er te pas en te onpas inzet.

[djwice]

De eval wordt door de scripts (bijvoorbeeld bij webpack) vaak gebruikt om de code die het moet injecteren te parsen. Als je dat parsen al in je build uitvoert is de eval in runtime verdwenen.

Helaas zie je in de praktijk veel dan in runtime alleen een naam (class of id) aan de code wordt toegevoegd in runtime, dat kan heel goed in build time gecombineerd met slimme naamgeving. En scheelt bovendien duplicate code met alleen andere id's. En het scheelt bovendien render tijd, zeker als je h2 (http/2) gebruikt; de browser laad de code dan parallel en het scheelt een parse en injectie stap; soms scheelt het zelfs een render blocking script.

[Reactie gewijzigd door djwice op 23 juli 2024 07:04]

[supersnathan94]

AH okee. En hoe geef je iets als webpack dan mee dat hij build time moet evalueren? Dan kan ik eens kijken of we het eruit kunnen kloppen.

[djwice]

Hierbij zal ik je dan een voorbeeld geven nieuws: Dienst achter cryptowallet wijt omleiding naar phishingsite aan dns-h...

[BlikHeineken]

De Israëlische beveiligers Check Point Research en CyberInt hebben zijn zo gek nog niet.
Goed gevonden van die gasten!
Vreemd dat de fout al zo lang bestaat en EA, Origin dit nooit zelf hebben ontdekt.
300 miljoen gebruikers wereldwijd!
Gelukkig heb ik nog niet gehoord van mensen die hijacking hebben ondervonden.

[SuperDre]

Zoals je kunt lezen is dit niet EA/Origin specifiek, maar gebeurd dit veel vaker..

[djwice]

Een hele goede reden om dus NOOIT sub-domeinen te gebruiken van een domein waar je cookies op zet.
Zet je cookies op www.domain.tld -> geen subdomeinen zoals: campagne.www.domain.tld
Zet je cookies op domain.tld -> geen subdomainen op je hele domein.

Zo voorkom je dat informatie van de ene naar de andere applicatie lekt.
Het is dus uiterst belangrijk dat je de login-applicatie host op een sub-directory van het sub-domein waar de applicatie op staat die je wil authenticeren.

Het kan anders zijn dat je per ongeluk informatie lekt naar een campagne domein of andere applicatie die deze informatie niet mag ontvangen, zoals in het voorbeeld van deze hack; de marketing campagne - sterker nog in dit geval de nieuwe partij die een vervangende site host op de oude campagne URL.

---
Grappig dat deze 0 wordt ge-mod. Bovenstaande voorkomt namelijk de uitvoerbaarheid van de aanval, zelfs ná een succesvolle DNS high-jack; het stelen van de sessie token wordt voorkomen.

[Reactie gewijzigd door djwice op 23 juli 2024 07:04]

[pe0mot]

Het is dus niet DNS kaping maar.....
AWS kaping omdat IP en cookies worden hergebruikt (omdat DNS niet is opgeschoond na verwijderen site).
"afgelopen, konden ze zelf de achterliggende AWS-record aanvragen", Wat is een AWS-record, wordt hiermee bedoeld het IP nummer met een quasi cryptisch subdomein?