Microsoft dicht lek in Azure-functie dat kwaadwillenden databasetoegang gaf

De databasedienst Cosmos DB binnen Microsoft Azure kende een beveiligingsprobleem waarmee kwaadwillenden onbeperkt toegang konden krijgen tot de accounts en databases van duizenden Microsoft Azure-klanten. Microsoft heeft het lek gedicht en klanten ingelicht.

Beveiligingsonderzoekers van Wiz kwamen erachter dat het mogelijk was om achter de primaire sleutels van Cosmos DB te komen. Met deze primaire sleutels krijgen mensen toegang tot alle data binnen een Cosmos DB-database. Gebruikers kunnen met deze sleutels niet alleen gegevens lezen, maar deze ook aanpassen en verwijderen.

Het probleem lag bij Jupyter Notebook, een functie binnen Cosmos DB waarmee klanten hun data kunnen visualiseren. Deze functie was in 2019 geïntroduceerd en is afgelopen februari bij alle Cosmos DB-klanten automatisch ingeschakeld. "Een serie aan verkeerde configuraties binnen deze notebookfunctie opende een nieuwe attack vector", stellen de onderzoekers.

Wiz geeft nog niet veel details vrij over deze verkeerde configuraties, al zeggen de onderzoekers wel dat de notebookcontainer een privilege escalation naar andere klantnotebooks mogelijk maakte. Met deze privilege escalation kon een aanvaller toegang krijgen tot de primaire sleutels van de Cosmos DB-database van de klant.

De onderzoekers lichtten Microsoft in, die de onderzoekers veertigduizend dollar gaven en de notebookfunctie uitschakelden. Volgens Wiz is deze functie nog steeds uitgeschakeld, in afwachting van een fix. Microsoft zegt in een mail aan klanten, die is ingezien door Reuters, dat het probleem is opgelost en dat er geen aanwijzingen zijn dat er misbruik van is gemaakt. Alleen de onderzoekers van Wiz zouden ervan hebben geweten, claimt Microsoft.

Overigens vindt Wiz dat Microsoft niet genoeg klanten heeft geïnformeerd. Microsoft heeft volgens de beveiligingsonderzoekers alleen klanten ingelicht van wie sleutels deze maand eenvoudig in te zien waren. De Azure-maker adviseert deze klanten ook om hun sleutels aan te passen. De Wiz-onderzoekers stellen echter dat het lek al sinds februari 2019 in Cosmos DB zat en dat Microsoft daarom veel meer klanten zou moeten inlichten. Wiz zelf lichtte Microsoft op 12 augustus in over het beveiligingsprobleem; twee dagen later is de Jupyter Notebook-functie uitgeschakeld.

Reacties (31)

[tomverhoeff]

Los van dat dit geen goede beurt is voor Microsoft lijkt het me wel relevant om de achtergrond van de onderzoekers hierbij te vermelden. Wiz is een relatief jong bedrijf dat begin 2020 is opgericht. Drie van de co-founders kwamen direct bij Microsoft vandaan en hadden daar functies in de "Cloud Security Group". Als buitenstaander is niet te zeggen of hier een verband tussen zit, maar het issue waar ze nu over rapporteren is al in 2019 geintrudoceerd (toen ze daar dus nog werkten)

Zie hun LinkedIn profielen
https://www.linkedin.com/in/assafrappaport/
https://www.linkedin.com/in/amiluttwak/
https://www.linkedin.com/in/yinonc/

[BytePhantomX]

Los van dit soort kwetsbaarheden, vind ik het vooral zorgelijk dat Microsoft zo weinig transparant is over dit soort zaken. Sommige klanten hebben hier last van en hebben niets te horen gekregen.
Hetzelfde met printernightmare. Weinig communicatie en als er al gecommuniceerd wordt is het eigenlijk alleen gericht op de positieve zaken. En met cloud doen ze het al helemaal niet.

[gorgi_19]

Het blogartikel geeft aan wie geinformeerd is:

