dimis linkdump

Ein täglicher auf den ISC-Blog von SANS lohnt sich definitiv. Heute wurde auf dem ISC-Blog ein interessantes Skript, welches ein User auf einem Server gefunden hat, vorgestellt. Dieses Skript ermöglicht es über PHP eine verteile Bruteforce-Attake auf WordPress-Blogs durchzuführen.

Das Skript bedient sich dazu der Möglichkeit unter PHP cURL zu nutzen.

cURL:

A free and easy-to-use client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, FILE, LDAP and LDAPS. libcurl supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, kerberos, HTTP form based upload, proxies, cookies, user+password authentication, file transfer resume, http proxy tunneling and more.

Wikipedia

Es wurde nicht das komplette Skript veröffentlicht, sondern nur einige Code-Snippets. Wer das Skript haben möchte, sollte schnell anfangen zu programmieren

Im ersten veröffentlichten Screenshot erkennt man eine Funktion, die 3 verschiedene Parameter erwartet. $ch ist dabei der Handle, der durch curl_init() erstellt wurde. Das ist im Ausschnitt nicht zu sehen.  An diesen Handle werden nun alle erforderlichen Einstellungen angehängt und am Ende mittels curl_exec($ch) ausgeführt.

Parameter 2 und 3 ergeben sich logischerweise aus ihrem Namen.

Enthält die Antwort des Servers, also die zurückgelieferte Webseite, den Ausdruck “Log Out” war die Brute-Force Attacke erfolgreich. Das wird mittels

[...]

eregi(“Log Out”,$result)

[...]

überprüft.

Interessanter als die Nutzung von cURL in PHP ist die Möglichkeit, Seiten, die gecrackt werden sollen, in einer zentralen Instanz zu verwalten um verteiltes Cracken zu ermöglichen.

Zunächst holt sich das Skript aus einer zentralen MySQL-Datenbank 200 URLs, die gecrackt werden sollen und markiert diese in der Datenbank mit seiner persönlichen “colo_id”. Bricht das Skript nun aus irgendeinem Grund ab, holt sich das Skript die vorher markieren Einträge wieder aus der Datenbank und kann an der Stelle weitermachen, an der es abgebrochen wurde. Genau diesen Schritt stehen wir hier in diesem Screenshot:

Mittels “select url, site_type from site where colo_id=’$colo_id’” werden die Einträge aus der Datenbank geholt, an denen dieser “colo”, also dieses Skript, vorher gearbeitet hat.

Interessant ist auch die Möglichkeit, Passwortlisten zentral in einer Datenbank zu speichern und so allen Skripts zur Verfügung zu stellen.

Auf jeden Fall eine interessante und erwähnenswerte Idee, wie ich finde.

Wenn man einen Server mit SSH-Zugang im Internet stehen hat, findet man in den auth-Logs oft folgende Einträge:

Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2

Ein Brute-Force Angriff auf SSH. Um das zu unterbinden kann man beispielsweise zusätzliche Tools wie denyhosts oder einem Eintrag im IPTables-Skript einsetzen. Eine andere Möglichkeit ist der Einsatz von Zertifikaten statt einer klassischen Username/Passwort-Authentifikation.

Als Server nutze ich in diesem Fall den freien OpenSSH-Server (einfach installiert per apt-get install ssh) und als Client Putty. Wenn man Putty als SSH-Client nutzen will, muss das Schlüsselpaar (öffentlicher und privater Schlüssel) mit PuttyGen erstellt werden. Sonst kann auch der Befehl ssh-keygen in der Linuxkonsole verwendet werden.

PuttyGen

Nach einem Klick auf Generate bewegt man die Maus einige male im Fenster und erstellt so einige Zufallszahlen. Man sollte auch auf jeden Fall ein Passwort angeben – um bei Verlust der Zertifikate noch einen Schutz zu haben.

Danach hat man sein Schlüsselpaar erstellt. (beide Schlüssel abspeichern!)

Wichtig ist nun der hier rot eingerahmte Bereich. Diesen kopieren wir in die Zwischenablage und verbinden uns anschließend zum SSH-Server, allerdings nicht als root sondern als normaler User.

Im Home-Verzeichnis des Users wird nun der Ordner .ssh und darunter die Datei authorized_keys erstellt (/home/$user/.ssh/authorized_keys). Ordner und Datei dürfen maximal “rwx——“ also Dateirecht 700 haben. Sobald group oder others Rechte haben, akzeptiert der SSH-Server die verwendeten Zertifikate nicht.

In die eben erstellte Datei authorized_keys fügen wir den Public Key (Zwischenablage) auf PuttyGen ein. Hier ist zu beachten, dass der Key in einer Zeile stehen muss. Zeilenumbrüche bringen den Server dazu, den Schlüssel zu verweigern.

Ein bestimmte User kann sich nur mit dem privaten Schlüssel am Server anmelden, wenn der dazu passende öffentliche Schlüssel im home-Verzeichnis des Users, in der authorized_keys eingefügt wurde.

Nun sollte der Server bereit sein und eine Verbindung mit Zertifikaten akzeptieren. Dazu gibt am in Putty unter “Connection => SSH => Auth” den vorher erstellten Privaten Schlüssel an. Evtl. kann man unter “Connection => Data” noch einen Usernamen angeben, den man anmelden will. Dann entfällt ein Schritt beim Anmelden.

