Kategorie-Archiv: Microsoft

Problem

Nach dem letzten Patchday am 16.1.2024 zeigt Edge beim starten nur noch ein weisses Fenster an, erzeugt eine irrsinnige CPU-Last und erzeugt im Eventlog Einträge die einen Appcrash Protokollieren.

Das „weisse leere Fenster“ gilt auch für Chrome, manchmal auch für Firefox (allerdings gibt’s da schon einen fix) und alles was „msedgewebview2“ als Webview-Element verwendet.

Betroffen ist Windows Server 2022 21H2.

Im Ereignisprotokoll findet sich dabei dieser Eintrag, der auf „bad_module_info“ verweist, aber keine weiteren Details bereithält:

Name der fehlerhaften Anwendung: bad_module_info, Version: 0.0.0.0, Zeitstempel: 0x00000000
Name des fehlerhaften Moduls: unknown, Version: 0.0.0.0, Zeitstempel: 0x00000000
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00007ff704a393ae
ID des fehlerhaften Prozesses: 0x3810
Startzeit der fehlerhaften Anwendung: 0x01da4a1151de7b46
Pfad der fehlerhaften Anwendung: bad_module_info
Pfad des fehlerhaften Moduls: unknown
Berichtskennung: d6beaba6-a725-44a9-bd16-dba961694a0c
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 

(Einen leeren weissen Screenshot spare ich mir)

Lösung

Das Update ASAP deinstallieren:

wusa /uninstall /kb:KB5034129

… geht auch via DISM …

DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.2227.1.4

… oder sogar per GUI…

Nach dem Reboot läuft sofort wieder alles.

Wie entfernt man an der Kommandozeile einen Computer aus dem AD?

Lösung (Lokal)

Um den lokalen Computer auf die Schnelle (mit Neustart!) aus dem ActiveDirectory zu entfernen:

Remove-Computer -UnjoinDomaincredential DOMÄNE\BENUTZER -PassThru -Verbose -Restart 

Lösung (DC)

Es geht natürlich auch mit Gewalt, auf der ActiveDirectory Seite:

Remove-ADComputer -Identity COMPUTERNAME

Diese kleine Schritt-für-Schritt Anleitung zeigt, wie man seine Website(n) im IIS so konfigurieren kann, dass eingehende http:// Anfragen zur Website sicherem https:// umgeleitet werden. Das passiert automatisch im Hintergrund mit einer „301“ HTTP-Meldung (permanent redirect), damit Browser und Clients das auch speichern können.

1. Das Microsoft IIS URL-Rewrite Modul herunterladen und installieren

2. Den „Internetinformationsdienste (IIS)-Manager“ öffnen, die Site um die es geht öffnen und das „URL Rewrite“ Modul öffnen

3. Oben rechts „Regel hinzufügen“ klicken …

4. dann eine „Leere Regel“ unter „Eingehende Regeln“ auswählen …

5. Den oberen Teil der Regel („Übereinstimmung mit URL“) folgendermaßen ausfüllen:
– Name: Ein sinnvoller Name fur die Kosmetik (Pro-Tipp: Keine Umlaute oder Emojies)
– „Angeforderte URL“: Entspricht dem Muster
– „Unter Verwendung von“: Reguläre Ausdrücke
– „Muster“: (.*)

6. „Bedingungen“ ausfüllen
– Die (leider zu kleine) Auswahl von „Logische Gruppierung“: Übereinstimmung mit allen Elementen
– Dann den Button „Hinzufügen“ rechts daneben klicken

7. Die „Bedingung“ ausfüllen, danach mit „OK“ schliessen
– Bedingungseingabe: {HTTPS}
– „Überprüfen, ob die Eingabezeichenfolge“: Entspricht dem Muster
– Muster: ^OFF$
– Groß-/Kleinschriebung ignorieren: aktiviert

8. Nachdem die Regel übernommen wurde, weiter unten im IIS nun eine „Aktion“ konfigurieren und die Änderung übernehmen:
– Aktionstyp: Umleiten
– Aktionseigenschaften „URL Umleiten“: https://{HTTP_HOST}/{REQUEST_URI}
– Abfragezeichenfolge anhängen: Deaktivieren
– Umleitungstyp: Dauerhaft
Oben rechts „übernehmen“

Ergebnis (schnelle Lösung)

Das ganze manifestiert sich mit dem Klick auf „Übernhemen“ auch in der entsprechenden web.config Datei der Site. Man kann den <rules> Block natürlich auch manuell bearbeiten und/oder kopieren.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="SSL-Weiterleitung" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="^OFF$" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}/{REQUEST_URI}" appendQueryString="false" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Windows speichert Benutzerkontokennwörter („Anmeldeinformationen“) grundsätzlich als Hash. Das ist auch eine gute Idee, denn wenn Angreifer die SAM-Datenbank erbeuten hilft diese nicht beim Einbruch weiter. In der Theorie.

Normalerweise, also „by default“ werden dabei sowohl einen LAN Manager-Hash („LM-Hash“) als auch einen Windows NT-Hashwert („NT-Hash“) abgelegt. Windows speichert beide Hashes dann entwerder in der lokalen Security Accounts Manager Datenbank (SAM)-Datenbank oder im Active Directory.

Der LM-Hash ist bekanntlich eher schwach und SEHR anfällig für Angriffe, die das Plaintext-Kennwort extrahieren. Am besten verhindert man also, dass Windows den LM-Hash überhaupt speichert. Das ist seit ein paar Jahren (~2012) auch praktisch nicht mehr nötig und nur noch zur Abwärtskompatiblität da. Windows 10 hat das Flag beispielsweise schon ab der Installation gesetzt.

Da eine lebendige Domäne aber selten aus den aktuellensten PCs und Betriebssystemen besteht, lautet unsere aktuelle Empfehlung „auf Nummer sicehr“ zu gehen.

Lösung

Man kann Windows die Speicherung der LM-Hashes per GPO verbieten. Achtung, selbige muss auch auf DCs angewendet werden. Die „Default Domain Policy“ ist zum Beispiel ein guter Ort für eine solche Änderung.

Computerkonfiguration > Windows-Einstellungen > Sicherheitsrichtlinien > Lokale Richtlinien > Sicherheitsoptionen > „Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern“

⚠️ Achtung: Bereits bestehende Hashes werden dadurch nicht sofort entfernt. Das passiert erst bei der nächsten Kennwortänderung.