quote: https://www.wiz.io/blog/c...azure-customers-databases

Microsoft only emailed customers that were affected during our short (approximately weeklong) research period.

In de beleving van de onderzoekers zouden de volgende mensen geinformeerd moeten worden:

Every Cosmos DB account that uses the notebook feature or that was created after February 2021 is potentially exposed. As a precaution, we urge every Cosmos DB customer to take steps to protect their information.

De titel van het artikel maakt het wel groter; alleen Cosmos DB zijn geraakt. SQL Server databases vallen hier volledig buiten.

De databasedienst Cosmos DB binnen Microsoft Azure kende een beveiligingsprobleem waarmee kwaadwillenden onbeperkt toegang konden krijgen tot de accounts en databases van duizenden Microsoft Azure-klanten

Kleine nuance... Ze konden toegang krijgen tot de Cosmod DB databases en de bijbehorende storage accounts. Niet het volledige Azure account.

[Reactie gewijzigd door gorgi_19 op 24 juli 2024 20:46]

[BytePhantomX]

De reden dat ik het schreef was deze quote:

Microsoft only emailed customers that were affected during our short (approximately weeklong) research period. However, we believe many more Cosmos DB customers may be at risk. The vulnerability has been exploitable for at least several months, possibly years.

[kodak]

Ik lees Microsoft niet transparant zijn waarom ze maar een beperkt aantal klanten inlichten. Dat Wiz uitleg geeft maakt niet dat Microsoft naar de juiste klanten transparant is.
Daarbij is het niet redelijk om een omstandigheid aan te grijpen om niet transparant te zijn. Die omstandigheid geeft namelijk niet aan dat Microsoft voldoende transparant is, hooguit dat Microsoft een mening over haar eigen verantwoordelijkheid heeft die ze niet duidelijk delen met de klanten die dit allemaal treft maar slechts met een zelf gekozen selectie die Microsoft goed uit lijkt te komen.

Ik zou als klant van een bedrijf dat mij diensten levert verwachten dat ze uit zichzelf ook informeren als ze een mening over mijn risico's hebben, zodat ik op zijn minst met ze een afweging kan maken in plaats van via Wiz te moeten vernemen dat het bedrijf wat ik grof betaal eigenwijs zelf beslist wat goed voor mij al klanten is om wel of niet te weten en te beslissen.

[Reactie gewijzigd door kodak op 24 juli 2024 20:46]

[Sluuut]

Alleen de onderzoekers van Wiz zouden ervan hebben geweten, claimt Microsoft.

Ja natuurlijk, want Microsoft weet van alle 7.7 biljoen mensen op deze planeet of ze van dit lek wisten en of ze het misbruikt hebben. Ik begrijp wel dat ze het claimen om de Azure & cloud reputatie hoog te houden, want het is hun core business. Het is gewoon wachten tot de dag dat het een keer goed mis gaat.

[Seven_PRX]

Er is zoiets als Auditing...

[klakkie.57th]

Mogen we die audit dan ook inzien ???
Laten we zeggen dat dit toch heel erg vaak gewoon gaat om een sample die nagekeken wordt ??

[Douweegbertje]

Dat kan als je contracten met SLA's hebt waarin dat is ondergebracht. Daarnaast kan je zelf ook een auditlog hebben. Ik bedoel, als je zo verontwaardigd reageert mag ik hopen dat je zelf je security opties op orde hebt.

[kodak]

Dat mag dan wel ergens uit blijken. Kennelijk schoot die auditing al behoorlijk tekort, en vervolgens lees je als klant via het nieuws een claim zonder te kunnen controleren waarom die redelijk is.

[Nrzonline]

Waaruit blijkt dat de audit tekort schoot? Dat er een lek is gevonden wil niet zeggen dat de audit niet correct is uitgevoerd. Audits en Iso certificeringen zijn een preventie middel, helaas bestaan er nog geen wondermiddelen.

[kodak]

