image

Microsoft lekt miljoenen klantgegevens via onbeveiligde database

woensdag 22 januari 2020, 14:55 door Redactie, 27 reacties

Microsoft heeft via een onbeveiligde database miljoenen klantgegevens gelekt. Volgens het techbedrijf was de klantensupportdatabase door een misconfiguratie 25 dagen lang voor iedereen op internet toegankelijk. De database, die 250 miljoen records bevatte, werd door een zoekmachine geïndexeerd en vervolgens door beveiligingsonderzoeker Bob Diachenko ontdekt.

De miljoenen records bleken logs te bevatten van gesprekken tussen Microsoftmedewerkers en klanten van over de gehele wereld. Het ging om een periode van 14 jaar, van 2005 tot december 2019. De data was voor iedereen op internet met een browser toegankelijk. Er was geen wachtwoord of andere vorm van authenticatie vereist. Microsoft en Diachenko stellen dat de meeste persoonlijke identificeerbare informatie, zoals e-mailnamen, contractnummers en betaalinformatie, was verwijderd.

In veel records werden echter toch persoonlijke gegevens aangetroffen, zoals e-mailadressen, ip-adressen, locaties, oplossingen, interne notities gemarkeerd als vertrouwelijk en andere zaken. Diachenko waarschuwde Microsoft op 29 december. Een dag later was de database beveiligd. In een verklaring stelt Microsoft dat door een misconfiguratie in de network security group van de database die sinds 5 december voor iedereen toegankelijk was.

"Misconfiguraties zijn helaas een veelgemaakte fout in de industrie. We hebben oplossingen om dit soort fouten te voorkomen, maar helaas stonden die voor deze database niet ingeschakeld", zegt Ann Johnson van Microsoft. Johnson stelt dat onderzoek naar de database geen misbruik heeft aangetoond. Microsoft zal alle getroffen klanten informeren.

Image

Reacties (27)
22-01-2020, 15:02 door Anoniem
Sta je dan met je security papers mbt hardening.
22-01-2020, 15:05 door Anoniem
Hey bedankt he. Hier een premier contact!
22-01-2020, 15:08 door Anoniem
Als er sprake is ve misconfiguratie. Hoe kan je dan stellen dat er geen misbruik is gemaakt. Stonden de logs aan dan en werden de bijbehorende events gelogd?

Sorry hoor maar dit komt erg ongeloofwaardig over.
22-01-2020, 15:22 door Anoniem
Dit is veel meer dan een "misconfiguratie". Alleen al dat de gegevens zo vreselijk lang bewaard bleven is een misser. Dat de database publiekelijk toegankelijk was is er ook een. En dan ja, dat die compleet open stond ook. Dus dat zijn al minstens drie missers, niet maar één.
22-01-2020, 15:55 door karma4
… five Elasticsearch servers, each of which contained an apparently identical set ...
Niet een Microsoft product, ze gaan als een tijdje voor de OSS varianten. Dit is het gangbare verhaal met het gemak van cloud databases waar je snel veel data in gooit en via het internet koppelt. Ik mis al een tijdje de Mongo-db en AWs bucket meldingen.
22-01-2020, 16:19 door Anoniem
Door karma4:
… five Elasticsearch servers, each of which contained an apparently identical set ...
Niet een Microsoft product, ze gaan als een tijdje voor de OSS varianten. Dit is het gangbare verhaal met het gemak van cloud databases waar je snel veel data in gooit en via het internet koppelt. Ik mis al een tijdje de Mongo-db en AWs bucket meldingen.

