Microsofts ai-assistent Copilot heeft gedurende langere tijd onjuiste toegangslogboeken gegenereerd binnen de Microsoft-cloudomgeving. Hierdoor konden organisaties niet accuraat vaststellen wie toegang had tot vertrouwelijke documenten. Dit kan worden opgevat als een ernstige tekortkoming met potentieel verstrekkende gevolgen voor zowel beveiliging als naleving van regelgeving.
Michael Bargury, cto van het beveiligingsbedrijf Zenity had tijdens een Black Hat-conferentie vorig jaar augustus 2024 deze fout onder de aandacht gebracht. Desondanks duurde het bijna een jaar voordat Microsoft actie ondernam. Die vertraagde reactie roept vragen op over de interne communicatie en prioritering van beveiligingsincidenten binnen het concern.
Auditlogboek
Microsoft reageerde pas toen Zack Korman, cto bij het cybersecurity-bedrijf Pistachio, de zaak onlangs aan het rollen bracht. In een blog met de titel ‘Copilot heeft uw auditlogboek gehackt, maar Microsoft wil u dat niet vertellen’ vroeg hij opnieuw aandacht voor deze kwetsbaarheid.
Inmiddels is de kritieke fout in Microsoft 365 Copilot opgelost die verborgen toegang tot bedrijfsbestanden mogelijk maakte. Microsoft heeft het probleem kortgeleden in stilte gepatcht, echter zonder klanten hiervan op de hoogte te stellen.
Korman beschreef begin juli in zijn blog hoe hackers auditlogboeken konden omzeilen. Als een hacker Copilot opdracht gaf geen referentielink op te nemen, kon de ai-assistent het bestand nog steeds openen en samenvatten. Dit gebeurde dan zonder een vermelding in de auditlogs aan te maken.
Documenttoegang
Korman gaf als voorbeeld Copilot te vragen een financiële rapportage met de laatste kwartaalcijfers samen te vatten. In het auditlogboek van Microsoft 365, dat normaal gesproken elke documenttoegang registreert, wordt standaard genoteerd wanneer Copilot een bestand raadpleegt. Maar bij een specifieke formulering van de opdracht—waarbij expliciet werd gevraagd om het document niet in het antwoord te koppelen maar uitsluitend samen te vatten—bleef die registratie opvallend leeg. Hierdoor ontstond een situatie waarin Copilot wel toegang had tot gevoelige informatie, zonder dat dit zichtbaar werd in de officiële logbestanden.
Wat op het eerste gezicht een onschuldige fout leek, bleek bij nader inzien een potentieel ernstige bedreiging voor bedrijfsbeveiliging en compliance. Korman waarschuwde dat organisaties afhankelijk zijn van volledige en betrouwbare auditlogboeken om te voldoen aan regelgeving en om ongeautoriseerde toegang tot gevoelige documenten te detecteren. Juist dat fundament bleek aangetast: een medewerker met kwade bedoelingen—of iemand die onder druk van externe aanvallers handelt—zou de fout in Copilot kunnen uitbuiten om vertrouwelijke informatie te bemachtigen, zonder dat dit in de logboeken wordt geregistreerd. Het ontbreken van correcte log-vermeldingen maakt het vrijwel onmogelijk om dergelijke datalekken op te sporen, en vormt daarmee een directe bedreiging voor de integriteit van bedrijfsnetwerken.
Kwetsbaarheid
Over de manier waarop Microsoft deze kwestie afhandelde, is discussie ontstaan. Microsoft bleek al maanden van de kwetsbaarheid te weten, maar heeft deze pas enkele dagen geleden verholpen. Het bedrijf heeft de getroffenen of het publiek niet op de hoogte gesteld.
Korman nam na zijn ontdekking contact op met het Microsoft Security Response Center (MSRC), aldus het Duitse it-blad Heise. Hij vertrouwde erop dat de professionals in Redmond hun gedocumenteerde procedure zouden volgen, het probleem zouden oplossen en de getroffen klanten zouden informeren. Op 17 augustus kwam Microsoft tot een oplossing.
En hoewel bedrijf het probleem heeft geclassificeerd als een ‘belangrijke’ kwetsbaarheid, heeft Microsoft er ook voor gekozen om klanten niet op de hoogte te stellen of te publiceren dat dit is gebeurd. Een CVE-identifier (Common Vulnerabilities and Exposures) bleef uit. Door de kwetsbaarheid als ‘belangrijk’ in plaats van als ‘kritiek’ te betitelen kon Microsoft voldoen aan de eigen interne richtlijnen voor publicatie van zo’n CVE-ID. Volgens Korman betekent dit auditlogboeks mogelijk onjuist zijn en dat Microsoft niet van plan is dat te melden.
Clouddiensten
Microsoft weigerde Korman ook de gevraagde CVE-ID te geven voor de kwetsbaarheid die hij had gemeld. Het bedrijf zegt over het algemeen geen CVE-ID’s toe te wijzen aan kwetsbaarheden in clouddiensten als eindklanten zelf geen actie hoeven te ondernemen.
Maar volgens Korman is dat ook duidelijk in tegenspraak met de verklaringen die het MSRC ruim een jaar geleden openbaar maakte. Destijds verklaarde Microsoft in de toekomst ook CVE-ID’s toe te wijzen aan kritieke kwetsbaarheden in cloudservices, inclusief gevallen waarin klanten zelf geen actie hoeven te ondernemen.
Door de kwetsbaarheid niet als kritiek te bestempelen bleef Microsoft onder de drempelwaarde voor het toekennen van een CVE-ID. Microsoft weigerde ook met Korman te praten over de graad van de classificatie van de kwetsbaarheid. Normaliter gebeurt dit wel in dit soort zaken. Microsoft reageerde tegenover Heise met de volgende korte verklaring: ‘We stellen het op prijs dat de onderzoeker zijn bevindingen met ons deelt, zodat we het probleem kunnen aanpakken en klanten kunnen beschermen.’