Het argument was dat de audit er voor is om een bewering te kunnen doen dat het wel mee zou vallen. Je kan niet en stellen dat een audit daar voor is en tegelijkertijd het tegenovergestelde beweren. Dat is van twee walletjes eten. Of de audit is hier onvoldoende of de audit is er niet voor bedoeld. Niet beiden. Microsoft toon geen van beiden aan en doet een bewering die nergens op gebaseerd lijkt of wat niet te controleren valt. Ondertussen lopen klanten risico.

[yade]

Microsoft zou dat wel kunnen weten als ze de logs hebben laten onderzoeken, maar dat onderzoek en de claim zou van een externe partij moeten komen.

Echter, als er een lek was dan zou er ongetwijfeld iemand zijn die er geld mee probeert te verdienen en dat zou dan weer opvallen.

Overheden of bedrijven die spioneren zouden dan weer minder opvallen, hooguit in de logs.

[arthur-m]

We zeggen in Nederland gewoon miljard in plaats van biljoen.

En natuurlijk kun je gewoon monitoren hoe het gebruik is geweest en een analyse uitvoeren op de logs. Daarmee breng je het aantal al heel snel naar beneden.

Misschien heb je gelijk dat het een keer goed mis gaat, en dan zijn ze screwed. Dan komt er een andere partij die net zo groot is, en die screwt het ook. Uiteindelijk kán het altijd misgaan, maar hoe ermee om wordt gegaan is key. Ik kan me prima voorstellen dat de communicatie, op basis van de inzichten die ze hebben opgedaan uit de analyse, niet elk bedrijf hoeft geïnformeerd te worden. Dat zou ook een beetje gek zijn. Hoe vaak had je dan wel niets als ‘device’ user wel niet geïnformeerd moeten worden dat er bij je gegevens gekomen had kunnen zijn.. Dat slaat nergens op en is ook niet (altijd) nodig

[fruitbakje]

Ja natuurlijk, want Microsoft weet van alle 7.7 biljoen mensen

Miljard, niet biljoen.

[Falcon]

Sinds februari 2021 werd deze functie ook nog eens automatisch aangezet voor alle CosmosDB's.
https://www.wiz.io/blog/c...azure-customers-databases

[Reactie gewijzigd door Falcon op 24 juli 2024 20:46]

[gorgi_19]

Blijkbaar toch wel:

quote: https://www.wiz.io/blog/c...azure-customers-databases

In 2019, Microsoft added a feature called Jupyter Notebook to Cosmos DB that lets customers visualize their data and create customized views (see image below). The feature was automatically turned on for all Cosmos DBs in February 2021.

[Falcon]

Had hem al aangepast

[delphium]

This is the worst cloud vulnerability you can imagine. It is a long-lasting secret,” Luttwak told Reuters. “This is the central database of Azure, and we were able to get access to any customer database that we wanted.

Auw! Ik vind het eerlijk gezegd onvoorstelbaar en onacceptabel dat dit kan gebeuren bij een dergelijke grote dienst van een gigant als MS.

Edit: @iedreen hieronder

Als je zelf software hebt ontwikkeld weet je dat iedereen fouten maakt. Dat is niet erg, sterker nog, dat is alleen maar goed. Iets met vallen en weer opstaan. Het is wel een verschil of je een blog over je hobby maakt of een webwinkel voor de grootste grutter van NL, of een database foundation voor een wereldwijd opererend merk als Azure.

Al naar gelang de impact van mogelijke foute groter wordt, richt je de infrastructuur in om die mogelijke fouten op te vangen. Voor je hobbyblog betekent dat dat je een goede vriend er naar laat kijken. Voor de webwinkel van de grote kruidenier betekent dat dat je naast een heel groot intern team, ook nog eens een heel groot extern team inschakeld om te zorgen dat er geen domme fouten in je software zitten. In het geval van Microsoft met hun Azure platform mag je een veelvoud verwachten van de inspecties op veiligheid en zelfs een keiharde garantie dat er niemand bij je data kan.