Anpassungen am Server

An SSHd-Config selbst ist nur wenig zu machen. Die Einstellungsdatei findet man unter Debian in der Datei /etc/ssh/sshd_config.

Zu Ändern:

PasswordAuthentication no

Damit wird zukünftig eine Authentifizierung per Benutzername/Passwort-Kombination verboten. D.h. jede Bruteforce-Attacke läuft ins leere.

!Achtung! Wenn diese Option geändert wird, kann man nicht mehr ohne Zertifikat auf SSH zugreifen. Also unbedingt sicher sein, dass die Authentifizierung per Zertifikat auch funktioniert.

Eigentlich Standard-Einstellung, nochmal überprüfen:

RSAAuthentication yes
PubkeyAuthentication yes

Danach muss kurz der SSHd neugestartet werden: /etc/init.d/ssh reload

Pageant

Pageant ist ein Tool, das private Zertifikate von Putty verwaltet. Nachdem Pageant gestartet wurde, ist es in der Taskleiste zu finden. Zunächst muss man einmal den privaten Schlüssel mit Passwort hinterlegen und ab sofort meldet sich Putty völlig automatisch am Server an – Pageant übernimmt die Passworteingabe, wenn ihm eine passende Passwort/Zertifikat-Kombination für die Verbindung hinterlegt wurde.

Zu beachten:

• Pageant verliert Password und Zertifikat, wenn es beendet wird. D.h. nach einem Neustart muss das Zertifikat neu eingebunden werden.
• Damit die Authentifizierung völlig ohne Benutzereingaben funktioniert, muss in Putty unter “Connection => Data” der Username hinterlegt sein.

Es gibt diverse Möglichkeiten die Sicherheit seines eigenen Passworts zu überprüfen. Meistens werden Passwörter nicht im Klartext gespeichert sondern als so genannter Hash.

Kurz was ein Hash ist: Quasi der Fingerabdruck des Passworts. Überall wo man sich anmeldet muss ja das Passwort zum vergleich gespeichert werden. Meldet man sich z.B. in einem Forum an, gibt man bei der Registrierung ein Passwort an. Der Hash des Passworts wird in der Datenbank gespeichert. (NICHT das Passwort im Klartext!) Bei

Cracker

jeder Anmeldung wird nun das eingegebene Passwort gehashed und mit dem in der Datenbank gespeicherten Passwort verglichen. Stimmt der Hash überein, ist man authentifiziert. (Vorsicht vor Webseiten, die einem das Passwort im Klartext zuschicken (per Mail oder SMS). Das heißt dann, dass das Passwort irgendwo im Klartext bzw in umkehrbarer Form gespeichert wird. Da würde ich mich sofort abmelden.)

Passwörter die im Klartext gleich sind, sind natürlich auch im Hash gleich. Menschen die geklont werden, haben ja auch die gleichen Fingerabdrücke. Logisch, oder?

Nun, da ein Hash nur ein Fingerabdruck des Passworts ist, kann man das Passwort also nicht einfach zurückrechnen. Deswegen kann man diverse Möglichkeiten nutzen sein Passwort zu überprüfen:

Ranbow-Tables

Die Tatsache, dass gleiche Klartext-Passwörter den gleichen Hash haben machen sich die Rainbow-Tables zu nutze. Denn in Rainbow-Tables werden Passwort und dazu der dazu passende Hash gespeichert. Diese Rainbow-Tables kann man sich entweder selbst mit diversen Programmen anlegen oder schon vorgefertigt von Webseiten per BitTorrent oder direkt herunterladen. Hat man nun beispielsweise einen MD5-Hash den man Cracken will muss man einfach die Tabellen nach dem passenden Hash durchsuchen. Findet man den Hash, hat man das Passwort.

Rainbow-Tables lassen mit einer einfachen Technik außer Kraft setzen: Man salzt die Passwörter (Salt). Ein so genannter Salt ist eine Zufallszahl, die zusätzlich an das Passwort angehängt wird.

Salt

Nehmen wir wieder unser Beispiel von vorher, in Verbindung mit der Hash-Funktion MD5. Ein User registriert sich in einem Forum und gibt dazu sein Passwort an. Im Hintergrund erstellt die Forensoftware eine Zufallszahl, den so genannten Salt. Wenn der User auf Registrieren klickt speichert die Forensoftware folgendes in der Datenbank:

md5($password.$salt) und $salt

Klartext: Die Forensoftware setzt das Passwort und den Salt zusammen, und speichert den Hash über Passwort+Salt (vgl. vorher: nur Passwort) in der Datenbank. Zusätzlich speichert es den Salt im Klartext. Um nun einen Nutzer zu authentifizieren muss die Forensoftware also bei jeder Anmeldung das eingegebene Passwort + Salt hashen und mit dem gespeicherten Wert vergleichen.

Da man das Passwort mit einem Salt verbunden hat, sind selbst identische Passwörter unterschiedlich.

Sinnvoll sind Hashes mit Salt natürlich nur, wenn absolut niemand an die Salts kommt. Hat man die komplette Datenbank an einen Hacker verloren, kann dieser den Salt schon mit einrechnen und hat somit die Sicherheitsvorkehrung des Salts umgangen. Mehr dazu im nächsten Teil “GPU/CPU Bruter”…