Archive for the ‘Sysinternals’ Category

Systemrechte unter Windows erlangen

17 August 2017

Schon seit Ewigkeiten ist bekannt wie man Systemrechte unter Windows erlangen kann. Aber das Ziel ist es – wie immer – es mit möglichst wenig Aufwand und am besten mit Bordmitteln zu erlangen. Zwar bringt jedes aktuelle Windows mittlerweile ein Recoverypartition mit aber man hat nicht immer unbedingt Zugriff im Bootvorgang darauf (z. B. bei gehosteten Webservern).

Der übliche Vorgang ist das Kopieren von CMD.EXE auf UTILMAN.EXE, OSK.EXE oder SETHC.EXE. Dies gelingt normalerweise nur, wenn man von einer Recoverypartition oder von WinPE bzw. eben WinRE-CD gebootet hat. Aus diesem Grund verwenden viele Sysinternals PSExec: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec.

Mit Adminrechten und etwas Gefummel in der Registry, bekommt man es auch mit Bordmitteln hin. Da es komfortabler ist dies per Script zu erledigen hier die nötigen Powershell-Anweisungen. Zuerst kopieren wir Utilman.exe und cmd.exe:

copy "C:\Windows\System32\utilman.exe" "C:\Windows\System32\utilman.exe.bak"
copy "C:\Windows\System32\cmd.exe" "C:\Windows\System32\cmd.exe.bak"

Nun benötigen wir den Zugriff auf den Registryschlüssel HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ um dort die Werte PeningFileRenameOperations und AllowProtectedRenames zu setzen.

$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"

AllowProtectedRenames ist wichtig, sonst klappt der Vorgang nicht. Dies ist mal wieder einer von so vielen Registrywerten die nicht klar dokumentiert sind. Er wird im MSDN nur einmal im Zusammenhang mit VSS und der Wiederherstellung von Dateien der Windows File Protection genannt: https://msdn.microsoft.com/en-us/library/windows/desktop/aa381498(v=vs.85).aspx.

set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1

Jetzt muss man die zu kopierenden Dateien angeben. Da es aber kein klassischer Copy-Befehl sondern ein Move-Befehl ist, wo die Quelldatei nach dem Vorgang weg ist, verwenden wir die vorher erstellte Kopie von CMD.EXE. Dabei ist darauf zu achten, dass vor den Dateinamen noch eine spezielle Notation \??\ nötig ist. Leider gibt es keine Informationen darüber wann !\??! verwendet wird. Aber damit hat es immer funktioniert. Wichtig ist noch, dass es ein String-Array sein muss, damit die Werte in der Registry korrekt als REG_Multi_Sz gespeichert wird.

[string[]]$moveFiles= @("\??\C:\Windows\System32\cmd.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Nun muss nur noch der Rechner neu gestartet werden und schon steht einem eine Eingabeaufforderung mit Systemrechten zur Verfügung. Bei Verwendung von UTILMAN.EXE klickt man am Anmeldebildschirm einfach auf den Kreis mit den zwei Pfeilen und der Einblendung “Erleichterte Bedienung”.

Um die Änderung rückgängig zu machen, könnte man nun dieses Script verwenden, welche einfach die Kopie von Utilman.exe zurückkopiert:

$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"
set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1
[string[]]$moveFiles= @("\??\C:\Windows\System32\Utilman.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Es geht aber noch einfacher, auch im Falle eines Fehlers zwischendrin, bemüht man einfach die Windows File Protection und beauftragt diese mit der Wiederherstellung der betreffenden Dateien:

# Falls was schiefgeht:
SFC /SCANFILE=C:\Windows\System32\cmd.exe
SFC /SCANFILE=C:\Windows\System32\utilman.exe

Jetzt nochmal das ganze Script um oben beschriebene Funktionalität zu erreichen:

copy "C:\Windows\System32\utilman.exe" "C:\Windows\System32\utilman.exe.bak"
copy "C:\Windows\System32\cmd.exe" "C:\Windows\System32\cmd.exe.bak"
$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"
set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1
[string[]]$moveFiles= @("\??\C:\Windows\System32\cmd.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Hier noch ein guter Blogartikel mit Registrybildern, wer es von Hand machen möchte: https://blog.cscholz.io/windows-72008-movefileex/. Eine weitere Methode anstatt PendingFileRenameOperations:
https://guyrleech.wordpress.com/2014/07/16/reasons-for-reboots-part-2-2/, einfachere Beschreibung: https://superuser.com/questions/1204878/how-can-i-tell-windows-to-overwrite-a-system-file-on-the-next-reboot.

Eine weitere Variante an Systemrechte zu gelangen ist hier beschrieben: https://newyear2006.wordpress.com/2013/01/01/eingabeaufforderung-mit-lokalen-systemdienst-rechten-unter-windows-8-und-windows-server-2012/.

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…