AI-onderzoekers Microsoft gaven per ongeluk toegang tot 38TB aan eigen data

Een fout in een GitHub-repository van AI-onderzoekers van Microsoft zorgde ervoor dat zo'n 38TB aan interne data jarenlang toegankelijk was. Onder meer tienduizenden berichten van honderden werknemers waren op deze manier in te zien.

Het datalek werd ontdekt door beveiligingsonderzoekers van Wiz.io. De betreffende GitHub-repository bestaat uit opensourcecode voor AI-modellen voor beeldherkenning, maar bij het downloaden van deze gegevens werden lezers doorverwezen naar een Azure-cloudopslagdatabase. Door een verkeerd geconfigureerde shared access signature-toegangstoken kon in principe iedereen met die URL de data van de gehele database inzien, niet alleen de bedoelde gegevens. Het is niet bekend of iemand ook in de praktijk onbevoegde toegang tot de gegevens heeft verkregen. De fout in de SAS-token zorgde drie jaar lang voor de foutieve toegangsmogelijkheid. Ondertussen is het probleem opgelost.

In een blogpost erkent Microsoft het datalek, maar benadrukt dat er geen gebruikersgegevens bij betrokken waren. Volgens de techgigant zou het gaan om systeemback-ups van twee voormalige werknemers en communicatie van deze twee werknemers met collega's. Volgens de ondervindingen van Wiz gaat het om gesprekken van in totaal honderden werknemers, waaronder gesprekken met gevoelige informatie, zoals wachtwoorden en beveiligingssleutels. Mensen met toegang tot de gegevens zouden zelfs de rechten hebben gehad om data aan te passen en te verwijderen. Zover bekend is dit in de praktijk overigens niet gebeurd.

Reacties (43)

[Anoniem: 1959400]

Het is nogal een aanname van MS om te zeggen dat er geen gebruikersgegevens bij betrokken zijn. Er zijn wachtwoorden, keys en berichten gelekt, wie weet wat daar nog achter aan data zit .

[Neus]

Hoe kan een bedrijf zo groot als Microsoft dit soort misstanden voorkomen? Lijkt mij redelijk onmogelijk.

[delphium]

En als het een klein bedrijf betreft, dan is het voor hen onmogelijk omdat ze de middelen niet hebben. Waar ligt dan de grens precies, waar het wel mogelijk is om dit soort misstanden te voorkomen? Want dat is wel waar we naartoe willen.

[d3burt]

Het begint natuurlijk bij security by design. Er schijnen in Azure meerdere user interfaces voor rechten te zijn die het heel makkelijk maken om zaken open te zetten voor "iedereen met een geldig token" of "iedereen met een geldige Azure login", zonder restricties op de tenant. Het zou al minder erg zijn als er een "are you sure" popup met een toelichting geweest zou zijn.

Het geniepige van deze situatie is dat het heel lastig is om te testen. Je logt uit en de access is weg, dus je denkt dat je data secure is, terwijl het in werkelijkheid voor de halve wereld open staat.

Er wordt vanuit de gemeenschap gelukkig op dit moment zwaar geleund op MS om wat aan de Azure UI te doen, want dit is niet het eerste lek wat MS zelf treft wat waarschijnlijk op een brakke security UI te terug te voeren. Dezelfde researcher Wiz heeft er al een paar gevonden, waaronder een intern control panel waarmee zoekresultaten van Bing konden worden vervalst.

[HADES2001]

Dat verhaal gaat natuurlijk twee kanten op. Een klein bedrijf heeft nog niet eens een duizendste van wat Microsoft aan omgeving en data heeft dus is sneller overzichtelijker. Microsoft bestaat al zo lang en heeft honderd duizenden medewerkers, het is gewoon een kwestie van tijd dat een keer iemand ergens een rechten foutje maakt en dat er iets lekt.

[StackMySwitchUp]

Op de Learn-documentatiepagina staat extreem duidelijk uitgeschreven hoe dit moet, ook zijn er tools om data-exfiltratie tegen te gaan (hoewel daar een behoorlijk dure licentie aan vast zit)
dus het hoeft allemaal niet zo moeilijk te zijn. De beheerder die dit inricht moet alleen wel even eerst nadenken over de impact en gevolgen van een beslissing voordat het wordt aangezet.
Ik ben absoluut geen fan van de certificering van Microsoft, maar in dit geval hadden ze misschien wel even hun eigen opleidingsmateriaal mogen nalezen.

[mjtdevries]

