Kommentare zu folgendem Beitrag: Windows Hardware-Treiber sind anfällig für eine Privilege Escalation
Quelle: https://thehackernews.com/2019/08/windows-driver-vulnerability.html
Wenn ich Quellen nutze, dann auch richtig: https://eclypsium.com/2019/08/10/screwed-drivers-signed-sealed-delivered/
Najaaaa, egal aus welcher Quelle die Informationen stammten…der Bericht hier enthält aber einiges an sachlichen und auch fachlichen Fehlern!
1.) Erstmal die erste sachliche Diskrepanz::
Betroffen sind davon alle großen BIOS-Anbieter wie beispielsweise ASUS, Intel, Gigabyte und Nvidia etc…
Keine dieser vier Firmen ist ein direkter BIOS-Anbieter. Es sind allesamt „nur“ Hardware-Hersteller, welche Prozessoren, dazugehörige Steuerungs-Chipsätze und komplexere Strukturen wie komplette Mainboards und ähnliche Hardware konzipieren und herstellen! Natürlich brauchen diese Komponenten eine Firmware, um interoperieren zu können. Allerdings haben diese Programme rein gar nichts mit dem eigentlichen BIOS gemein.
Das "Basic-Input-Output-System kurz BIOS ist ein eigenständiges „Betriebssystem“, welches weit vor dem Start irgendwelcher Windows-Komponenten ausgeführt wird. Zu dem Zeitpunkt (kurz nach Power-On), wenn das eigentliche BIOS ausgeführt wird, interagieren die betroffenen Komponenten in reiner Maschinensprache miteinander!
Eine Maschinensprache ist eine Programmiersprache, die ein Prozessor direkt ausführen kann.
Der Programmcode eines in einer Maschinensprache geschriebenen Programms wird Maschinencode genannt. Sowohl Befehle als auch Daten bestehen dabei aus einer Folge von Nullen und Einsen ( Bitfolge ).
Eine einheitliche Maschinensprache gibt es nicht. Soll ein Programm auf unterschiedlichen Prozessortypen laufen, muss für jeden Typ ein geeigneter Maschinencode erzeugt werden.
Hersteller bzw. Anbieter dieser BIOS-Software sind nur diese drei Firmen:
- American Megatrends International (AMI)
- Phoenix Technologies
- Award Software International Inc.
Netto bleiben dabei aber nur noch zwei BIOS-Programme übrig, da Phoenix Tech. und Award Soft. im September 1998 fusionierten!
2.) Der zweite sachliche Fehler im Text wäre:
Microsoft hat keinen Schutzmechanismus implementiert, der das Laden der anfälligen Treiber verhindert.
…Zuerst einmal hat Microsoft durch die damalige Einführung und Etablierung von UEFI (zuvor EFI) die ursprünglich sehr stabile Grenze zwischen Hardware und Software aufgeweicht!!
Als bestes Beispiel wäre hier zum Beispiel ein BIOS-Upgrade, resultierend aus dem Windows-Betriebssystem, zu nennen! Der Ursprung der Entwicklung BIOS-gestützter Ressourcen, hatte diese Möglichkeiten nie vorgesehen…
Nachdem man gemerkt hatte, dass diese „Grenze“ völlig aufgelöst wurde, haben sich kurzerhand Hardware-Hersteller, Software-Entwickler und federführend Microsoft zuammengeschlossen, um dieses „Einfallstor“ wieder abzusichern.
Somit wurde u.a. SECURE BOOT geboren!
Secure Boot ist ein Sicherheitsstandard, der von Mitgliedern der PC-Industrie entwickelt wurde, um sicherzustellen, dass ein Gerät nur mit Software bootet, der der Original Equipment Manufacturer (OEM) vertraut. Beim Start des PCs überprüft die Firmware die Signatur jedes einzelnen Bootprogramms, einschließlich der UEFI-Firmwaretreiber (auch bekannt als Options-ROMs), EFI-Anwendungen und des Betriebssystems. Wenn die Signaturen gültig sind, bootet der PC, und die Firmware gibt dem Betriebssystem die Kontrolle.
Der OEM kann Anweisungen des Firmware-Herstellers verwenden, um sichere Boot-Keys zu erstellen und in der PC-Firmware zu speichern. Wenn Sie UEFI-Treiber hinzufügen, müssen Sie auch sicherstellen, dass diese signiert und in der Secure Boot-Datenbank enthalten sind.
- Nach dem Einschalten des PCs werden die Signaturdatenbanken jeweils gegen den Plattformschlüssel geprüft.
- Wenn die Firmware nicht vertrauenswürdig ist, muss die UEFI-Firmware eine OEM-spezifische Wiederherstellung einleiten, um die vertrauenswürdige Firmware wiederherzustellen.
- Wenn es ein Problem mit dem Windows Boot Manager gibt, versucht die Firmware, eine Sicherungskopie des Windows Boot Managers zu starten. Wenn dies ebenfalls fehlschlägt, muss die Firmware eine OEM-spezifische Fehlerbehebung einleiten.
- Nachdem der Windows Boot Manager gestartet wurde, wird bei Problemen mit den Treibern oder dem NTOS-Kernel die Windows Recovery Environment (Windows RE) geladen, damit diese Treiber oder das Kernel-Image wiederhergestellt werden können.
– Windows lädt Antimalware-Software.
– Windows lädt andere Kerneltreiber und initialisiert die Prozesse im Benutzermodus.
Das bedeutet natürlich auch, dass dies hier genannte „Angriffsszenario“ nur temporärer Natur sein kann, da spätestens nach dem Neustart die Karten komplett neu gemischt sind!!!
Was anscheinend hier von allen vergessen wurde, ist z.B. die Tatsache, dass Windows seit jeher immer einen „Built-In-Administrator“ mitbringt, der natürlich sogar höhere Rechte besitzt, wie der Installer, Besitzer oder Verwalter des Systems!
Da dieser Admin nicht nur die Berechtigungen hat, diese Treiber zu installieren, sondern parallel dazu mit einer viel höheren Priorität ausgestattet ist, um seinen Kernel zu schützen (Thema: WATCHDOG etc.), wird wohl erfahrungsgemäss der größte Anteil dieser illegalen Rechteerweiterungen absolut ins Leere laufen!!
Was ich auch nirgends in den Quellen lesen konnte, weil es wohl einfach nicht berücksichtigt wurde, ist die nächste Tatsache, dass es immer ZWEI Rechteverwaltungen in einem laufenden System gibt!!
– Benutzerberechtigungen
– Dateisystemberechtigungen
Da diese beiden Rechteverwaltungen immer nur kombiniert arbeiten, kann es kaum sein, dass bei einem erfolgreichen Angriff von aussen, wenn die Benutzerrechte ausgetrickst wurden, einfach „Holland in Not“ ist! 
Hinzu kommen seit Win 10 einige Neuerungen zum Tragen, die dem genannten Angriffsszenario eigentlich keine Chance lassen, zu eskalieren!!
Diese hier nur stichwortartig, weil es dann einfach zu weit führt:
a) Windows Defender Exploit Guard
The Exploit protection feature in Windows Defender Exploit Guard includes hypervisor-protected code integrity (HVCI), which is a kernel process mitigation that leverages virtualization based security to isolate the process that performs integrity validation and authorization for kernel-mode code.
b) Windows Defender Application control
WDAC is used to control what code can run on the system in either kernel or user mode. When HVCI is enabled, WDAC benefits from the increased kernel memory protections since the kernel mode CI checks occur in virtualization based security and user mode code integrity runs as part of the kernel itself and is thus protected against kernel memory exploits. There are no hardware requirements for WDAC.
c) Windows Defender Device Guard and Windows Defender Credential Guard Readiness Tool
To determine if a device is able to run Windows Defender Device Guard and Windows Defender Credential Guard, download the Device Guard and Credential Guard hardware readiness tool. For guidelines about how to create more secure drivers, see the Driver security checklist.
d) Driver security checklist
This article provides a driver security checklist for driver developers to help reduce the risk of drivers being compromised.
Driver security overview
Security checklist: Complete the security task described in each of these topics.
Confirm that a kernel driver is required
Control access to software only drivers
Do not production sign test driver code
Follow driver secure coding guidelines
Validate Device Guard compatibility
Follow technology specific code best practices
Enhance device installation security
Execute proper release driver signing
Use code analysis in Visual Studio to investigate driver security
Use Static Driver Verifier to Check for Vulnerabilities
Check code with Binscope Binary Analyzer
Review debugger techniques and extensions
Review secure coding resources
Ich glaube einfach mal an dieser Stelle, dass der Neuling „Eclypsium“ nach seinem einjährigen Bestehen, einfach etwas in das Netz geworfen hat, um dem Sommerloch zu entkommen! Man hats halt nicht einfach als neue „Security Research Firm“ in dem Pulk aus Researcher-Fliegen, die alle um den Kackhaufen der IT schwirren!! 
1 „Gefällt mir“
Besser hätte ICH das auch nicht schreiben können…
Schon erstaunlich das es nur noch 2-3 BIOS Anbieter gibt.
Kann mich an früher erinnern, wo manch einer sagte
OH, ich habe ein AMI Bios oder Phoenix Bios als würde das
die oberste Priorität beim Computerkauf sein…
Übrigens schön, wieder was von dir zu lesen.
DANKE
Dafür gibt es von mir „Sonderpunkte“ 
1 „Gefällt mir“
Arbeiten wir mal alle Punkte chronologisch ab.
1.) Hast absolut recht, wurde geändert! Wie ein BIOS arbeitet und welche Firmen es anbieten weiß ich bereits durch mein Studium, trotzdem danke!
2.)
Mit den zwei Rechteverwaltungen hast du absolut recht! Nichtsdestotrotz hatte Lojax keine Schreibrechte und nutzte einen Exploit um diese zu erlangen, da hilft auch das Berechtigungssystem nicht viel… Auch nicht der Kernelschutz von Windows.
In der folgenden Abbildung ist dargestellt, dass die LoJax-Malware die Schreibrechte – insofern sie eingeräumt sind – ausnutzt. Wenn keine Schreibrechte vorliegen, setzt LoJax ein Exploit gegen eine bekannte Schwachstelle ein.
Bild: https://www.welivesecurity.com/deutsch/2018/09/27/lojax-uefi-rootkit-sednit-apt28/
Hier das offizielle Whitepaper dazu: https://www.welivesecurity.com/wp-content/forum/uploads/2018/09/ESET-LoJax.pdf
Du hast es schon richtig beschrieben EIGENTLICH KEINE CHANCE. Dennoch ist es der APT 28 gelungen.
Schau dir mal die Folien von der DEF CON an und beurteile dann selbst:
https://eclypsium.com/wp-content/forum/uploads/2019/08/EXTERNAL-Get-off-the-kernel-if-you-cant-drive-DEFCON27.pdf
…zum thema „apt28“ aka fancy bear aka sednit etc. es ist ja schon länger bekannt, dass diese gruppe keine gewöhnliche 08/15 hacker-truppe aus irgend einem vorstadtkeller ist, sondern wohl entweder eine regierungsnahe organisation, oder aber aus einem staatlichen geheimdienst selber resultiert (zur diskussion dabei: china & russland).
das eine solche gruppierung natürlich ganz andere und weitaus durchgreifendere mittel und wege hat, ihre aktionen erfolgreich durchzuführen, liegt schon in der natur der sache an sich !
alleine schon deshalb ist die wertung, dass es apt28 geschafft hat, den hack durchzuführen erstmal ganz weit aussen vor! es kann somit absolut kein vergleich zu den cyberkriminellen und blackhats im netz herangezogen werden…und denen ist es bislang halt noch nicht gelungen, dieses szenario 1:1 umzusetzen!!!
…nun einmal zu den obrigen zitaten:
die ganzen aussagen aus den texten setzen aber erstmal einige vorarbeiten voraus, BEVOR diese dann überhaupt erst zum einsatz kommen!!
-
Ein lokaler, authentifizierter Angreifer könnte bösartigen Code in die Plattform-Firmware schreiben. Wenn die Region „UEFI Variable“ des SPI-Flash, wie viele Implementierungen, auf BIOS_CNTL.BIOSLE als Schreibschutz angewiesen ist, könnte diese Schwachstelle genutzt werden, um UEFI Secure Boot zu umgehen. Schließlich könnte der Angreifer die Plattform-Firmware beschädigen und dazu führen, dass das System inoperabel wird. ergebnis: ein inoperables system stellt ab diesem zeitpunkt KEINE bedrohung mehr dar!!!
-
jetzt der viel wichtigere teil der vorarbeiten: Das erste Teil des Puzzles war eine Datei namens ReWriter_read.exe. Diese Datei enthielt den gesamten Code, der erforderlich ist, um einen System-SPI-Flash-Speicher mit dem RWEverything-Treiber RwDrv.sys zu entladen. Damit der Gerätetreiber die erforderlichen Vorgänge ausführen kann, muss das Dumper-Tool die korrekten IOCTL-Codes (I/O Control) senden. Während RwDrv.sys viele verschiedene IOCTL-Codes unterstützt, werden sowohl das in diesem Abschnitt beschriebene Dumper- und Writer-Tool als auch die nächste Verwendung von nur vier davon unterstützt.
…wie selbst eset in seinem bericht schreibt, startet das komplette szenario erst durch den flash des bios-chips, der auch das uefi beinhaltet!
um diesen flash durchzuführen, muss eine physische verbindung (usb) zum system bestehen!!!
siehe auch:
Dumper- und Writer-Tool (USB Flasher-Tool)
RESULT:
…und jetzt erst können wir einmal über eine praktikable umsetzung dieses szenarios im „real-life“ nachdenken und uns einmal die frage stellen, ob dieser angriff bei dieser umsetzung dann noch sinn macht für einen reinen cyberkriminellen?!?
wohl eher NICHT! apt28 konnte den physischen zugriff wohl durch strohleute, social engineering, bestechung…what ever erlangen (siehe voraussetzungen der gruppe oben)!
für einen hack in einem „real scenario“ wäre diese ganze vorarbeit einfach mit viel zu viel aufwand, zeit, kosten verbunden…meiner meinung nach!
natürlich ist solch ein angriff extrem und natürlich auch sehr schadhaft in einem solchen theoretischen prinzip, aber im echten leben eher unwarscheinlich, da der aufwand drumherum den eigentlich erzielten nutzen bei weitem übersteigt – da kann man natürlich geteilter meinung drüber sein (IMHO)…
Ja, das stimmt. Um auf die Kernaussage zurückzukommen:
Damit ist gemeint, dass z.B. Drucker-Treiber mit Sicherheitslücken, oder auch wie im Fall LoJax mit falsch signierten Treiber, natürlich nachgeladen werden können. In dem Kontext wurde gar nicht das BIOS/UEFI genannt…