Uber heeft te maken met grote hackaanval op zijn intranet

Uber heeft te maken met een 'cybersecurity-incident' waar het de politie bij heeft betrokken, zo meldt het bedrijf zelf. Volgens bronnen van onder andere The New York Times heeft een hacker 'veel interne Uber-systemen doordrongen' en zijn meerdere systemen offline gehaald.

The New York Times sprak met security-onderzoeker Sam Curry, van web3-bedrijf Yuga. Hij zou de hacker gesproken hebben en stelt dat de aanvaller 'volledige toegang' heeft tot interne Uber-systemen. De 18-jarige hacker zou geen ransomware geïnstalleerd hebben; hij zou ingebroken hebben omdat Ubers beveiliging 'zwak' zou zijn. In het Slack-bericht waarin hij de hack aankondigde, zou hij verder hebben opgeroepen tot hogere vergoedingen voor Uber-chauffeurs.

De hacker zou binnengedrongen zijn op het Uber-intranet middels social engineering. Naast toegang tot de Uber-Slack zou de aanvaller ook toegang hebben tot broncodes, e-mailsystemen 'en andere interne systemen'.

Uber heeft publiekelijk al erkend dat er iets aan de hand is. Op Twitter schrijft het bedrijf "We hebben momenteel te maken met een cybersecurity-incident. We hebben contact met de politie en zullen aanvullende updates plaatsen zodra deze beschikbaar zijn."

Ook uit een andere hoek komt vermeende informatie over de hack naar buiten. Screenshots van gesprekken tussen de hacker en een ander persoon circuleren op onder andere Twitter. Daar worden ook beelden van de intranetonderdelen van Uber gedeeld. De echtheid ervan is nog niet bevestigd. De aanvaller beweert in de vermeende screenshots dat hij op het interne netwerk een PowerShell-script aantrof met admin-credentials, waarna hij toegang kon krijgen tot 'DA, DUO, Onelogin, AWS en Google Workspace'.

Hoewel Uber interne systemen afgesloten zou hebben om de schade te beperken, lijkt de dienstverlening van het bedrijf niet onderbroken.

Door Mark Hendrikman

Redacteur

16-09-2022 • 08:10

97

Submitter: AeonLucid

Reacties (97)

Sorteer op:

Weergave:

Die hacker is niet echt heel handig trouwens he, als dat screenshot uit die Twitter thread bij die persoon vandaan komt... Om 5 uur 's middags (12-uurs notatie, gebruikelijk in de USA) was het daar 77*F (Fahrenheit gebruikelijk in de USA) en bewolkt. Dan moet je toch wel specifieker kunnen pinpointen waar die screenshots vandaan komen.. En om 1.53 pm stopte het bijna met regenen.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 00:39]

En dan heb je vastgesteld dat het b.v. San Francisco zou kunnen zijn. Dan stuur je daar gewoon de politie van deur tot deur langs? 8)7
Nee, maar op basis van die gegevens kun je wel vérder gaan onderzoeken. Ik mag toch zeker hopen dat dat het gekoppeld wordt aan logging binnen Google, Amazon, VMware et cetera.
Wanneer jij inlogt vanaf een weggooi-VMmetje via een VPN-verbinding valt er weinig te loggen door Google en Amazon. Waarom VMware netwerklocatie zou loggen begrijp ik even niet, want dat is een hypervisor, geen cloudplatform.
Nee, maar de interface waarop je inlogt (VCenter?) logt dat natuurlijk wel. Althans, wel het IP waar je vanaf inlogt.
IP zegt natuurlijk ook geen ruk, met elk laagdrempelig VPN-programma maskeer je dat in een handomdraai. Het enige wat je uit die logs gaat halen is welk account vanaf welk IP en hoe laat. Als je al zo geavanceerd bent dat je alles bij Uber kan overnemen, dan weet je heus wel hoe je dat soort logs wegknikkert of niets achterlaat van waarde.
Je zou ervan staan te kijken hoe vaak hackers gewoon amateuristisch te werk gaan..
IP zegt natuurlijk ook geen ruk, met elk laagdrempelig VPN-programma maskeer je dat in een handomdraai. Het enige wat je uit die logs gaat halen is welk account vanaf welk IP en hoe laat. Als je al zo geavanceerd bent dat je alles bij Uber kan overnemen, dan weet je heus wel hoe je dat soort logs wegknikkert of niets achterlaat van waarde.
Die VPN-programma's zijn anders ook niet de heilige graal.

En dan moet de data nog van het netwerk af om via een publieke WIFI te ontvangen of zo? Terwijl je Google, Amazon & VMWare voor blijft? Nah.. Dan moet die hacker ook nog ergens in de Cloud een VM hosten.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Dat is niet hoe dit werkt. Dat is hoe niets van dit werkt.