het is gewoon een kwestie van tijd dat een keer iemand ergens een rechten foutje maakt en dat er iets lekt.

Je wilt natuurlijk een systeem waarbij een rechten foutje niet meteen dergelijke consequenties heeft.

In on-premise omgevingen was een dergelijk lek wat vaker beperkt tot alle mensen in het bedrijf. Ook niet goed, maar een stuk minder erg dan wanneer de hele wereld het kan bekijken.

[Orgel]

Want dat is wel waar we naartoe willen.

Een wereld zonder oorlog ook. Dit valt gewoonweg niet te voorkomen vroeg of laat

[OruBLMsFrl]

Conclusie, zolang het mensenwerk is blijft er kans op fouten bestaan. Het is een argument voor volledige blokkade op sommige platformen, hoe vervelend ook voor sommige eindgebruikers. Dat je enkel extern kan delen, door een expliciete kopie te maken op een plek waar je ook externe toegang wenst. Of zo een incident het waard is om dat soort ongemak voor alle medewerkers te introduceren is aan ieder voor zich. Defensie zal blokkeren kiezen, een open source bedrijf zal dingen niet onnodig dubbel willen doen. Volgens mij doet dat karakter en type onderneming er meer toe dan de bedrijfsgrootte inderdaad.

[Yzord]

Ook als het computerwerk zou zijn. AI antwoorden staan niet bepaald bekend als accurate info en het heeft zelfs de neiging maar wat bij elkaar te verzinnen. Mocht dit soort werk in de toekomst door AI worden gedaan houd ik mijn hart vast. Er zal altijd iemand met kennis mee moeten kijken cq. handelen.

[Ryangr0]

Je ziet in dit nieuwsbericht wat ervan komt als er mensen aan te pas komen. Dit vinkje gaat niet zomaar aan. Ik heb er 100% vertrouwen in dat we binnen afzienbare tijd dit soort saaie inrichtingstaken niet meer door mensen hoeven te laten doen, en dat we er beter mee af zijn zo.

[com2,1ghz]

Door externe audits te doen.

[Xfade]

Basis dingen goedpraten omdat een bedrijf zo groot is, is wel erg makkelijk.

[Oon]

Audits, logging, alleen openbare repo's toestaan met een reden en na goedkeuring van management..

Onmogelijk om het waterdicht af te dekken, maar je kunt procesmatig al een heel eind komen

[BCC]

Vergissen is menselijk, of je nou bij een groot of klein bedrijf werkt.

[Ché Mig]

Sterker nog:
Hoe kan een bedrijf zo groot als Microsoft dit soort misstanden verkopen?

[Leemeijer]

Das een hoop data voor 2 personen

[Lodd]

Is dat zo? Ik ben zelf iemand die bijna dwangmatig al mijn mail archiveert. Dan hebben we natuurlijk ook nog de neurotische "versie 0.8", "versie 0.9" "versie 1.0" "versie 1.0_final" en "versie 1.0_final_nu echt" van mijn bestanden.

Sommige van mijn collega's genereren met enkele regelmaat behoorlijke bestanden met data. Als die mijn systeem zouden toepassen zouden ze het makkelijk halen.

[dasiro]

ooit al van versioning, track changes en incremental backups gehoord?

[gooos]

Als het mail betreft gaat het al hard omhoog als er regelmatig bijlagen meegezonden worden. Versioning en dergelijke zijn daarbij helaas niet echt van toepassing.

[dasiro]

mailboxen zijn niet gemaakt voor document management

[gooos]

Weet ik - maar vertel dat de massa maar eens... Gelukkig komt er inmiddels wel een beetje verandering in door meer gebruik van SharePoint en dergelijke, maar nog altijd ontvang ik (te) veel documenten als bijlagen in mijn mailbox.

Aan de andere kant, alleen de definitieve versie in je mailbox ontvangen is op zijn tijd wel goed voor lange(re) termijn archivering. Zeker als er in de organisatie de neiging bestaat om nog al eens de SharePoint opnieuw in te richten of "oude" documenten op te schonen.

[lamlion]

Schijnbaar ook AI modellen voor beeldherkenning. De ernst van de lek focust zich natuurlijk op de berichten tussen die 2 medewerkers

[the_stickie]

Wellicht Teamlead of middle mgmt
Zowat in elk bedrijf waar ik kwam heeft dat niveau eigenlijk te veel toegang, meestal onder het mom van controle over wie wat doet.

[virtualjoe]

