Hacker können Windows-Anmeldedaten abgreifen

In Windows gibt es eine Schwachstelle, über die Hacker die Windows-Anmeldedaten über öffentliche und ohne Passwort geschützte Freigaben im Netzwerk abgreifen können.


Werbung



Was steckt hinter SCF-Dateien?

SCF steht für Shell Command File (siehe), die Dateien werden unter Windows eigentlich häufiger verwendet. Hier ein Beispiel einer solchen .scf-Datei, die den Explorer öffnen soll.

[Shell]
Command = 2
IconFile = explorer.exe, 1
[Taskbar]
Command = Explorer

All zu viel Dokumentation gibt es nicht, wie man der Diskussion hier und hier entnehmen kann.

Ungeschützte Netzwerkfreigaben

Unter Windows kann man nun mit sehr einfachen Methoden über das Netzwerk die Anmeldedaten abgreifen. Der Angreifer muss lediglich eine bösartige SCF-Datei in öffentlich zugänglichen Windows-Ordnern ablegen, die diese Informationen anfordert.

Ich habe bei meiner Suche diesen Artikel aus 2016 gefunden, wo jemandem dies aufgefallen ist. Aktuell hat man das Thema bei Bleeping Computer aufgegriffen. Der Hintergrund: Computer mit gemeinsam genutzten Ordnern, die durch ein Passwort geschützt sind, sind sicher. Da dies die Standardoption in Windows ist, sind die meisten Benutzer nicht anfällig für diesen Angriff.

Dennoch teilen sich Benutzer in Unternehmensumgebungen, Schulen und anderen öffentlichen Netzwerken aus Gründen der Benutzerfreundlichkeit häufig Ordner ohne Passwort, so dass viele Systeme für Angriffe offen bleiben.

Platziert nun ein Angreifer eine bösartige SCF-Datei in öffentlich zugänglichen Windows-Ordnern ablegen. Sobald sie platziert wurde, wird sie aufgrund eines mysteriösen Fehlers ausgeführt, sammelt den NTLM-Passwort-Hash des Ziels und sendet ihn an einen vom Angreifer konfigurierten Server. Mit öffentlich zugänglicher Software könnte ein Angreifer den NTLM-Passwort-Hash knacken und später auf den Computer des Benutzers zugreifen.

Im April gemeldet, teilweise gepatcht

Die Schwachstellewurde von dem kolumbianischen Sicherheitsforscher Juan Diego entdeckt, der das Problem im April an Microsoft meldete. Microsoft hat den Angriffsvektor beim Oktober 2017-Patchday über den Sicherheitshinweis ADV170014 gepatcht. Zur Zeit stehen optionale Updates für Windows 10 und Windows Server 2016 sowie den Internet Explorer zur Verfügung.

Windows 7 und Windows 8.1 haben keine Updates zum Schließen dieser Lücke erhalten, wie Bleeping Computer hier schreibt. Die Angriffsmethode soll, laut Bleeping Computer, immer mal wieder zum Abfischen von Anmeldedaten benutzt worden sein. Weitere Details sind dem Artikel bei Bleeping Computer zu entnehmen.


Werbung

Dieser Beitrag wurde unter Sicherheit, Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