Je kunt zelf een VPN opzetten met open source software of ssh tunnel via VMs in een land waar je slachtoffer geen jurisdictie heeft. Tor is ook nog een optie. Je kunt inderdaad een publiek/gehackt netwerk gebruiken aan jouw kant om het eea te maskeren als dat nodig is.
Terwijl je Google, Amazon & VMWare
Je doet alsof het personeel van die 3 bedrijven achter je aan zit. Dat is dus niet zo. Daarnaast dekt die VM precies dit. Die 3 partijen gaan enkel de server zien waar jij doorheen tunnelt. Google en Amazon hebben geen magische toverhoed waarmee ze alle encryptie kunnen breken. Die VPN server flikker je natuurlijk weg zodra je klaar bent, dus daar kan het slachtoffer niks meer mee.
Je wilt niet weten hoeveel klik-klak-klaar en yes-ok-yes-ok installaties hier in Europa staan. Die hebben allemaal de zelfde 12 uurs notatie en overige usa-instellingen. De lokale tijd wordt vaak nog wel aangepast en de lokatie wordt vaak automatisch bepaald. Dus ja, redelijke aannames maar niet echt.

Die automatisch bepaalde lokatie zie ik voor mij als Nederlander (met verder wel nette instellingen) overigens vaak redelijk random over het land springen. Dat gebeurt ook/mede op basis van ip-adres en met dhcp kan en mag die nog wel eens wisselen.
Of het lijkt maar zo. Misschien draait hij alles in een VM ergens hosted op een eigen afgenomen server met VPN.
Het feit dat ik zijn downloads putty staat lijkt het mij dat dit een VM is. Iemand die putty gebruikt en zich met hacking bezig houdt zal dit niet net installeren voor hij aan een hack begint maar zal dit al op zijn systeem staan hebben standaard.
Het feit dat ik zijn downloads putty staat lijkt het mij dat dit een VM is. Iemand die putty gebruikt en zich met hacking bezig houdt zal dit niet net installeren voor hij aan een hack begint maar zal dit al op zijn systeem staan hebben standaard.
Da's vooral een Windows admin (MCSE) want een Linux user gaat rechtstreeks over SSH. Of curl ofc.

Maar voor de terugweg is het idd wel handig om putty.exe erbij te zetten. Ook handig voor de admin om nog een ad hoc VNC (of xterm) remote sessie op te starten. Het is meer dat iets zoals winget of nuget of zo ontbreekt dus de intentie is waarschijnlijk data-extractie..

Samen met de observatie dat er hard-coded admin-accounts in de Powershell scripts staan... Het lijkt me eerder dat de vSphere beheerders een destinatie IP hebben gevonden; ook een VM in de Cloud , evt. via IAM Onelogin naar AWS.

Wholyguacomole! POSIX <> Powershell yiháá
They claim to have compromised Uber's Duo, OneLogin, AWS IAM, email and GSuite environments.

The attacker shared several screenshots of Uber's internal environment, including their GDrive, VCenter, sales metrics, Slack, and even their EDR portal.
an intruder has compromised Uber's AWS cloud account and its resources at the administrative level; gained admin control over the corporate Slack workspace as well as its Google G Suite account that has over 1PB of storage in use; has control over Uber's VMware vSphere deployment and virtual machines.

There have been further claims of unauthorized access to a Confluence installation, private source code repositories, and a SentinelOne security dashboard used by the app developer's incident response team.
lol, vCenter sales metrics...
VCenter Manage up to 70,000 virtual machines and 5,000 hosts across 15 vCenter Server instances

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Tsja, het kan. Vond het gewoon opvallend, dat dat er niet afgeknipt was..
soms wil je dat er als validatie in hebben staan, soms als distraction en soms staat het er als vergetelheid in. Ik denk dat de politie meer is met de gegevens die twitter hen kan verschaffen over de bewuste tweet, dan met de screenshot.
Klinkt als dat ze 1. hun beveiliging niet op orde hadden. 2. geen responsible disclosure policy hebben. Het gaat niet om afpersing dus lijkt me dat je dan eerst in gesprek gaat.

[Reactie gewijzigd door Vaevictis_ op 23 juli 2024 00:39]

Responsible disclosure contracten sluiten eigenlijk altijd het gebruik van social engineering uit voor het verkrijgen van een bounty.
Wellicht eerst social engineering.. Bijv spear phising. Maar volgens de thread op Twitter is het meer een man in the middle-attack een gespoofde inlog pagina waar een medewerker z'n mfa heeft ingevuld.
Beveiliging is per definitie nooit 100% op orde. Dat is al zolang de mensheid bestaat het geval.
Uber heeft een bug bounty programma. Dus dat iemand inbreekt wil niet zeggen dat er geen policy voor melden van beveiligingsproblemen is.

