Archive for Februar 2015

Wertvolle Infos zu Innereien von wichtigen Dateiformaten

28 Februar 2015

Viele relevante Infos zu den Innereien und unterschiedlichen Versionen von Dateiformaten findet man hier: http://www.digitalpreservation.gov/formats/fdd/browse_list.shtml. Dabei werden auch die IANA-Mediatypes, MagicNumbers sowie Informationen über die Entwicklung angegeben. Es finden sich auch jede Menge Links zu weiteren Seiten mit tiefergehenden Details oder Standards.

Batchdatei als Administrator ausführen funktioniert nicht und was dies mit dem &-Zeichen im Benutzernamen zu tun hat

27 Februar 2015

Windows hat so seine Eigenheiten. Aktuell bin ich mal wieder über eine solche gestolpert, wo man sich fragt: Was geht da ab? Kurz zur Geschichte, ein Kunde hatte Probleme mit dem Adobe Reader Update: https://newyear2006.wordpress.com/2014/07/03/adobe-reader-installation-meldet-umgltiges-laufwerk-und-bricht-die-installation-ab/. Meine Antwort darauf war, eine Batchdatei anzulegen und diese mit Adminrechten auszuführen. Nur funktionierte die Variante nicht. Nach einigem hin und her wurde es dann klar, dass keinerlei Batchdatei des Kunden, welche über den Windows Explorer mit rechter Maustaste und “Als Administrator ausführen” angefordert wurde, klappte.

Dazu wurde eine einfach Test.BAT-Batchdatei im Benutzer-Verzeichnis C:\USERS\M&M geschrieben:

@ECHO Hallo
PAUSE

Also nichts weltbewegendes. Führt man diese Batchdatei in der Commandline aus, funktioniert alles wie gewünscht, ob mit oder ohne Adminrechte. Führt man die Batchdatei jedoch im Windows Explorer aus, funktioniert nur die Variante ohne Adminrechte. Bei der Variante mit den Adminrechten wird zwar nach dem Zulassen von CONSENT.EXE mit dem bekannten UAC-Dialog gefragt aber es wird effektiv nichts ausgeführt.

Bei der näheren Analyse mittels Procmon.EXE fiel dann folgendes auf, der Punkt  wo der CMD.EXE-Prozess erzeugt wird, wird die richtige Commandline übergeben:

Parent PID: 1996, Command line: "C:\Windows\System32\cmd.exe" /C "C:\Users\M&M\Test.bat" , …

Einige Zeilen später, wo die .BAT-Datei auf Vorhandensein geprüft wird, findet sich auf einmal diese Zeile:

QueryDirectory  C:\Users\M.*

Wo doch der Benutzer M&M heißt und nicht M.*!!

Und genau da entsteht nun das Problem, so dass wieder einige Zeilen später, der Versuch die Batchdatei zu lesen ins Leere läuft:

CreateFile C:\Windows\system32\M\Test.bat PATH NOT FOUND

Echt interessant! D. h. hier wird der Pfadname quasi in zwei Teile aufgelöst, einmal in C:\Users\M und einmal in M\Test.Bat, was eigentlich C:\Users\M&M\Test.Bat lauten sollte.

Dies bedeutet, dass keine Batchdatei des Benutzers M&M als Administrator ausgeführt werden kann! Sobald man aber hergeht und z. B. ein Verzeichnis C:\TestDir anlegt, dort die Test.BAT-Datei ablegt und diese als Administrator ausführt klappt wieder alles.

Was lernen wir daraus: Verwende unter Windows niemals einen Benutzernamen mit einem &-Zeichen!

Dieses Phänomen tritt von Windows 7 bis Windows 10 auf, wahrscheinlich sind aber generell auch ältere Versionen davon betroffen. Man könnte es zwar durch Escapen des &-Zeichen lösen aber im Punkt bei “Ausführen als Administrator” sind einem die Hände gebunden. Hier wird das Escapen beschrieben: http://www.robvanderwoude.com/escapechars.php.

Wireshark bleibt bei 100% beim Laden der Konfigurationsdateien hängen

23 Februar 2015

Scheinbar ein bekanntes Phänomen mit Windows 8.1 und dem Starten von Wireshark, dass Wireshark bei der Anzeige mit dem Laden der Konfigurationsdateien bei 100% hängen bleibt. Das Problem dabei ist nicht Wireshark selber sondern DUMPCAP.EXE welches direkt von Wireshark aus gestartet wird. Dies scheint irgendeine Info nicht zu bekommen und lässt dann alles hängen.

Im aktuellen Fall half der Artikel https://ask.wireshark.org/questions/26361/loading-configuration-files mit dem Hinweis

sc config npf start= delayed-auto

und Neustart des Rechners.

NPF steht für “NetGroup Packet Filter Driver” und ist ein Kerneltreiber.

C:\WINDOWS\system32>sc qc npf
[SC] QueryServiceConfig ERFOLG

SERVICE_NAME: npf
        TYPE               : 1  KERNEL_DRIVER
        START_TYPE         : 2   AUTO_START  (DELAYED)
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : system32\drivers\npf.sys
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : NetGroup Packet Filter Driver
        DEPENDENCIES       :
        SERVICE_START_NAME :

Offenbar gab es damit auch schon früher Probleme mit Windows 7 und Wireshark: https://ask.wireshark.org/questions/1281/npf-driver-problem-in-windows-7.

Das eigentliche Problem scheint aber WinPCap zu sein, denn NPF.SYS ist der Kerneltreiber von WinPCap:

