Uber wijst Lapsus$-hackers als daders van recente hack aan

Uber zegt dat de hackers die het bedrijf vorige week aanvielen, van de Lapsus$-groep waren. Lapsus$ is de afgelopen maanden hard gegroeid en bekender geworden. De aanvallers spamden een tweetrapsauthenticatieprompt op een werknemer, totdat die het verzoek accepteerde.

Uber geeft in een bijgewerkte blogpost meer informatie over de grote hack waar het bedrijf vorige week mee te maken kreeg. Toen bleken aanvallers veel interne toegang te hebben gekregen tot bedrijfsinformatie. In de update herhaalt Uber wat het eerder al zei: dat er geen gegevens van gebruikers buit zijn gemaakt. Het bedrijf zegt nu ook voor het eerst dat de Lapsus$-hackersgroep vermoedelijk achter de aanval zit. Uber baseert zich daarbij op dezelfde aanvalsmethode die de groep eerder inzette.

Lapsus$ is een groep van overwegend jonge hackers die sinds eind 2021 actief werd. De groep richt zich op grote bedrijven en probeert die te infiltreren en zo snel mogelijk veel informatie buit te maken. Lapsus$ lijkt niet geïnteresseerd in het verspreiden van ransomware of in het gijzelen van die informatie. De groep lijkt enigszins professioneel georganiseerd, maar veel minder dan de meeste cybercriminele bendes die wel ransomware versturen. De groep zat eerder al achter grote aanvallen op onder andere Microsoft. Begin dit jaar viel de groep managedserviceprovider Okta aan. Securityexperts vreesden toen voor mogelijk grote gevolgen waarbij kleinere bedrijven die klant waren van Okta zouden worden gehackt, maar die gevolgen bleven uit. Lapsus$ had waarschijnlijk niet genoeg informatie verzameld om grote schade aan te richten.

Uber geeft in de update ook meer informatie over hoe de hackers te werk gingen. Ze zouden de inloggegevens van een externe werknemer online hebben gekocht. De laptop van die werknemer was eerder nog geïnfecteerd met malware en dat leidde ertoe dat de gegevens werden gestolen. Om in te loggen op het Uber-netwerk was tweetrapsauthenticatie nodig. De hackers bleven net zo lang een verzoek sturen totdat de werknemer die uiteindelijk accepteerde. Vanaf daar konden de aanvallers bij de gebruikersaccounts van andere werknemers komen. Ze konden daarna toegang krijgen tot de G Suite-applicaties en Slack.

Door Tijs Hofmans

Nieuwscoördinator

20-09-2022 • 08:42

42

Reacties (42)

Sorteer op:

Weergave:

https://therecord.media/l...ript-kiddies-are-alright/

Interessante podcast over deze groep. Ze gaan niet heel geavanceerd te werk maar weten kennelijk net op de juiste knoppen te drukken om toch ergens binnen te komen.
Uiteindelijk komt het toch weer bij menselijk falen terecht.

Als je continue 2FA meldingen krijgt en je accepteert die zomaar, zonder het te melden, dan doe je als werknemer ook iets fout.

Ik zou zeggen geef trainingen, scherm vooral externe medewerkers verder af van je (cruciale) systemen en doe regelmatig checks op je infrastructuur.
Als IT de boel zo instelt dat je om de haverklap een 2FA melding krijgt om interne applicaties en pagina's te gebruiken, doet het bedrijf ook iets fout.

De vraag is hier of de gebruiker het aan IT heeft gemeld dat die 2FA-spam binnenkrijgt, en zo ja, wat IT heeft opgedragen te doen. Ik kan het me prima voorstellen dat IT het afwimpelt als "het is een bug ofzo, we gaan ernaar kijken [ticket prio: onderaan]. Ondertussen klik je maar op OK als je inlogt anders niet."
Dat is ook de mening van vele security experts. Te veel MFA meldingen is ook weer gevaarlijk simpelweg omdat mensen het gaan aanzien als een zoveelste melding die ze weg te klikken hebben. Toegegeven, dat risico loop je altijd, ook wanneer je het niet vaak hoeft te doen.

Spijtig genoeg heb ik een CISO die voor bepaalde applicaties vereist dat elke login een MFA triggert. Maar laat dat dan weer net iets zijn dat sommige MFA providers weer niet mogelijk maken voor individuele apps.
Ze (Lapsus) deden zich voor via een whatsapp bericht naar de gebruiker dat zij juist de IT-afdeling waren en dat de gebruiker even op "Akkoord" moest klikken om van alle meldingen af te komen, storing of zo en excuus voor het ongemak blah blah blah.