Daarbij gaat deze hacker ook nog eens zo ver om na een lek gevonden te hebben niet te stoppen, maar kennelijk nog verder te gaan en dan ook nog zomaar te publiceren. Ook vertelde de persoon het te doen omdat het bedrijf slechte beveiliging heeft. Kennelijk geen woord over zelf verantwoordelijkheid hebben genomen het eerst met het bedrijf op te willen lossen. Dat klinkt allemaal meer dat het helaas normaal vinden van crimineel gedrag is.
Uber heeft een bug bounty programma. Dus dat iemand inbreekt wil niet zeggen dat er geen policy voor melden van beveiligingsproblemen is.
Betreft dat verhaal uit 2016? Dat programma lijkt me down.

Da's meer gericht op de code; niet zo zeer op het netwerk. Wellicht dat tooling een aparte categorie is?
To aid researchers in their search for bugs, Uber created what it calls a "treasure map guide" showing how to find different classes of vulnerabilities across the company's codebase. The company also promised to publicly disclose and highlight the highest-quality submissions, with the researcher's permission, so everyone can see what kinds of issues get rewarded. Finally, Uber will provide ~200 researchers with access to new features at the same time it rolls them out to employees, whenever possible.
De Responsible disclosure dat zal wel, maar wat er achter dat éné VPN account allemaal gebeurd dat valt nog te bezien.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Dat er online geen bug bounty programma te vinden is lijkt me niet dat je kan stellen dat je dus geen problemen kan melden of dat dus maar niet hoeft te doen. En dat gaat net zo goed op als iemand andere problemen heeft gevonden dan je beloningen voor kan krijgen.
Dat er online geen bug bounty programma te vinden is lijkt me niet dat je kan stellen dat je dus geen problemen kan melden of dat dus maar niet hoeft te doen. En dat gaat net zo goed op als iemand andere problemen heeft gevonden dan je beloningen voor kan krijgen.
Dat is niet belangrijk.
Uber disclosed in November 2017 that hackers had stolen 57 million driver and rider accounts and that the company had kept the data breach secret for more than a year after paying a $100,000 ransom.

The deal was arranged by the company’s chief security officer and under the watch of the former chief executive, Travis Kalanick, according to several current and former employees who spoke on the condition of anonymity because the details were private.
Er lopen nogal wat rechtzaken.
[...]Dat is niet belangrijk.
Bij het argument dat er geen responsible disclosure zou zijn is dat wel degelijk belangrijk. Want verantwoord samenwerken hangt niet alleen af van of er iets wat vooraf duidelijk publiek omschreven is, maar ook of iemand die iets te melden heeft dat hoe dan ook verantwoord wilde doen en pogingen heeft gedaan. Heel veel bedrijven hebben geen responsible disclosure, maar dat wil niet zeggen dat je er dus maar geen problemen kan melden en dus ook maar niet hoeft te proberen.
Er lopen nogal wat rechtzaken.
Dat is een heel zwak argument om dan maar zaken te gaan doen die strafbaar zijn in plaats van het verantwoord op te proberen te lossen. Als bijvoorbeeld bleek dat iemand erg makkelijk toegang kon krijgen tot een belangrijk systeem, dan kon dat ook bijvoorbeeld via toezichthouders of journalisten proberen op te lossen en dan verantwoord openbaar maken.
Deze data-brach is bovenop de network-breach van 2016. Die uitspraak uit 2017 staat in hoger beroep nog eens ter discussie.

De https://www.nytimes.com/ zit er boven op. Waarschijnlijk hebben ze alvast wat infosec-watchers en malware-librarians vooruit gestuurd. Wellicht een gefrustreerde Flash developer?
Chris Evans, chief hacking officer for HackerOne, told the BBC-cyber-reporter Joe Tidy: "We're in close contact with Uber's security team, have locked their data down, and will continue to assist with their investigation."

Sam Curry, one of the bug bounty hunters (among a cohort of 200), communicated via Slack, a workplace messaging app, with the Uber hacker.
HackerOne was launched May 1 in 2016 by then Uber's Chief Security Officer Joe Sullivan. Since Feb 2021, Latha Maripuri is Uber’s chief information security officer.

https://www.nytimes.com/2...-security-trial-ciso.html

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Tegen mensen die gewoon hun login informatie overdragen onderneem je allicht ook niet zo veel...
Neemt niet weg dat het op z'n minst niet handig is dat een "gewone" mederwerker blijkbaar een Powershell script kan lezen waar credentials in staan die zoveel toegang geven.
Hier ben ik het dan inderdaad wel weer mee eens.
Sowieso dat je in een Powershell script een account gebruikt die rechten heeft buiten zijn usecase....

