Drucksache: Windows Developer 1.17 - Angriffe auf Windows Update
Im windows.developer 1.17 ist ein Artikel über Angriffe auf Windows Update erschienen.
Wer den Inhalt eines Update-Pakets kontrolliert, hat damit auch die Kontrolle über das zugehörige System bzw. Programm. Entweder automatisch und sofort nach der Veröffentlichung des Updates, wenn die automatisch installiert werden. Oder mit etwas Verzögerung, nachdem der Benutzer oder Admin das Update installiert hat. Weshalb man Updates und ihre Installation auch möglichst gut absichert. Und weshalb Komponenten wie z.B. der Windows Server Update Services für Angreifer ein besonders interessantes Ziel sind.
Flame hat gezeigt, wie gefährlich Angriffe auf bzw. über Windows Update sein können, und das "in the wild". Die ausgenutzten Schwachstellen in Form der veralteten MD5-Hashes und der zum Signieren zu missbrauchenden Zertifikate hat Microsoft zwar behoben, aber das bedeutet ja nicht, dass es nicht noch weitere Schwachstellen geben kann. Paul Stone und Alex Chapman haben bereits welche gefunden, zwei besorgniserregende und eine unschöne.
Unschön ist die Möglichkeit eines Injection-Angriffs auf den WSUS. Aber den kann man mit einer sicheren Konfiguration, konkret dem Aktivieren von SSL, verhindern.
Besorgniserregender sind die vorgestellten Angriffe über Dritthersteller-Treiber, die einen neuen Angriffsvektor bilden können. Bisher haben die Cyberkriminellen sich darauf beschränkt, ihren Schadcode durch erbeutete Signaturen einen legitimen Anstrich zu geben, s.u.. Aber genau so gut könnten sie auch nach Treibern mit ausnutzbaren Schwachstellen suchen und die als Einfallstor nutzen.
Und dann ist da noch die Feststellung der beiden Forscher, dass Windows Update alle von Microsoft signierten Dateien akzeptiert und nicht nur die, die mit einem speziell dafür vorgesehenen Zertifikat signiert wurden. Wie es eigentlich seit 2012 der Fall sein sollte. Da liegt irgend etwas im Argen, und merkwürdigerweise gibt es auch ein Jahr nach der Vorstellung der Ergebnisse noch keine Reaktion von Microsoft auf diese Entdeckungen.
Falsche Treiber mit echter Signatur, erstellt mit ausgespähten privaten Schlüsseln zu Code-Signing-Zertifikaten, gab es bereits einige "in the wild". Diese Gefahr ist also sehr real. Und schwer zu beseitigen, denn mehr als prüfen, ob eine Signatur unverändert ist und das verwendete Zertifikat gültig ist und nicht zurückgezogen wurde kann man ja nicht machen. So lange niemand den Missbrauch eines Zertifikats oder das Ausspähen eines privaten Schlüssels bemerkt, gibt es keinen Grund, ein Zertifikat zurückzuziehen. Und so lange das Zertifikat nicht zurückgezogen wurde, wird jede Prüfung der damit signierten Update-Pakete und Programme ergeben, dass sie vertrauenswürdig sind. Das ist sehr unschön, aber nicht zu ändern.
Und hier noch die Links und Literaturverweise aus dem Artikel:
- [1] Carsten Eilers; entwickler.de: "Stuxnet, Duqu und Flame – der virtuelle Krieg hat begonnen"
- [2] Graham Cluley; Sophos Naked Security: "Flame worm – Iran claims to discover new Stuxnet-like malware"
- [3] Carsten Eilers: "Flame? - Kein Grund zur Panik!"
- [4] Jonathan Ness; Microsoft Security Research & Defense Blog: "Microsoft certification authority signing certificates added to the Untrusted Certificate Store"
- [5] Jonathan Ness; Microsoft Security Research & Defense Blog: "Flame malware collision attack explained"
- [6] Marc Stevens; Centrum Wiskunde & Informatica: "Technical Background of the Flame Collision Attack"
- [7] Windows Update Team; Microsoft Update Product Team Blog: "Update to Windows Update, WSUS Coming This Week"
- [8] Paul Stone, Alex Chapman; Black Hat USA 2015: "WSUSpect - Compromising the Windows Enterprise via Windows Update" (Video auf YouTube)
- [9] Microsoft TechNet: "Configure Automatic Updates using Registry Editor"
- [10] Microsoft Developer Network: "[MS-WUSP]: Windows Update Services: Client-Server Protocol"
- [11] Microsoft Knowledge Base: "How to update the Windows Update Agent to the latest version"
- [12] Microsoft Knowledge Base: "An update for Windows Server Update Services 3.0 Service Pack 2 is available"
- [13] ctxis/wsuspect-proxy auf GitHub
- [14] Microsoft TechNet: "Windows Server Update Services" -> "Deploy Windows Server Update Services in Your Organization -> "Step 3: Configure WSUS"
Trackbacks