Vinkje "public access" aangezet dus. Kan gebeuren 😁

[GrasshopperNL]

Daarom moet ook gewerkt worden met Azure Policies, die een dergelijke optie afdwingen.

[nzall]

Ik vermoed dat dit gaat over een default die standaard te permissief is. En het valt hier ook op dat zelfs Microsoft zelf hier fouten in kan maken. Als zelfs de makers van het product zo'n fouten maakt, mag het dan verbazen dat dit erg vaak voorkomt?

[n4m3l355]

Microsoft kent ruim 200.000 werknemers, of bijna twee keer heel Maastricht. Ze werken niet allemaal in de software development maar het zal toch wel een behoorlijke kluit zijn die met Azure werken. En op die gigantische berg employees heeft men een (royale) fout gevonden. Kan gebeuren maar... dit lijkt me toch helemaal niet zo gewoon gezien hoe zelden dit voorkomt.

[kodak]

Dat is dus niet zomaar een oplossing. Het probleem lijkt de verkeerde keuze bij het opzetten van een policy te zijn geweest. En of dat nu azure policies of andere rechten zijn, je kan dan nog net zo goed een verkeerde policy opzetten en dus afdwingen.

[kuurtjes]

Tot als er een actuele usecase is om zo'n optie te omzeilen.

[mcmnio]

Neen, de container was wel beveiligd maar er is een token dat je read-write rechten geeft per ongeluk in een publieke repository gesukkeld.
Dat die token geen expiration heeft is dan weer wel bedenkelijk...

[hooibergje]

Waarom zou je überhaupt interne berichten tussen collega's op github mikken?
Dat heeft helemaal niets met versiemanagement te maken.

[Yaksa]

Er staat nergens dat die gegevens op gihub gemikt zijn.
"Lezers werden doorverwezen naar een Azure-cloudopslagdatabase en konden daar (na aanpassen van de URL) de gegevens inzien".

[mcmnio]

In de git repository zat een token dat je toegang gaf tot een storage container. Die bevatte o.a. backups van de developers hun systeem.

[Ragger]

Het was een grote download, maar het is gelukt.

[Bofferman]

Hoeveel wil je er voor hebben?

[digibaro]

Met al die regelmatige lekken begint het al normaal te voelen bij de gemiddelde burger. De social media heeft daar nog extra aan meegedragen, privacy bestaat niet meer hoor je (te) vaak. Zal mij niks verbazen dat wat in de media komt maar een topje van de ijsberg is.

[MilanSxD]

Uiteraard is dat maar het topje van de ijsberg.
De media gooit zich vol op akkefietjes bij gigantische bedrijven.
Over een lek bij de lokale veehouderij hoor je natuurlijk niets.

Maar ook data lekken bij Microsoft komen veel vaker voor dan je in de media terug zult vinden.
Maar als Microsoft zelf het lek vind en zelf het lek dicht, zonder dat er data is gecompromitteerd, zullen zij dit echt niet melden aan hun klanten.

Lekken bij overheden zijn ook veel gebruikelijker dan je in de medai hoort.
Maar die willen dat liefst zo MIN mogelijk in het nieuws hebben.
Stel dat de burger het vertrouwen verliest. Al is het daar misschien een beetje laat voor.

Data lekken gebeuren niet alleen dagelijks, maar elk uur is er wel een datalek bij een bedrijf.
En dat geld voor HEEL veel bedrijven. Loopt al gouw op.
Alleen komt meestal niemand er achter.

[Chanfan]

Op Youtube en Neogaf zijn de interne mails van Phil Spencer van Xbox gelekt en de gehele roadmap tot 2028. Dit lek is echt groot!

[Roel1966]

In 1ste instantie dacht ik dat het om iets tijdelijks ging maar tja, jaren lang, ergens wel een beetje onbegrijpelijk voor een bedrijf als Microsoft.

[antimorian]

Wacht nog steeds op de dag dat van je "OS" ongeveer alles op straat ligt en de pleuris uitbreekt.
wat er allemaal zomaar wordt geaccepteerd tegenwoordig.
Tenzij dit het nieuwe normaal is dat je een bult tools nodig hebt om ons "Personal Computer" ook enigzins personal te houden.
Beetje hetzelfde met die office 365 promotie rommel. Lekker professioneel met die tig vragen opties en "hier wil je deze rommel" en nog jaarlijks ervoor betalen ook. Met de meeste geweldige standaard "prioriteit" en "overige" in je standaard email. Ga lekker bij Facebook werken dan.