Als ik het goed begrijp stonden er volledige admin accounts in die scripts.
De infosec-watcher en malware-librarian zitten er bovenop.
Afgaande op de screenshots, zou zo'n hacker alle servers kunnen deleten?
Dat is één ding, maar hoe krijgen die lui in hemelsnaam 530 TiB aan e-mails bij elkaar ?!
Heel veel powerpoints heen en weer sturen
En wellicht app demos (Android APK-files) heen en weer sturen voor testen?
Via mail..? Mag toch aannemen dat daar een repo voor is ergens.. :)
Ik zie het vaker gebeuren hoor, dat er 'even' een APK bestandje via de mail wordt gestuurd.
Slechte mailbeheerder dan, dat die grootte mag in de attachments.
Dat is één ding, maar hoe krijgen die lui in hemelsnaam 530 TiB aan e-mails bij elkaar ?!
530 TiB aan e-mails?? lol, filter=*.*
Volgens een van die screenshots van de Google Workspace: 1,1 PiB (!) aan data en 530 TiB aan mail
Dat is één ding, maar hoe krijgen die lui in hemelsnaam 530 TiB aan e-mails bij elkaar ?!
Waarschijnlijk wordt alle messaging/chat in de Uber-app wereldwijd als emails m.b.v. een MTA opgeslagen.
Of alle taxi's naar 1 punt laten rijden
Of allemaal van dat punt weg :-)

Of nog leuker: taxi's een bepaald patroon laten rijden.
Ik ben ook verbaast hoe dit soort bedrijven zijn opgezet zonder dat er een keer wordt gekeken of het allemaal nog wel koosjer is.

Bij Twitter nieuws: Getuigenis klokkenluider: Twitter misleidt gebruikers, overheid en ei... konden minstens 4000 mensen Tweets inzien, locatie en zelf tweets plaatsen.


https://www.bbc.co.uk/news/technology-62889754.amp
It is believed around 4,000 employees had access to this data. He said he was worried that rogue employees had the power to take information without leaving a trace.
He added that there was a danger that employees could "dox" users, where private information is posted online, though he had not seen this happen.
He said Twitter does not log the activity of employees who access private data - which surprised him.
He also said that Twitter's security systems made it difficult to monitor potential espionage. In a previous statement Mr Zatko said that an Indian agent had been employed by the company .
Daarnaast wist het bestuur 100% dat er sprake was van kindermisbruik en kinderporno op twitter omdat de eigen teams het naar boven hadden gebracht,
https://www.theverge.com/...content-problem-elon-musk


Alleen het rare is dat tot op heden zowel politici als journalistiek hun mond houden en geen maatregelen nemen. Met name Kamerleden, gemeentes en andere hooggeplaatste mensen binnen de overheid (veiligheidsdiensten, politie, leger) zouden per direct van twitter af moeten.
Ai, deze hacker heeft zelfs toegang tot de IAM omgeving van AWS. Als dat niet goed is afgeschermd middels rollen, rechten en MFA dan is Uber zwaar de klos.

Ik vermoed dat er binnenkort een nieuwe vacature openstaat bij Uber voor een nieuwe CISO..
Het is niet noodzakelijk de schuld van de CISO. Hoewel ik in een bedrijf van dit formaat verwacht dat de CISO wel wat gewicht in de schaal zou moeten kunnen gooien, kan er enorm veel pushback zijn vanuit andere diensten. Als de CISO al jaren een beleid wil invoeren waarbij bijvoobeeld overal MFA wordt verplicht en priviliged credentials in een credential store horen te zitten maar dat andere diensten dat tegenhouden dan zie ik niet waarom de CISO hier ineens zou moeten opstappen. Dan mogen er anderen gaan vrezen voor hun functie.

Of misschien is het meeste gewoon wel in orde, maar is er een sysadmin geweest die voor zichzelf een service account had aangemaakt omdat deze het beu was van altijd via MFA naar die credstore te gaan om daar een account te gaan halen telkens hij een bepaalde taak wenste uit te voeren.

En zo kan ik nog wel wat scenarios bedenken. Het is nu eerst zaak voor Uber om uit te zoeken hoe alle gaten in het Swiss Cheese model zijn ontstaan en hoe dat deze aanvaller dus tot in de kern van hun systemen is kunnen doordringen om dan na te gaan hoe dit voorkomen had kunnen worden en welke fouten er dus gemaakt zijn geweest.
@Blokker_1999
De schuldvraag begint bij verantwoording, en in dit geval is de CISO verantwoordelijk voor het intranet. *.corp.uber.com

Die CISO zal wel wat moeten afstemmen met de netwerk-beheerder en de verschillende product-owners.