Ik niet. :(
Net zo min als de MS-SQL en de MySQL meldingen. Die komen nog dagelijks binnen.

Ik zie ook steeds meer applicaties die gelijk maar even MSSQL configureren als je de applicatie op je werkplek installeert. En de focus van de ontwikkelaar ligt op de beveiliging van de applicatie, als er al aandacht is voor beveiliging. Ze gaan uit dat Microsoft MSSQL wel afdoende beveiligt.

Peter
22-01-2020, 16:20 door Anoniem
Een misconfiguratie zal iedereen die een paar jaar meeloopt in de ICT minimaal 1 keer voorkomen.

De meesten zijn snel te herstellen
22-01-2020, 16:30 door Anoniem
Misconfiguraties zijn helaas een veelgemaakte fout in de industrie. We hebben oplossingen om dit soort fouten te voorkomen, maar helaas stonden die voor deze database niet ingeschakeld.
Als dat veel voorkomende fouten zijn, dan had je daar al lang geleden van kunnen leren. Dat was dat naar boven gekomen tijdens een risicoanalyse en dan had je zo'n database nooit in de buurt van het internet gehangen. Dit is broddelwerk.
22-01-2020, 16:37 door Anoniem
Door Anoniem: Een misconfiguratie zal iedereen die een paar jaar meeloopt in de ICT minimaal 1 keer voorkomen.

De meesten zijn snel te herstellen

Eens maar niet een database met gegevens v zoveel klanten. Dan klopt er iets niet procedureel. Iets met check dubbelcheck
22-01-2020, 16:38 door Anoniem
Je verwart de kluis met de kluissleutel.

ElasticSearch is een OSS (open source software) zoekmachine voor grote databestanden:
https://nl.wikipedia.org/wiki/Elasticsearch

Elastic is een van oorsprong Nederlands bedrijf:
https://www.volkskrant.nl/economie/elastic-is-het-jongste-nederlandse-techsucces-in-een-klap-vijf-miljard-dollar-waard~bebd0dc2/
ElasticSearch wordt door veel (grote) bedrijven gebruikt: onder andere het Nederlands Forensisch Instituut (voor de forensische zoekmachine Hansken), Tinder, Uber, eBay, Ticketmaster, Microsoft en Facebook.

ElasticSearch vergelijk ik met een kluisdeur, maar als je fouten maakt in de configuratiebestanden (de kluisdeur) zet je de kluisdeur open en kan iedereen binnenlopen. Dat is hier het onderwerp.
22-01-2020, 16:46 door Anoniem
Door Anoniem: Je verwart de kluis met de kluissleutel.

ElasticSearch is een OSS (open source software) zoekmachine voor grote databestanden:
https://nl.wikipedia.org/wiki/Elasticsearch

Elastic is een van oorsprong Nederlands bedrijf:
https://www.volkskrant.nl/economie/elastic-is-het-jongste-nederlandse-techsucces-in-een-klap-vijf-miljard-dollar-waard~bebd0dc2/
ElasticSearch wordt door veel (grote) bedrijven gebruikt: onder andere het Nederlands Forensisch Instituut (voor de forensische zoekmachine Hansken), Tinder, Uber, eBay, Ticketmaster, Microsoft en Facebook.

ElasticSearch vergelijk ik met een kluisdeur, maar als je fouten maakt in de configuratiebestanden (de kluisdeur) zet je de kluisdeur open en kan iedereen binnenlopen. Dat is hier het onderwerp.

Sorry, deze post van mij (Anoniem 16:38) is een reactie op Karma4 (15:55).
22-01-2020, 17:15 door Anoniem
Door karma4:
… five Elasticsearch servers, each of which contained an apparently identical set ...
Niet een Microsoft product, ze gaan als een tijdje voor de OSS varianten.
Dat ze de software niet zelf geschreven hebben is in dit geval volstrekt irrelevant. Hun servers, hun verantwoordelijkheid.
22-01-2020, 18:05 door Anoniem
Door karma4:
… five Elasticsearch servers, each of which contained an apparently identical set ...
Niet een Microsoft product, ze gaan als een tijdje voor de OSS varianten. Dit is het gangbare verhaal met het gemak van cloud databases waar je snel veel data in gooit en via het internet koppelt. Ik mis al een tijdje de Mongo-db en AWs bucket meldingen.
Niet een Microsoft product, maar wel één die onderhouden wordt door het door jou zo geadoreerde Microsoft, en die dus weer eens zwaar in de fout gaan. Dat vergeet je er gemakshalve even bij te vermelden. Geen onbelangrijk aspect.

Het is niet OSS dat de schuldige is, maar degene(n) die het beheren. Nice try, Karma4. Maar wederom: no cigar!
22-01-2020, 18:47 door linux4
Door karma4:
… five Elasticsearch servers, each of which contained an apparently identical set ...
Niet een Microsoft product, ze gaan als een tijdje voor de OSS varianten. Dit is het gangbare verhaal met het gemak van cloud databases waar je snel veel data in gooit en via het internet koppelt. Ik mis al een tijdje de Mongo-db en AWs bucket meldingen.

Doet natuurlijk pijn als Microsoft een blunder maakt. Meteen de schuld op OSS schuiven.
22-01-2020, 19:33 door karma4
Door linux4: Doet natuurlijk pijn als Microsoft een blunder maakt. Meteen de schuld op OSS schuiven.
Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker. Je ben heel consequent in microsoft bashing helaas niet in informatieveiligheid analyses.
22-01-2020, 19:36 door karma4
Door Anoniem:
Ik niet. :(
Net zo min als de MS-SQL en de MySQL meldingen. Die komen nog dagelijks binnen.

Ik zie ook steeds meer applicaties die gelijk maar even MSSQL configureren als je de applicatie op je werkplek installeert. En de focus van de ontwikkelaar ligt op de beveiliging van de applicatie, als er al aandacht is voor beveiliging. Ze gaan uit dat Microsoft MSSQL wel afdoende beveiligt.

Peter
Dank je, het bekende probleem, een ander zal de beveiliging wel doen. Met die houding, daar gaat het mis.
22-01-2020, 20:15 door Anoniem
Heeft de AP al gevraagd aan Microsoft waarom ze zo lang conversaties bewaren?
22-01-2020, 20:52 door The FOSS
Door karma4:
Door linux4: Doet natuurlijk pijn als Microsoft een blunder maakt. Meteen de schuld op OSS schuiven.
Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker. Je ben heel consequent in microsoft bashing helaas niet in informatieveiligheid analyses.

Databases niet goed configureren valt onder slecht beheer en dat gebeurt inderdaad overal. De andere problemen met Microsoft software (voornamelijk Windows) zijn tekenend voor closed source spaghetticodebouwwerken.
22-01-2020, 22:14 door Anoniem
Ik ben benieuwd of ik de log terug kan vinden van mijn gesprek met die Microsoft “beveiligings” meneer met accent.
Die belde mij omdat mijn Windows gehackt was. Na 20 minuten aan de telefoon kwam hij eindelijk tot de conclusie dat ik helemaal geen Windows heb haha.
22-01-2020, 22:28 door [Account Verwijderd] - Bijgewerkt: 22-01-2020, 22:29
Door karma4:
Door linux4: Doet natuurlijk pijn als Microsoft een blunder maakt. Meteen de schuld op OSS schuiven.
Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker. Je ben heel consequent in microsoft bashing helaas niet in informatieveiligheid analyses.
Als het zo gangbaar is (zoals je beweert), dan had Microsoft JUIST goed beheer moeten plegen en er bovenop moeten zitten. Nietwaar? Het feit dat ze dat in Redmond niet gedaan hebben maakt het, zoals jij het nu stelt, eigenlijk nóg kwalijker! Feitelijk heb je het dus "een soort van" bij het rechte eind (kuch!), alleen zal mijn conclusie op jouw bewering je nu niet bevallen.

Met andere woorden: deze banaan kun je simpelweg niet recht buigen. Wat je ook probeert om Microsoft te verdedigen en de schuld bij OSS te leggen. Microsoft is nalatig en slordig geweest, en ze tonen hiermee wéér eens aan dat ze OSS databases niet op een verantwoorde manier kunnen beheren én dat ze security nog steeds niet tot in de puntjes beheersen. Het is de schuld van de beherende partij (Microsoft!). Geeft verder niks, maar het zou je sieren als je hierin eens je verlies neemt en het erkent. ;-)
22-01-2020, 22:30 door [Account Verwijderd]
Door The FOSS:
Door karma4:
Door linux4: Doet natuurlijk pijn als Microsoft een blunder maakt. Meteen de schuld op OSS schuiven.
Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker. Je ben heel consequent in microsoft bashing helaas niet in informatieveiligheid analyses.

Databases niet goed configureren valt onder slecht beheer en dat gebeurt inderdaad overal. De andere problemen met Microsoft software (voornamelijk Windows) zijn tekenend voor closed source spaghetticodebouwwerken.
Eens! Geen speld tussen te krijgen.
23-01-2020, 08:57 door Anoniem
"Hello dis is mike from micosoft tek support, i believe you may hav a virus on your computor"
23-01-2020, 12:11 door Anoniem
Door karma4: Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker. Je ben heel consequent in microsoft bashing helaas niet in informatieveiligheid analyses.
...beweert iemand die even consequent is in OSS-bashing als in het ontkennen dat hij dat doet.

Het is heel simpel. Als je software die naar een poort luistert om daar opdrachten op te ontvangen gebruikt dan heb je na te denken over wie die poort kan benaderen en over wat daar vervolgens mee kan, en maatregelen te nemen om te voorkomen dat dat verkeerd gaat. Als je dat overslaat ga je met de beste produkten nog de mist in.
23-01-2020, 14:51 door Anoniem
Door Anoniem: Ik ben benieuwd of ik de log terug kan vinden van mijn gesprek met die Microsoft “beveiligings” meneer met accent.
Die belde mij omdat mijn Windows gehackt was. Na 20 minuten aan de telefoon kwam hij eindelijk tot de conclusie dat ik helemaal geen Windows heb haha.

En jij had niemand van Microsoft aan de lijn.

Of was het sarcastisch bedoeld :)
23-01-2020, 16:45 door karma4 - Bijgewerkt: 23-01-2020, 16:49
Door Anoniem:
...beweert iemand die even consequent is in OSS-bashing als in het ontkennen dat hij dat doet.