C:\> powershell -command "& {(get-item C:\windows\system32\drivers\npf.sys).VersionInfo.ProductName}"
WinPcap

Ganz einfach WLAN-Sicherheitsschlüssel unter Windows auslesen

23 Februar 2015

Ich hab hier früher schon einmal eine Methode beschrieben, wie man WLAN-Netzwerkkennwörter per Commandline auslesen kann: https://newyear2006.wordpress.com/2013/01/02/wifi-netzwerksicherheitsschlssel-unter-windows-per-powershell-auslesen/. Die Variante funktioniert, ist aber entsprechend aufwändig. Was wenn nun von Haus aus eine viel einfachere Methode existiert?

Na dann nutzen wir diese halt:

netsh wlan show profiles

listet zunächst die verfügbaren WLAN-Profile auf. Den Schlüssel dafür bekommt man mittels:

netsh wlan show profiles "Mein WLAN-Netzwerkname" key=clear

Dabei löscht clear nichts, sondern sagt lediglich, dass der Netzwerkschlüssel im Klarnamen angezeigt werden soll.

So sieht der Aufruf konkret z. B. bei einer Fritzbox aus:

netsh wlan show profiles "Fritz!Box 7490" key=clear

Die Sache funktioniert bereits bei Windows 7! Für Windows 8 gibt es sogar eine offizielle Doku: http://windows.microsoft.com/de-at/windows-8/manage-wireless-network-profiles.

Viel Spaß beim Stöbern…

Malware-Plage und jetzt auch noch Superfish

22 Februar 2015

Es wird immer schlimmer und keiner blickt mehr richtig durch. Das ganze TLS und Zertifikatsgedöns ist nicht nur kompliziert, sondern kann auch schön ausgehebelt werden. Aktuelles Beispiel Visual Search bzw. Visual Discovery von Superfish.

Nicht nur, dass es Leute gibt, die sich bewusst oder unbewusst irgendwelche schrottigen Onlinevergleichstools auf den Rechner laden und dadurch massiv ausspioniert werden bzw. tolle Werbeeinblendungen bekommen, nein jetzt werden auch noch Rechner ab Werk mit solchen Programmen ausgeliefert.

Heise Online meldet:

Ab sofort können sich Cyber-Gangs online gegenüber Besitzern von vielen Lenovo-Laptos mit einer beliebigen Identität ausweisen und gefährliche Man-in-the-Middle-Angriffe tätigen.
http://www.heise.de/newsticker/meldung/Lenovo-Laptops-Sicherheitsluecke-erreicht-kritisches-Stadium-2555934.html

Die Vorgehensweise, die Sache ausnutzen zu können ist dabei recht einfach. Robert Graham zeigt mit einfachsten Mitteln, wie es geht. http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html. Er startet einfach die Malware und erzeugt mittels Procdump von Sysinternals einen Speicherdump des Prozesses. Danach holt er sich wiederum mittels Sysinternals-Tool Strings alle Strings aus dem Dump. Schwupps hat er den privaten Schlüssel des Zertifikats. Normalerweise müsste man nun das Passwort für den privaten Schlüssel brutforcen. Aber das kann dauern. Also geht er einfach her und verwendet eine Dictionary-Attacke. Doch zunächst ohne Erfolg. Dann denkt er sich, vielleicht ist das Passwort ja im Stringdump enthalten und schwupps hat er es: “komodia”.

Warum ist dies nun alles so gefährlich? Ein schöner einleitenden Artikel bringt wiederum Robert Graham: http://blog.erratasec.com/2015/02/some-notes-on-superfish.html. Die Quintessenz daraus ist, auch wenn man die Malware deinstalliert, dass Stammzertifikat bleibt immer noch auf dem Rechner und erlaubt später problemlos “Man in the middle”-Attacken.

Damit nicht alles graue Theorie bleibt, geht wiederum Robert Graham zum Beweis über und bastelt mittels Raspberry Pi ein plastisches Beispiel. Mittels eines Pi für 40€, einem WLAN-Modul für 15€, einer Speicherkarte für 5€ bastelt er einen Man in the Middle Proxy. dazu verwendet er SSLSplit und die Zertifikate und Passwörter von Superfish und kann nun problemlos seine verschlüsselte TLS-Kommunikation mitlesen. http://blog.erratasec.com/2015/02/exploiting-superfish-certificate.html. Natürlich muss es nicht ein Pi sein, sondern kann jede x-beliebige Maschine sein, es geht nur darum deutlich zu machen, dass so ein kleines Stück Hardware für solche Attacken nicht teuer sein muss.

Ach und aus Erfahrung kann ich sagen, dass Rechner, bei denen so eine Spionagesoftware mal nicht richtig funktioniert, massiv Probleme mit ihrer Internetverbindung haben und der unbedarfte Benutzer ständig komische Fehlermeldungen zwecks Proxy und so Gedöns an den Latz geknallt bekommt.

Hier noch ein paar Powershell-Befehle mittels derer man das Superfish-Zertifikat ermitteln kann:

dir cert:\ -Recurse| where {$_.Subject -match "Superfish"}

oder direkt per Fingerprint:

dir cert:\ -Recurse| where {$_.Thumbprint -eq "C864484869D41D2B0D32319C5A62F9315AAF2CBD"}

Wer braucht da noch nen Staatstrojaner, wenn die Computerhersteller bereits alles dafür tun, die Geräte mit Malware auszustatten. Interessant in diesem Zusammenhang ist noch dieses: http://blog.fefe.de/?ts=aa16d2ff. Der große Bruder lässt grüßen…