Bypass Windows-Login, oder: Wie man es nicht macht
Ich liebe Herausforderungen. Zumindest die, von denen ich glaube, sie schaffen zu können. Vor allem diejenigen, bei denen nichts schiefgehen kann und ich mir bereits im vornherein zu hundert Prozent sicher bin, dass ich das auch tatsächlich hinbekomme. Herausforderungen im Stile von „Ich wette, du schaffst es nicht, meinen Windows-Account zu knacken“. Und mal ehrlich: Was könnte da schon schiefgehen?
Im Gegensatz zu meinem letzten Artikel geht es hierbei nicht darum Daten nur auszulesen sondern darum, tatsächlich den Windows-Login zu umgehen um auf besagtem Rechner die installierte Software nutzen zu können. Das genaue „Warum?“ will ich hier gar nicht beantworten, sagen wir einfach: Warum nicht?
Zur Verfügung stand mir also eine Standard Windows 7 Installation ohne Verschlüsselung oder sonstige Spielereien.
Vorbereitung
Ich bin wie gesagt ein Freund der Linux-Distribution Kali und hatte mir diesmal, wenn ich schon dabei war, auch vorgenommen gleich einen „Live Persistence USB-Stick“ anzufertigen. Das ist ein Live-USB-Stick welcher Kali Linux bootet, zusätzlich aber noch eine ~5GB große „persistence“-Partition mitbringt, auf welcher Änderungen oder auch beliebige Daten dauerhaft gespeichert werden können. Das bedeutet, dass ich damit all meine Änderungen, die ich bisher nach jedem Start von Kali Linux vorgenommen hatte nur noch ein einziges mal vornehmen muss.
Den USB-Stick anfertigen
Die Vorgehensweise ist dabei erstaunlich einfach. Zunächst kopiert man das Image der aktuellen Version mittels dd auf einen mindestens 8GB großen USB-Stick:
dd if=kali-linux-1.0.9-amd64.iso of=/dev/sdb bs=1M
Anschließend erzeugt man eine weitere, etwa 5GB große Partition. Ich habe dies mittels GParted vorgenommen, die Partition wird als /dev/sdb3 erkannt. Kali Linux identifziert die Partition übrigens anhand des Namens, weshalb man diesen noch ändern muss. Die Partition formatiert man nun noch im ext3-Format und speichert darauf eine Konfigurationsdatei welche Kali Linux später mitteilt, wie die Partition eingehangen werden muss.
# mkfs.ext3 -L persistence /dev/sdb3
# e2label /dev/sdb3 persistence
# mkdir -p /mnt
# mount /dev/sdb3 /mnt
# echo "/ union" > /mnt/persistence.conf
# umount /dev/sdb3
Von nun an kann der USB-Stick mit der Option persistence gebootet werden und verliert keine Daten mehr.
Tools ausfindig machen
Unter Linux werden sämtliche Passwörter in der Textdatei /etc/shadow gespeichert. Anders gesagt: Will ich ein Passwort ändern, dann ändere ich einfach den Hashwert in besagter Datei. Das ist nicht schwierig und auch ein Backup inklusive anschließendem Wiederherstellen der originalen Passwörter ist – ohne diese zu kennen – problemlos möglich. Dadurch kann man sehr einfach Zugriff erlangen und hinterlässt auch nur wenige Spuren, wenn man es richtig anstellt sogar gar keine.
Unter Windows hingegen sieht die Sache anders aus. Die relevanten Dateien liegen alle unter C:\Windows\System32\config. Die SAM-Datenbank (Secure Account Manager) ist keine einfache Textdatei sondern eine Binärdatei, was die Sache um ein vielfaches komplizierter machen kann. Und auch die Dateien SYSTEM und SECURITY, welche ebenfalls gebraucht werden, liegen nicht im Klartext vor. Glücklicherweise gibt es einige Tools, welche die SAM-Datenbank bearbeiten können oder auch einfach nur den Windows-Login umgehen.
Aus meiner Schulzeit ist mir hierbei noch Kon-Boot bekannt, welches den Windows-Login direkt umgeht (bypass). Allerdings ist die Software Closed Source und ich kann beziehungsweise will sie daher, aus ideologischen Gründen, nicht nutzen. Letztlich bleibt, neben einigen anderen Tools von zweifelhaftem Ruf, noch das kleine Programm chntpw übrig, welches in der Lage ist die Daten in der SAM-Datenbank darzustellen und entsprechend zu verändern (chntpw steht übrigens für „change NT password“).
Los geht's
Mit dem angeeignetem Wissen macht man sich also ans Werk und bootet Kali Linux auf dem Windows-Rechner. Anschließend findet man heraus, auf welcher Festplatte und Partition sich die Windows-Installation befindet:
# fdisk -l
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xde1d875c
Device Boot Start End Blocks Id System
/dev/sda1 206848 1953521663 976657408 7 HPFS/NTFS/exFAT
Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4024fb0a
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 206847 102400 7 HPFS/NTFS/exFAT
/dev/sdb2 206848 468858879 234326016 7 HPFS/NTFS/exFAT
Disk /dev/sdc: 8027 MB, 8027897856 bytes
177 heads, 32 sectors/track, 2768 cylinders, total 15679488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4d26df41
Device Boot Start End Blocks Id System
/dev/sdc1 * 64 5777279 2888608 17 Hidden HPFS/NTFS
/dev/sdc2 5777408 15679487 4951040 83 Linux
Das geschulte Auge sollte sehen, dass /dev/sdc der USB-Stick ist, von dem aus man gebootet hat. Auf /dev/sdb1 ist das Boot-Flag aktiv, auf /dev/sda1 hingegen nicht. Allerdings ist /dev/sdb1 für eine Windows-Partition etwas zu klein, das heißt Windows wird wohl auf /dev/sdb2 liegen.
Überprüfen kann man das, indem man die Parition einhängt und sich ansieht, welche Dateien vorhanden sind:
# mount /dev/sdb2 /mnt
# cd /mnt
# ls -l
total 9430401
lrwxrwxrwx 2 root root 60 Jul 14 2009 Documents and Settings -> /mnt/Users
drwxrwxrwx 1 root root 4096 Aug 19 20:25 ProgramData
drwxrwxrwx 1 root root 4096 Aug 20 19:14 Program Files
drwxrwxrwx 1 root root 8192 Aug 29 08:18 Program Files (x86)
drwxrwxrwx 1 root root 0 Jul 27 18:04 Recovery
drwxrwxrwx 1 root root 0 Sep 14 17:50 $Recycle.Bin
drwxrwxrwx 1 root root 8192 Sep 14 19:26 System Volume Information
drwxrwxrwx 1 root root 4096 Sep 14 17:50 Users
drwxrwxrwx 1 root root 16384 Sep 14 12:31 Windows
Das sieht doch gut aus, nicht?
Kennwort knacken
Das Kennwort zu knacken ist eine Möglichkeit um Zugriff auf das Konto zu erhalten, ohne dabei am Rechner selbst etwas ändern zu müssen. Das erscheint auf den ersten Blick wesentlich einfacher, allerdings braucht ein langes Passwort auch entsprechend lange, bis es geknackt wurde – vor allem, wenn man auf Brute-Force setzt.
Die SAM-Datenbank, in welcher die Hashwerte der Kennworte lagern, ist unter Windows 7 mittels eines Syskeys verschlüsselt. Dieser befindet sich zum Glück innerhalb des gleichen Verzeichnisses wie auch die SAM-Datenbank. Aus meiner Sicht für den normalen Nutzer also irrelevant und eher Security through obscurity, allerdings kann man den Syskey auch auslagern, etwa auf einen USB-Stick den man bei sich trägt. Bei nicht vorhandener Verschlüsselung nutzt einem das, wenn man lediglich an die Daten will, aber herzlich wenig.
1. Windows Syskey auslesen
Das Auslesen des Syskeys funktioniert mit dem Tool bkhive. Dazu wechselt man in das Verzeichnis /mnt/Windows/System32/config und nutzt bkhive um die Daten aus der Datei SYSTEM auszulesen. Die daraus entstehende Datei speichert man in einem beliebigen Verzeichnis:
# bkhive SYSTEM /tmp/bkhive.dat
bkhive 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
Root Key : CMI-CreateHive{E65EB4BF-2520-6CD0-F87F-7B457C32F5E6}
Default ControlSet: 001
Bootkey: 3afe09cd8769ea71ba7d86e599b5b905
2. SAM-Datenbank auslesen
Mit dem ermittelten Syskey und dem Tool samdump2, welches von den gleichen Entwicklern (oder dem gleichen Entwickler?) wie bkhive stammt, kann man nun die SAM-Datenbank entschlüsseln und auslesen:
# samdump2 SAM /tmp/bkhive.dat
samdump2 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
Root Key : CMI-CreateHive{E65EB4BF-2520-6CD0-F87F-7B457C32F5E6}
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Gast:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
username:1000:aad3b435b51404eeaad3b435b51404ee:0cb6948805f797bf2a82807973b89537:::
HomeGroupUser$:1002:aad3b435b51404eeaad3b435b51404ee:a9d38d05ef59f0bde0d98564ebe31424:::
Die letzten vier Zeilen sind dabei immer gleich aufgebaut und ähneln dem, was man auch von Unix/Linux her kennt. Durch Doppelpunkte getrennt stehen dabei zuerst der Benutzername, dann die Benutzer-ID, anschließend der LM-Hash sowie der NTLM-Hash. Da LM-Hashes nicht mehr verwendet werden, ist für alle 4 Konten der Wert aad3b435b51404eeaad3b435b51404ee eingetragen, welcher für ein leeres Passwort steht. Das NTLM-Pendant (eingetragen beim Administrator und Gast-Account) sieht so aus: 31d6cfe0d16ae931b73c59d7e0c089c0.
3. Hashes berechnen
Theoretisch kann man mittels hashcat oder auch oclhashcat, wobei letzeres auf der Grafikkarte läuft, das Passwort knacken. Allerdings haben sich bei mir beide Programme partout geweigert überhaupt irgendwas zu machen. Vor allem bei oclhashcat hätte mich interessiert, wie schnell ein ~8-stelliges Passwort auf einer aktuellen Grafikkarte geknackt werden kann. Leider musste ich auch genannten Gründen dann auf eine Alternative zurückgreifen, namentlich John the Ripper, oder kurz: john.
Damit john mit den Daten auch etwas anfangen kann muss man diese in ein bestimmtes Format bringen, das heißt man erstellt eine Datei mit dem Inhalt <username>:<hashwert>. Für meinen Test-Account mit dem Namen „username“ sieht das so aus:
username:0cb6948805f797bf2a82807973b89537
Nun kann man john mit entsprechenden Parametern aufrufen:
# john -format=nt2 /tmp/hashes.txt
Created directory: /root/.john
Loaded 1 password hash (NT MD4 [128/128 SSE2 intrinsics 12x])
test (username)
guesses: 1 time: 0:00:00:00 DONE (Sat Sep 27 18:04:51 2014) c/s: 1200 trying: TestuserTestuser - estuse
Use the "--show" option to display all of the cracked passwords reliably
Eine übersichtlichere Ausgabe erhält man allerdings mit dem Parameter --show:
# john -format=nt2 --show /tmp/hashes.txt
username:test
1 password hash cracked, 0 left
4. Testen
Natürlich musste ich mein Ergebnis ausprobieren und in der Tat, auf dem Test-Account konnte ich mich mit Hilfe des Passwortes test problemlos anmelden. Da dies der einzig aktive Account war, hatte ich zudem Administratorrechte.
Passwörter ändern bzw. löschen
Doch damit nicht genug: Was ist, wenn das Passwort länger ist, sagen wir 64 Zeichen, und man es nicht innerhalb von Stunden, Tagen oder Monaten via Brute-Force knacken kann? Was, wenn auch keine Rainbowtables und Wörterbuchattacken mehr helfen? Dann ist es an der Zeit, ein anderes Programm zu verwenden: chntpw.
Passwort ändern
Mittels chntpw kann man, wie bereits geschrieben, Passwörter ändern. Allerdings findet man in diversen Foren immer wieder verzweifelte Nutzer bei denen anschließend weder das alte noch das neue Passwort funktionierten. Bei mir hing Windows sogar in einer Boot-Schleife fest und auch der „Abgesicherte Modus“ konnte nicht mehr erreicht werden. Daher eine Warnung: Wer mit chntpw ein Passwort ändert muss sich darauf gefasst machen, dass anschließend auch eine Neuinstallation anstehen könnte. Trotzdem hier der Befehl, welcher wiederum im Verzeichnis /mnt/Windows/System32/config ausgeführt werden muss:
# chntpw -u "username" SAM
Aus der Sache mit der Boot-Schleife bin ich übrigens herausgekommen, indem ich in die Recovery des PCs gelangt bin und dem Tool das machen habe lassen, wofür es gedacht ist: Beschädigte Dateien wiederherstellen. Dass das funktioniert hat grenzt schon an ein Wunder, ist Windows doch nicht unbedingt dafür bekannt Probleme zu lösen.
Passwort löschen
Wesentlich sicherer ist es, das Passwort komplett zu löschen. Doch auch hier besteht noch die Gefahr, dass man sein Windows gleich neu installieren darf. Um das Passwort zu löschen startet man chntpw im interaktiven Modus:
# chntpw -i SAM
Anschließend wählt man den Nutzeraccount aus, den man löschen möchte und wählt „1 - Clear (blank) user password“ aus. Danach muss man die Änderungen noch auf die Festplatte schreiben, dies muss mit „y“ bestätigt werden.
Doch auch bei dieser Methode hatte ich Unglück und konnte mich immer noch nicht an meinem Test-Account anmelden. Anders gesagt: Ich konnte mich weder mit dem alten Passwort, dem neuen Passwort noch ohne Passwort anmelden. Doch auch dieses Problem lässt sich lösen, wie der nächste Punkt zeigen wird.
Account freischalten
Was mit hoher Wahrscheinlichkeit funktioniert (nach dem, was ich jetzt schon alles mit chntpw durchgemacht habe will ich von „garantiert funktioniert“ lieber Abstand nehmen), ist den Administrator-Account zu entsperren. Wenn man sich nämlich die vorhandenen Benutzerkonten ansieht, fällt auf, dass ein Administratoraccount zwar vorhanden, dieser aber deaktiviert ist:
# chntpw -l SAM
chntpw version 0.99.6 080526 (sixtyfour), (c) Petter N Hagen
Hive <SAM> name (from header): <\SystemRoot\System32\Config\SAM>
ROOT KEY at offset: 0x001020 * Subkey indexing type is: 666c <lf>
Page at 0x10000 is not 'hbin', assuming file contains garbage at end
File size 262144 [40000] bytes, containing 7 pages (+ 1 headerpage)
Used for data: 280/55296 blocks/bytes, unused: 13/5920 blocks/bytes.
* SAM policy limits:
Failed logins before lockout is: 0
Minimum password length : 0
Password history count : 0
| RID -|---------- Username ------------| Admin? |- Lock? --|
| 01f4 | Administrator | ADMIN | dis/lock |
| 01f5 | Gast | | dis/lock |
| 03ea | HomeGroupUser$ | | |
| 03e8 | username | ADMIN | |
Dafür geht man wiederum in den interaktiven Modus von chntpw, nimmt den Administrator-Account und wählt die vierte Option „Unlock and enable user account“ aus. Die Änderungen bestätigt man wiederum und schreibt diese auf die Festplatte.
Das System letztlich geradebiegen
Ich fasse nochmal zusammen: Bei der Änderung des Passwortes habe ich versehentlich eine Boot-Schleife erzeugt, mittels der Recovery bin ich da (zum Glück) wieder herausgekommen. Auch das Passwort zu löschen hat mir nicht viel geholfen, denn von da an war es mir überhaupt nicht mehr möglich, mich überhaupt am System anzumelden. Mittels des nun aktivierten Administrator-Accounts konnte ich mich aber am System anmelden, ein Passwort ist nicht erforderlich. Über die Systemeinstellungen von Windows konnte ich so das Passwort des Test-Accounts ändern oder auch löschen, wobei ich mich für letzters entschieden habe. Anschließend habe ich mich ausgeloggt und ohne Passwort am Test-Account eingeloggt. Da dies funktioniert hatte, habe ich das Administrator-Konto wiederum über die Eingabeaufforderung deaktiviert:
net user Administrator /active:no
Der Befehl ist nicht unbedingt intuitiv aber funktioniert. Damit wäre das System wieder am Anfangszustand. Zumindest mehr oder weniger, wer weiß was chntpw und die Windows-Recovery noch alles verändert haben.
Fazit
Die ganze Aktion hatte mich knappe 2 Tage gekostet. Theoretisch ist es einfach: Kali Linux booten, Passwort knacken oder löschen, fertig. Praktisch hatte sich das ganze, vor allem wegen chntpw, um einige Stunden verlängert. Zwar hatte das eigentliche knacken des Passwortes, was eigentlich schon ausgereicht hätte, zwar tatsächlich nur wenige Minuten gedauert, allerdings muss man auch die Zeit mitrechnen, die man braucht, bis man alle Informationen gesammelt hat um überhaupt so weit zu kommen.
Nachtrag
Ich wurde via E-Mail (Danke, Ralph) darauf hingewiesen, dass das Programm chntpw in den Versionen vor 0.99.5 noch ordnungsgemäß funktioniert hat. Der Bugreport dazu findet sich hier. In Kali Linux kommt nach aktuellem Stand Version 0.99.6-2 zum Einsatz, welches ebenfalls noch von dem Bug betroffen ist. Übergangsweise kann man sich aus einem älteren Repository eine ältere Version installieren. Damit sollte es dann gehen, ohne dass man sich sein Windows gleich zerschießt. Es ist wirklich schade, dass überhaupt solch fehlerhafte Versionen zum Release freigegeben werden.