Am 13. August veröffentlichte Microsoft das nächste Sicherheitsupdate (Review
News ) für Windows-Betriebssysteme und Office-Programme. Diesmal erwies sich der Patch als wirklich gigantisch: Jemand konnte diesen Sommer offensichtlich nicht in den Urlaub fahren. Insgesamt wurden 93 Sicherheitslücken geschlossen, von denen 23 als kritisch eingestuft wurden. In Remotedesktopdiensten, im
DHCP- Client und im .LNK-Dateihandler wurden
zwei schwerwiegende
Fehler in Hyper-V mit einem Sandbox-Escape behoben.
Eine monumentale Arbeit an den Bugs ist also eine sehr gute Nachricht. Unter anderem sind mehrere Schwachstellen an sich interessant, und eine andere hat eine interessante Erkennungsgeschichte. Zusätzlich zu den bereits in Remotedesktopdiensten erwähnten Problemen werden wir uns heute die Sicherheitsanfälligkeit im MSCTF-Dienst genauer ansehen. Der Forscher von Google Project Zero, Tavis Ormandy, der letzteres entdeckt hat, behauptet, das Problem bestehe seit 20 Jahren. Gleichzeitig werden wir die Sicherheitsanfälligkeit in Bluetooth bewerten, die nicht nur Windows betrifft.
WTF ist CTF?
Eine Sicherheitslücke im MSCTF-Dienst wurde von Tavis Ormandi fast zufällig entdeckt (
Nachrichten ,
Beitrag auf Tavis 'Blog). Alles begann mit einer Untersuchung der Windows-Mechanismen, mit denen verschiedene Programme miteinander interagieren können. Diese Interaktion ist auf das System zur Isolierung von Benutzeroberflächenberechtigungen beschränkt, das beispielsweise verhindert, dass Benutzerprozesse Systemprozesse stören. Tavis untersuchte seltsame Fälle, in denen trotz der Einschränkungen immer noch Nachrichten weitergegeben wurden, und stieß auf das MSCTF-Modul.
Dieses Modul gehört zum Text Services Framework, das wiederum Tastaturlayouts und dergleichen steuert. Alle laufenden Anwendungen sind damit verbunden. Warum? Zum Beispiel, um die Eingabe von Text auf Chinesisch oder Japanisch zu erleichtern.
Für solche Sprachen verarbeitet ein separates Programm die Eingabe im Anwendungsfenster und ändert die Eingabe in Hieroglyphen. Im Wesentlichen ist MSCTF ein separater Kommunikationskanal zwischen Anwendungen, der, wie sich herausstellte, nicht ausreichend geschützt ist. Die früheste Version von MSCTF, die Tavis gefunden hat, ist Teil der Microsoft Office XP-Office-Suite, die mit Windows 98 kompatibel ist. Ab Windows XP ist MSCTF Teil des Betriebssystems. Die Möglichkeiten der Interaktion mit anderen Anwendungen über MSCTF sind sehr groß, und vor allem gibt es keine Autorisierung. Infolgedessen schrieb Tavis ein
Dienstprogramm für die Arbeit mit CTF und begann, nach Schwachstellen zu suchen:
Es wurden Sicherheitslücken gefunden, wenn auch nicht sofort. Im „besten“ Fall können Sie auf einem System mit einer der Sprachen, für die erweiterte Eingabetools erforderlich sind (Japanisch, Chinesisch, Koreanisch und einige andere), Text in der Anwendung ersetzen, Befehle mit Administratorrechten an die Konsole senden, ohne ein privilegierter Benutzer zu sein, oder Benutzerpasswörter stehlen. Im schlimmsten Fall (obwohl das oben Genannte bereits schlimm genug ist) können Sie Systemrechte erhalten, dh Ihre Berechtigungen auf das Maximum erhöhen. Ein solcher Proof of Concept wird im Video gezeigt:
Die Sicherheitsanfälligkeit ist nur begrenzt von Nutzen, und höchstwahrscheinlich sind die meisten Szenarien nur mit Zugriff auf das System verfügbar. Es gibt jedoch möglicherweise Fälle, in denen ein Benutzer ohne Berechtigungen beispielsweise die Rechte eines Domänenadministrators in einem Unternehmen erhält. Die Sicherheitsanfälligkeit wird
durch das August-Update für alle Betriebssysteme ab Windows 7 geschlossen.
Bluekeep oder nicht Bluekeep
Die Probleme bei Remotedesktopdiensten (
Nachrichten , ein
Newsletter auf der Microsoft-Website) ähneln teilweise der Sicherheitslücke, die
Bluekeep im Mai dieses Jahres
entdeckt hat . Durch Löcher im RAS-Dienst (jedoch nicht im RDP-Protokoll selbst) kann der Angriff theoretisch ohne Beteiligung des Benutzers auf alle Computer im Netzwerk verteilt werden: Es besteht ein gewisses Risiko, dass sich die Situation mit dem
WannaCry- Kryptoverschlüsseler im Jahr 2017 wiederholt, als das Problem der Implementierung des SMB-Protokolls in großem Umfang ausgenutzt wurde.
Es gibt jedoch Unterschiede zu BlueKeep. Ein früheres Problem trat nicht bei den neuesten Betriebssystemversionen auf, betrifft jedoch im Gegenteil alle Betriebssysteme von Windows 7 bis Windows 10 (jedoch nicht Windows XP, Server 2003 und 2008). Während der internen Revision von Microsoft wurden Fehler festgestellt, echte Angriffe wurden noch nicht bemerkt. Sowohl Bluekeep als auch vier neue Probleme werden durch die Einbeziehung der Autorisierung auf Netzwerkebene neutralisiert. NLA auf einem nicht gepatchten System rettet Sie jedoch nicht vollständig vor einer Reihe von Skripten für die Ausführung von Code auf einem Remotecomputer. Im schlimmsten Fall (kein NLA, August-Patch nicht installiert, Fernzugriff aktiviert) kann die Autorisierung umgangen und die Kontrolle über das System durch Senden einer vorbereiteten Anforderung erlangt werden.
Bluetooth-Sicherheitsanfälligkeit
Das als KNOB Attack (Key Negotiation of Bluetooth) bekannte Problem wurde von Forschern aus Singapur, Deutschland und Großbritannien entdeckt (
Nachrichten , Forschungsseite, wissenschaftliche
Arbeit ). Im Gegensatz zu anderen Sicherheitslücken im Microsoft-Patch-Set gilt dies nicht nur für Windows, sondern ist im Allgemeinen fast überall dort relevant, wo Bluetooth verwendet wird. Eine große Liste von Updates von Herstellern von Smartphones, Laptops und IP-Telefonen, die auf das Problem reagiert haben, finden Sie
hier .
In den Bluetooth-Spezifikationen können zwei Geräte, die eine sichere Verbindung untereinander herstellen, eine Schlüssellänge zwischen 1 und 16 Byte auswählen. Im Fall eines "Acht-Bit" -Schlüssels kann dieser durch einfache Aufzählung schnell genug geknackt werden: Wenn aus irgendeinem Grund eine solche "leicht sichere" Verbindung hergestellt wird, kann der Angreifer den Datenaustausch entschlüsseln. Zum Beispiel zwischen einer Tastatur und einem Desktop-Computer. Die Frage ist, wie ein solcher Angriff implementiert werden kann, und Forschungsarbeiten belegen, dass es mindestens zwei mäßig realistische Optionen gibt.
Im ersten Fall kann ein Angreifer in der Nähe von zwei Opfern die Verwendung einer Verschlüsselung mit einer Schlüssellänge von 1 Byte erzwingen. Tatsache ist, dass während des Verbindungsaufbaus keine Verschlüsselung oder gar Kontrolle der Datenintegrität erfolgt. Im zweiten Fall wurde das Szenario eines Angriffs auf die Lieferkette untersucht: Das Ersetzen der Gerätefirmware führt in allen Fällen zu einer schwachen Verschlüsselung. Der zweite Angriff wurde auf einem Nexus 5-Telefon ausgeführt: Wir ändern einige Bytes in der Firmware, begrenzen die Schlüssellänge und stellen eine Verbindung zu einem anderen Smartphone her, das die Bedingungen für den Verbindungsaufbau akzeptieren muss.
Dies ist eine schwerwiegende Sicherheitsanfälligkeit, die aufgrund der anfänglich schwachen Spezifikationen des Bluetooth-Standards besteht. Darüber hinaus sind viele Geräte weiterhin einem KNOB-Angriff ausgesetzt, da sie einfach kein Update veröffentlichen. Andererseits ist die Umsetzung eines solchen Szenarios in der Praxis ziemlich kompliziert: Im ersten Fall ist es notwendig, zum richtigen Zeitpunkt in der Nähe des Opfers zu sein, im zweiten Fall in die Lieferkette einzugreifen und sich dann wieder neben dem angegriffenen Gerät zu befinden, wenn vertrauliche Daten über dieses übertragen werden. In allen Fällen legt der Patch die minimale Schlüssellänge fest, sodass der Angriff praktisch nicht mehr anwendbar ist.
Haftungsausschluss: Die in dieser Übersicht geäußerten Meinungen stimmen möglicherweise nicht immer mit der offiziellen Position von Kaspersky Lab überein. Sehr geehrte Redakteure empfehlen generell, Meinungen mit gesunder Skepsis zu behandeln.