Dat een domme configuratie fout met zo veel impact doorgang kan vinden binnen een "gerenommeerd" bedrijf als Microsoft is ronduit schandalig. Het gaat hier niet om één programmeur die een foutje maakt. Het gaat om een hele keten van "professionele" mensen die hier keihard falen.

FYI: Ik heb websites gebouwd voor AH, ANWB, Unesco, McDonald's, MinBZ, enz.
Ik heb ook hele domme fouten gemaakt. Gelukkig werkte ik in teams die mijn fouten naadloos konden opvangen.

[Reactie gewijzigd door delphium op 24 juli 2024 20:46]

[repmeer]

Ik zou gaan solliciteren bij Microsoft. Jij kan blijkbaar software schrijven die over 100 jaar nog niet gehackt is of lek is. Er zullen altijd nieuwe lekken ontdekt worden door nieuwe inzichten en technieken.

[delphium]

Er zullen altijd nieuwe lekken ontdekt worden door nieuwe inzichten en technieken.

Natuurlijk, maar dit is niet zomaar een lekje. Dit is een gigantisch lek met mogelijk gigantische gevolgen. Er is zelfs niet eens sprake van een programmeerfout, maar een serie van configuratiefouten. Dat is gewoon onvergeeflijk. Als zelfs je eigen mensen niet snappen hoe je software werkt, hoe moet dat dan in vredesnaam goed komen met je klanten?

[hiostu]

Dus een programmeer fout kan, maar een fout in een script voor het automatisch uitrollen en configureren van CosmosDB instances (wat uiteindelijk ook gewoon code is), is onvergeeflijk? Hou er rekening mee dat heel Azure draait rondom het principe van Infrastructure as Code.

[RGAT]

Daarom raden we je aan bij MS te solliciteren
Jij snapt duidelijk wel de exacte configuratie icm met alle theoretisch ooit mogelijke aanvalsvectoren, daar zit MS daadwerkelijk naar te zoeken naar dat soort experts, helaas bestaan ze niet.

Het is een flinke fout inderdaad, maar het gelijk uit verband trekken en verdraaien om te zeggen dat de mensen daar de eigen software niet snappen is wel erg flauw, vind je niet? Zo kan je alles wel zo negatief mogelijk proberen te maken door de boel te verdraaien om een bepaald 'narrative' te ondersteunen.

[cricque]

De meeste mensen die hierop reageren en echt zeggen dit kan jiet werken zelf niet in ops of development of security. Een fantasiewereld is leuk uiteraard, maar dan is er rel life. Elk mogelijke manier testen om iets te gebruiken is onmogelijk. Dan mag je nog zoveel personeel heb en, er zal altijd wel iemand zijn die een manier zal vinden of een workaround voor bepaalde dingen. Als ik zelf bekijk hoeveel testen er dagmijks op mij saas apps zijn … is het wix of wordpress, dan weet je wel dat je ooit wel eens prijs zal hebben. Jem mag doen wat je wilt, als iemand jou wilt hacken dan zal.dat gebeuren. Net hetzelfd met een reguliere inbraak

[Iblies]

Dit is een non-argument.

Het grootste probleem met zowel windows, android en ios is dat er te veel rommel inzit en daardoor per definitie onveiliger.

https://windowsreport.com/install-windows-10-lean/

Ze weten dat het minder kan, en het moet minder. Hoe minder, hoe sneller je afwijkingen kan opsporen.

[repmeer]

Ja daar hebben we weer een linuxprofeet. Alsof in Linux nooit wat fout gaat. Hou toch op.

[Iblies]

nieuws: Techbedrijven VS beloven miljarden voor verbeteren cybersecurity van ...

Waar zie je linux als het zover is gekomen?

[Cartman!]

Heartbleed alweer vergeten?

[BeosBeing]

Ja daar hebben we weer een linuxprofeet. Alsof in Linux nooit wat fout gaat. Hou toch op.