Het is heel simpel. Als je software die naar een poort luistert om daar opdrachten op te ontvangen gebruikt dan heb je na te denken over wie die poort kan benaderen en over wat daar vervolgens mee kan, en maatregelen te nemen om te voorkomen dat dat verkeerd gaat. Als je dat overslaat ga je met de beste produkten nog de mist in.
Onze OSS fanaten geven altijd aan dat de oorzaak in het OS gezocht moet worden. Als je dat consequent aanhoudt kom je hier tot OSS probleem. Ik doe niet aan OSS bashing ik zou willen dat de OSS mensen meer aan informatieveiligheid zouden doen in plaats van in hun OS oorlogjes te blijven hangen.

Een tijdje terug werden de constateringen van open poorten met gevoelige data nog afgedaan als de betreffende onderzoeker onkundig was, bij het verkeerde foute bedrijf werkte. Een lek bij de heilige systemen mocht niet.
We gaan vooruit, het wordt in ieder geval niet meer ontkend of die onderzoeker als onkundig beschouwd.
23-01-2020, 20:47 door Anoniem
Door karma4:
Door Anoniem:
...beweert iemand die even consequent is in OSS-bashing als in het ontkennen dat hij dat doet.[...]
[...] Ik doe niet aan OSS bashing [...]
Zie je wel? ;-)

