Im Bereich eingebetteter Systeme ticken die Uhren langsamer, als im Desktop- und Server-Bereich. Hier lassen sich noch leicht klassische Schwachstellen wie Directory Traversal oder OS Command Injection finden. Letztere Variante findet sich auch im WLAN-Router RPD-150 der Firma PC-Professional, der durch Inter-Tech vertrieben wird. Das Gerät wird für circa 11 Euro angeboten und wird mit überragender Sicherheit beworben.
RPD-150: Mit überragender Sicherheit.
OS Command Injection Angriffe (nach OWASP) bezwecken es, Befehle die durch den Angreifer festgelegt werden, in eine anfällige Anwendung einzuschleusen. Dabei verhält sich die verwundbare Anwendung wie eine Pseudo-Shell, die es erlaubt, mit den Rechten und in der Umgebung in der sie ausgeführt wird, Befehle auf dem System auszuführen.
Erste Stelle, die oft für Command Injection Angriffe besonders interessant ist, ist die Ausführung von Diagnosebefehlen in der administrativen Oberfläche eines Routers. Hier werden teilweise Eingaben ungefiltert an die entsprechenden Systembefehle wie ping oder traceroute weitergegeben. So auch beim RPD-150. Das folgende Bildschirmfoto zeigt, wie mit Hilfe der PING Funktion und Einbettung von Shellbefehlen ein Telnet-Server gestartet werden kann.
Ein kurzer Test bestätigt den Start des Telnet-Servers, wie auf folgendem Bildschirmfoto zu sehen.
Ein laufender Telnet-Server ist aber nicht gleichbedeutung mit vollem Superuser-Zugriff auf den Router. Dafür muss ein Kennwort gebrochen werden. Da das Webinterface mit Root-Rechten ausgeführt wird (eine Eingabe von 127.0.0.1; echo $USER bestätigt das), ist die Gewinnung der Datei /etc/passwd kein Problem.
Sie enthält bei eingebetteten Systemen nicht nur die bekannten Informationen zu Benutzernamen und User-IDs, sondern darüber hinaus auch das gehashte Kennwort. Auf Desktop-Systemen wird es sonst in der Datei /etc/shadow/ gespeichert. Durch Ausnutzung der Schwachstelle mit dem Befehl 127.0.0.1; cat /etc/passwd kann der Inhalt der Datei gewonnen werden: root:C75rzlQ3E2Dkc:0:0:root:/:/bin/sh.
Das Kennwort des Superusers kann darauf folgend mit John the Ripper in kurzer Zeit gebrochen werden. Es lautet admin.
Mit dem Kennwort kann jetzt eine Verbindung als Superuser zum vorher gestarteten Telnet-Server hergestellt werden, wie das folgende Bildschirmfoto zeigt.
Die Schwachstelle ist natürlich nur geringfügig, da eine Anmeldung im Webinterface erforderlich ist.
Besonderer Dank an Inter-Tech, die sehr schnell reagierten und der Veröffentlichung des Artikels zugestimmt haben. Quelle des Produktfotos: Inter-Tech RPD-150 Bilderpaket.
Im gestrigen Artikel wurde beschrieben, wie durch eine Hintertür in vsftpd 2.3.4, Rootrechte auf der virtuellen Maschine Metasploitable 2 erlangt werden können. Diese Rootrechte sollen verwendet werden, um die Kennwörter der virtuellen Maschine zu entnehmen und folgend zu brechen.
Mit den Befehlen cat /etc/passwd und cat /etc/shadow werden die Inhalte der entsprechenden Dateien ausgegeben. Warum gerade diese? Sie enthalten die Benutzerdaten der lokalen Systembenutzer; zumindest solange keine esoterischen Verfahren wie OpenLDAP zur Authentifikation eingesetzt werden. Der Hash des Kennworts und die Benutzerdaten werden seit Ende der 1980er Jahre in getrennten Dateien gesichert, damit normale Benutzer die Benutzerdaten lesen dürfen, nicht aber damit auch die Hashes der Kennwörter zu Gesicht bekommen.
Die aus der virtuellen Maschine entnommenen Dateien als passwd und shadow speichern. Dann werden sie mittels unshadow wie folgt zusammenfügen.
Das Ergebnis des Programms unshadow kann mit John the Ripper bearbeitet werden. Für Metasploitable sind weder Wörterbücher noch Parallelisierung notwendig, darum kann die von Kali Linux mitgelieferte Version verwendet werden. Die ersten sieben von acht Kennwörtern werden innerhalb von Sekunden gebrochen.
john metasploitable2_credentials.txt
Loaded 7 password hashes with 7 different salts (FreeBSD MD5 [128/128 SSE2 intrinsics 12x])
user (user)
postgres (postgres)
msfadmin (msfadmin)
service (service)
batman (sys)
123456789 (klog)
Der Wert in Klammern entspricht dem Benutzernamen, der vorgestellte Wert dem Kennwort.
Benutzername
Kennwort
user
user
postgres
postgres
msfadmin
msfadmin
service
service
sys
batman
klog
123456789
Da john ohne Wörterbuch einen Bruteforce-Angriff gegen die Hashes durchführt (sogenannter Incremental Mode), kann es überraschen, dass bereits ein neunstelliges Kennwort gebrochen wurde.
Aufgrund der Reife der Software, arbeitet john die möglichen Kennwörter in sinnvollen Phasen ab. Begonnen wird mit dem Single Mode, dem der Benutzername und Informationen aus den weiteren Feldern der passwd zugrunde liegt. Dadurch werden bereits vier der Kennwörter gebrochen. Die weiteren beiden Kennwörter der Benutzer sys und klog werden mit Hilfe des mitgelieferten Wörterbuchs password.lst gefunden. Erst nach diesen beiden Phasen wird zu einem Bruteforce-Angriff übergegangen.
Wie in einigen vorherigen Artikeln beschrieben, ist mein Heimlabor für Penetrationstests in Form eines Virtualisierungsservers endlich fertig. Trotz Klausurstress lasse ich es mir nicht nehmen, abends zur Entspannung virtuelle Maschinen anzugreifen. Den Anfang macht Metasploitable 2, von dem ich bereits viel gelesen habe, es aber noch nie selbst angefasst habe.
Wie der Name bereits andeutet, soll zum Testen Metasploit zum Einsatz kommen. Nach Installation und Einrichtung (unter Kali Linux nicht notwendig), wird Metasploit durch Eingabe des Befehls msfconsole gestartet. Metasploit erlaubt das Verwalten verschiedener Ziele in sogenannten Workspaces. Workspaces erleichtern es, den Überblick zu behalten. Darum wird einer verwendet.
Um einen ersten Überblick über die von Metasploitable angebotenen Dienste zu bekommen, wird der Portscanner nmap eingesetzt. Da nur ein einzelner Host zu prüfen ist und die Erkennung des Scans keine Rolle spielt, kann ein kompletter Portscan mit Test aller 65.535 Ports und Versionserkennung gestartet werden. Der Scan wird mit dem Befehl db_nmap -A -p1-65535 metasploitable-ip-adresse gestartet und dauert circa 5 Minuten. Das Ergebnis sieht wie folgt aus und wird automatisch in der an Metasploit angeschlossenen Datenbank gespeichert.
Eine kurzeRecherche ergibt, dass auf dem Server Ubuntu 8.04 LTS läuft. Da auf vielen Servern der SSH-Port offen ist, lässt sich aus der meist angepassten SSH-Version (hier OpenSSH 4.7p1 Debian 8ubuntu1) schnell ein Ausgangspunkt für die Schwachstellen-Recherche finden.
Die Version 2.3.4 des FTP-Servers vsftpd sticht sofort ins Auge. In 2011 wurden die Projektserver des vsftpd Projekts kompromittiert und eine angepasste Version dort bereitgestellt. Bei Anhängen eines einfachen Smilies wie 🙂 an den Benutzernamen öffnet die kompromittierte vsftpd Version eine Bind-Shell auf Port 6200 mit Rootrechten. Eine angemessene:) Schwachstelle:) um:) das:) Heimlabor:) einzuweihen.
Praktischerweise liefert Metasploit ein Modul für genau diese Schwachstelle mit. Durch Eingabe des Befehls search vsftpd wird Metasploit angewiesen, nach Modulen zu suchen, deren Beschreibung vsftpd enthält.
Das Modul wird mit dem Befehl use exploit/unix/ftp/vsftpd_234_backdoor aktiviert. Mit dem Befehl set ohne Argumente werden die möglichen Parameter des Moduls angezeigt. Um das Exploit auszuführen genügt es, die Zieladresse durch Eingabe des Befehls set RHOST ip.des.ziel.hosts zu setzen.
Folgend kann das Exploit mit dem Befehl run ausgeführt werden und liefert eine einfache nicht-interaktive Shell auf dem Zielsystem, die wie folgt aussieht.
Im folgenden Artikel wird beschrieben, wie durch den temporären Zugang eine permanente Hintertür installiert oder die Kennwörter gebrochen werden können.
Und um der Gemeinschaft rund um Penetrationstests etwas zurück zu geben, betreibe ich (scheinbar als erste Privatperson) einen Kali Linux Mirror.
Privater Kali Linux Mirror – Danke Offensive Security!
Bei einem Server von OVH zum Spottpreis von 3,99 Euro (echt wahr) kann niemand wiederstehen. Jetzt bekommt der Server endlich etwas zutun. Der dauerhafte Link befindet sich in der Top-Navigation.
Wie bereits aus dem letzten Beitrag zu Proxmox VE zu erahnen, entsteht hier gerade ein einfaches Penetrationstest Labor mit Proxmox. Dafür wird eine virtuelle Maschine mit Kali Linux benötigt. Zusätzlich muss ein einfacher grafischer Zugang mittels Linux Werkzeugen (vergleichbar zu Windows Remote Desktop) zur Verfügung stehen. Eine solche virtuelle Maschine gibt es bislang noch nicht für Proxmox und die Herstellung erfordert einige Tricks. Das Ergebnis präsentiert sich wie folgt.
Proxmox bietet sowohl Vollvirtualisierung mittels KVM, wie auch Paravirtualisierung mittels OpenVZ. Das Template wird für OpenVZ erstellt, um ohne große Verluste mehrere Instanzen gleichzeitig ausführen zu können. Der entfernte grafische Zugang wird über X2go eingerichtet. Es stehen bereits Paketquellen für Debian „wheezy“ zur Verfügung, auf dem Kali Linux 1.0 aufbaut. X2go wird dafür sorgen, dass grafische Sitzungen im Hintergrund weiterlaufen, wenn der entfernte Zugang beendet wird (ähnlich zu screen).
Für Die Herstellung des Templates werden Superuser-Rechte benötigt, die zum Beispiel mittels sudo -s erlangt werden können.
1.1 Debootstrap herunterladen und anpassen
mkdir -p ~/Development/proxmox/kali-linux
cd ~/Development/proxmox/
wget http://archive.kali.org/kali/pool/main/d/debootstrap/debootstrap_1.0.48+kali1_all.deb
ar -xf debootstrap_1.0.48+kali1_all.deb
tar xzf data.tar.gz
tar xzf control.tar.gz
Jetzt muss geprüft werden, ob der Inhalt des Pakets unverändert auf dem lokalen System angekommen ist. Jedes Debian Paket liefert eine Datei md5sums mit, die Prüfsummen über die enthaltenen Dateien enthält. Mit dem folgenden Einzeiler lässt sich die Integrität des debootstrap Pakets prüfen.
Der Befehl darf keine Ausgabe erzeugen, sonst sind Daten verändert worden. Um jetzt per debootstrap installieren zu können, muss der Quelltext von debootstrap leicht angepasst werden.
nano usr/sbin/debootstrap
Die folgenden Zeilen entsprechend editieren
Suchen:
DEBOOTSTRAP_DIR=/usr/share/debootstrap
und ersetzen mit:
DEBOOTSTRAP_DIR=/tmp/usr/share/debootstrap
1.2 Installation durchführen
Um sicherzugehen, dass nur offizielle Pakete ohne Hintertüren auf dem neuen System installiert werden, müssen die Signaturen aller Pakete geprüft werden. Alle Debian Pakete sind durch öffentliche Schlüssel in einer Public-Key-Infrastruktur gesichert. Damit diese Signaturen geprüft werden können, muss der Hauptschlüssel des Kali Linux Archivs wie folgt importiert werden.
Mit dem Befehl gpg --list-keys wird geprüft, ob der Schlüssel erfolgreich importiert wurde. Ist das der Fall, kann das Grundsystem wie folgt installiert werden.
usr/sbin/debootstrap --keyring=~/.gnupg/pubring.gpg --arch=amd64 --include=kali-archive-keyring,kali-debtags,kali-defaults,kali-linux,kali-menu,kali-root-login,gnome,openssh-server kali ./kali-linux/ http://archive.kali.org/kali
Bei der Ausführung des Befehls kann es zu einem Fehler mit der Nachricht W: Failure while installing base packages. This will be re-attempted up to five times. kommen. Dieser Fehler kann ignoriert werden. Auch kann es zu einem abschließenden Fehler im Zusammenhang mit dem Paket metasploit kommen. Auch dieser Fehler kann ignoriert werden. Er wird vor der Erstellung des Templates behandelt.
Nach der Installation des Grundsystems erfolgt die Anmeldung über den chrootBefehl, um die weitere Einrichtung durchzuführen.
mount -t proc none ./kali-linux/proc/
mount -o bind /dev ./kali-linux/dev/
mount -t tmpfs none ./kali-linux/tmp/
mount -o bind /sys ./kali-linux/sys
LANG=C chroot ./kali-linux /bin/bash
Erzeugen die Befehle keine Fehlermeldung, wurde erfolgreich in das frisch installierte Kali Linux gewechselt.
1.3 System einrichten und aktualisieren
Um die Signaturen der in Zukunft zu installierenden Pakete prüfen zu können, müssen die Schlüssel der Paketquellen auch im neuen OpenVZ Template importiert werden.
Jetzt werden die Paketquellen aktualisiert und das System auf den Stand der den neuen Paketquellen entspricht, gebracht. Neuer Inhalt der Datei /etc/apt/sources.list hat wie folgt zu lauten.
## KALI Main
deb http://http.kali.org/kali kali main non-free contrib
deb-src http://http.kali.org/kali kali main non-free contrib
## KALI Sec
deb http://security.kali.org/kali-security kali/updates main contrib non-free
## X2Go
deb http://packages.x2go.org/debian wheezy main
deb-src http://packages.x2go.org/debian wheezy main
Damit jede virtuelle Maschine eigene SSH Host-Schlüssel hat, muss die Datei /etc/rc.local wie folgt vor dem Befehl exit 0 ergänzt werden und danach der Befehl rm /etc/ssh/ssh_host_* ausgeführt werden.
# SSH-Keys bei Erststart erzeugen
test -f /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server
Damit der SSH-Dienst im Gegensatz zur Voreinstellung von Kali Linux beim Systemstart gestartet wird, ist das Anlegen der Verknüpfungen aus den Runleveln zu SSH sowie die korrekte Ablegung des start-stop-daemon Skripts notwendig. Folgende zwei Befehle erledigen die Arbeit.
Jetzt muss das Kennwort des Superusers der virtuellen Maschine mit dem Befehl passwd mit dem bekannten Wert toor initialisiert werden. Daraufhin werden alle lokalen Konsolen (gettys) bis auf das Erste in der Datei /etc/inittab wie folgt auskommentiert.
cd kali-linux
GZIP=-9 tar --numeric-owner -zcf ~/Development/proxmox/kali-1.0.5-standard_1.0.5-1_i386.tar.gz .
Im Anschluss kann das erstellte Template in den Storage-Bereich von Proxmox hochgeladen und provisioniert werden.
1.6 Verbindung mittels X2go
Nach der Provisionierung ist die Verbindung zur virtuellen Maschine mittels X2Go mit folgenden Einstellungen möglich (IP-Adresse anpassen!). Das verwendete Icon gibt es hier.
X2Go Kali Linux Einstellung
Um die Provisionierung abzuschließen, muss in einem Terminal der Befehl apt-get install -f eingegeben werden und ein MySQL-Kennwort vergeben werden. Zuletzt folgt die Konfiguration der lokalen Sprache.
dpkg-reconfigure locales
Hier wird de_DE.UTF-8 gewählt. Die Zeitzone muss auch gesetzt werden, in der Regel auf Europa/Berlin.
dpkg-reconfigure tzdata
Wem die Anpassungen nach der Provisionierung zuviel sind, oder wer das Template nur in einer Sprache benötigt, kann aus dem Verzeichnis /var/lib/vz/private/VZID ein neues finalisiertes Template erzeugen.
Viel Spaß!
KALI LINUX ™ is a trademark of Offensive Security.
Am 16.12 durfte ich in der Vorlesung Rechnernetze und verteilte Systeme einige Angriffsmethoden quer über den TCP/IP Stack verteilt vorstellen. Die Vorlesung richtet sich an Bachelor-Studenten im dritten Semester.
Diese Anleitung beschreibt die Installationen von Debian Wheezy auf einem Server mittels Rettungssystem. Der Server ist nach der Installation weder gegen Angriffe aus dem Netzwerk abgesichert noch entspricht er dem Standard-Image des Providers. Durch den Einsatz einer Debian Basis-Installation fallen Überwachungsskripte und gepatchte Kernel des Providers weg. Das ist kein Zufall.
Das Ergebnis ist ein Minimalsystem für einen voll-verschlüsselten Server, der folgende Eigenschaften hat.
Möglichst unabhängig von der Provider-Infrastruktur
Minimalsystem
Full-Disk-Encryption (FDE) mit Entsperrung per SSH
Die Anleitung basiert auf dem Squeeze from Scratch HowTo von Sven Richter und stellt das Vorgehen zur Installation nach den Prinzipien meines Vortrags „Tauchfahrt mit Linux – Colocation Anti-Forensik“ dar. Die Folien führen in die Problemsituation und meinen Lösungsansatz ein und sind hier zu finden. Es wird davon ausgegangen, dass die Installation von einem Linux-System aus durchgeführt wird.
Natürlich lässt sich jede Debian basierte Distribution nach dem im Artikel Debian Colocation/Leased Server Full-Disk-Encrytion vorgestellten Prinzip installieren. Dafür sind nur sehr wenige Änderungen notwendig. Hier die Anpassungen, um statt Debian Kali Linux zu installieren.
Es sind die Abschnitte 4.1 und 4.2 der Anleitung wie hier gezeigt zu ersetzen und die veränderten Paketquellen in Schritt 5.2 zu verwenden.
4.1 Debootstrap herunterladen und anpassen
mount -t tmpfs none /tmp
cd /tmp
wget http://archive.kali.org/kali/pool/main/d/debootstrap/debootstrap_1.0.48+kali1_all.deb
ar -xf debootstrap_1.0.48+kali1_all.deb
tar xzf data.tar.gz
tar xzf control.tar.gz
Jetzt muss geprüft werden, ob der Inhalt des Pakets unverändert im Rettungssystem angekommen ist. Jedes Debian Paket liefert eine Datei md5sums mit, die Prüfsummen über die enthaltenen Dateien enthält. Mit dem folgenden Einzeiler lässt sich die Integrität des debootstrap Pakets prüfen.
Der Befehl darf keine Ausgabe erzeugen, sonst sind Daten verändert worden.
Um jetzt per debootstrap installieren zu können, muss der Quelltext von debootstrap leicht angepasst werden.
nano usr/sbin/debootstrap
Die folgenden Zeilen entsprechend editieren
Suchen:
DEBOOTSTRAP_DIR=/usr/share/debootstrap
und ersetzen mit:
DEBOOTSTRAP_DIR=/tmp/usr/share/debootstrap
4.2 Installation durchführen
Um sicherzugehen, dass nur offizielle Pakete ohne Hintertüren auf dem neuen System installiert werden, müssen die Signaturen aller Pakete geprüft werden. Alle Debian Pakete sind durch öffentliche Schlüssel in einer Public-Key-Infrastruktur gesichert. Damit diese Signaturen geprüft werden können, muss der Hauptschlüssel des Debian Archivs wie folgt importiert werden.
Mit dem Befehl gpg --list-keys wird geprüft, ob der Schlüssel erfolgreich importiert wurde. Ist das der Fall, kann das Grundsystem installiert werden.
usr/sbin/debootstrap --keyring=/root/.gnupg/pubring.gpg --arch=amd64 kali /mnt/ http://archive.kali.org/kali
Nach der Installation des Grundsystems erfolgt die Anmeldung über den chrootBefehl, um die weitere Einrichtung durchzuführen.
mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev
mount -t tmpfs none /mnt/tmp
mount -o bind /sys /mnt/sys
LANG=C chroot /mnt /bin/bash
Erzeugen die Befehle keine Fehlermeldung, wurde erfolgreich in das frisch installierte Debian gewechselt.
5.2 Ergänzung für Kali
Hier wird statt der angegebenen Quellen für Debian folgender Inhalt in die Datei /etc/apt/sources.list hinzugefügt.
deb http://http.kali.org/kali kali main non-free contrib
deb http://security.kali.org/kali-security kali/updates main contrib non-free
deb-src http://http.kali.org/kali kali main non-free contrib
deb-src http://security.kali.org/kali-security kali/updates main contrib non-free
Wer regelmäßig nach Schwachstellen recherchieren muss, braucht eine schnelle, umfassende und relevante Suchmaschine um schnell im Rahmen eines Penetrationstests bekannte Schwachstellen finden zu können. Bisher gab es ein großes Angebot an mehr oder weniger vernetzten Datenbanken wie die OSVDB oder die NVD-Datenbank des NIST. Darüber hinaus gibt es die Exploit-Database von Offensive Security, die sich durch direkt verlinkte Exploits zu den Schwachstellen abhebt.
Das Hasso-Plattner-Institut hat die Vulnerability Database VDB veröffentlicht, die viele Datenbanken zusammenfassen soll. Die Nutzung ist nach einer Registrierung ohne Realdaten kostenlos.
Wie hilfreich ist die Datenbank für Penetrationstester?
Die HPI-VDB hat nicht den Anspruch die Exploit-DB zu ersetzen, direkte Links zu den zugehörigen Exploits gibt es nicht. Da es sich um eine reine Schwachstellen-Datenbank handelt, muss sich die VDB aber auch nicht mit Exploit-Datenbanken messen. Bleibt die Suchfunktion, um im Rahmen der Informationsbeschaffung erkannte Programme und Versionsnummern mit Schwachstellen zu korrelieren.
Und genau dort bietet die VDB bereits einen sehr praktischen Vorteil. Eine funktionierende Freitext-Suche. Und schnell ist die Suche, was rein subjektiv betrachtet bei anderen Datenbanken zu Stoßzeiten nicht immer der Fall ist.
Darüber hinaus bietet die VDB Vor- und Nachbedingungen in einem XML-Format, die maschinell ausgewertet werden können. Zugang zu einer API ist auf Anfrage per E-Mail laut FAQ möglich. Folgend zwei Screenshots der Datenbank (der zweite ist gekürzt).
Habt ihr die VDB schon ausprobiert? Was haltet ihr von dem Projekt?