Die VPN is de point-of-entry geweest. @EstimatiesEnzo
De Uber SSO-infrastructuur is vrij default, al zouden daar nog FIDO2 als extra maatregelen getroffen kunnen zijn.
Met 1 MFA bij alle systemen kunnen komen is een heel slecht plan, alternatief is om FIDO2 te implementeren of op z'n minst multiple-single-sign-on met MFA (hoe grappig dit ook klinkt...). Laat niet je héle omgeving achter één MFA'tje zitten, authenticeer voor belangrijke onderdelen steeds opnieuw.
aldus @DigitalExorcist

Maar die VPN-user (e.o.a. admin) had ook Powershell scripts met hard-coded passwords, dus dat zal niet de brightste op de MCSE cursus geweest zijn.

@rapanui en nog 1,1 PiB (!) aan data bij Google G Suite (Workspace) en 530 TiB aan e-mail. Bovendien was er nog toegang tot de IAM Onelogin AWS.

Die CISO mag zich wel verantwoorden, mn. over VMWare vSphere
vSphere is an industry-level virtualization platform and a foundation for a cloud-based infrastructure. The vCenter Server is a centralized platform for managing vSphere environments. It allows you to assign custom roles to users, create new VMs, search the vCenter Server inventory, etc.
Het complete platform van VMware heet vSphere en bestaat uit verschillende componenten, zoals vCenter Server, waarmee een complete virtuele omgeving kan worden beheerd, en natuurlijk de hypervisor ESXi, waarop virtuele machines hun werk kunnen doen.
Sinds vSphere 6 liep er een langdurig Beta programma, in de voetstappen van Hyper-V 2016.
Docker, nested VM's, encrypted vm's. Het is alsof ik een deja vu momentje heb met de featurelist van Windows 2016/Hyper-V en Oracle VirtualBoax.
Er zijn meerdere vCenter cliënts: native ESX host, en de nieuwe HTML5 client ter vervanging van de oude Flash-based Webclient.

esxi-embedded-host-client
Webcliënt

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Een CISO is niet almachtig, een CISO is niet alwetend. De CISO is in de eerste plaats verantwoordelijk voor het beleid en niet eens voor de praktische uitwerking er van. Daar heb je meestal een heel security team voor in een bedrijf van deze omvang.

Maar zelfs dan, stel even dat het beleid wel goed is binnen Uber, maar je hebt een medewerker die er zijn/haar voeten aan veegt en dus een script maakt met hardcoded credentials omdat dat nu eenmaal gemakkelijker is dan telkens opnieuw credentials te moeten opvragen en ingeven, en ondanks dat zoiets in gaat tegen het beleid dat is uitgestippeld door een CISO. Hoe moet dat security team dat zomaar voorkomen? Spijtig genoeg zijn er nog te veel applicaties en geautomatiseerde processen die niet zomaar overweg kunnen met steeds veranderende wachtwoorden. Dat je dus service accounts hebt met statische wachtwoorden die maar eens om de zoveel maanden worden aangepast, is al niet de juiste manier om op zoek te gaan naar dit soort van situaties. Ga je een scanner zoeken die alle harde schijven kan gaan afscannen naar hardcoded credentials? Hoe ga je dat doen? En hoe ga je dan omgaan met gevallen waar men de credential niet direct in het script zet, maar bijv. plaintext in een tekstbestandje, want zoveel eenvoudiger voor de meerdere scripts die er gebruik van willen maken. Moet je maar in 1 plaats editeren.

We weten niet wat er gebeurd is. We weten niet wat er gefaald is. Ik vind het dan ook vreemd dat men hier op Tweakers dan al maar snel weer de conclusie trekt dat de CISO verantwoordelijk zou zijn. Ja, het kan zijn dat het beleid van de CISO niet in orde was. Dat ontken ik ook niet. Maar ik durf niet zomaar zeggen, zonder meer informatie, dat het onomwonden de schuld is van de CISO.
Heel verhaal.
De entiteit die de policies vanuit Uber's VMware vSphere beheerde, ik vermoed onder de CISO en de Security Officer. die zullen zich toch moeten uitleggen. Ongetwijfeld refereeren die daarbij naar andere fte's, collega's, leveranciers, netwerk shares, producten en het verleden. Uiteindelijk zal het om een service account gaan die al draaide vóórdat de verantwoordelijke rol/FTE in dienst was.

Ik zie wel een beetje vergelijking met Twitter; dat betrof denk ik aanzienlijk meer dan 1PB data. Die ging over 500.000 servers waarvan de helft maar ge-update was. Deze zaak vergelijken ze ook met die Okta-, Lapsus- en Microsoft-haks.
In the past year or so alone, T-Mobile, Planned Parenthood and the NFT marketplace OpenSea have been hacked.
@YopY ik denk dat het hier vooral order-processing data betreft. Twitter betreft ongestructureerdere data.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Ben zelf security manager en implementeer security al een hoop jaren. Mee eens, is 99% niet de schuld van de CISO. Het probleem is dat naast MFA je bijv. oplossingen als een IP lock niet overal kan implementeren. Uber is immers een publiekelijke server dus er zijn gewoon servers waar er simpelweg minder security aanwezig is. Wat ik wel extreem bizar vind is dat ze niet eens een paar simpele policies hebben geimplementeerd.

