De cybersecurity-industrie is weer eens in rep en roer na het Uber-beveiligingsincident. Vooropgesteld: dit had niet voorkomen kunnen worden door een enkele technologische oplossing. Het is ook geen inbreuk waarbij één persoon, bedrijf of provider de schuldige was. Wel zitten in de aanval een aantal interessante elementen waar wij als cybersecurity-specialisten van kunnen leren.
De inbreuk werd voor het eerst werd gemeld op 15 september. Een (naar verluidt) 18-jarige aanvaller was blijkbaar in staat was om de it-infrastructuur van het bedrijf te hacken en toegang te krijgen tot gebruikersgegevens en gemelde kwetsbaarheden op Ubers HackerOne-account. Veel van de analyses zijn gericht op het menselijke element: social engineering en frustratie door multi-factorauthenticatie. Maar het echte keerpunt van de aanval vond plaats na de eerste toegang. De beveiligingsupdate van Uber van 19 september beantwoordde enkele vragen (en riep nieuwe vragen op) door Lapsus$ te noemen als potentiële aanvalsgroep.
De vraag die gesteld moet worden is: maakt het uit wie de aanvaller was of hoe hij binnen is gekomen? Als je als beveiligingsprofessional een ‘assumed breach’-standpunt hebt, dan is alles wat er na die eerste entree gebeurde niet alleen nieuwswaardig, maar moet dit ook tot nieuwe acties leiden.
Het CyberArk Red Team en Labs ontleedden de Uber-hack verder, met de nadruk op de hard-coded credentials die naar verluidt werden gebruikt om beheertoegang te krijgen. We zullen ook laten zien hoe gestapelde verdedigingen samen kunnen werken om gerelateerde aanvallen te voorkomen.
Wat we al weten over de aanval
- Stap 1: Initiële toegang
Door toegang te krijgen tot de credentials voor de vpn-infrastructuur van Uber kon de aanvaller de it-omgeving van Uber binnendringen.
- Stap 2: Ontdekking
De gebruiker wiens account werd gehackt had waarschijnlijk geen uitgebreidere of unieke toegangsrechten tot kritieke bronnen, maar hij of zij had wel toegang tot een netwerkshare, net als andere Uber-werknemers. Ofwel was deze netwerkshare toegankelijk, ofwel verkeerd geconfigureerd om de access control list te kunnen lezen. De hacker vond vervolgens een PowerShell-script met hard-coded geprivilegieerde credentials voor Ubers privileged access management (pam)-oplossing binnen de netwerkshare.
Kleine kanttekening: zowel it-medewerkers als ontwikkelaars automatiseren vaak processen door scripts te schrijven waarvoor een of ander authenticatiecredential nodig is, bijvoorbeeld handmatige backups of het genereren van aangepaste rapporten door gegevens uit databases te halen. Deze credentials kunnen van alles zijn, van geprivilegieerde tokens en ssh-sleutels tot api-tokens en andere soorten wachtwoorden. Het is gebruikelijk dat ontwikkelaars deze referenties in de code inbouwen (of hard-coden) om tijd te besparen en automatisering te verzekeren. Dit maakt het moeilijk om de referenties te beheren en te roteren, omdat ze open staan voor iedereen met toegang tot de code. De hard-coded referenties die bij de inbraak bij Uber werden gebruikt, gaven beheertoegang tot een pam. Deze credentials lijken al een tijdje niet te zijn geroteerd, waardoor ze aanzienlijk eenvoudiger te misbruiken zijn.
- Stap 3: Toegang tot het pam-systeem en privilege-escalatie
De aanvaller kon de privileges verder verhogen door de hard-coded admin-credentials van het pam te stelen.
- Stap 4: Toegang tot pam-systeem-secrets en toegang tot kritieke bedrijfssystemen
De aanvaller verkreeg uiteindelijk ‘verhoogde rechten voor een aantal tools’, volgens een update van Uber. De kans op schade was groot door toegang te krijgen tot de secrets van de pam-oplossing. Volgens berichten kreeg de hacker toegang tot de sso, consoles en tot de cloudmanagement-console, die Uber gebruikt om vertrouwelijke klant- en financiële informatie op te slaan.
- Stap 5: Exfiltratie van gegevens
Hoewel Uber het incident nog steeds onderzoekt, bevestigde het bedrijf dat de aanvaller ‘enkele interne Slack-berichten heeft gedownload, evenals toegang tot of het downloaden van informatie van een interne tool die ons financiële team gebruikt om sommige facturen te beheren.’
Tips
Er zijn wel wat tips te geven voor het beveiligen van embedded credentials De eerste stap om een dergelijke aanval te voorkomen is uiteraard het verwijderen van embedded credentials. Advies is hiermee te stoppen en een inventarisatie uit te voeren om alle hard-coded credentials te identificeren en te verwijderen die mogelijk aanwezig zijn in code, paas-configuraties, devops-tools en intern ontwikkelde toepassingen. Dit is gemakkelijker gezegd dan gedaan. Focus daarom eerst op de meest cruciale en krachtige credentials en secrets van de organisatie, en breidt deze best practices in de loop der tijd uit om het risico geleidelijk te verminderen.
Daarnaast zijn andere maatregelen te overwegen voor het omgaan met hard-coded credentials. Het grootste risico komt nog steeds voort uit diefstal van credentials. Aanvallers worden steeds bedrevener in het omzeilen van MFA door gebruik te maken van een breed scala aan vectoren en methoden. Het Uber-verhaal bevat zelfs meerdere MFA-aanvalstechnieken. Medewerkers zijn de poortwachters, dus leer hen routinematig om phishing te herkennen en deze te melden om identiteitsdiefstal te helpen voorkomen. Omdat aanvallen blijven veranderen, moet een hele organisatie alert zijn, maar we kunnen helaas geen absolute precisie verwachten.
Zo min mogelijk rechten
Verder is het belangrijk ervoor te zorgen dat werknemers en externe contractanten zo min mogelijk rechten hebben om hun verantwoordelijkheden uit te voeren. Pas consequent het principe van least privilege toe, te beginnen bij het endpoint. Stel programma’s voor het beheer van privileged access met de grootste zorgvuldigheid op. Toegang tot privileged accounts voor beheerders mag alleen worden verleend als het absoluut noodzakelijk is. Alle toegang tot privileged accounts moet worden gescheiden en gevalideerd.
Het zero-secret-probleem, waarmee beveiligingsprofessionals allang worstelen, werd door deze aanval opnieuw onder de aandacht gebracht: wat gebeurt er als iemand erin slaagt de sleutel te bemachtigen die alle andere sleutels beveiligt? Sterke defence-in-depth controles die zowel proactief als reactief zijn, zijn daarom essentieel. Zij zorgen ervoor dat andere systemen aanwezig zijn om bedreigingen op te sporen en tegen te houden, zelfs als de mfa is gecompromitteerd.
Ook het beperken van zijwaartse bewegingen kan enorm helpen. Dit kan door bestaande toegang tot gevoelige infrastructuur en online of cloud-interfaces te verwijderen. Just-in-time-toewijzing van privileges kan de toegang van een gecompromitteerde identiteit aanzienlijk beperken, waardoor de straal van een aanvaller kleiner wordt – vooral in combinatie met robuuste authenticatie.
Wondermiddel
Er is geen wondermiddel om cyberaanvallen te stoppen, en zeker niet in het geval van Uber, waarbij zowel de tools als de mensen niets te verwijten valt. Maar we kunnen de impact ervan wel beïnvloeden. Aanvallen zoals bij Uber kunnen worden beperkt door robuuste, gelaagde verdedigingsmechanismen, ondersteund door voortdurende en herhaalde opleiding van personeel om potentiële gevaren te herkennen. Deze aspecten maken het moeilijker voor aanvallers om voet aan de grond te krijgen, zich te verplaatsen, doelen te vinden en die te bereiken. Bovendien stellen ze ons in staat het succes en de impact van aanvallen te minimaliseren en zo snel mogelijk terug te keren naar de normale gang van zaken.
Sterke defence-in-depth controles ten spijt maakt de Uber-hack vooral duidelijk dat de achterliggende breiwerkjes kwetsbaar zijn voor low-tech aanvallen, zeker als de bedrijfsgeheimen op slecht beveiligde shares staan. Zo worden scripts niet alleen gebruikt om tijd te besparen en automatisering te verzekeren als we kijken naar DevOps.