Het probleem bij Windows, maar ook bij Linux, is dat de code continu groeit. Dat komt door het toevoegen van bugfixes, maar ook door het toevoegen van nieuwe features.

Volgens Wired in 2004 bevat iedere 1000 regels commerciële code 20-30 bugs terwijl de code van de Linux kernel slechts 0.17 bugs per 1000 regels code bevat.

Nu is dit opmerkelijke verschil op zich al interessant om te verklaren*, maar Windows en Linux hebben gemeenschappelijk dat voor beide met iedere nieuwe versie de totale codebase groeit. Ten tijde van het door mij aangehaalde artikel, bevatte Windows (destijds XP) 40 miljoen regels code, en Linux 5,7 miljoen. Zelfs bij een gelijk aantal regels code zou je dus in 2004 maar liefst 7 keer zoveel bugs mogen verwachten in de Windows codebase, als in de Linux codebase.

Inmiddels (januari 2020) is de Windows codebase gegroeid naar 50 miljoen (W10) terwijl de Linux kernel is gegroeid via 15 miljoen in 2016 naar https://www.theregister.c...2020_kernel_systemd_code/ 27,8 miljoen[/url] waarbij nog 1,3 miljoen regels bijkomen voor systemd.

Als dus het aantal bugs per 1000 regels code voor Windows en Linux gelijk gebleven zou zijn, zou het aantal bugs in Windows met 25% gestegen zijn; maar bij Linux zou het bijna zijn vervijfvoudigd.

En dat is dus precies wat we zien gebeuren, Linux is heel hard op weg om Windows op dit punt in te halen. Naarmate de codebase groeit, bevat de software dus steeds meer fouten en dus ook beveiligingsproblemen. Als Linux op dit tempo doorgroeit, dan is de codebase over 5 jaar groter dan de codebase van Windows. Er gaat een moment komen waarbij beiden onder hun eigen omvang bezwijken, simpelweg omdat het aantal bugs zo groot wordt dat het onmogelijk wordt om deze nog te verhelpen.

* Nu geven andere bronnen iets andere cijfers:
- Quora schrijft The industry average is between 15 and 50 bugs per 1,000 lines of code…
- Openrefactory schrijft On average, a developer creates 70 bugs per 1000 lines of code (!)
15 bugs per 1,000 lines of code find their way to the customers
Fixing a bug takes 30 times longer than writing a line of code
75% of a developer’s time is spent on debugging (1500 hours a year!)

een aantal verklaringen (zeer generaliserend) is
1) het is veel leuker om aan nieuwe features te werken dan om bugs op te sporen en te verhelpen (dit speelt dus al 1-persoons hobby-projecten, maar dat is bij grotere projecten ook zo, ongeacht of het community, of bedrijfsresultaatgericht is.
2) Nieuwe features zijn vooral bij commerciële projecten een drijfveer omdat deze voor de marketing- en verkoopafdelingen essentiëel zijn om nieuwe betalende klanten binnen te halen en bestaande klanten over te halen naar de nieuwe versie te upgraden, uiteraard tegen betaling.
3) commerciële projecten hebben een deadline die gehaald moet worden omdat anders de winstgevendheid in gevaar komt. Er wordt dus minder tijd besteed aan debugging. FOSS-projecten hebben vaak ook wel een deadline, maar als een feature de code freeze niet haalt, dan wordt deze makkelijker doorgeschoven dan bij commerciële software.

Anderen kunnen vast nog meer verklaringen geven.

Een interessant artikel in deze is https://labs.sogeti.com/how-many-defects-are-too-many/.

[Reactie gewijzigd door BeosBeing op 24 juli 2024 20:46]

[alionfire]

Zolang het mensenwerk is blijf je fouten krijgen, je kan hooguit de kans verlagen maar naar 0 krijgen lukt niet zoals je weet.

[bhartman]

Waarom wordt deze functie automatisch ingeschakeld? Laat het tenminste aan de klanten over, zodat ze er bewust voor kiezen...