Bijv:.
- Device lock down, alleen de assigned user kan de zijn laptop inloggen en alleen met zijn account.
- Alleen x device kan op de server RDPen
- Alleen een admin account van x device kan RDPen naar x server.
- Voeg hier encrypted SSH sleutels aan toe die een extra MFA inlog + wachtwoord nodig hebben, opgeslagen zitten bijv in lastpass/keeper/andere tools.. en het wordt nog vrij lastig.

Wat ik heb begrepen uit het artikel/tweets, ze hebben deze basis reeks aan policies niet geimplementeerd. In mijn persoonlijke ervaring is werken in security een politieke baan, de directeur/eigenaar van het bedrijf of een core supplier kan jouw gewoon blokkeren wat betreft implementatie van policies.

Voorbeeld (werkelijk gebeurd): was betrokken bij een grote multi national, 500 man in security, alles top, hoop effort ingezet om alles op orde te krijgen. Niks was veilig, waarom?, de directeur vond dat men mag doen met zijn devices wat hij/zij wil. Oftewel.. Azure policy: allow uninstall intune. Had echt een brok in mn keel wetende dat er miljoenen werknemers zitten met onveilige devices, honderden apps die databases lokaal opslaan zonder encryptie en dan deze policy was een steek in de rug. Ben daar snel weggegaan.

Wat betreft suppliers, het klinkt misschien schokkend maar als we kijken naar high level suppliers/vendors die multi-miljoenen users supporten dan kom je vaak tot maar 1 conclusie: shit er is geen andere vendor of x vendor heeft x dat wij echt echt nodig hebben en er zijn maar twee andere opties. In de meeste gevallen is het dan ook praktisch onmogelijk om een vendor te blocken.
Omdat het zo politiek is vind ik het in veel gevallen ook een wasse neus

Leuk policies, beleid en andere theorieën. Het zijn vaak de uitzonderingen en het gebrek aan checks die het naar mijn mening gevaarlijk maken. Ik heb een tijdje in de financiële wereld gewerkt met o.a. sox audits en kan uit ervaring zeggen dat de praktijk vaak anders is dan de theorie. Hoe vaak ik wel niet een bevinding heb besproken waarna ik de opmerking kreeg dat alles wat besproken is de 4 muren van de vergaderruimte moest blijven

Edit: je voorbeeld zou niet zo kwalijk moeten zijn. Het is tegenwoordig redelijk de standaard dat je ervan uitgaat dat je end user devices onveilig zijn en behandeld worden als gewoon internet verkeer

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 00:39]

hij zou ingebroken hebben omdat Ubers beveiliging 'zwak' zou zijn. In het Slack-bericht waarin hij de hack aankondigde, zou hij verder hebben opgeroepen tot hogere vergoedingen voor Uber-chauffeurs.
Klinkt als iemand die hoopt dat Uber zich gaat verbeteren.

De laksheid van Uber komt me bekend voor. Heb zelf wel eens geprobeerd om Uber Eats te laten begrijpen dat in NL veel met iDeal wordt gewerkt, en dat iDeal niet werkt via hun website (alleen via de app). Je wordt dan van het kastje naar te muur gestuurd. Allerlei medewerkers die het allemaal niet begrijpen etc.
Ook de website kan buggy zijn. Iets dat je snel krijgt als je een SPA library als React werkt, maar de techniek nog niet helemaal beheerst. Het verbaast me dus niets, dat bij Uber het één en ander mis is.
Klinkt als verschillende teams voor de app en website. Misschien voor de app een lokaal team gebruikt, en voor de website slechts een vertaler? (ik mag aannemen aan dat de bedrijven die via Uber Eats werken allemaal in dezelfde database staan, ongeacht de front-end)
ReactJS is a GUI library. Een beetje SPA app heeft zéker geen React of Vue. jQuery zelfs is al te bloated en je hebt ook geen behoefte om alle features van Nginx in te bouwen.

En dat is als je security policies sowieso al JavaScript en php toestaan. In dat geval zou ik voor Express, Grunt & bootstrap gaan, maar nog steeds wel php-vrij.

Maar iDeal hebben ze gewoon niet aangesloten op de webpage; ze hebben liever dat je via de app besteld.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Zo zie je maar, 'gewoon eventjes' MFA aanzetten is óók niet alles. Met 1 MFA bij alle systemen kunnen komen is een heel slecht plan, alternatief is om FIDO2 te implementeren of op z'n minst multiple-single-sign-on met MFA (hoe grappig dit ook klinkt...). Laat niet je héle omgeving achter één MFA'tje zitten, authenticeer voor belangrijke onderdelen steeds opnieuw. Ja het is irritant, ja het kost iets meer tijd - maar niet zoveel tijd als het oplossen van dit gedoe.

