[English]Anfang April 2023 hat Microsoft eine neue Version seines Microsoft Security Compliance Toolkit 1.0 veröffentlicht. Eigentlich ist es für Administratoren in Unternehmen eine Pflichtübung, sich mit diesem Teil zu befassen. Nachfolgend stelle ich das Microsoft Security Compliance Toolkit 1.0 kurz vor – gehe allerdings auf dessen Schattenseiten ein. Denn die Implementierung dieses Toolkits ist eine "Lachnummer", die zeigt, dass die Verantwortlichen bei Microsoft nicht mehr verstehen, was sie da zusammenstoppeln und an die Administratoren bringen.
Anzeige
Microsoft Security Compliance Toolkit 1.0
Das Microsoft Security Compliance Toolkit ist eine Zusammenstellung an Tools, die es Sicherheitsadministratoren in Unternehmen ermöglichen, von Microsoft empfohlene Sicherheitskonfigurations-Baselines für Windows und andere Microsoft-Produkte herunterzuladen, zu analysieren, zu testen, zu bearbeiten und zu speichern und sie mit anderen Sicherheitskonfigurationen zu vergleichen. Der Download auf dieser Microsoft-Webseite umfasst in der Fassung vom 7. April 2023 folgende Dateien:
| Version: 1.0 | Published: 4/7/2023 |
| File Name: | Size |
| Windows 11 version 22H2 Security Baseline.zip | 1.4 MB |
| LGPO.zip | 520 KB |
| Microsoft 365 Apps for Enterprise-2206-FINAL.zip | 722 KB |
| Microsoft Edge v112 Security Baseline.zip | 352 KB |
| PolicyAnalyzer.zip | 1.5 MB |
| SetObjectSecurity.zip | 314 KB |
| Windows 10 Update Baseline.zip | 453 KB |
| Windows 10 Version 1507 Security Baseline.zip | 904 KB |
| Windows 10 Version 1607 and Windows Server 2016 Security Baseline.zip | 1.5 MB |
| Windows 10 Version 1809 and Windows Server 2019 Security Baseline.zip | 1.3 MB |
| Windows 10 Version 20H2 and Windows Server Version 20H2 Security Baseline.zip | 1.5 MB |
| Windows 10 version 21H2 Security Baseline.zip | 1.2 MB |
| Windows 10 version 22H2 Security Baseline.zip | 1.2 MB |
| Windows 11 Security Baseline.zip | 1.2 MB |
| Windows Server 2012 R2 Security Baseline.zip | 699 KB |
| Windows Server 2022 Security Baseline.zip | 1.3 MB |
Unterstützt werden Windows Server 2019, Windows Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows 11, Windows Server 2022, wobei Windows 8.1 seit Januar 2023 aus dem Support gefallen ist. Zum Toolkit schreibt Microsoft:
The Microsoft Security Configuration Toolkit enables enterprise security administrators to effectively manage their enterprise's Group Policy Objects (GPOs). Using the toolkit, administrators can compare their current GPOs with Microsoft-recommended GPO baselines or other baselines, edit them, store them in GPO backup file format, and apply them via a domain controller or inject them directly into testbed hosts to test their effects. For more information, see Windows Security Baselines.
Die dunklen Seiten des Toolkit
Stefan Kanthak hat mich bei einer Mail, die er Ende April 2023 an das Microsoft Security Response Center (MSRC) geschickt hat, auf BCC gesetzt. Bei einem Blick auf die Details sind ihm Punkte aufgefallen, die jedem Beobachter quasi die Kinnlade herunter fallen lassen. Es handelt sich um ein Security Toolkit, so dass man annehmen darf, dass die Ersteller ihren Job beherrschen. In der Mail an das MSRC fragt Kanthak, ob die Verantwortlichen schon mal auf den Kalender geschaut hätten.
Hi MSRC,
have you lately dared to look at your calendar?
Have you noticed that it shows the year 2023?Then visit your companies the web page Download Microsoft Security Compiance Toolkit 1.0, click the circled plus sign in front of the "System Requirements" and see the (fortunately DEAD) hyperlink "Microsoft Word Viewer"!
Es geht Kanthak um folgende Passage mit den Systemanforderungen zur Verwendung des Microsoft Security Compliance Toolkit 1.0, und er fragt, ob Microsoft die Leute verschaukeln möchte.
Denn unter den Systemanforderungen wird tatsächlich weiterhin der Microsoft Word Viewer genannt und sogar verlinkt. Der Word Viewer ist vor fast 6 Jahren aus dem Verkehr gezogen worden (siehe mein Blog-Beitrag Word Viewer: Rückzug im November 2017). Folgerichtig führt der Link auf der Microsoft-Seite auch auf eine Landing-Page, die mit dem Word Viewer nichts mehr zu tun hat. Auch der Verweis auf Windows 8.1 zeigt, dass Microsoft die Seite mit den Systemanforderungen nicht mehr wirklich überarbeitet. Aber es gibt einen weiteren Klopper, den Kanthak so beschreibt.
The executables of the Microsoft Security Compliance Toolkit offered there are still vulnerable to DLL hijacking. Will your developers ever learn to use /DEPENDENTLOADFLAG:2048?
Es ist bezeichnend, dass die ausführbare Programmdatei des Microsoft Security Compliance Toolkit für DLL-Hijacking anfällig ist. Raymond Chen hat in diesem Beitrag einige Hinweise gegeben, dass man beim Linken der Programme über den Parameter /DEPENDENTLOADFLAG festlegen kann, dass Windows (ab Windows 10 Version 1607) abhängige DLLs nur statisch lädt. Mit dem Wert LOAD_LIBRARY_SEARCH_SYSTEM32 als Parameter dürfen DLLs nur auch dem Windows-Ordner System32 geladen werden. Kanthak weist in diesem Kommentar hier im Blog ebenfalls auf dieses Thema hin. Unter dem Strich hinterlässt das bei mir keinen guten Eindruck von dem, was Microsoft so treibt.
2015
"System Requirements
Supported Operating System
Windows Server 2019, Windows Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows 11, Windows Server 2022
. Microsoft or Microsoft Word Viewer (available as a free download can be used to view Word documents.
. For Windows 8.1 and Windows 7, .NET Framework 4.6 or later is required."
Ist nach der englischen Grammatik Windows 7 jetzt unterstützt oder nicht?
Sie meinen in der Schrödinger-Edition? ;-)
Würde das relativieren wollen. Auch wenn man als Endanwender oder Admin ein durchgängiges Management von Doku + Programm wünscht ("dass die Ersteller ihren Job beherrschen", s.o.) ist dies halt nicht immer der Fall. Im Blog sprechen
wir über mehrere Aspekte:
1. Doku ist alt, unklar oder falsch (vgl "Viewer) und unvollständig (vgl Win 7 @Andy)
– Doku ist operativ oder selbst im Audit nicht sauber traceable (imho echt defizitär bei diesern MS Web-generated-Docs).
Es fehlen rudimentäre Attribute für jedes instanziiertes Objekt der Klasse "Doku XY" wie "Erstellungsdatum", "Überarbeitung", "Verfasser", "Changelog", Verantwortlicher
– Intern weiss ich zufällig, dass durch (nennen wir's positiv) "interne Arbeitsteilung" bei MS die Erstellung von Doku zB von internen Prozessen der Programmierung recht stark entkoppelt sind. Internes Prozessmanagement und Datagovernance? 5, setzen.
2. Systemanforderungen
– Womit läuft es denn nun wirklich – aber wenn (1) Doku an sich schon nicht stimmt ?
– Hier nützt es dann wenig, wenn man nur auf das aktuelle Datum in 2023 verweist (den eigentlich wissen wir ja, das die Doku veraltet ist oder nicht stimmt)
– Schon vor zig Jahren hab ich einige Treiber für XP einfach unter W7 testen lassen – ohne Doku.
– Eindeutige Systemanforderungen sind hier wohl eher ein nerviges Doku-Problem
3. Vulnerabilities durch DLL Hijacking und Einhaltung MS-eigener Programmier, Compilier oder Roleout-Practices.
– Kann durchaus kritisch oder tragisch sein
– Im Sicherheitsbereich echt unschön, lasse Begriffe (s.o.) "Schattenseiten" 100% gelten
– Jedoch ist dies leider auch andernorts zu finden. Korrektes Softwareengeneering und Management bei Definition von klaren "Best Practice" im Development, Standards oder Protokollauswahl bis zu Compilerhärtungseinstellungen, etc …
^ HIER zu (3) würde ich zuerst ansetzen und meckern
Anstatt Sicherheit ins OS via Mausklick per Default zu implementieren, wird die Verantwortlichkeit mit solchen Frickel-Lösungen an die örtliche Administration verschoben.
Das ist nichts anderes wie 200+ GPO Richtlinien betreffend für den Datenschutz die sich fortlaufend ändern.
Microsoft könnte, aber dann stirbt das 20 jahre alte Drittanbieter program. ich implementiere ein Ruleset jede Woche bei einem anderen Kunden.
die excludes die ich bauen muss, baue Ich nie für MS Systeme. immer nur für irgendeine andere Software oder nicht vorhandene Technik oder Workflow beim Kunden
Die Programme LGPO.exe und SetObjectSecurity.exe hat Aaron Margosis vor VIELEN Jahren verbrochen. Ich habe ihn bereits damals auf seine ANFÄNGER-Fehler hingewiesen, und als das auf taube Ohren stiess, auch das MSRC informiert.
JFTR: die aktuelle Antwort des MSRC lautete "Bitte wenden Sie sich an den Support."
"Trustworthy computing" ist bei M$FT ein FREMDWORT!
Was diese Klitsche wirklich kann und macht ist unverantwortliche SCHLAMPEREI!
@Stefan – sage mal – haben die denn keine Vorgaben? Da sollt's doch so ne "Art" Merkzettel oder Company Policy für Code, EXE, DLL oder Compilersettings geben… Oder macht's jeder so wie's gefällt?
Auch wenn ich kein Coder (mehr) bin – DEPENDENTLOADFLAG und Verhinderung von DLL Preloading Attacks kommt ja von MS, einmal suchen reicht – und den letzten Link mit Frage erstellte ein Aaron in 4/2023- ist das der von oben ? :-) :-) wohl eher nicht, da public FAQ-area…
Müsste man aus Audit-Sicht bei Windows und Tools dann alle DLLs oder EXEs von MS noch einmal durchschauen? Auf die Idee wär ich nie gekommen.
Was haltet ihr denn inhaltlich von dem Tool? Also ich fand es jetzt leider inhaltlich wenig hilfreich (oder habe es einfach nicht geschafft, es richtig anzuwenden) – da mir für Windows 10 nur eine handvoll Policies angezeigt wurden – ich aber eigentlich GPOs nach Intune verlagern muss und eine Bestandsaufnahme der GPOs mit Gap zur Baseline erreichen wollte… naja irgendwie nicht geklappt… 🤷🏻♀️
kein Mensch benutzt irgendetwas anderes als das integrierte GPO Backup. mehr braucht es nicht.
manchmal noch den Policyanalyser, aber nur für den compare.
der Import findet, wenn es vereinzelt ist, per powershell (set-gpregistryvalue) statt.
der Richtlinien Vorschlag ist ordentlich.
Es gibt zum ganzen Themenbereich viele weitere Probleme, z.b. auf nicht englischen OS Versionen!
Ich empfehle das GitHub Projekt HardeningKitty auszuprobieren, um schnell und sicher eine Abgleich der verschiedenen Sicherheitsempfehlungen Microsoft, CIS, DOD mit der eigenen Umgebung durchzuführen.
https://github.com/scipag/HardeningKitty
Welche Probleme? Die Richtlinien Backups sind sprachneutral. Der Import Fehler ist rein GPMC technisch, aber die in der gpttmpl.inf angemeckerten Sicherheitskennungen sind als Wellknown SID hinterlegt und werden entpsrechend als SID und nicht als STRING integriert.
Die Registry ist was die Werte angeht nicht lokalisiert, sodass die registry.pol in jeder Sprache funktioniert.
Die audit.csv arbeitet mit GUIDs für das Logging, auch das ist sprachneutral.
Von welchen Fehlern redest du?
sorry aber eigentlich ist die Präsenz dieses tools schon eine Lachnummer an sich. Wenn Microsoft die Sicherheit seiner Systeme so ein wichtiges Anliegen wäre, dann hätten diese nach der Installation längst dieses Defaults so gesetzt, wie sie in diversen Beispiel GPOs definiert sind und wären nicht änderbar.
Aber da kommt dann die ominöse Abwärtskompatibilität von MS ins Spiel, weil man angeblich noch immer aus Kompatibilitätsgründen Sachen von vor gefühlt 30 Jahren mitziehen muss. Allein dieser Wunsch zeigt wie weit her es mit der Security bei Microsoft ist.
> ominöse Abwärtskompatibilität von MS
Diverse ominöse Möglichkeiten beizubehalten, wird sicherlich nicht alleine von MS abhängen, Recherchetipps:
https://de.wikipedia.org/wiki/CLOUD_Act
https://de.wikipedia.org/wiki/National_Security_Letter
Leider flasch.
Gerade weil es MS ein Anliegen ist, veröffentlichen sie die Liste, damit die Systeme sicherer werden. MS kann den Schalter nicht "per Default" umlegen.
Schau dir doch nur die Aufschreie an mit jeder Härtung des Systems. Diese rumgeheule der Admins: "Das kommt zu schnell", "Das geht bei uns nicht", "unsere WaWi macht TLS 1.0", "Der Hersteller bietet nur NTLM", "Ahhhh, Cloud mit 2FA erzwingen, das geht nicht" … usw.
Microsoft tut vielleicht nicht genug, aber wäre es ihnen egal, würden sie die Baseline nicht veröffentlichen.
Nimm das BSI, CIS, STIG DoD, ACSZ und wie sie alle heissen: Die Basis ist immer das MSSCT. Beim CIS arbeitet MS mit usw.
Vorsicht: Die Windows 10 Update Baseline ist veraltet und vom Datum immer noch 2020..
Die Einstellungen passen nicht mehr zu den Kategorien, die Micrososft mit den aktuellen ADMX temp. eingebaut hat. Darüber bin ich schonmal gestolpert. Dachte mir ich warne hier mal kurz vor, ehe sich jemand den Kopf zerbricht.
Naja was soll ich sagen. Hätte mich auch mal gewundert, wenn etwas vom Microsoft veröffentlicht wird, wo man nix meckern kann. Aber sie schaffen es halt immer wieder. Ich würde sagen typisch im Konzern, läuft bei anderen Konzernen auch nicht anders, weil Person A nicht weiß was Person B tut und niemand sich für irgendwas verantwortlich fühlt. Aber wie meine Vorredner schon sagten, es wäre ja auch zu einfach gewisse Dinge schon defaultmäßig zu implementieren. Aber da redet die Sicherheitsabteilung nicht mit den Kernelprogrammierern
Was mir in all den Jahren als Admin immer noch völlig unverständlich ist, warum man diese Rulesets nicht standarmässig integriert und aktiviert und dazu einen kleinen Guide liefert warum man diese Einstellungen an lassen soll. Wenigstens für Neuinstallationen. Migrationen übernehmen ja das vorgehende Ruleset.
Hätte zudem den Vorteil, das ein Admin bei Neuinstallation allenfalls über etwas stolpert, das er noch nicht bedacht hat in älteren Installationen.
So funktioniert das nicht.
Die Härtung erfolgt durch dich, deswegen gibt es ja die Richtlinien, da es immer kundenspezifisch ist, was durchzusetzen und umsetzbar ist. MS ist da wie Standard VGA: Der kleinste gemeinsame Nenner.
Wäre es simpel möglich und so trivial, einfach nur "Sicherheit anschalten" und alles ist schick, dann hätte ich keinen Job.