Exploit Guard - Exploit Protection - EMET lebt

HowTo Make the Admin wahnsinnig by misching Technik. Tsänk ju for träweling with Microsoft

Die Technik ist nah an Magie und extremer Raketenwissenschaft.

Ich möchte über ein spezielles Problem im IE schreiben, das ich selber hatte. Liebe Grüsse an meinen Kunden, der sich jetzt sofort wiedererkennt ;-)  Ihr seid toll, den Dank für den Artikel sammel ich für euch.

Ganz einfacher Fehler: Internet Explorer - Schriftarten einer Webseite werden nicht nachgeladen

Nein, ihr müsst nicht googlen, diese Lösungen sind es nicht.

1. Definition innerhalb der IE Zonen Sicherheitskonfiguration, verschieben des Ziels in eine, in der der Schriftartendownload erlaubt ist: TRUSTED oder nur INTRANET Zone
   Computer Configuration\Administrative Templates\Windows-Komponenten\Internet Explorer\Internetsystemsteuerung\Sicherheitsseite\Intranetzone\
   Schriftartdownloads zulassen = Aktivieren
2. Buzzword Fontmitigation, eine Sicherheitseinstellung, die mit den ersten Microsoft Security Baselines bis zur 1607 als "Aktiviert" empfohlen wurde, aber aufgrund von Technischen Änderung, die die "GDI font-rendering bugs" abfangen, in der Microsoft Security Baseline 1703 herausgenommen wurde
   Computer Configuration\Administrative Templates\System\Ausgleichsoptionen\
   Blockieren nicht vertrauenswürdiger Schriftarten = Aktiviert
3. Exkludieren einer definierten .exe von dem Blockieren
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<process_image_name>.
   Hilft nicht in dem Fall, denn dann müsste der IE von der genannten Technik blockiert worden sein, damit der Exklude auch funktioniert. Wird er aber nicht ...

Die Antwort auf mein Fehlerbild lautet: Exploit Guard

Was ist der Epxloit Guard und was macht er überhaupt? 

Microsoft hat zu Zeiten von Windows 7 einen Angriffsüberwachungs-Prozessmonitor entwickelt. Anhand der definierten Executables werden innerhalb dieser .exe Funktionen/APIs/Schnittstellen blockiert. Bekannte schadhafte Lücken können damit verhindert werden. Microsoft kennt seine alten Programmiersprachen und auch andere und die darin möglichen Angriffe. Die Schnittstellen, die aufgrund der Funktionalität dieser Sprache möglich sind, werden für eine bestimmte ausführbare Datei blockiert, oder explizit erlaubt.

Stellt euch vor Ihr möchtet eine uralte Software aus Sicherheitsgründen verbieten, weil Angriffe zur Laufzeit der Anwendung möglich sind und man dieses Risiko nicht tragen möchte. Jetzt ist diese Anwendung aber unternehmenskritisch, sie wird benötigt. Vielleicht ist es dann eine gute Idee, diese technisch in ihrer Funktion einzuschränken, vor allem wenn diese Schnittstelle vom Programm nicht verwendet wird und nur als Angriffsvektor genutzt werden kann.

Das ist "win win" ... die Software darf weiterhin eingesetzt werden, ist jetzt aber sicher.

Das ist der Teil Rocket Science, wir reden von CFG, DEP, ASLR, Bottom-Up ASLR, SEHOP, Validate Heap, ACG, EAF, IAF und noch ein paar Buchstaben die ich auch nicht verstehe. Ich bin Admin, kein Entwickler und ich wette, die wissen das auch nicht. Reden wir einfach von "Ansprechbaren Funktionen und Methoden", die Angriffe erlauben.

Der Weg der Integration für einen Admin ohne Ahnung wie mich ist einfach: Ich verbiete alles, weil ich keine Ahnung habe. Ich teste was passiert, ist es kaputt, funktioniert es nicht, dann muss ich es im, Regelwerk korrigieren. Der Schuldige ist ja bekannt. Easy Work.

Der Prozessmonitor nannte sich EMET (Enhanced Mitigation Expirience Toolkit). EMETs Tod wurde zum Januar 2017 angekündigt, aber die Beerdigung war erst am 31. Juli 2018.

Einige Funktionen von EMET sind technisch als Grundfunktion in den Windows 10 Kern eingeflossen, andere Teile leben im Exploit Guard weiter, der zusätzlich neue Bedrohungen abfangen kann und nur in der Enterprise funktioniert.

Vergleich EMET vs. Exploid Guard Protect devices from exploits

Shorttrack Step by Step Anleitung, den IE kaput zu machen:

Export der Default Exploit Guard Einstellung eines blanko installierten Systems in ein XML und dieses als Regelwerk verteilen. Fertig.

Die Default Einstellung für jeden Prozess ist:

<SystemConfig>
<Fonts DisableNonSystemFonts="true" AuditOnly="false" />
</SystemConfig>

Die erste Idee, das true mit dem false auszutauschen ist leider nichtzielführend. Microsoft hat sich hier etwas besonderes ausgedacht. Sie definieren das Fontblocking im XML zwar SYSTEMWEIT(!), aber das Deaktivieren dieses Schalters kann nur auf ANWENDUNGSEBENE geschehen. also PRO Prozess. Nicht allgemein ...

Block untrusted fonts = App-level only 

siehe: Customize exploit protection

Lösung, XML Edit, in diesem Fall für den IE:

<AppConfig Executable="iexplore.exe">
<ASLR ForceRelocateImages="true" RequireInfo="false" />
<Fonts DisableNonSystemFonts="false" AuditOnly="false" Audit="true" />
</AppConfig>

über die Notwendigkeit von Audit = True kann man streiten, wenn es ins Eventlog geschrieben wird, sollte es auch jemanden geben, der das liest ...

Das XML kann über diverse Methoden verteilt werden, auch in der Workgroup. Es gibt 3 cmdlets:

• ConvertTo-ProcessMitigationPolicy
  Das cmdlet konvertiert ein vorhandenes EMET XML. Upgrade ist also problemlos möglich.
• Get-ProcessMitigation
  Export einer per Hand geklickten Konfiguration oder editiertem XML
• Set-ProcessMitigation
  Anwenden des XMLs

Anschalten/ Verteilen über die Gruppenrichtlinie

Computerkonfiguration\Administrative Vorlagen\Windows Komponenten\Administrative Vorlagen\Windows Defender Antivirus\ Exploit Guard\
Allgemeine Einstellungen für den Exploit Schutz verwenden = Aktiviert
Dann den Pfad zum XML definieren, Lokal oder UNC