[English]Im Windows SmartScreen und in Smart App Control gibt es Schwachstellen, die auf Design-Fehlern beruhen. Nun wurde bekannt, dass diese Schwachstellen bereits seit dem Jahr 2018 durch Angreifer ausgenutzt werden. Sicherheitsforscher der Elastic Security Labs haben eine Übersicht über die Probleme und Designschwächen der unter Windows verwendeten Sicherheitsfunktionen erstellt und veröffentlicht.
Anzeige
Was ist der SmartScreen?
Beim SmartScreen handelt es sich um eine eine Sicherheitsfunktion, die von Microsoft entwickelt wurde. Der SmartScreen-Filter ist seit Windows 8 verfügbar und ist in Windows sowie im Microsoft Edge-Webbrowser integriert. Die Funktion dient dem Schutz von Benutzern vor potenziell schädlichen Websites, Downloads und Anwendungen, indem er deren Reputation und Gefährdungsgrad analysiert. Eine Übersicht über den Microsoft Defender SmartScreen wurde von Redmond hier veröffentlicht.
Was ist Windows Smart App Control?
Bei Windows 11 wurde der SmartScreen durch die eingeführte Funktion Smart App Control ersetzt. Es handelt es sich um ein neues Feature, welchen einen Schutz vor neuen und neuen Bedrohungen bieten soll, indem Apps blockiert werden, die böswillig oder nicht vertrauenswürdig sind. Smart App Control soll auch helfen, potenziell unerwünschte Apps zu blockieren, d. h. Apps, die dazu führen können, dass ein System langsamer läuft, weil unerwartete Werbung angezeigt oder zusätzliche Software angeboten wird (Adware und PUP). Smart App Control (SAC) wurde mit Windows 11 Version 22H2 (Version 22572 oder höher) eingeführt. Microsoft hat diese Informationsseite zu den Windows Smart App Control-Funktionen veröffentlicht. Vom BSI gibt es dieses Dokument mit einigen Informationen.
Beide Sicherheitsfunktionen verwenden bei Dateien das Mark of the Web-Flag (MotW), um Downloads aus dem Internet zu erkennen. In diesem Bereich musste Microsoft in der Vergangenheit immer wieder Schwachstellen patchen. Und die Schwachstellen wurden durch Angreifer seit Jahren ausgenutzt (siehe zum Beispiel Windows und das "Mark of the Web" (MotW) Sicherheitsproblem).
Bugs und Designschwächen aufgedeckt
Sicherheitsforscher der Elastic Security Labs sind bei der Analyse der Windows Smart App Control (SAC) auf Fehler und Designschwächen in Verbindung mit .lnk-Dateien gestoßen. Die Probleme gelten auch für den älteren SmartScreen. Eine Möglichkeit, Smart App Control zu umgehen, besteht darin, Malware einfach mit einem Code-Signatur-Zertifikat zu signieren. Dann erhält die Anwendung eine höhere Reputation und wird von den Schutzfunktionen eventuell nicht als schädlich eingestuft.
Anzeige
Weitere Ansätze für Angriffe bestehen in einem Reputing Hijacking, um eine Vertrauensstellung vorzutäuschen. Skript-Hosts sind ein ideales Ziel für einen Reputation-Hijacking-Angriff, schreiben die Sicherheitsforscher. Dies gilt insbesondere dann, wenn sie über eine FFI-Funktion (Foreign Function Interface) verfügen. Mit FFI können Angreifer problemlos beliebigen Code und Malware in den Speicher laden und ausführen. Bei Recherchen der Sicherheitsforscher bei VirusTotal und GitHub haben sie wir viele Skript-Hosts identifiziert, die bekanntermaßen einen guten Ruf haben und für die vollständige Codeausführung genutzt werden können. Dazu gehören Lua, Node.js und AutoHotkey-Interpreter.
Ein weiterer Angriff auf den Reputationsschutz besteht darin, von Angreifern kontrollierte Binärdateien in das System einzuschleusen. Dabei kann es sich einfach um eine neue Skript-Host-Binärdatei, eine Anwendung mit einer bekannten Sicherheitslücke oder eine Anwendung mit einem nützlichen Primitiv handeln. Andererseits könnte es sich um eine Binärdatei handeln, die eingebetteten bösartigen Code enthält, aber nur nach einem bestimmten Datum oder Umgebungsauslöser aktiviert wird. Smart App Control scheint anfällig für Seeding zu sein, die Sicherheitsforscher konnten Samples auf einem Rechner ausführen und haben festgestellt, dass diese nach 2 Stunden eine gute Reputation in Windows Smart App Control erhalten hatten.
Eine dritte Angriffsklasse gegen Reputationssysteme ist die Manipulation der Reputation. Normalerweise verwenden Reputationssysteme kryptografisch sichere Hashing-Systeme, um Manipulationen unmöglich zu machen. Die Sicherheitsforscher haben jedoch festgestellt, dass bestimmte Änderungen an einer Datei die Reputation für Smart App Control (SAC) nicht zu verändern scheinen. Überraschenderweise, schreiben sie, konnten einige Codeabschnitte geändert werden, ohne dass die damit verbundene Reputation verloren ging.
Bei der Analyse stellten die Sicherheitsforscher zudem fest, dass es eine MotW-Schwachstelle gibt, die sich über Lnk-Dateien ausnutzen lässt. Das MotW-Flag wird für eine Datei gesetzt, sobald der Nutzer diese aus dem Internet auf ein Windows-System herunterlädt. Der SmartScreen-Filter scannt nur Dateien mit gesetztem Mark of the Web-Flag. Und Smart App Control (SAC) blockiert bestimmte Dateitypen vollständig, sobald diese das MotW-Flag aufweisen.
Die Sicherheitsforscher waren in der Lage, dass MotW-Flag zu manipulieren, indem sie LNK-Dateien erstellten, die nicht standardmäßige Zielpfade oder interne Strukturen aufweisen. Wenn diese LNK-Dateien angeklickt werden, werden sie von explorer.exe mit der kanonischen Formatierung versehen. Diese Änderung führt dazu, dass die MotW-Kennzeichnung entfernt wird, bevor Sicherheitsprüfungen durchgeführt werden.
Insgesamt sind die beiden Windows-Sicherheitsfunktionen SmartScreen und Smart App Control (SAC) sehr leicht aushebelbar und im Grunde nutzlos. Die oben skizzierten Schwachstellen werden durch Cyberangreifer seit mindestens 2018 auch praktisch ausgenutzt. Die Sicherheitsforscher der Elastic Security Labs haben ihre Erkenntnisse im Blog-Beitrag Dismantling Smart App Control ausführlich dokumentiert.
Anzeige
Was lernen wir daraus…
1. Codesignierung ist für den popo es ist zu leicht an falsche Zertifikate zu kommen.
Im Grunde ist es einfach man sollte keiner CA trauen, Entwickler sollten ihre Software mit eigenen (nicht von einer CA signierten) Zertifikaten signieren und es muss dem Benutzer überlassen werden die Zertifikate als vertrauenswürdig oder nicht einzustufen.
2. Signatur basierte Erkennung ist auch Käse.
Was es braucht ist Verhaltensbasierte Erkennung.
Und dazu ein system design welches inherent sicher ist, oder zumindest sichererer als windows nativ.
Ein Ansatz etwas mehr Sicherheit in windows zubringen sind HIPS tools wie https://github.com/xanasoft/MajorPrivacy
Damit kann man regeln erstellen z.b. um Verzeichnisse und Dateien vor zugriff durch unbefugte Programme zu schützen. Zeitgleich kann man mit anderen regeln Programme davon schützen unbekannte DLL's zu laden und noch wichtiger davor das andere Programme ihren Arbeitsspeicher auslesen oder verändern.
In windows gibt es nur eine Schutz grenze (innerhalb einer user session) zwischen Programmen die nicht elevated laufen und Programmen die mit admin rechten laufen.
Somit kann ein jedes program mit user rechten z.B. den Passwortspeicher vom Chrome oder Firefox oder und sogar von Passwort Managern wie Keepass (wenn sie gerade offen sind) auslesen.
Das ist im höchsten masse unsicher!!!
Jedes laufende Programm welches sensible Daten handhabt sollte von allen anderen Programmen auf dem System abgeschirmt sein.
Das kann man mit einem tool wie MajorPrivacy sehr leicht erreichen: https://www.youtube.com/watch?v=NkVR5ktvqBc
Kurz gesagt der Plan sollte nicht sein es zu verhindern das malware auf dem eigenem system ausgeführt wird (denn mit 100% Sicherheit kann man das einfach nicht) sondern der Plan muss es sein dafür zu sorgen das auf dem eigenem system laufende malware kein schaden anrichten kann und auch kein zugriff auf persönliche Daten erhalten kann.
Der Speicher ist unter Windows nicht "flat" wie bei einer 68000 oder einem 8080, sondern besteht aus – ich nenne es jetzt mal so – "Segmenten" (das gabs in vereinfachter Form schon im 8086, nur war es damals ein Graus, damit zu programmieren, die dem jeweiligen Programm gehören, und der Zugriff darauf ist von anderen Programmen durchaus geschützt, auf Hardware-Ebene, durch eine in die CPU verbaute "MMU". So einfach, wie du es hier darstellst, ist es also nicht. Die Schwachstellen sind meistens, wenn einzelne Prozesse miteinander über Kanäle/Pipes, Shared-Memory, usw. miteinander kommunizieren müssen, Beispiel Applikation mit Kernel um Betriebssystemfunktionen zu nutzen.
Mag ja sein, dennoch fand ich auf einem W10x64-Testsystem die Passworte selbst eines per runas user:Keepass […] gestarteten Keepass als User [egal] schon mit normalen Userrechten im Speicher wieder.
So weit her kann es mit der Trennung also nicht sein.
@1ST1
Ja der speicher ist per MMU geschützt, das ist nur komplett Witzlos wenn die das OS erlaubt per kernl32.dll ReadProcessMemory den speicher eines jeden Prozesses welches mit dem gleichem oder weniger privilegiertem token läuft auszulesen.
Und mein program macht hier auch keine hexerei mot der hardware oder so, es registriert mit einem driver ein Callback mit dem es einfach bestimmen kann ob ein process ein handle bekommt mit dem es den speicher eines andren Prozesses lesen könnte, oder eben ob es den nicht bekommt.
Ein mit vista eingeführtes system das man nur richtig einsetzen muss.
>>> und der Zugriff darauf ist von anderen Programmen durchaus geschützt, auf Hardware-Ebene, durch eine in die CPU verbaute "MMU". <<<
Sie wieder mit Ihren hingeworfenen Altherrenweisheiten ("68000", "MMU" etc.). In dem vom Vorredner korrekt dargestellten Zusammenhang ist Ihre Einlassung völliger Nonsens!
Schon in (1) schwelgten Sie in den Achtzigern und schwadronierten über den IBM 5150 PC, in (2) riefen Sie die Heimleitung an, weil Ihnen angeblich ein Olli über die Leber gelaufen sein soll. Ist das schon beginnende Altersrenitenz?
(1) borncity.com/blog/2024/08/07/crowdstrike-nachlese-neuer-bericht-aktueller-status-klagen-und-deren-konter/#comment-189985
(2) borncity.com/blog/2024/08/07/crowdstrike-nachlese-neuer-bericht-aktueller-status-klagen-und-deren-konter/#comment-190000