Je hebt er serieus meerdere malen de grootst mogelijke onzin over beweerd, en als een dogmaticus die totaal ongevoelig is voor argumenten heb je dingen die zowel feitelijk als logisch niet kloppen tot in het absurde volgehouden.

Maar het punt blijft overeind staan dat wat hier misgaat eraan ligt dat iets open aan het internet is gehangen dat niet open aan het internet gehangen had moeten worden. Als je in SQL Server de toegang tot data niet nauwgezet inricht en je hangt het aan het internet dan liggen er ook gegevens op straat. Als je een directory met vertrouwelijke Word-documenten open en bloot via het internet deelt dan liggen die documenten op straat. En dat ligt dan niet aan SQL Server of aan Word, dat ligt aan het feit dat iemand die systemen niet goed heeft ingericht.

Ik heb geen inhoudelijke kennis van Elasticsearch, maar zelfs als dat een systeem is waar geen enkele vorm van toegangsbeveiliging is ingebouwd dan nog is degene die het inzet zonder daarbij stil te staan ernstig aan het blunderen. Als software zelf beveiligingsmogelijkheden aan boord heeft heb je die goed te configureren, als het die niet heeft dan heb je die beveiliging te regelen door het bijvoorbeeld via een goed beveiligd vpn beschikbaar te stellen aan degenen die bevoegd zijn om erbij te komen. En dit klopt dus niet:
Door karma4: Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker.
Je moet het wel degelijk wijten aan de gebruiker. Dit zijn geen consumenten zonder enige IT-kennis, dit is professioneel gebruik en daar is professionaliteit bij nodig. Die realiteit weet je maar al te goed naar voren te brengen als het je uitkomt, met al je referenties aan ISO-normeringen en andere normenkaders. Maar als een OSS-produkt gebruikt is hoeft de gebruiker dat kennelijk allemaal niet goed te doen en moet de software het allemaal automagisch opvangen. Dat is meten met twee maten, karma4, en daarmee is het wel degelijk OSS-bashing wat je doet.
24-01-2020, 12:23 door Anoniem
Wat mij nu wel interesseert, is Microsoft in dit dossier nu verwerker of verwerkersverantwoordelijke? Volgens mij heeft Microsoft geen melding gedaan bij een van de DPA's. Microsoft gaat er vanuit dat de klant verwerker is en dus moet melden bij de lokale DPA. Gaat volgens mij een stortvloed aan meldingen opleveren. Ben benieuwd wat de collega's hiervan vinden?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.