Overigens:
De manier waarop dit gebeurd is, is door het spoofen van MFA van een medewerker .. leidt het MFA-mechanisme om naar je eigen malafide website en je bent binnen.. Het ging niet perse om social engineering; ja voor een deel wellicht, omdat er natuurlijk iemand érgens moet inloggen op jouw verzoek, maar het gaat verder dan alleen maar even iemand vragen om een wachtwoord en de MFA-code.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 00:39]

Zo zie je maar dat de menselijke operator de zwakste schakel blijft. Had ook gelezen dat er een PowerShell script gevonden was met hardcoded credentials erin. De hacker zou die gebruikt hebben om verdere toegang te krijgen.

Unconfirmed maar lijkt me niet onaannemelijk
Dat las ik ook, ja. Sterker: ik schreef het ook nog! In dit artikel!
Niet zo flauw doen. Wees blij dat hij het artikel gelezen heeft en er informatie uit heeft opgenomen. Hij kan er toch niets aan doen dat die 5 seconden later al is vergeten waar hij de informatie vandaan heeft? :+
Is dat flauw? Als ik sommige reacties lees met als boodschap dat artikels op tweakers onvolledig en/of verkeerd zijn, dan zou ik ook wel eens reageren.

Dat de menselijke schakel altijd de zwakste zal blijven, is niet verwonderlijk. Maar het verwondert me wel dat blijkbaar één medewerker een paswoord heeft die toegang geeft tot zoveel verschillende onderdelen. Maar als je, als doorsnee gebruiker, beschikt over een script met daarin admin paswoorden, zet je de deur wel zeer ver open.
Ben zoiets bij een bedrijf eens tegengekomen. De medewerker was grote fan van python en maakte verschillende scripts voor verschillende diensten. Maar alle paswoorden naar bijvoorbeeld sql databanken stond gewoon in het script. Bovendien wordt in bepaalde scripts de sa-gebruiker gebruikt met bijhorend paswoord. Zijn reactie was "oh, gebruikers weten toch niet dat je zo'n script kunt openen in een teksteditor" |:(
Hij maakte er ook geen probleem van om eens een script door te sturen als "inspiratie" met alle credentials er nog in.
Maar het verwondert me wel dat blijkbaar één medewerker een paswoord heeft die toegang geeft tot zoveel verschillende onderdelen.
Het lijkt er steeds meer op dat dit heel erg veel voorkomt; zo laatst ook een klokkenluider van Twiiter die aangaf hoeveel mensen toegang hadden tot de gebruikersgegevens.

Het is gemakzucht; het is dat niemand aangesteld wordt, of het op zich neemt, om fijnmazige toegang te beheren (omdat je, als je dat doet, eigenlijk de hele dag mensen toegang moet toekennen of afnemen, en dat wordt steeds meer als je organisatie en de hoeveelheid systemen die je hebt toeneemt). En de werknemers zelf worden erdoor gefrustreerd, dat ze continu nieuwe toegang moeten vragen.

Als bedrijf moet je ervoor zorgen dat je zo weinig mogelijk systemen, zo weinig mogelijk permissies nodig hebt. Maar dat is makkelijker gezegd dan gedaan.
Ik zie dat ik niet de goede smileys heb gekozen :)
Hoe moeten we goedkoop scoren met een fipo en een feitje als jij alles al in het artikel zet en als schrijver per definitie de eerste bent? Oneerlijk…
Als het zo eenvoudig is om binnen te dringen; mag je dan niet aannemen dat allerlei staatshackers al in alle vezels van de systemen zijn doorgedrongen?
Die hebben er geen belang bij om hun aanwezigheid aan de grote klok te hangen.
Dat ligt eraan of die hackers het bedrijf interessant genoeg vinden om het bedrijf te hacken en of ze de juiste persoon hebben kunnen vinden om hen van inlog gegevens te voorzien.
En als ze al niet zijn binnengekomen door te hacken dan kunnen ze nog proberen om van binnenuit bij data en code te komen. Als developer of devops engineer kom je tegenwoordig zonder problemen overal binnen, je hoeft alleen maar te solliciteren.
Helemaal waar dat de mens een zwakke schakel is. Maar wat dit ook laat zien is dat deze zwakke schakel dus ook bij al die systemen kan. Want als je vanuit 1 account bij al die systemen kan komen.