7 Kommentare zu Hacker können Windows-Anmeldedaten abgreifen

  1. Bolko sagt:

    manueller Fix:

    Mittels Registry File den SCF-Filehandler löschen:

    —–Schnipp—–
    Windows Registry Editor Version 5.00

    [-HKEY_CLASSES_ROOT\.scf]
    [-HKEY_CLASSES_ROOT\SHCmdFile]
    [-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.scf]
    [-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SHCmdFile]
    —–Schnapp—–

    In der Firewall eine SMB-NetBIOS-Sperre einrichten, damit via SMB keine Daten ins Internet geschickt werden können:

    in einer Konsole mit Adminrechten eingeben:

    netsh advfirewall firewall add rule name=”Port 135, 137, 138, 139, 445 – TCP – eingehend” profile=any enable=yes dir=in action=block protocol=TCP localport=135,137,138,139,445

    netsh advfirewall firewall add rule name=”Port 135, 137, 138, 139, 445 – TCP – ausgehend” profile=any enable=yes dir=out action=block protocol=TCP localport=135,137,138,139,445

    netsh advfirewall firewall add rule name=”Port 135, 137, 138, 139, 445 – UDP – eingehend” profile=any enable=yes dir=in action=block protocol=UDP localport=135,137,138,139,445

    netsh advfirewall firewall add rule name=”Port 135, 137, 138, 139, 445 – UDP – ausgehend” profile=any enable=yes dir=out action=block protocol=UDP localport=135,137,138,139,445

    Wer keine Scripte braucht, der kann auch den Scripting-Host abschalten:
    —–Schnipp—–
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings]
    “enabled”=”0”
    —–Schnapp—–

    Anschließend Computer neu starten.

    Edit:
    Die Zeilenunmbrüche in den obigen Reg-Files muss man korrigieren. Das liegt an der Forensoftware.

    • Martin Feuerstein sagt:

      Es geht auch mit etwas weniger Brechstangeneinsatz.
      – es müssten lediglich in den Schlüsseln HKCR\.scf und (pro Benutzerkonto) HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.scf jeweils der Default-Wert gelöscht/auf etwas unnützes geändert werden.
      –> Vorsicht: Unter Windows XP (und ich meine auch Vista) wurde z. B. die Funktion des Icons “Desktop anzeigen” durch eine SCF-Datei gesteuert.

      – die ausgehenden Firewallregeln verhindern keinen ausgehenden Zugriff per SMB, da nicht wie oben genannt die Quell-, sondern wenn überhaupt die Zielports blockiert werden müssen. Das ist fürs öffentliche WLAN gut, würde dann aber auch den Zugriff aufs eigene NAS zu Hause blockieren oder auch auf den Firmenserver. Dazu müsste also noch mit den Profilen für “Öffentlich” und “Privat”, ggf. “Domäne” gearbeitet werden.
      – durch die eingehenden Firewallregeln wird verhindert, dass – auch aus dem lokalen Netz – auf die Shares des eigenen Computers zugegriffen werden kann, was in Unternehmensumgebungen gerne mal zur Installation des Virenscanners und anderer Agenten genutzt wird. Ebenso ist die Computerverwaltungskonsole blockiert, es kann auch Auswirkungen auf die Kommunikation zwischen Domänen-Clients und -Controller haben.
      ==> im öffentlichen WLAN zu empfehlen, zu Hause sicher auch nicht grundlegend verkehrt, da wird wohl weniger auf die Shares bzw. Computerverwaltung zugegriffen. In einer kleineren Unternehmensumgebung würde sich – wenn überhaupt – z. B. eine Erlauben-Regel für eingehenden Verkehr anbieten, bei der die Edge-Ausnahme auf “Blockieren” (=Standard) gesetzt ist. Verkehr aus dem eigenen Netz geht dann durch, Verkehr aus fremden gerouteten(!) Netzen nicht. Auch hier sollte das dann zusätzlich über die Profile etwas feiner gesteuert werden.

      Der Windows Scripting Host hat mit SCF-Dateien nix zu tun und es werden “nur” VBScripts blockiert, Batch-Skripts funktionieren weiterhin – mit denen kann man dann immer noch genug Schaden anrichten (um das zu blockieren müsste für die Dateitypen .bat und .cmd ebenfalls noch der Default-Wert aus der Registry entfernt werden, Vorsicht: Batch-Dateien werden ggf. auch durch Installations- und andere Programme und Abläufe gebraucht).

    • Bolko sagt:

      Falls man Freigaben im Netzwerk benötigt, dann darf man die Firewallregeln nicht innerhalb dieses Netzwerkes anwenden, sondern nur am Gateway (Router oder Firewall-Computer), also an der Schnittstelle zwischen lokalem Netzwerk und Internet.

      • Martin Feuerstein sagt:

        Deine Regeln für ausgehenden SMB-Verkehr funktionieren nicht, da sie nicht die ZIEL-Ports blockieren. Der durschnittliche Gateway ist kein Windows-PC, die Befehle sind dort also nicht anwendbar (bestenfalls sinngemäß, bei Heim-Routern meist gar nicht). Wer sich Profi-Hardware hinstellt, sollte wissen, dass man niemals eine Any-Regel zum Erlauben von Datenverkehr erstellt, insofern sollte keine Blockieren-Regel erforderlich sein.

        • Bolko sagt:

          Die ausgehenden Reglen weglassen oder auf profile=public setzen?

          Die eingehenden Regeln auf profile=public setzen (statt profile=any) ?

          Weißt du, ob SMB2 nur den Port 445 benötigt?

          • Martin Feuerstein sagt:

            hast RPC mit dynamischen Ports vergessen 😉

            Warum dann nicht gleich so? Der Durchschnitts-DAU weiß leider nicht, was er durch welchen Parameter verursacht und tippt blind ab. Durch deine Pauschal-Befehle werden nun wohl einige Windows-Umgebungen zerstört oder mindestens nachhaltig geschädigt, spätestens durch die Reparaturversuche.

            Deine Befehle (in Gesamtheit) schaden im Zweifel mehr als sie nützen. Und derjenige, der das wieder richten muss, erfährt hoffentlich, was der unbedarfte Anwender zuvor eingetippt hat. Sonst bleibt nur die Neuinstallation, da es, um unspezifische Fehler durch aus dem Internet abgetippte Befehle zu finden, meist so viel Zeit (und damit Geld) kostet, dass eine Neuinstallation wirtschaftlicher ist, selbst mit Herunterladen von Treibern bei 1 MBit/s. Ob dabei dann auch Daten draufgehen… pfff… (hoffentlich nix verschlüsselt ;-)) Dazu kannst du dir gerne mal die “Stunts” angucken, die SemperVideo in abgeschotteten VMs veranstaltet, wie z. B. die Analyse der “Bad Rabbit”-Schadware.

            Dennoch, um deine – ja, weiß ich, in bester Absicht vorgeschlagenen und gut gemeinten – Vorschläge noch ins rechte Licht zu rücken: die Registry-Bearbeitung, um den Start von SCF-Dateien zu verhindern, um dieses spezifische Problem zu vermeiden, ist ein gangbarer Ansatz.

          • Martin Feuerstein sagt:

            >> Weißt du, ob SMB2 nur den Port 445 benötigt?

            Generell läuft es über 445 TCP, kann aber auch in NetBIOS eingepackt werden.

            SMB ist serverseitig übrigens nicht NAT-fähig (zumindest Windows-Dateiserver). Es könnten also nicht mehrere Computer eines Netzwerks gleichzeitig eine Sitzung zum gleichen SMB-Server im Internet (hinter dem NAT-Router) aufbauen – die Sitzung der zuvor anfragenden Computers würden dann beendet.

            Hier noch paar Infos zu SMB/NetBIOS und den Ports/Protokollen eines Windows-Betriebssystems:
            https://en.wikipedia.org/wiki/Server_Message_Block#SMB_2.0
            https://en.wikipedia.org/wiki/NetBIOS_over_TCP/IP
            https://support.microsoft.com/de-de/help/832017/service-overview-and-network-port-requirements-for-windows – insbesondere auch Punkt 31, 36, 38, 43, beachten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.