Bad-USB geskriptet abwehren (ab Windows 8)
Moin Kollegen.
Vor einiger Zeit stieß mal ein Beitrag von mir USB-Laufwerke sperren auf reges Interesse, in dem ich skizziert hatte, wie ich unter Windows domänenweit verhindere, dass unerwünschte USB-Datenträger angeschlossen werden. Ich möchte das hier wieder aufgreifen und etwas ausführlicher erklären.
Viele kennen mittlerweile das USB-Rubberducky. http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe
Das ist ein präparierter USB-Stick, den man lieber nicht an seinen Rechner anstecken sollte, denn er emuliert eine Tastatur und tippt wie wild Schadcode ein. Weitaus besser als ein Skript – es ist eher wie ein Makrorekorder/-player, der genauso handelt, wie der Hacker selbst – nur viel, viel schneller. Probate Abwehrmaßnahme ist natürlich, die Installation von unbekannten Geräten zu verbieten – meist wird dies über eine Securitysoftware erreicht. Diese muss jedoch erst einmal wissen, was denn erlaubt ist und was nicht… gerade bei Tastaturen wäre es fatal, zu viel zu verbieten…
Ich werde zeigen, dass man es auch über eventgetriggerte Tasks und kleine Skripte mühelos lösen kann.
Speziell soll es in diesem Beispiel darum gehen, als Tastatur getarnte Geräte wie das Ducky abzuwehren.
Warum das Ganze? Man stelle sich vor, jemand hat seinen Bildschirm nicht gesperrt und das Büro verlassen. Der Angreifer hat darauf gewartet, weiß aber nicht, wieviel Zeit ihm bleibt und geht von weniger als einer Minute aus. Das ist für ein Gerät wie das Rubberducky jedoch mehr als genug, um kräftig Schaden anzurichten. Das Rubberducky installiert sich also und nach etwa drei Sekunden tippt es mit mehreren Tausend Anschlägen pro Minute munter Schadcode in die Powershell, und was an Daten im Homeverzeichnis aufgefunden wird, wird mal eben auf den Stick kopiert, fein.
Nach der Vorrede hier nun zum Plan.
Was die Schwäche des Duckies ist, ist die kleine Anlaufzeit, die Windows braucht, um ihn startklar zu machen. In diesen kurzen Sekunden kann man ihn einfach gleich wieder deinstallieren lassen.
Ablaufplan: Ein Bad-USB-Gerät wird angesteckt, Windows installiert es und trägt die Installation im Eventlog ein. Ein eventgetriggerter Task springt an und schaut nach, ob die derzeit installierten Geräte mit einer Whitelist übereinstimmen und deinstalliert alles Überzählige. Nach weniger als einer Sekunde ist die Ente meist bereits abgeschossen, noch bevor sie ihren ersten Tastendruck absenden konnte.
Als erstes besorgt man sich die devcon.exe (zum Skripten von Gerätedeinstallationen), wie hier beschrieben ist http://social.technet.microsoft.com/wiki/contents/articles/182.how-to-o ...
Wichtig: eine Version pro Architektur, die 32er-Version läuft zwar auf 64-Bit, aber fehlerhaft! Ich verwende Version 6.1.7600.16385 auf win8.1.
Die devcon verteilt man zunächst per GPO domänenweit nach c:\windows
Man erzeugt dann per Domänenstartskript eine Whitelist pro Rechner:
Dann kommen wir auch schon zum geplanten Task, den wir per GPO verteilen (siehe https://technet.microsoft.com/en-us/library/cc725745.aspx ):
Ausführendes Konto: System
Trigger: Tasktrigger bei Event und zwar Log: Microsoft-Windows-Kernel-PnP/Device Configuration, Source: Kernel-PnP, Event ID:410
Ausgeführt wird: eine Batch “Keyboardguard.bat”, die ich ebenso domänenweit nach c:\windows verteilt habe mit folgendem Inhalt:
Das war’s schon. Der Code sollte selbsterklärend sein, er folgt dem Ablaufplan. Man kann das noch ausweiten mit Logging, Adminalarm, Popups usw., aber ich stelle bewusst nur das Grundgerüst hin. Erfolgreich getestet habe ich es mit einem echten Ducky.
Edit: habe gerade gesehen, dass man mindestens Windows 8 dazu braucht und den Anleitungstitel deshalb angepasst.
PS: Der erste Link dieses Artikels stellt übrigens das Gerüst gegen USB-Datenträger und Telephone (WPD-Devices) zur Verfügung.
PSPS: Achtung: nicht vergessen, dass es fortan ein Problem darstellt, neue Tastaturen anzuschließen! Der Task muss zuvor deaktiviert oder die Whitelist angepasst werden. Edit: denkt auch an sogenannte "cordless presenter", auch die geben sich nämlich als Tastaturen aus und werden "abgewehrt".
--
Update 13.09.2016
Eine weitere mögliche Attacke wird hier beschrieben: http://www.heise.de/newsticker/meldung/Zugangsdaten-von-gesperrtem-PC-i ... ->eine USB-Netzwerkkarte wird hierbei benutzt. Als Abhilfe empfehle ich dieses Vorgehen: https://davidzou.com/articles/windows/defend-against-badusb
Netzwerkkarten Class GUID: {4d36e972-e325-11ce-bfc1-08002be10318}
Man sollte tunlichst vermeiden, in der GPO den Haken zu setzen, "also apply to matching devices that are already installed"! Sonst werden alle Netzwerkkarten deinstalliert und eine Neuinstallation geblockt!
Man könnte auch meinen bisherigen Ansatz auf USB-Netzwerkkarten ausweiten und auch hier mit Whitelisting arbeiten, aber ich denke, dass diese USB-Netzwerkkarten eher selten benutzt werden.
Vor einiger Zeit stieß mal ein Beitrag von mir USB-Laufwerke sperren auf reges Interesse, in dem ich skizziert hatte, wie ich unter Windows domänenweit verhindere, dass unerwünschte USB-Datenträger angeschlossen werden. Ich möchte das hier wieder aufgreifen und etwas ausführlicher erklären.
Viele kennen mittlerweile das USB-Rubberducky. http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe
Das ist ein präparierter USB-Stick, den man lieber nicht an seinen Rechner anstecken sollte, denn er emuliert eine Tastatur und tippt wie wild Schadcode ein. Weitaus besser als ein Skript – es ist eher wie ein Makrorekorder/-player, der genauso handelt, wie der Hacker selbst – nur viel, viel schneller. Probate Abwehrmaßnahme ist natürlich, die Installation von unbekannten Geräten zu verbieten – meist wird dies über eine Securitysoftware erreicht. Diese muss jedoch erst einmal wissen, was denn erlaubt ist und was nicht… gerade bei Tastaturen wäre es fatal, zu viel zu verbieten…
Ich werde zeigen, dass man es auch über eventgetriggerte Tasks und kleine Skripte mühelos lösen kann.
Speziell soll es in diesem Beispiel darum gehen, als Tastatur getarnte Geräte wie das Ducky abzuwehren.
Warum das Ganze? Man stelle sich vor, jemand hat seinen Bildschirm nicht gesperrt und das Büro verlassen. Der Angreifer hat darauf gewartet, weiß aber nicht, wieviel Zeit ihm bleibt und geht von weniger als einer Minute aus. Das ist für ein Gerät wie das Rubberducky jedoch mehr als genug, um kräftig Schaden anzurichten. Das Rubberducky installiert sich also und nach etwa drei Sekunden tippt es mit mehreren Tausend Anschlägen pro Minute munter Schadcode in die Powershell, und was an Daten im Homeverzeichnis aufgefunden wird, wird mal eben auf den Stick kopiert, fein.
Nach der Vorrede hier nun zum Plan.
Was die Schwäche des Duckies ist, ist die kleine Anlaufzeit, die Windows braucht, um ihn startklar zu machen. In diesen kurzen Sekunden kann man ihn einfach gleich wieder deinstallieren lassen.
Ablaufplan: Ein Bad-USB-Gerät wird angesteckt, Windows installiert es und trägt die Installation im Eventlog ein. Ein eventgetriggerter Task springt an und schaut nach, ob die derzeit installierten Geräte mit einer Whitelist übereinstimmen und deinstalliert alles Überzählige. Nach weniger als einer Sekunde ist die Ente meist bereits abgeschossen, noch bevor sie ihren ersten Tastendruck absenden konnte.
Als erstes besorgt man sich die devcon.exe (zum Skripten von Gerätedeinstallationen), wie hier beschrieben ist http://social.technet.microsoft.com/wiki/contents/articles/182.how-to-o ...
Wichtig: eine Version pro Architektur, die 32er-Version läuft zwar auf 64-Bit, aber fehlerhaft! Ich verwende Version 6.1.7600.16385 auf win8.1.
Die devcon verteilt man zunächst per GPO domänenweit nach c:\windows
Man erzeugt dann per Domänenstartskript eine Whitelist pro Rechner:
devcon findall =keyboard>%temp%\whitekey.txt
del %windir%\admin\whitekey.txt
for /f %%a in ('findstr /v "matching" %temp%\whitekey.txt') do echo %%a>>%windir%\admin\whitekey.txt
Dann kommen wir auch schon zum geplanten Task, den wir per GPO verteilen (siehe https://technet.microsoft.com/en-us/library/cc725745.aspx ):
Ausführendes Konto: System
Trigger: Tasktrigger bei Event und zwar Log: Microsoft-Windows-Kernel-PnP/Device Configuration, Source: Kernel-PnP, Event ID:410
Ausgeführt wird: eine Batch “Keyboardguard.bat”, die ich ebenso domänenweit nach c:\windows verteilt habe mit folgendem Inhalt:
if not exist %windir%\admin\whitekey.txt goto end
devcon findall =keyboard >%temp%\keyb.txt
del %temp%\keyb2.txt
for /f %%a in ('findstr /v "matching" %temp%\keyb.txt') do echo %%a>>%temp%\keyb2.txt
for /f "tokens=1,2,3 delims=\" %%a in (%temp%\keyb2.txt) do findstr "%%a\%%b" %windir%\admin\whitekey.txt || devcon.exe remove "@%%a\%%b\%%c"
:end
Das war’s schon. Der Code sollte selbsterklärend sein, er folgt dem Ablaufplan. Man kann das noch ausweiten mit Logging, Adminalarm, Popups usw., aber ich stelle bewusst nur das Grundgerüst hin. Erfolgreich getestet habe ich es mit einem echten Ducky.
Edit: habe gerade gesehen, dass man mindestens Windows 8 dazu braucht und den Anleitungstitel deshalb angepasst.
PS: Der erste Link dieses Artikels stellt übrigens das Gerüst gegen USB-Datenträger und Telephone (WPD-Devices) zur Verfügung.
PSPS: Achtung: nicht vergessen, dass es fortan ein Problem darstellt, neue Tastaturen anzuschließen! Der Task muss zuvor deaktiviert oder die Whitelist angepasst werden. Edit: denkt auch an sogenannte "cordless presenter", auch die geben sich nämlich als Tastaturen aus und werden "abgewehrt".
--
Update 13.09.2016
Eine weitere mögliche Attacke wird hier beschrieben: http://www.heise.de/newsticker/meldung/Zugangsdaten-von-gesperrtem-PC-i ... ->eine USB-Netzwerkkarte wird hierbei benutzt. Als Abhilfe empfehle ich dieses Vorgehen: https://davidzou.com/articles/windows/defend-against-badusb
Netzwerkkarten Class GUID: {4d36e972-e325-11ce-bfc1-08002be10318}
Man sollte tunlichst vermeiden, in der GPO den Haken zu setzen, "also apply to matching devices that are already installed"! Sonst werden alle Netzwerkkarten deinstalliert und eine Neuinstallation geblockt!
Man könnte auch meinen bisherigen Ansatz auf USB-Netzwerkkarten ausweiten und auch hier mit Whitelisting arbeiten, aber ich denke, dass diese USB-Netzwerkkarten eher selten benutzt werden.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 269737
Url: https://administrator.de/contentid/269737
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
18 Kommentare
Neuester Kommentar
Hallo "deus on machina" ,
nein, da kommt nichts, Dienst "Volumeschattenkopie" befindet sich jetzt im Status "Ausgeführt" wird von Service Control Manager zu exakt dem Zeitpunkt des connects geliefert, was ich nicht interpretieren kann, ob das jetzt der event ist. ID: 7036
Quelle Kernel Pnp Einträge sind nur spärlichst zu finden, an eine anderem Datum (Gestern, als ich herumprobiert habe) hab ich als Beispiel :
Fehler beim Laden des Treibers \Driver\WUDFRd für das Gerät WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_GENERIC&PROD_USB_CF_READER&REV_1.01#058F63626376&1#.
Ansonsten, wie gesagt, nichts. Komisch ist, dass ich aber die connect/disconnect sounds höre, also tun tut sich was, nur wo?
Scheint, dass sich von win 7 auf 8.1 einiges dahingehend getan hat.
nein, da kommt nichts, Dienst "Volumeschattenkopie" befindet sich jetzt im Status "Ausgeführt" wird von Service Control Manager zu exakt dem Zeitpunkt des connects geliefert, was ich nicht interpretieren kann, ob das jetzt der event ist. ID: 7036
Quelle Kernel Pnp Einträge sind nur spärlichst zu finden, an eine anderem Datum (Gestern, als ich herumprobiert habe) hab ich als Beispiel :
Fehler beim Laden des Treibers \Driver\WUDFRd für das Gerät WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_GENERIC&PROD_USB_CF_READER&REV_1.01#058F63626376&1#.
Ansonsten, wie gesagt, nichts. Komisch ist, dass ich aber die connect/disconnect sounds höre, also tun tut sich was, nur wo?
Scheint, dass sich von win 7 auf 8.1 einiges dahingehend getan hat.
Lesenswert dazu auch:
http://www.heise.de/ct/ausgabe/2015-5-Angriffe-mit-dem-USB-Rubber-Ducky ...
http://www.heise.de/ct/ausgabe/2015-5-Angriffe-mit-dem-USB-Rubber-Ducky ...
Das ist ein präparierter USB-Stick, den man lieber nicht an seinen Rechner anstecken sollte
OS-X warnt aber wenigstens vorher was Windows nicht macht... OS-X warnt aber wenigstens vorher was Windows nicht macht...
Warum sollte OSX vor einem Stick warnen, der sich als Tastatur ausgiebt? Sowas macht meines Wissens nach kein aktuelles BS weil eben weil sich das Gerät als Tastatur meldet.
Hallo,
wollte nur kurz fragen, ob Dein Beitrag immer noch Gültigkeit hat oder ob MS bei Windows 10 1909/2004 inzwischen per Boardmittel die Möglichkeit bietet, eine USB-Whitelist anzulegen.
Nutzen hier bei uns Barco Clickshare und das kollidiert mit der Wechselmedien GPO sodass ich eine Whitelist benötige.
Vielen Dank!
wollte nur kurz fragen, ob Dein Beitrag immer noch Gültigkeit hat oder ob MS bei Windows 10 1909/2004 inzwischen per Boardmittel die Möglichkeit bietet, eine USB-Whitelist anzulegen.
Nutzen hier bei uns Barco Clickshare und das kollidiert mit der Wechselmedien GPO sodass ich eine Whitelist benötige.
Vielen Dank!
devcon ist wie immer dein Freund:
https://www.wintotal.de/tipp/devcon-als-kommandozeilen-geraetemanager-un ...
Ist aber gegen den hier alles völlig nutzlos:
https://usbkill.com/products/usb-killer-v3
https://www.wintotal.de/tipp/devcon-als-kommandozeilen-geraetemanager-un ...
Ist aber gegen den hier alles völlig nutzlos:
https://usbkill.com/products/usb-killer-v3