Ja die werknemer heeft boter op z'n (m/v) hoofd. Maar ik ken ook een verhaal uit de praktijk van iemand die een "betaalverzoek" kreeg van de "CFO" via Whatsapp. Die Whatsapp gaf aan dat hij in een meeting zat en even snel iets moest regelen. Werknemer checkt in Teams of dat klopt: ja, teamleider/CFO zat inderdaad in een meeting met een andere VP die gevraagd had kunnen worden of het klopte. Op dat moment dus in een meeting (Status 'Bezet') en 'dus' klonk het wel plausibel genoeg. Werknemer was op dat moment thuis, met andere dingen bezig in de tussentijd, en ja die controle via Teams .. dat leek toch te kloppen?

Afijn. De rest is geschiedenis. Schade viel mee achteraf bezien.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 15:57]

Als een gewone gebruiker met klikken autoriteit kan uitoefenen mankeert er iets aan de software. Bij Uber is dat een onvermijdelijk probleem omdat het allemaal prive-systemen zijn.
Het is natuurlijk een combinatie van alles. Hoezo kun je met één MFA overal bij. Hoezo staan er powershell scripts waar de credentials ingebakken zijn op een share die kennelijk toegankelijk is. Hoezo gebruik je een 'push-to-confirm' MFA in plaats van het overtikken van een code die je ontvangt, et cetera.
Als IT de boel zo instelt dat je om de haverklap een 2FA melding krijgt om interne applicaties en pagina's te gebruiken, doet het bedrijf ook iets fout.
Ik vind die hele ja/nee prompts twijfelachtig. Gewoon überhaupt.
Hoe vaak die terugkomen zou niet zo relevant mogen zijn mijns inziens.

Die prompts met ja/nee als two-factor zijn leuk makkelijk en vriendelijk maar volgens mij lever je heftig in op effectiviteit tegenover gewoon TOTP tokens/apps.
Snap niet waarom o.a. google zo graag heeft dat je two-factor met die prompts gebruikt.
Misklik is zo gemaakt.
Zelfs als je heel goed beter weet.

Per abuis zo'n cijfersreeks ergens inkloppen is toch een stuk moeilijker.

[Reactie gewijzigd door Polderviking op 23 juli 2024 15:57]

Gewoon Yubikeys gebruiken. Dingen zijn supersimpel, kunnen niet overspoeld worden met pushberichten (er zijn geen pushberichten) en kunnen (momenteel ten minste) niet onderschept worden via pishing.

Google is hier al erg lang een groot promoter van (securitykeys).
De broekzak zit zo aardig vol.
- telefoon
- sleutels
- plastic cards
- Yubikey
Het risico van verlies/diefstal, daardoor geen toegang, en het aanvalsvlak neemt met elke extra device weer toe.
Ja zo'n ding is veilig, maar ook de balans werkbaar/veilig gaat de verkeerde kant op.
Haha, ik heb al meer dan 3? jaar niets ander mee op zak dan mijn telefoon. De yubikey die ik gebruik is een Nano dus die zit gewoon in vast in mijn laptop.

Ja zo'n ding is veilig, maar ook de balans werkbaar/veilig gaat de verkeerde kant op.
Dat is mijn punt juist, een yubikey (of een andere FIDO2 oplossing) zijn simpel en laagdrempelig.
Helemaal mee eens.

Een 2FA krijg je alleen toegestuurd als je net een authenticatie actie aanvraagt.
Als je er willekeurige binnenkrijgt, dan weet je dat er iets niet klopt.
Als je er talloze achter elkaar binnenkrijgt (bijvoorbeeld in een meeting of buiten werktijd), en daar erger je je aan, dan kan je beter het toestel uit zetten. Waarom dat niet bij mensen op komt weet ik niet.

