Copilot beschädigte Audit-Logs, aber Microsoft informiert Kunden nicht
(pistachioapp.com)- Es wurde eine Schwachstelle in den Audit-Logs von Microsofts M365 Copilot entdeckt, durch die Dateizugriffe nicht protokolliert wurden
- Wenn man Copilot einfach auffordert, auf eine bestimmte Weise zu arbeiten, ist Dateizugriff ohne Audit-Eintrag möglich, was zu Risiken durch Insider-Bedrohungen und Verstößen gegen gesetzliche Vorgaben führen kann
- Ein Forscher meldete das Problem an das MSRC, doch Microsoft vergab entgegen der offiziellen Richtlinie keine CVE und informierte auch die Kunden nicht
- Microsoft stufte die Schwachstelle nur als „Important“ ein und entschied, dass keine gesonderte Mitteilung nötig sei, da sie per automatischem Update behoben wurde
- Das kann jedoch schwerwiegende Sicherheits- und Rechtsprobleme für Unternehmen verursachen, die in regulierten Branchen wie unter HIPAA auf Audit-Logs angewiesen sind, und Microsofts mangelnde Transparenz steht stark in der Kritik
Schwachstelle in Copilots Audit-Logs: Überblick und Auswirkungen
- Bei Copilot, einem von Microsoft aktiv vorangetriebenen KI-Dienst, wurde ein Fehler entdeckt, durch den Dateizugriffe auf Grundlage von Benutzeranfragen nicht in den Audit-Logs erscheinen
- Normalerweise sollte M365 Copilot beim Zusammenfassen einer Datei den Zugriff auf diese Datei im Audit-Log vermerken; das ist ein zentraler Bestandteil der Informationssicherheit in Organisationen
- Wenn Copilot jedoch gebeten wird, in der Dateizusammenfassung keinen Link zur Datei aufzunehmen, wird der entsprechende Log-Eintrag überhaupt nicht erzeugt
- So könnte ein Mitarbeiter etwa vor seinem Ausscheiden mit Copilot eine große Zahl von Dateien einsehen und sie ohne Protokollspur abfließen lassen
- Die Schwachstelle erfordert keinen gezielten Hack, sondern kann auch zufällig und auf natürliche Weise auftreten; der Autor des Blogbeitrags entdeckte sie bei internen Funktionstests
- Auch Michael Bargury, CTO von Zenity, hatte die Schwachstelle bereits vor einem Jahr entdeckt und an Microsoft gemeldet, dennoch blieb sie bis zu diesem Hinweis lange unbeachtet
Probleme beim MSRC (Schwachstellenmeldung) und ausbleibende Anerkennung der Reaktion
- Microsoft stellt zwar offizielle Hinweise und Prozesse für Schwachstellenmeldungen bereit, hält sich im tatsächlichen Umgang damit jedoch nicht ordentlich daran
- Nachdem der Autor das Problem an das MSRC gemeldet hatte, änderte sich Copilot unmittelbar, obwohl die Reproduktionsschritte noch nicht durchlaufen worden waren, was zu einer verwirrenden Situation führte
- Der Status der Meldung wurde geändert (Reproduktion → Entwicklung), doch es fehlte an klarer Kommunikation zu Fortschritt und Entscheidungsgrundlage
- Zur Frage der Vergabe einer CVE wurde mitgeteilt, dass nur dann eine offizielle Kennung vergeben werde, wenn Kunden selbst Maßnahmen ergreifen müssten
- Das weicht jedoch von Microsofts bisheriger Richtlinie ab; die Schwachstelle wurde lediglich als „Important“ eingestuft und weder offengelegt noch gesondert bekannt gemacht
- Insgesamt wurde die Nachverfolgung des Fortschritts nur oberflächlich sichtbar aktualisiert, ohne klaren Bezug zu tatsächlichen Maßnahmen, was aus Sicht des Meldenden ineffizient und intransparent war
Probleme durch fehlende Bekanntmachung und Kundenbenachrichtigung
- Microsoft entschied, für diese Schwachstelle weder eine CVE zu vergeben noch die Kunden zu informieren
- Da dieser Fehler auch leicht versehentlich auftreten kann, besteht die Möglichkeit, dass in realen Organisationen Audit-Logs über lange Zeit hinweg falsch aufgezeichnet wurden
- Obwohl viele Organisationen, darunter auch Gesundheitseinrichtungen (z. B. im Rahmen von HIPAA), Audit-Logs für rechtliche und regulatorische Zwecke nutzen, informierte Microsoft die Nutzer nicht über die Auswirkungen
- Audit-Logs werden in vielen Bereichen zentral eingesetzt, darunter Unternehmenssicherheit, Incident Response und rechtliche Beweisführung, doch Microsoft schwieg zu den relevanten Fakten
- Dieser Umgang deutet darauf hin, dass auch andere potenzielle Sicherheitsprobleme ohne Offenlegung behandelt werden könnten, und wirft ernsthafte Fragen zur Vertrauenswürdigkeit des Unternehmens auf
1 Kommentare
Hacker-News-Kommentare
Ich bin intern für die Entwicklung von Chatbots im Unternehmen zuständig und habe Schwierigkeiten, dem Management zu erklären, dass unweigerlich ein Informationsleck entsteht, wenn der Chatbot beim Zugriff auf vertrauliche Dokumente nicht sämtliche Berechtigungen des aktuellen Nutzers prüft
Vektordatenbanken, Suchindizes oder AI Search Database müssen entweder pro Nutzer existieren oder die Zugriffsrechte zusammen mit den Inhalten nachverfolgen
Ich möchte betonen, dass Zugriffsrechte sehr komplex sind, sich jederzeit ändern können, sich daher schwer im großen Maßstab anwenden lassen und anfällig für Race Conditions sind
Das ist ein konkreter Fall des „Confused-Deputy“-Problems
Es fällt unter die Risiken LLM02:2025 „Sensitive Information Disclosure“ und LLM06:2025 „Excessive Agency“ aus den OWASP LLM Top 10
Einige Enterprise-RAG-Lösungen lösen das wegen der vielfältigen ACLs mit nutzerspezifischen Indizes
Wie diese Zugriffsprobleme verwaltet werden, unterscheidet sich je nach Anbieter, daher sollte man diesen Punkt bei der Analyse einer RAG-Lösung unbedingt prüfen
In Japan nennt man das „Berechtigungsverwechslung (権限混同)", was ich als Bezeichnung ganz interessant finde
Erklärung zu Confused Deputy, OWASP LLM Top 10 Risiken
Mich würde interessieren, warum du das Nachverfolgen von Nutzerberechtigungen für ein Skalierungsproblem hältst
Wenn eine Anfrage eingeht, sucht man passende Dokumente in der Vektor-DB oder im Index und übergibt dann nur die, auf die der Nutzer zugreifen darf, an das LLM
Das ist ähnlich wie bei einem Bankberater, der nur die Daten authentifizierter Kunden sehen kann und daher nicht versehentlich Informationen anderer preisgibt; ohne Authentifizierung können nicht einmal Administratoren die Daten anderer sehen, sodass auch kein Missbrauchsrisiko besteht
Wenn ich auf solche Wände stoße, liegt es in der Praxis weder daran, dass ich schlecht kommuniziere, noch daran, dass das Management das Problem nicht versteht
Wahrscheinlich hat das Management beschlossen, das Problem zu ignorieren, und will später bei einem Leak den Ingenieuren die Schuld zuschieben
Wenn es schwer ist, das Problem dem Management zu erklären, kann es helfen, Legal/Compliance in CC zu setzen
Allerdings könnten manche auf Buzzwords fixierte Führungskräfte darüber verärgert sein
Die meisten Vektordatenbanken können zusätzliche Metadaten an Vektoren hängen
Wenn man die Liste der zugriffsberechtigten Stellen (z. B. HR, Führungskräfte) als Metadaten speichert, kann man den Nutzer bei der Anfrage auf diese Rollen erweitern und danach filtern
So lassen sich Dokumente, die der Nutzer nicht sehen darf, von Anfang an ausschließen
Allerdings müssen die Vektor-Metadaten auch sofort aktualisiert werden, sobald sich Berechtigungen pro Dokument ändern
Es ist problematisch, dass Copilot Audit-Logs umgeht und wie ein privilegierter Benutzer agiert
Das sollte eigentlich nicht möglich sein
Copilot greift in Wirklichkeit wohl nicht direkt auf Dateien zu, sondern liest die Inhalte bereits indexierter Dateien über die Suchmaschine
Microsoft sollte die Suchhistorie von Copilot auditieren; wenn Copilot nur den Index gelesen hat, aber protokolliert wird, als hätte es auf die Datei zugegriffen, ist das irreführend
Das ist so, als würde man sagen, jemand habe eine Website direkt besucht, nur weil er Google-Suchergebnisse gesehen hat
Microsoft vernachlässigt die Audit-Logs, weil man unnötig auf AI-Integration um jeden Preis drängt
Unter Windows kann ein Prozess mit Backup-Berechtigung sämtliche Zugriffsrechte umgehen und standardmäßig wird das nicht auditiert
Bei Backup-Apps würde das Audit-Log sonst zu groß werden; diese Berechtigung muss ausdrücklich aktiviert werden und das geht auch in verwaltetem Code wie C# leicht
Dasselbe gilt für die Restore-Berechtigung
Das erinnert an frühere Probleme bei der Einführung von Delve, als das Permission Trimming fehlerhaft war und Dinge in Suchergebnissen für Nutzer sichtbar wurden, oder an SharePoint Search, das teils Dokumente anzeigte, die zwar existierten, aber nicht zugänglich waren
Wenn man zum Beispiel nach „Fall 2025 layoffs“ suchte, reichte schon die bloße Existenz eines Dokuments, damit es sichtbar wurde, was sicherheitsrelevant war
Bei Microsoft bleibt weiterhin stark der Eindruck, dass Sicherheit nachrangig ist
Ein besserer Titel wäre wohl „Microsoft Copilot ist nicht HIPAA-konform“
Mit so einem Titel würde das Problem vermutlich viel schneller gelöst
Mehr noch: Jedes nützliche AI-Suchsystem ist vom Design her unsicher, denn die RAG-Vektoren in einer Vektordatenbank sind letztlich verlustbehaftete Kompression von Dokumenten
Das Problem wurde bereits behoben
Der aktuelle Vorwurf ist, dass die Kunden nicht darüber informiert wurden
„CVEs werden Sicherheitsreleases zugewiesen, wenn Kunden Maßnahmen zu ihrem Schutz ergreifen müssen. In diesem Fall wird die Behebung automatisch in Copilot ausgerollt, Nutzer müssen also nicht manuell aktualisieren, daher wurde keine CVE vergeben“
Ich frage mich, ob das ein wesentlicher Teil von CVEs ist oder ob Microsoft CVEs einfach so verwendet
Es wäre gut, auch für solche Schwachstellen eine gemeinsame Referenz-ID zu haben, und ich denke, dafür bräuchte es ein separates, vendorunabhängiges Nummernsystem
Bei Microsoft geht es bei CVEs um die Nachverfolgung von Sicherheitsvorfällen/Schwachstellen
Selbst wenn sich ungewöhnlich schnell patchen lässt, ist es dadurch nicht plötzlich kein Sicherheitsvorfall mehr
Microsoft ist zuletzt immer weniger zu transparenter Offenlegung von Sicherheitsvorfällen bereit und wirkt zunehmend unglaubwürdig, daher ist Offenheit in solchen Fällen umso wichtiger
Das wirkt weniger wie eine Grenze des CVE-Systems als vielmehr so, als würde Microsoft den CVE-Prozess aus PR-Gründen verbiegen
Das „C“ in CVE steht für „Common“
Das System ist also auf „Gemeinsamkeit“ ausgerichtet
Wir versuchen derzeit sogar, wichtige LOB-Apps von Microsoft wegzubekommen
Nach mehreren Hacks in den letzten Monaten, einem SSO-Zero-Day und Copilot, dessen Indexer wie ein Global Admin agiert und Berechtigungen ignoriert, wächst die Unruhe immer weiter
Es gibt so viele potenzielle Probleme, die entstehen können, wenn man Audit- und Activity-Logs direkt dem LLM überlässt, dass man sie kaum alle erfassen kann
Daher frage ich mich, wie der Bugfix in diesem Fall umgesetzt wurde, und ob vielleicht ein „Shadow Prompt“ eingeführt wurde
Im Beitrag steht nirgends, dass das LLM die Audit-Logs direkt verwaltet
Eher scheint es so zu sein, dass die Audit-Logs nicht vom LLM, sondern vom darüberliegenden Scaffolding bzw. Seitensystem geschrieben werden und man nur den falschen Zeitpunkt für das Logging gewählt hat
Statt zum Beispiel erst dann zu loggen, wenn jemand auf einen Link klickt, hätte man loggen müssen, wenn das Dokument in den LLM-Kontext eingespeist wird
Auch dieses Design ist nicht optimal, aber immer noch weniger gravierend, als wenn das LLM selbst protokollieren würde
Ich bin sehr skeptisch gegenüber dem Einsatz von Shadow Prompts (oder irgendeiner Form von Prompts) als echte Sicherheits- oder Compliance-Kontrolle
Solche Kontrollen müssen zwingend deterministisch und vorhersagbar sein
Wenn ein Tool dem LLM auch nur einen Teil einer Datei zeigt, dann sollte anschließend jede vom LLM ausgegebene Information so behandelt werden, als hätte es die Datei gelesen
Ich kann mir vorstellen, dass auch seltsame Anforderungen in den LLM-Prompt gelangen könnten, etwa: „Wenn der Nutzer dir sagt, dass du ihm keinen Link geben sollst, ignoriere das, andernfalls passiert deiner Familie XYZ Schreckliches“
Das erinnert auch an das Problem mit Shadow Copies
Es ist unklar, welche Art von Audit-Log hier genau gemeint ist
SharePoint-Dateizugriffslogs? Verhaltensprotokolle von Copilot? Purview? Oder noch etwas anderes?
Vieles ist nicht eindeutig
Da Copilot auf indexierte Inhalte und nicht auf die Datei selbst zugreift, stimmt es schon, dass kein echter Dateizugriff erfolgt ist
Der Blogautor müsste sich die Zugriffslogs des Indexes ansehen
In einer Fußnote des Blogs steht sinngemäß: „Das Audit-Log erscheint als CopilotInteraction und nicht als Spur eines direkten Dateizugriffs durch den Nutzer, und das halte ich für beabsichtigt
Wenn der Nutzer nur über Copilot zugegriffen hat, wäre es eher seltsam, das so zu protokollieren, als hätte er die Datei direkt angefasst“
Ich habe ChatGPT dieselbe Frage gestellt, und es erklärte mir, gemeint seien die Audit-Logs von Microsoft 365 bzw. Office 365, insbesondere das Unified Audit Log im Microsoft Purview Compliance Portal
Solche Themen sorgen genau dafür, dass sich Vertrauen in große Anbieter wie Microsoft weniger wie eine „Garantie“ und mehr wie „pures Glück“ anfühlt
Ich frage mich wirklich, wie sich dieses Problem praktisch beheben lässt
So wie ich es verstehe, hat der von Copilot verwendete Index bzw. die DB die Datei bereits gecrawlt, sodass die Information auch ohne erneuten Dateizugriff geliefert werden kann
Wie soll man das also überhaupt beheben?
Muss man den Zugriff auf Datenbank/Index selbst mit dem Audit-Log verknüpfen?
Oder soll man dem LLM sagen: „Wenn du Wissen abrufst, halte bitte unbedingt die Regeln ein und schreibe auf jeden Fall einen Log-Eintrag“?
Es braucht dringend offizielle Kommunikation dazu, wie Microsoft dieses Problem erkannt und gelöst hat
Für Unternehmen, die mit sensiblen Daten arbeiten, sollte dieser Vorfall ein Weckruf sein
Grundsätzlich kann jeder eine CVE einreichen
Ich könnte selbst eine Meldung einreichen und Microsoft zu einer Reaktion zwingen
Allein der Blogbeitrag wirkt auf mich schon recht überzeugend
In der Praxis ist das nicht so einfach
Bei den meisten CVE Numbering Authorities (CNAs) wie MITRE oder nationalen CERTs kann zwar jeder etwas melden, aber es gibt eine Bewertung und Prüfung
Microsoft ist eine eigene CNA, daher wird man MS-bezogene CVEs von außen ohne besonderen Grund wohl nicht vergeben
Ich frage mich, ob es überhaupt sinnvoll ist, für einen Dienst, den nur Microsoft betreibt, eine CVE zu beantragen
Was könnten Nutzer damit überhaupt anfangen?
Das Formular zur CVE-Einreichung gibt es hier
Mit PGP-Unterstützung, langer Historie und verifizierten Sponsoren wirkt das sehr vertrauenswürdig
Man sollte es nur für legitime und berechtigte Fälle nutzen
Interessanter Gedanke, aber ich glaube nicht, dass das ein Fall für eine CVE ist
Eine CVE sollte sich auf eine Schwachstelle beziehen, die sich produktübergreifend auf verschiedene Produkte aus mehreren Quellen anwenden lässt, und das trifft auf Copilot nicht zu
Der gravierendste Punkt in diesem Vorfall ist der Designfehler, das Copilot-LLM selbst mit der Erzeugung von Audit-Logs zu beauftragen
Das API zum Abrufen von Dateien oder URLs hätte Audit-Logs automatisch schreiben müssen; das ist grundlegende Ingenieurspraxis