Daarom is het ook reëel om bij grote bedrijven de beveiliging te delen tussen verschillende teams. Niet iedereen kan en mag overal bij kunnen. En als dat dan wel het geval moet zijn, dan moet dat met verschillende accounts zodat er toch een vorm van scheiding is.
In theorie heb je helemaal gelijk.
In de praktijk vinden mensen dit onpraktisch en teveel gedoe.
Een goed en eenvoudig permissie systeem inrichten is vaak niet zo eenvoudig. Een complex en verwarrend systeem inrichten is vaak een stuk simpeler ;-)
@Kenhas

Het zijn meerdere handelingen; zelfs individuele apps hebben vaak al onderscheid tussen frontend gebruiker en database gebruiker. Ook shares hebben allerlei policies, en group policies zijn er ook nog.

Die verdeling is er altijd al geweest, maar ergens gaat het niet goed. De Grote Versnippering, of Data Verzuiling.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Oke, spannend. Ik gebruik al 4+ jaar Uber / Uber eats enzo.
Komt wel dichtbij zo hè?
Datalek is wel kwalijk toch. Mijn gehele bestel en boekingshistory staat erin. Inclusief NAW gegevens en noem maar op. Bedrijf van kaliber uber mag je toch wel meer van verwachten dan een simpele social engineering hack alleen.
Hoezo? Ze zijn bezig een markt te veroveren en zoeken de grenzen van alles op. En gaan ook wel eens overheen misschien.
Datalek is wel kwalijk toch. Mijn gehele bestel en boekingshistory staat erin. Inclusief NAW gegevens en noem maar op. Bedrijf van kaliber uber mag je toch wel meer van verwachten dan een simpele social engineering hack alleen.
Dat de data van hun orderprocessing systemen gedupliceerd is, is niet bekent gemaakt door Uber's Responsible Disclosure volgens mij.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Lijkt erop dat het hier om het zelfde verhaal gaat:

https://www.linkedin.com/...are&utm_medium=member_ios

Hardcoded user/pw in powershell script van hun Thycotic (PAM). Niet heel handig…
Hardcoded user/pw in powershell script van hun Thycotic (PAM). Niet heel handig…
Je zou voor de grap eens moeten kijken hoeveel hardcoded user/pw er als service accounts in bedrijven zijn. Ook niet heel handig maar mensen vergeten deze accounts, het doet iedere dag z'n werk dus waarom het risico nemen dat het fout gaat als je wachtwoorden wilt veranderen.

Ik weet dat MFA niet de holy grail is maar wanneer je (bv) een MSFT/OKTA/PING authenticator voor je kantoor gebruikers inzet en een DUO/Silverfort MFA aan de binnenkant vang je al een heel gedeelte van het MiM probleem op. Dan nog MFA aanzetten op fileshares/CLI-tools/PAM en je effectiviteit tegen aanvallen met gestolen credentials is significant verbeteterd zonder veel werk.
Je zou voor de grap eens moeten kijken hoeveel hardcoded user/pw er als service accounts in bedrijven zijn. Ook niet heel handig maar mensen vergeten deze accounts, het doet iedere dag z'n werk dus waarom het risico nemen dat het fout gaat als je wachtwoorden wilt veranderen.
Lol, een password manager voor admins. Maar je hebt zoveel soorten admins, dus uiteindelijk moet je eens soort van super admin met bundle-rechten hebben. Anyway, wachtwoord-managers schieten in mijn ogen zowieso hun doel voorbij.
Wat ik bij deze hack ook weer interessant vind is dat ze dezelfde MFA oplossing voor interne IT systemen gebruiken als voor de "normale" gebruikers.
tja, heb je die interne systemen gezien? Je moet rechtenbeheer initieel uitsplitsen naar servers en users, en dan verder gaan denken over authenticatie voor services, apps en users. Dat gaat verder dan enkel een AD-deployment, en zeker als er apps met eigen rechten-beheer in de workflows zitten.
Ik weet dat MFA niet de holy grail is maar wanneer je (bv) een MSFT/OKTA/PING authenticator voor je kantoor gebruikers inzet en een DUO/Silverfort MFA aan de binnenkant vang je al een heel gedeelte van het MiM probleem op. Dan nog MFA aanzetten op fileshares/CLI-tools/PAM en je effectiviteit tegen aanvallen met gestolen credentials is significant verbeterd zonder veel werk.
Mooie oplossing! Zo'n Yubico zou ook niet verkeerd geweest zijn voor Uber. Maar ik zie geen enkele reden waarom dat, een token op fileshares/CLI-tools/PAM, met 2fa niet kan.

Je moet vooral intruders buiten houden, en dan intern nog meer safety maatregelen nemen. En die zijn er ook voldoende. Maar Uber mist de historische scheiding tussen interne IT systemen en web-based systemen volgens mij in zijn geheel.

@jscholte Meer discussie bij Jamil Farshchi (chief information security officer at the data broker Equifax)
https://www.linkedin.com/...vity:6964917840604794880/

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 00:39]

Op dit item kan niet meer gereageerd worden.