Het probleem is waarschijnlijk dat veel mensen hun privetelefoon gebruiken voor 2FA omdat de baas geen werktelefoon wil verschaffen. IMO is dat een probleem opzich. Als mijn privetelefoon thuis stuk valt en bij de reparateur ligt, dan valt er dus ook een stukje bedrijfsprocess stil |:(
Of werkt de 2FA verkeerd? In plaats van een pushmelding naar een telefoon met een authenticator app, zou je ook een fysieke key kunnen gebruiken (yubikey o.i.d., al dan niet met fingerprint scanner) - die kán geen pushmeldingen ontvangen en werkt alleen wanneer de eigenaar daar bewust voor kiest.
Het zijn meer social engineers dan hackers. Aan de andere kant: dat was Kevin Mitnick ook. Phone phreaking en programmeren waren niet zijn kwaliteiten.
De hackers bleven net zo lang een verzoek sturen totdat de werknemer die uiteindelijk accepteerde.
Dat wekt toch irritatie? En dat is ook verdacht dat er iets niet klopt, want hij had geen foute wachtwoord en of foute 2factor authenticatie gehad? Dus waarom die verzoek, zoiets moet je het even controleren waar die bericht vandaan komt en ook aan systeembeheerder en of netwerk beheerder vragen!
Of is hij gewoon een sukkel of ignorant?
Het kan ook dat die verzoeken bijna gelijktijdig gedaan werden terwijl iemand er al een verwachtte.
Of dat er vaker problemen zijn dat die verzoeken met vertraging aankomen of dat de verzoeken hoe dan ook al erg vaag zijn om te weten waarvoor het is.
" Om in te loggen op het Uber-netwerk was tweetrapsauthenticatie nodig. De hackers bleven net zo lang een verzoek sturen totdat de werknemer die uiteindelijk accepteerde. "

Ik vind bovenstaande toch wel een gebrek aan de Microsoft authenticator (ik vermoed dat deze is gebruikt), in mijn eigen werksituatie merk ik ook dat ik regelmatig een melding van de authenticator krijg, waarbij mij niet altijd meteen duidelijk is waar die vandaan komt.
Als je dat krijgt, dan moet je toch gaan afvragen of je inloggegevens niet zijn gelekt of dat iemand je account continue probeert te herstellen. Meld dit zeker aan IT-beheer!

Ik krijg die melding nooit, enkel bij het inloggen (nieuwe computer/sessie) of bij account herstel.

Overigens vind ik het systeem van MS wel erg fijn. Geen gedoe met een nummer invullen en het werkt erg snel.
Meestal is het wel te verklaren, bijvoorbeeld door teams die nog in moet loggen oid.

Maar o.b.v. de melding in m'n authenticator kan ik niet zien waar het verzoek vandaan komt.
Het zou beter zijn als de authenticator zou melden: "teams stuurt een inlogverzoek" oid, dan kan ik het al makkelijker herleiden.
Omdat ik enkel de optie ja en nee heb in de Microsoft authenticator is de verleiding om altijd op ja te klikken groot. De eenvoud bevorderd het gebruiksgemak, maar het verminderd de veiligheid/bewijstzijn.
Expliciet een nummer overnemen bevorderd het bewustzijn en de veiligheid, maar zorgt voor een mindere gebruikerservaring.
Bedoel je die waar je een nummer moet selecteren? 33,33% kans dat een aanvaller de goeie kiest versus ~0,00% bij overnemen via airgab (screen to screen).
Dat systeem is sinds kort bij ons aangepast, je moet nu zelf het nummer intypen ipv te selecteren.
Ik veronderstel dat die aanpassing bij MS zit en niet bij onze IT.
Geen gedoe met een nummer invullen en het werkt erg snel.
En hier zit ook meteen je probleem, een meldingen waar je veel te makkelijk akkoord mee kunt gaan. Zelfs een oplettende gebruiker zou hier de fout in kunnen gaan.
Als het niet duidelijk is waar die vandaan komt, dan accepteer je hem toch niet? Dat is het hele punt van 2fa...

Edit: sterker nog, als je regelmatig meldingen krijgt zonder reden, dan zijn hoogstwaarschijnlijk je inloggegevens in verkeerde handen (of je it afdeling is incapabel). Beter dat je je inloggegevens reset en security hiervan op de hoogte stelt.

[Reactie gewijzigd door Tiddo op 23 juli 2024 15:57]

Of er is een process dat in de achtergrond of op een andere machine draait dat continue verzoeken aan het sturen is. Stel dat je aanmeld op een machine die bijv. niet door een conditional access policy gaat en daar start een app zoals Teams, ik kan je zeggen: die blijft je spammen met authenticatieverzoeken.
Dat betekent dat die app dus jouw wachtwoord heeft opgeslagen, en in de achtergrond gebruikt? Dat is niet bepaald veilig...
Dan nog gaat op dat je niet op die onbekende verzoeken in moet gaan.

Dit nieuws toont nogmaals waarom: omdat je de vraag niet zomaar kan vertrouwen en de vraag komt omdat er iets aan de hand is wat waarschijnlijk een te groot risico is.
Dat is niet hoe mensen denken over software, zeker niet van MIcrosoft. Ik kan je ook wel vertellen dat het verdomd aanlokkelijk is om gewoon op OK te klikken als je telefoon de hele nacht ligt te pingelen.
Bolletje Moderator Harde Waren @T-8one20 september 2022 09:16
Bij de Microsoft Authenticator app staat er een (geschatte) locatie en device bij. Ook krijg je bij onbekende devices vaak als extra security nog een code te zien die je vervolgens op je telefoon aan moet klikken uit een rij van 3 (bijv. 60 - 82 - 13).

Ik krijg daar nooit random verzoeken van. Is nog wel een idee om in te loggen op je account en kijken naar je inloggeschiedenis. Staan ook gefaalde pogingen bij met meer info.

[Reactie gewijzigd door Bolletje op 23 juli 2024 15:57]

Ik zou liever zien dat apps kunnen meegeven welke app ze zijn en vanop welke PC ze vandaan komen. Dat geeft mij niet alleen meer vertrouwen, maar maakt het ook eenvoudiger voor de gebruiker om op zoek te gaan naar welke app zich mogelijks aan het misdragen is zonder dat je moet gaan zoeken in de logs op Azure.
Ik heb dit nog nooit gezien bij een zakelijke Office365 omgeving, krijg jij deze info bij een persoonlijk Microsoft account?
Heb ik nu bij persoonlijk Microsoft account (wel betaalde account). Daar is het al een tijdje. Is nu ook beschikbaar voor business.
Zie hier: https://learn.microsoft.c...n/how-to-mfa-number-match

"When a user responds to an MFA push notification using the Authenticator app, they'll be presented with a number. They need to type that number into the app to complete the approval."

Bij mijn werkgever is het nog met password + OTP (kan je Google Authenticator of MS gebruiken).
Of met smartcard (physical) en password.
Thanks, hier was ik nog niet vanaf. Zie ook deze optie die ook de locatie gegevens toevoegd: https://learn.microsoft.c...to-mfa-additional-context
Klopt ja.

Die 2 samen zorgt er wel voor dat het veel minder waarschijnlijk is dat je hem per ongeluk goedkeurd zoals beschreven in het artikel. Je moet nog een code invoeren die overeen moet komen.

Bij weinig gebruikte devices is het dan de code invoeren in een veld. Bij bekende devices kan je de code kiezen uit een rijtje van 3.
RDP knalt er hier om de haverklap uit waarna je moet herauthentificeren. Ook moet je voor de interne wachtwoordmanager zowat elk uur weer opnieuw inloggen via Microsoft. Intern gehoste diensten zijn gaar en onthouden je wachtwoord niet, waardoor je uiteindelijk meermaals per dag moet inloggen.

Veiligheid is prima, maar dit is gewoon drempels opwerpen waardoor mensen gefrusteerd raken en manieren zoeken om dat te omzeilen.
Herauthenticatie voor een wachtwoordmanager is helemaal niet vreemd. Het is 1 van die stukjes software die enorm veilig hoort te zijn maar dat betekend ook veilig op momenten dat jij besluit van je PC even onbeheerd achter te laten. Ik kan ook geen uitspraken doen over hoe gevoelig interne informatie is in jullie onderneming, maar het niet onthouden van wachtwoorden is ook daar gewoon een manier om als extra beveiligingslaag te dienen.

Als iedereen verantwoord zou omgaan met alles, moet men ook geen drempels opwerpen. Maar hoeveel mensen loggen er actief uit op systemen wanneer ze gedaan hebben? Dat zijn er ook niet veel. Klik maar op het kruisje, kan geen kwaad.
Het een sluit het ander niet uit.. Of het klopt? Geen idee. Maar nu roepen dat die gast dus niet erachter zit is veels te voorbarig zonder bewijs
Ik stel het daarom ook als vraag. Ik had namelijk wel verwacht dat die GTA-hacker Lapsus$ zou noemen als hij daar een deel van was, maargoed, ik weet helemaal niet wat zulke hackergroepen voor regels hebben.
Vergeet ook niet dat Uber zelf baat heeft bij het aanwijzen van een bekende (grote) hackersgroep of dat nu exact waar is of niet, dat klinkt beter dan een enkele random 18 jarige die even binnendringt via social engineering en op het gehele netwerk kan komen...
Feit blijft wel dat expres liegen veel grotere problemen op gaat leveren als dat eenmaal uitlekt. Mij lijkt het niet logisch dat men liever dat risico loopt dan toegeven dat het een scriptkiddie was.
intussen is Uber ook mensen aan het aannemen op het gebied van security
https://www.reddit.com/r/...iring_security_engineers/
Ze zouden de inloggegevens van een externe werknemer online hebben gekocht.
In het nieuwsbericht staat steeds "ze" (meervoud), maar hoe weten we dat (het meerdere personen zijn)? Het bericht leest realistischer als je één hacker, lid van de lapsus-groep leest. Ik ben meestal ook alleen als ik iets online koop.
De hacker zou de inloggegevens van een externe werknemer online hebben gekocht.

[Reactie gewijzigd door Sando op 23 juli 2024 15:57]

Op dit item kan niet meer gereageerd worden.