Es geht darum wie PHP (und die anderen anfälligen Sprachen auch) Hash-Tabellen erstellen und verwalten. Die hier interessante Hash-Tabelle ist das $_POST Array, das man von außen füllen kann, und das anfällig ist wenn man nur genügend “passende” Datensätze reinfüllt. Der Algorithmus der die Hash-Tabelle befüllt wird nämlich langsamer sobald Kollisionen der Keys auftreten. Schickt man also beispielsweise 300KB POST-Daten an ein PHP-Script ist eine schnelle CPU damit ca. 30 Sekunden unter Volllast. Bei 8MB (dem Standard-Maximum für POST-Daten in der php.ini) wären es immerhin schon 5 Stunden, die die CPU benötigt um die Hash-Table zu füllen. Man kann also mit einer relativ kleinen DSL-Leitung einigen Schaden anrichten. Mit einer Gigabit-Leitung kann man so 10.000 CPU-Kerne dauerhaft beschäftigen.

Etwas Abhilfe schaffen da die Einstellungen max_input_time und max_execution_time, die je nach Distribution 30 Sekunden, 60 Sekunden bzw. nicht beschränkt sind. Man müßte also mehrere kleine Anfragen schicken und kann nicht die 8MB ausnutzen. mit ca. 500KB kann man einen CPU-Kern dann etwa eine Minute beschäftigen.

Das Problem ist wohl seit 2003 bekannt, Perl hat es damals behoben indem in die Generierung des Hash-Index auch Zufall mit einfließt, und nicht nur der Key die Hash-Position bestimmt. Neben PHP sind übrigens auch Java, Apache Tomcat, Apache Geronimo, Jetty, Oracle Glassfish, ASP.NET, Python, Plone, CRuby 1.8, JRuby, Rubinius und v8 (Node.JS) betroffen (Details zu betroffenen und gefixten Versionen).

Abhilfe schafft beispielsweise die PHP-Extension Suhosin, mit der die Anzahl an POST-Variablen beschränkt werden kann (Standard ist 200). Seit 3 Wochen gibt es auch einen Patch für PHP der eine neue php.ini Variable max_input_vars (Standard 1000) einführt, dieser Patch wird enthalten sein in PHP >=5.3.9 und >=5.4.0 RC4

Ein sehr hilfreicher Artikel bei cryptanalysis.eu erklärt noch einige Details. Natürlich empfiehlt es sich auch das aufgezeichnete Video des Talks zu schauen. Aktuell ist es ein PreRelease, das finale Video wird wahrscheinlich erst morgen oder übermorgen erscheinen nehme ich an.

Aktuell werden wohl noch keine großflächigen Angriffe beobachtet, aber wer auf der sicheren Seite sein will installiert sich Suhosin falls nicht eh schon geschehen. Aber Achtung, einige Restriktionen sind zu streng und könnten die Benutzung der Applikation beeinflussen die auf hohe Werte einiger Einstellungen angewiesen ist, also bitte vorher testen. Oder noch etwas gedulden und bald auf PHP 5.3.9 bzw. PHP 5.4.0 updaten.

EDIT: php.net ist langsam bzw. zeitweise nicht erreichbar…

EDIT: Der torrent zum offiziellen Release des Videos.

EDIT: Demo-Webseite incl. Quelltext

Ähnliche Artikel:

1. PDT 2.1 unter Windows mit Subclipse SVN Client

In der Apache Konfiguration kann das beispielsweise so aussehen:

<VirtualHost *:80>
    DocumentRoot /path/to/wwwroot
    ServerName domain.de

    Header add X-Content-Security-Policy "allow 'self'; img-src images.domain.de; script-src static.domain.de;"
</VirtualHost>

oder hier mittels PHP gesetzt:

<?php
header("X-Content-Security-Policy: allow 'self'; img-src images.domain.de; script-src static.domain.de;");

Sollten nun Bilder oder Javascripte eingebunden sein die nicht von den angegebenen Domains kommen wird der Browser sie blockieren und nicht laden. Es gibt neben img-src und script-src auch noch frame-src, xhr-src und weitere.

Wir können nun also alle gültigen Quellen für die externen Ressourcen definieren. Ein hilfreiches Zusatzfeature ist das Reporting, das den Browser anweist, im Falle einer CSP-Verletzung eine bestimmte URL aufzurufen. Es ist auch möglich, nur das Reporting zu aktivieren. Falls also eine unerwartete Ressource geladen wird von einem fremden Server, können wir Alarm schlagen und das Problem analysieren und beseitigen. Ein Reporting-Header sieht beispielsweise so aus:

<?php
header("X-Content-Security-Policy-Report-Only: allow 'self'; img-src images.domain.de; script-src static.domain.de; report-uri /violation.php");

Der Header-Name hat sich leicht geändert, eine Reporting-URI ist hinzugekommen, ansonsten ist alles gleich geblieben. Im Unterschied zum normalen Header sorgt der Report-Only-Header dafür dass nichts blockiert wird, nur die Verletzungen werden gemeldet. Ideal falls man nur XSS entdecken möchte, es ist auch hilfreich wenn man gerade den richtigen CSP-Header erstellt und produktiv schaltet, denn man kann beide Header senden, dann wird blockiert und reported. Eigentlich sollte der Reporting-Only Header immer da sein, um Rückmeldungen zu erhalten und auf Bedrohungen reagieren zu können.

Wie sieht nun die violation.php aus?

<?php
$json = file_get_contents('php://input');
if ($json === false) {
    throw new Exception('Bad Request');
}

$csp = json_decode($json, true);
if (is_null($csp)) {
    throw new Exception('Bad JSON Violation');
}

$msg = "Request: ".$csp['csp-report']['request']."\n".
       "Request: ".$csp['csp-report']['blocked-uri']."\n".
       "Request: ".$csp['csp-report']['violated-directive'];
// log or mail $msg now

Die Reporting-Informationen kommen als RAW POST JSON Daten. Wir lesen also von der Standard-Eingabe, JSON-decodieren den Text und loggen oder versenden dann die wichtigen Informationen per E-Mail. So sind wir immer auf dem aktuellen Stand bezüglich der CSP-Verstöße.

Hier noch ein Beispiel, und wie es im Firebug dargestellt wird:

<?php
header("X-Content-Security-Policy: allow 'self'; img-src images.domain.de; script-src static.domain.de");
header("X-Content-Security-Policy-Report-Only: allow 'self'; img-src images.domain.de; script-src static.domain.de; report-uri /violation.php");
?>
<html>
    <head>
        <script type="text/javascript">
            alert('CSS');
        </script>
    </head>
    <body>
        <img src="http://www.phpgangsta.de/wp-content/uploads/update-300x225.jpg" />
    </body>
</html>

Die Webseite bleibt komplett weiß, weder das Javascript wird ausgeführt noch das Bild wird angezeigt.

Das hier vorgestellte Verhalten ist wahrscheinlich kein Problem von PHP sondern eventuell vom Webserver, aber ich weiß es nicht genau. Vielleicht kann ja mal jemand mit Tomcat oder nginx dieses Problem nachstellen.

Wir nehmen folgendes Script als Beispiel:

<?php
file_put_contents('/tmp/outp', '1');

echo 'start';
file_put_contents('/tmp/outp', '2', FILE_APPEND);
echo 'ende';

Ich glaube ihr stimmt mir alle zu wenn ich behaupte: Das Script erstellt immer eine Datei mit dem Inhalt “12″. Es kann zum Beispiel nicht passieren dass nur “1″ in der Datei steht.

Falsch gedacht. Ein Client (Browser) kann einen HEAD Request zum Webserver(Apache) schicken, d.h. der Client ist nur an den Header-Informationen der Antwort interessiert. Was tut der Apache? Er startet das PHP Script, und bricht es bei der ersten Ausgabe ab!! Denn dann kann man mit PHP nicht mehr die Header verändern, und der Apache spart CPU etc. und stoppt das PHP-Script.

Was bedeutet das für unser Beispiel-Script? In der Datei /tmp/outp steht plötzlich nur “1″ drin. Man kann sich nun überlegen was das für seine eigene Applikation bedeutet. Man schaue sich dieses Beispiel an:

<?php
session_start();
$_SESSION['admin']=1;

if (!isset($_POST['pass']) || $_POST['pass']!='somepassword') {
    echo '<b>Wrong or empty password.</b><br>';
    $_SESSION['admin']=0;
} else {
    echo 'logged in';
}

Ich hoffe niemand programmiert so, aber ihr sehr das Problem: In der Session wird erstmal ein Flag gesetzt, das bei falschem Passwort wieder zurückgesetzt wird. Normalerweisse funktioniert das super, es sei denn jemand schickt einen HEAD Request wird mit falschem Passwort, dann wird das Script beim echo gestoppt, in der Session ist der Benutzer dann eingeloggt!

Oder stellt euch vor ihr habt ein Script, das eine CSV-Datei erstellt, zum Beispiel so:

<?php

$data = <datenbankabfrage>

foreach ($data as $d) {
    file_put_contents('/tmp/csv.csv', $d['id'] . ';' . $d['name'] . "\n", FILE_APPEND);
    echo ".";
}

Falls jemand das Script mit der Methode HEAD aufruft wird eure CSV-Datei nur eine Zeile enthalten, sprich defekt sein, euer System das von der Vollständigkeit der CSV-Datei ausgeht wird Fehler produzieren.

Was kann man gegen dieses Problem tun? Man rechnet einfach immer damit dass ein Script auch abbrechen kann (wenn der Apache abstürzt, das Netzteil durchbrennt), man nutzt Output-Buffering (ob_start() etc.) oder deaktiviert HEAD-Requests komplett.

Eventuell habt ihr weitere interessante Beispiele was dadurch kaputt gehen kann. Das ist jedenfalls ein Problem über das ich mir so noch nie Gedanken gemacht habe. Das Problem habe ich in diesem PDF gefunden.

In viele Webseiten wird heutzutage eingebrochen und es werden Änderungen an der Webseite durchgeführt. Das kann die selbst programmierte Webseite sein bei der man eine Lücke eingebaut hat, das kann aber auch ein installiertes WordPress oder Joomla sein.

Häufig sind solche Angriffe nicht geziehlt, sondern werden mittels automatischer Scripte durchgeführt, die dann auf allen anfälligen Servern kleine Änderungen an den Dateien durchführen:

- Phishing Webseiten werden auf den Server gelegt
– in die Webseite wird bösartiger Code eingebaut der mittels Flash, Javascript, Windows Media Player oder anderen Techniken versucht einen Drive-By-Download bei den Besuchern zu platzieren
– die Webseite wird “nur” defaced, sprich ein witziges Bild wird auf die Webseite gesetzt die den Besitzer blossstellen soll
– an strategisch gut platzierte Stellen im Code werden mail() Aufrufe eingefügt die beispielsweise die Klartextpasswörter an den Angreifer senden
– es werden kleine Scripte abgelegt wie beispielsweise PHProxy oder ein Spam-Mail-Script
– heutzutage wird auch gern die .htaccess Datei verändert, mit der der Suchmachinen-Traffic auf eine andere Seite umgeleitet wird, beispielsweise so:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*netscape.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*lycos.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*metacrawler.*$ [NC,OR]
RewriteRule .* http://hackerwebseite.de [R,L]

Falls die Angreifer Dateien verändern oder hinzufügen können wir das mit einem geeigneten Programm erkennen. Falls der bösartige Code in die Datenbank geschrieben wird hilft die hier vorstellte Lösung nicht.

Die strategisch beste Lösung ist die Überwachung auf Betriebssystemebene. Dazu gibt es Programme wie die unten aufgeführten die eine Liste von Dateien und Ordnern abarbeiten und die Dateien auf Veränderungen prüfen. Standardmäßig sind das Dateien in denen häufig Rootkits installiert werden wie /usr/bin/sh, /usr/bin/ls, /usr/bin/ps usw. aber auch eigene Ordner können auf Änderungen überwacht werden. Bekannte Programme sind Tripwire, AIDE, Osiris, Samhain, iWatch, und OSSEC.

Was aber macht man wenn man ein Webhosting-Paket hat? In diesen Fällen kann man sein Webverzeichnis nicht von solchen Programmen überwachen lassen, sondern muss sich selbst darum kümmern, mit natürlich einigen Nachteilen.

Ich habe auf GitHub das Projekt FileWatcher gestartet, eine PHP Klasse die Dateien und Ordner auf Änderungen überprüfen kann, und bei Änderungen Alarm schlägt. Wird dann so genutzt:

<?php

require_once 'FileWatcher.php';

$fileWatcher = new FileWatcher();
$fileWatcher->readConfig('FileWatcher.config.php')
            ->checkNow();

Die Konfiguration könnte beispielsweise so aussehen (hier für ein Windows-System):

$config = array(
    'password'              => 'secretPassword',
    'includePaths'          => array('C:\\Temp', 'D:\\temp'),
    'excludeFolderList'     => array('C:\\Temp\\projekt'),
    'excludeExtensionList'  => array('jpg', 'png', 'pdf'),

    'hashMasterFilename'    => 'FileWatcher.MasterHashes.txt',
    'logFilename'           => 'FileWatcher.log',
    'overwriteMasterFile'   => true,

    'alertEmailAddress'     => 'alerts@domain.de',
    'alertEmailSubject'     => 'ALERT: File hashes on your server have changed',
    'alertEmailMethod'      => 'mail',  // mail or smtp
    'alertEmailSmtpServer'  => '1.2.3.4',
    'alertEmailSmtpUser'    => 'XXXX',
    'alertEmailSmtpPass'    => 'XXXX',
);

Es ist die erste Version, man kann natürlich noch einige Features hinzufügen wie alternative Benachrichtigungswege (Jabber, SMS?), oder eine Änderungsprüfung anhand des Last-Modified-Dates statt einem SHA1-Hash, das dürfte bei vielen großen Dateien deutlich schneller sein.

Man könnte sich auch an Extensions wie FAM oder Inotify heranwagen, interessant um sehr schnell Änderungen an Dateien mitzubekommen, aber dazu muss man diese Extensions auch installieren können.

In der README sind noch einige weitere ToDos.

Tut ihr irgendetwas in der Richtung, fremde Veränderungen auf euren Servern zu entdecken?

PS: Falls nur ein WordPress Blog betrieben wird hilft evtl. auch der Einsatz des Plugins File Monitor Plus.

Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.

Nachdem ich ja in den letzten Wochen über den sicheren Umgang mit Passwörtern in Webprojekten erzählt habe, soll es heute mal um etwas anderes gehen (aber trotzdem um das Thema Sicherheit). Wenn man oft auf fremden oder eigenen Servern arbeitet, kommt man an OpenSSH eigentlich nicht vorbei. Und wenn man dazu noch so faul ist wie ich (und vermutlich die meisten von Euch auch), hat man keine dutzenden Dateien mit Passwörtern, sondern wickelt die gesamten Loginvorgänge mit Hilfe von öffentlichen und privaten Schlüsseln ab. Dieses Verfahren ist nicht nur bequem, es bietet auch zusätzliche Sicherheit, da man nicht in Versuchung kommt, einfache Passwörter zu verwenden. Ausserdem ist die eigene Passwortliste schon von Haus aus verschlüsselt.

Das Verfahren hat aber für einen Serverbetreiber Nachteile. Der öffentliche Schlüssel muss auf dem Server hinterlegt werden. Ausserdem muss man sobald der Zugang nicht mehr benötigt wird, nachsehen, ob ein Benutzer sich vielleicht eigene Schlüssel hinterlegt hat und natürlich muss man ihm den Zugang manuell sperren.

Alle diese Vorgänge sind lästig und zeitaufwendig und bergen Gefahren, vor allem dann, wenn man die Zugänge von vielen Benutzern verwalten muss. Schnell hat man eine Zeile in der „authorized_keys“ Datei für einen Benutzer übersehen und handelt sich damit dauerhaft ungebetene Gäste ein. Seit OpenSSH 5.6 gibt es nicht nur die Möglichkeit, öffentliche und private Schlüssel zu hinterlegen, sondern den öffentlichen Schlüssel zu signieren. Dieses Verfahren der Signierung oder Zertifizierung bietet uns gewaltige Vorteile.

Der Server kann bei einer Signierung erkennen, ob ein Schlüssel nur für einen gewissen Zeitraum gültig sein soll oder schon abgelaufen ist und ob gewisse Rechte, z. B. zum X11 Forwarding oder Port Weiterleitung erteilt wurden oder nicht. Ausserdem müssen wir die Public Keys der Nutzer nicht mehr hinterlegen und unser Privatekey ist quasi unangreifbar. Dieses Verfahren benötigt fertig eingerichtet nicht mal mehr einen Login auf dem Server zur Erstellung neuer Zugänge.

Wichtiger Hinweis und Ausgangssituation

Lest bitte erst den ganzen Text, damit Ihr nicht in der Mitte stecken bleibt. Wenn Ihr nicht regelmäßig auf Linuxsystemen arbeitet, dann richtet euch eine virtuelle Maschine ein, die Ihr nach Lust und Laune kaputt konfigurieren könnt. Das Verfahren nutze ich selbst auf meinen Servern, wenn Ihr Euch trotzdem aussperrt, dann ist das nicht meine Schuld, bei mir geht es ja. Man kann das Verfahren auch auf einem Rechner testen.

Falls Euer Zielrechner nicht greifbar für Euch ist, also irgendwo im Rechenzentrum steht, lasst die Passwortauthentifizierung an und loggt Euch zusätzlich auf einer anderen Konsole ein. Lasst das Fenster offen. Sollte etwas schief gehen, könnt Ihr es in diesem Fenster immer noch reparieren. Diese Anleitung richtet sich eindeutig an erfahrende Nutzer und ist nichts für Hobbyadmins und „Menschen mit schwachem Herz“.

Server und Client sind bei mir beide Linuxrechner – für Windows bin ich kein Fachmann. Da aber OpenSSH auch unter Windows arbeitet, dürfte die Konfiguration letzendlich in etwa die gleiche sein.

Alle Einstellungen sind lediglich Vorschläge und nicht verbindlich. Verbesserungen sind natürlich willkommen, eigenes Nachdenken erwünscht. Als Testsystem habe ich Debian Squeeze auf dem Server und bei mir zu Hause ArchLinux. Bei Debian muss der SSH Server aus dem „unstable“ Zweig installiert werden (libssl, openssh-server, openssh-client), da es dort noch kein aktuelles Paket in testing oder stable gibt. Als Mindestversion empfehle ich OpenSSH 5.8, Version 5.6 sollte aber theoretisch auch funktionieren.

Ich arbeite zunächst als root während der Einrichtung bis ich etwas anderes sage. Wer das nicht möchte, muss überall sudo vor die Befehle schreiben. Sollte noch kein SSH Server und/oder Client installiert sein, fangen wir damit an.

Auf dem Server (root)

apt-get install openssh-server openssh-client libssl

Auf dem Client (root)

apt-get install openssh-client

Nach kurzer Wartezeit ist unser SSH Server fertig eingerichtet und gestartet.

Was werden wir tun?

1. Grundlegende (sichere) Konfiguration des SSH Dienstes
2. Sperren des SSH Login für root
3. Anlegen und Einrichten eines neuen Benutzers zum Login
4. Zugang für diesen Benutzer nur mit gültigem signiertem Schlüssel

Die Konfiguration

Zunächst sichern wir die aktuelle Konfiguration. Dann editieren wir die sshd_config mit nano (joe, vi usw. gehen natürlich auch).

Auf dem Server (root)

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
nano /etc/ssh/sshd_config

Innerhalb der Datei ändere ich die Einstellungen unter dem Punkt Authentification auf die angegebenen Werte. die LoginGraceTime kann auf 10 Sekunden herunter gesetzt werden, da ein Zugriff mit Passwörtern nicht genutzt wird und meine Schlüssel vom ssh-agent verwaltet werden. Den root Login verbiete ich, denn ich will es „Brute Forcern“ etwas schwerer machen. Die Einstellungen für StrictModes, RSAAuthentication, PubkeyAuthentication bleiben gleich. PasswordAuthentication setze ich hier schon auf no (siehe Hinweise). Wenn Ihr wollt, könnt Ihr auch mit AllowUsers user1 user2 usw. eine „Whitelist“ für erlaubte Loginnamen fest legen. Das bietet aber auch nicht mehr Sicherheit – nur die Fehlermeldung ändert sich.

Die Werte für AuthorizedKeysFile, AuthorizedPrincipalsFile und TrustedUserCAKeys fügen wir hinzu. In der AuthorizedKeysFile stehen normalerweise die Publickeys der Benutzer. Da wir die aber hier nicht brauchen, ändern wir den Wert auf /dev/null. So kann sich kein Benutzer eigene Zugänge hinterlegen. TrustedUserCAKeys ist der öffentliche Teil unseres Zertifikats. In der AuthorizedPrincipalsFile stehen alle Benutzer, die in den Zertifikaten hinterlegt werden. Dazu später noch mehr.

# Authentication:
LoginGraceTime 10
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes

AuthorizedKeysFile /dev/null
TrustedUserCAKeys /etc/ssh/trusted_ca_keys
AuthorizedPrincipalsFile %h/.ssh/authorized_ca_user

PasswordAuthentication no

Die Einstellungen übernehmen wir mit einem SSH Neustart. Wenn Ihr Euch nicht sicher seid, wartet noch. Die Änderungen könnt Ihr jederzeit rückgängig machen, indem ihr die .bak Datei zurück kopiert und dann ssh neu startet.

Auf dem Server (root)

/etc/init.d/ssh restart

Der authorisierte Benutzer

Als nächstes legen wir einen neuen Benutzer an. Den nenne ich jetzt einfach mal login, weil er nur dafür da ist, sich auf dem Server anzumelden. Bevor Ihr versucht anonsphere.com zu brute forcen – da hab ich nen anderen Benutzer – ausserdem werde Ihr nach 3 Versuchen gebannt. Die zweite Zeile ist optional. Ihr könnt natürlich auch ein Passwort für den Benutzer hinterlegen, aber ich habe keine Lust, dass jedesmal einzugeben. Wer sich als dieser Benutzer einloggen kann, könnte eh unbemerkt keylogger o. ä. installieren. Mir persönlich reicht der abgesicherte Zugang. Wenn der Benutzer eingeschränkt handeln soll, also nicht zum root werden darf, ändert den Befehl von -G users,admin auf -g users

Auf dem Server (root)

useradd -c "Login" -d /home/login -G users,admin -u 1003 -m -s /bin/bash login
passwd --delete login

Der normale Schlüssel

Auf Eurem Clientsystem erzeugen wir für unseren Benutzer einen Schlüssel, falls Ihr schon einen habt, springt zum nächsten Kapitel.

Auf dem Client (Benutzer)

ssh-keygen -t rsa -b 4096 -f id_rsa

Verschiebt den private Schlüssel in den Ordner ~/.ssh/id_rsa. Der Publickey wird nicht auf dem Server hinterlegt!

Auf dem Client (Benutzer)

mkdir ~/.ssh/
mv id_rsa ~/.ssh/id_rsa

Der signierte Schlüssel

Zum Erstellen der Zertifikate brauchen wir noch ein Schlüsselpaar. Den Ablauf kennen wir ja schon. Den Inhalt des öffentlichen Schlüssel hinterlegen wir auf dem Server in der Datei trusted_ca_keys. Dann wechseln wir auf unseren Benutzer und hinterlegen die ID des Zertifikats („principal“), die erlaubt sein sollen – dieser muss nicht mit dem Benutzernamen übereinstimmen. Auf dem Server muss nur der Publickey des Zertifikats liegen.

Auf dem Client oder Server (Benutzer)

ssh-keygen -t rsa -b 4096 -f zertifikat_rsa

Auf dem Server (root)

cat zertifikat_rsa.pub >> /etc/ssh/trusted_ca_keys
su login
mkdir ~/.ssh/
echo "oliver" >> ~/.ssh/authorized_ca_user

Die einzige wichtige Datei ist die zertifikat_rsa. Diese muss gesichert werden (auch mehrfach) und möglichst weit weg von direktem Zugriff (Container, USB Stick, etc.). Alle anderen Dateien sind uninteressant! Wir haben also jetzt unsere Vorbereitungen getroffen. Als letztes muss noch Euer Publickey (aus „Der normale Schlüssel“) signiert werden. Das macht ihr mit folgender Zeile. I ist der Name der Zertifizierung und steht später im auth.log. n ist der principal, also der Benutzername, für den das Zertifikat ausgestellt ist und der in der authorized_ca_user hinterlegt wurde.

ssh-keygen -s zertifikat_rsa -I MeinLogin -n oliver .ssh/id_rsa.pub
ssh-add .ssh/id_rsa

Falls Ihr den SSH Agent benutzt, fügt danach den Schlüssel hinzu mit ssh-add .ssh/id_rsa.

Aufräumen

Jetzt könnte es passiert sein, dass die Rechte nicht korrekt gesetzt wurden bei unseren Aktionen. Dieses Problem erledigen wir mit der beliebten „Holzhammermethode“, damit unser Setup sicher ist. Wir gehen zurück auf den root Account auf dem Server und setzen dann unsere Rechte.

Auf dem Server (root)

chown -R root:root /etc/ssh/*
chmod 600 /etc/ssh/*

Auf dem Client (Benutzer)

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

Der Login sollte nun funktionieren. Wenn nicht, gibt die Datei /var/log/auth.log (Client und Server) weitere Informationen. Falls da nichts brauchbares steht, erhöht in der ssh_config/sshd_config den LogLevel auf DEBUG3. Fast immer sind irgendwo die Rechte falsch. Wenn bis hier hin alles funktioniert, können wir jetzt ein zeitlich eingeschränktes Zertifikat erzeugen. Dafür benutzen wir diese Zeile.

Auf dem Client (Benutzer)

ssh-keygen -s zertifikat_rsa -I MeinLogin -n oliver -V +5m .ssh/id_rsa.pub

Der Zugang wäre damit fünf Minuten gültig. Probiert es aus! Meldet Euch auf dem Server an, meldet Euch ab und schaut, ob Ihr Euch nach 5 Minuten noch anmelden könnt. Wenn Ihr mit dem Prinzip warm geworden seid, könnt Ihr natürlich auch fremde Publickeys signieren. Der Befehl sieht dann z. B. so aus:

ssh-keygen -s zertifikat_rsa -I Zeitarbeiter -n zeitarbeiter -V +1d fremderPubkey.pub

Neben der Zeit könnt Ihr auch seine Rechte, wie Port- oder X11-Forwarding einschränken. Mehr Infos bekommt Ihr mit

man ssh-keygen

Auf dem Server müsst Ihr dann in der Datei /home/login/authorized_ca_user auf dem Server den Benutzer zeitarbeiter in einer neuen Zeile hinterlegen. Ihr könnt jede ID mehrfach verwenden. So könntet Ihr natürlich auch Signaturen vorher entwerten, indem Ihr einen verwendeten Priincipal löscht. Um einem neuem Benutzer Zugang zu erteilen, benötigt Ihr seinen Publickey. Diesen signiert Ihr mit der zertifikat_rsa und schickt ihm die *-cert.pub Datei zurück. Kein Login nötig!

Was geht? Was geht nicht?

Mit Hilfe der Signaturen ist es nun endlich möglich, Zugänge zu Servern zu erteilen, die nach einer gewissen Zeit selbst verfallen, ab einem gewissem Zeitpunkt gültig sind oder Aktionen verbieten, ohne in der sshd_config Änderungen vorzunehmen. Das Verfahren eignet sich u. a. für die Vergabe von Serverzugängen für Wartungsarbeiten an der Datenbank oder zur Einrichtung von Software, die vom Benutzer genutzt wird. Ausserdem natürlich auch für die sichere Vergabe von SFTP oder FISH Zugänge mit denen der Benutzer seine Dateien ändern kann. Wenn jemand für ein Jahr bezahlt und nicht verlängert, haben wir keine Arbeit mehr damit. Verlängert er den Zugang, können wir ihm einfach lokal ein neues Zertifikat generieren.

Der größte Vorteil ist aber, dass Euer Privatekey quasi nicht mehr kompromitiert werden kann. Ich benutze den RSA Schlüssel nur für meine Serverzugänge. Sollte er mir aus irgendwelchen Gründen gestohlen werden und das Passwort gleich dazu, benenne ich einfach den principal um und erzeuge mir ein neues Zertifikat. Meinen Privatekey kann sich derjenige dann ausdrucken und an die Wand hängen, weil der ist für den Zugang völlig unerheblich. Wichtig ist nur die zertifikat_rsa, die muss geschützt werden und diese liegt natürlich sicher in einer verschlüsselten Datei.

Als Einschränkung müssen wir allerdings hin nehmen, dass das Verfahren bisher nur in aktuellen OpenSSH Versionen integriert ist, was evtl. den Zugang durch Programme wie PuTTY oder WinSCP erschwert. Für Windows habe ich generell noch nach keiner Lösung gesucht. Es kann also sein, dass es schon funktioniert, muss aber nicht – Infos bitte in die Kommentare. Unter Linux funktioniert das Verfahren mit allen Programmen, die auf der Basis von OpenSSH arbeiten, also eigentlich mit allen.

Einen Hinweis noch
Falls Ihr auf eure Server fail2ban einsetzt, müsst Ihr aus der Filterdatei für ssh die Zeile mit „Invalid Publickey“ entfernen oder auskommentieren, denn der ist durch den Verweis auf /dev/null natürlich immer falsch, auch wenn die Authentifizierung letzendlich erfolgreich ist (und ja, ich hatte beim ersten Mal auch nicht dran gedacht). In diesem Fall solltet Ihr auch eine Whitelist setzen, denn ansonsten werden Benutzer mit falschem Namen nicht immer gebannt.

Damit ich mich darauf einlasse verlange ich aber mindestens eine Passwort Blacklist, sprich eine Liste der meistgenutzten Passwörter, die dann nicht erlaubt sind, beispielsweise “12345678″ oder “passwort”, um das ganze zumindestens etwas sicherer zu machen. Man muss den Benutzer vor sich selbst schützen, sonst werden sie “12345678″ oder “passwort” als Passwort nutzen.

Gestern ist eine Liste mit E-Mail-Adressen und Klartext-Passwörtern von Rewe aufgetaucht, von denen ich die am meisten genutzten Passwörter extrahiert habe. Im Internet findet man auch hier und da “The Top 50 Passwords”, da sind aber häufig englischsprachige Begriffe dabei. Mich interessieren bei deutschen Benutzern natürlich deutsche meistgenutzte Begriffe, und da habe ich noch keine längere Liste gefunden mit mehr als 20 Einträgen. Die sortierte Rewe-Liste findet sich übrigens hier als Textdatei zum Download. Hier die Top 20:

123456
sticker
123456789
schmetterling
michael
vanessa
sonnenschein
giraffe
moritz
rewe2011
sabrina
alexander
maximilian
pauline
schule
johanna
elefant
tauschen
dennis
andreas

Interessant an dieser Liste ist, dass “passwort” erst weit unten erscheint, in englischen Listen ist “password” eigentlich immer in den Top3.

Microsoft hat letzte Woche groß angekündigt dass Hotmail-Nutzer nun keine leichten Passwörter wie “123456″ mehr benutzen können, sprich sie haben auch eine Blacklist geschaltet. Dass man für solch eine Selbstverständlichkeit, die man hätte schon vor Jahren aktivieren müssen, eine große Pressemitteilung verbreiten kann ist mir ein Rätsel.

Nutzt ihr auch Passwort Blacklists? Wie sieht eure Sperrliste aus? Mich würden vor allem deutsche Passwörter interessieren die häufig genutzt werden und die man sperren sollte.

Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängisten Internetsprachen: PHP, HTML, Javascript und CSS.

Bei meinem vorherigem Gastbeitrag wurde ich direkt im ersten Kommentar aus meiner heilen Welt geworfen. Dort stand nämlich folgender „erschütternder Kommentar“ zu lesen:

Das du Salting und Mehrfachhashing predigst, während der Rest der Welt schon einen Schritt weiter zu bcrypt geht… Traurig.

Nun ja, dazu möchte ich drei Dinge sagen.

1. Ich predige nicht (Ausnahme: „Es heißt Standard, verdammt, nicht Standart!“).
2. Ach, wenn die Welt schon mal auf dem Stand des einfachen md5 wäre …
3. Bcrypt verdient einen eigenen Beitrag.

Natürlich hatte der Autor völlig recht. Über Hashfunktionen im Web zu schreiben und bcrypt nicht zu erwähnen ist fast schon schändlich. Also bcrypt ist eine Hashfunktion, die auf Langsamkeit optimiert wurde. Um genauer zu sein, es ist nicht mal ein richtiger Hashalgorithmus, sondern eine Blowfish Verschlüsselung, bei der am Ende „die Schlüssel weggeworfen werden“, daher lässt sich das Ergebnis nicht mehr entschlüsseln. bcrypt ist eine Weiterentwicklung der „Traditional DES Scheme“ Funktion aus der Unixwelt. Obwohl dieses Verfahren 30 Jahre lang (!) gute Dienste geleistet hat, stellen sich so langsam „Alterserscheinungen“ ein. Der Zahn der Zeit nagt auch hier in Form von gestiegener Rechenleistung.

Kurze Rückschau

Hashalgorithmen wie md5 und die shaX sind auf Schnelligkeit optimiert. Das ist gut, wenn man prüfen will, ob der heruntergeladen Film auch wirklich korrekt übertragen wurde. Das ist auch gut, wenn man testen möchte, ob das SSL Zertifikat einer Webseite nicht verfälscht wurde. Das ist aber eher suboptimal, wenn man damit Passwörter speichern will. Wie schon im letzten Artikel erklärt und ausgiebig diskutiert, ist die gestiegene Rechenleistung auch ein Problem für die klassischen Hashfunktionen in Webanwendungen. Zwar kann man mit Salts, mehr Salts und Mehrfachhashes das Schlimmste verhindern, aber irgendwie ist das alles nicht so nachvollziehbar für jeden. Kurz gesagt: „Das geht besser“.

Was bcrypt kann

Selbst wenn wir dafür sorgen, dass unsere Passwörter gut geschützt sind, können wir natürlich kaum verhindern, dass ein Benutzer trotzdem ein schwaches Passwort verwendet. Wenn es der Angreifer gezielt auf eine Person, z. B. den Admin abgesehen hat, wird die Situation noch schlimmer, denn bis 10 Zeichen kann man auch schon mal eine Brute Force Attacke für einen einzelnen Hash probieren. Deshalb sollten wir unserem Cracker das Leben grundsätzlich so schwer wie möglich machen.

Bcrypt bringt gewisse Vorkehrungen für genau diesen Fall mit. Der Algorithmus ist auch optimiert noch sehr langsam, und das ist gut so. Der Hash beinhaltet einen Wert für die Rundenanzahl, den sog. „Kostenfaktor“. Dies ist der Aufwand der bei der Berechnung betrieben werden muss. Jedem Hash kann zusätzlich ein individueller Salt zugeordnet werden. In PHP ist bcrypt über die crypt() Funktion seit Version 5.3 fest implementiert. Davor hing der Einsatz vom Betriebsystem ab.

Was bcrypt nicht kann

Bcrypt bringt einige schöne Fähigkeiten mit, die wir in der Webwelt wunderbar nutzen können. Allerdings gibt es einige Dinge, die designbedingt nicht vorgesehen sind. Dazu zählt ein geheimer Salt, den wir in unserer Anwendung hinterlegen können. Der Sinn resultiert aus der Überlegung, dass wenn ein Angreifer aus welchen Gründen auch immer auf die Datenbank zugreifen kann, er auch noch auf den Quelltext der Webanwendung zugreifen können muss. Im Zweifel entscheidet sich dort, ob unsere Passwörter weiter geschützt sind oder nicht.

Die zweite fehlende Funktion, ist die Möglichkeit Hashes von zusätzlichen Faktoren, wie der E-Mail Adresse (ersatzweise dem Benutzernamen oder die UserID) abhängig zu machen. Der Hintergrund ist etwas speziell. Nehmen wir mal an, ein Angreifer findet in unserer Webanwendung eine XSS Lücke, mit denen er die Session eines Benutzers übernehmen kann. Was wäre das Schlimmste, was er tun kann? Richtig, er ändert das Passwort oder die E-Mail Adresse. Wie kann ich das am effektivsten verhindern? Ganz klar, ich muss ihn zwingen zur Überprüfung das alte Passwort einzugeben. Durch die Kopplung der Hashes an die E-Mail kann ich das gar nicht vergessen. Man könnte natürlich den Salt abhängig von der E-Mail machen, aber was ist wenn ein Benutzer mehrfach angemeldet ist? Brute Force Attacken werden mit jedem Ziel lohnenswerter.

Vom Rein und Raus

Ein ganz einfacher Hash ensteht so:

crypt ( 'Passwort', '$2a$04$EinSaltFuerDasPasswort' );

Als Ausgabe ergibt sich:

$2a$04$EinSaltFuerDasPasswore.oNHNUzZrs1V5tpdv/WJ64.DIyBV1kC

Auf den ersten Blick ist das im Vergleich zu md5(‘Passwort’) natürlich etwas verwirrend, aber dafür schreibe ich das ja hier. Im ersten Argument steht der zu hashende String. Das zweite Argument besteht aus drei Teilen, die je mit einem $ eingeleitet werden. Der erste Block bestimmt die verwendete Funktion. Die möglichen Werte könnt Ihr auf php.net nachschauen. Wir nutzen hier nur $2a für bcrypt.

Der zweite Block beschreibt die Anzahl der Runden, mit dem der Hash erstellt wird. Der Wert darf zwischen 04 und 31 liegen. Mit jeder Runde verdoppelt sich die Zeit zur Erstellung, das System ist also exponentiell. Wenn eine Runde etwa 1 ms dauert, dann dauern 31 Runden ca. 74 Minuten. Genug Luft nach oben also. Brauchbare Werte liegen derzeit bei etwa 08 bis 12, je nach eingesetzter Hardware und Geduld. Gibt man Zahlen ausserhalb des Bereichs an, wird *0 zurück gegeben.

Der dritte Block ist der individuelle Salt. Dieser darf aus Groß- und Kleinbuchstaben, Zahlen, sowie ./ bestehen. Tauchen andere Zeichen auf, wird ebenfalls *0 zurück gegeben. Die Eingabewerte müssen also gut gewählt sein. Weiterhin darf der Salt aus 128 Bits, also 21 1/2 Zeichen bestehen. Wen das verwundert, 21 Zeichen werden komplett dargestellt, beim letzten Zeichen werden die Hälfte der Bits verworfen. Deshalb wird aus ‘EinSaltFuerDasPasswort’ im hash ‘EinSaltFuerDasPasswore’.

Die Ausgabe entspricht der Eingabe, gefolgt vom eigentlichem Hash. Jetzt kann man natürlich berechtigt fragen, was daran sicher sein soll, wenn da ja alles steht. Stimmt, aber genau dieses Verfahren ist gleichzeitig ein Vorteil.

Einmal bcrypt …

Ich erstelle der Einfachheit halber eine Funktion, mit der man die Eigenschaften von bcrypt richtig nutzen kann. Auch hier gilt wieder – nichts ist in Stein gemeisselt. Wenn Ihr Vorschläge habt, her damit. Die Funktionen nenne ich (besonders kreativ) bcrypt_encode und bcrypt_check.

function bcrypt_encode ( $password )
{
	return crypt ( $password, '$2a$04$EinSaltFuerDasPasswort' );
}

Diese Funktion gibt uns einen ersten Anfang. Ein Aufruf von bcrypt(‘Passwort’) gibt uns den o. g. Hash zurück. Die Saltfunktion nutzt natürlich überhaupt nichts, wenn man überall den gleichen Salt verwendet. Da der Salt in der Datenbank steht und daher nicht geheim ist, kann dieser pseudozufällig sein kann. Folgendes Konstrukt ist also ausreichend.

$salt = substr ( str_shuffle ( './0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' ) , 0, 22 );

Die Anzahl der Runden sollte variabel sein. Der Hintergrund ist ganz einfach. Manche Accounts sind wichtiger als andere. Wenn ich als Admin 3 Sekunden zum Login warten muss, dann stört mich das nicht. Einem Besucher diese Wartezeit zu erklären, könnte sich aber schwierig gestalten oder als technische Schwäche fehlinterpretiert werden. Als Bonbon kann man dem Besucher auch anbieten, die sichere Variante zu wählen. Ein Normalwert sollte festgelegt werden, aber mit der Möglichkeit zu abweichenden Werten. Übertragen auf unsere Funktion ergibt sich.

function bcrypt_encode( $password, $rounds='08' )
{
	$salt = substr ( str_shuffle ( './0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' ) , 0, 22 );
	return crypt ( $password, '$2a$' . $rounds . '$' . $salt );
}

Zur Passwortspeicherung habe ich jetzt eigentlich alle Möglichkeiten von bcrypt ausgeschöpft. Mit jedem Aufruf wird ein neuer Hash mit einem anderem Salt erzeugt. Nur sicherer fühl ich mich jetzt nicht, denn genau wie oben schon erwähnt gebe ich dem Angreifer freiwillig alle Daten. Es ist natürlich besser als ein purer md5 hash, aber eher noch gut gemeint als gut gemacht.

Daher würde ich diese Funktion gerne erweitern. Wie bei unserem md5 Beispiel bringe ich zusätzlich einen Salt ein, der nur im Quelltext hinterlegt ist. Dieser muss vor dem ersten Aufruf der Funktion mit define(‘SALT’, ‘beliebigerWert’) definiert werden. Ausserdem möchte ich, dass man bei einer Änderung der E-Mail Adresse das alte Passwort eingeben werden muss. In den Kommentaren zum letzten Beitrag hat ein Besucher erwähnt, dass das Einbringen eines Salt mit hash_hmac() sicherer wäre als einfaches voranstellen oder anhängen. Auch wenn ich die Bedenken in diesem speziellem Fall nur bedingt teile, da sich der individuelle Salt in jeder Zeile ändert und daher ein Angriff auf den systemweiten Salt sinnlos wäre, schaden kann es auch nicht und wenn wir schon einmal dran sind, klotzen wir mal richtig.

Dazu erweitern wir zunächst einmal mit str_pad() unseren String auf die viefachefache Länge des Passwortes, indem wir ihn mit dem sha1 hash der E-Mail Adresse davor und dahinter auffüllen. Ich nehme hier sha1, weil ich möchte, dass sich bei jeder E-Mail der Salt komplett ändert. Diesen String jagen wir dann durch hash_hmac() mit unserem systemweiten Salt in Whirlpool als Binärausgabe. Den entstandenen Zeichensalat verpacken wir mit bcrypt.

function bcrypt_encode ( $email, $password, $rounds='08' )
{
	$string = hash_hmac ( "whirlpool", str_pad ( $password, strlen ( $password ) * 4, sha1 ( $email ), STR_PAD_BOTH ), SALT, true );
	$salt = substr ( str_shuffle ( './0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' ) , 0, 22 );
	return crypt ( $string, '$2a$' . $rounds . '$' . $salt );
}

Ein Aufruf von

bcrypt_encode( 'oliver@anonsphere.com', 'Test-Null8Fünfzehn' );

führt also zu diesen Ergebnissen:

// Passwort mit E-Mail auf vierfache Länge aufgefüllt
4e707693b984367edadf5a022867Test-Null8Fünfzehn4e707693b984367edadf5a022867e

// hash_hmac mit Whirlpool und systemweitem Salt (im Original binär)
b0492febbd81ef10387e2e7127295e09c197ff0cadf8ae5dc98182178f9e0891cf86b91abb1c723e0de510361cb67e1149460a687271672d77de439d7c572b57

// Verpackt mit bcrypt
$2a$08$jb8v67zmCNMO9dlX1tkVqOxGlhQkJNL45AvfpbEWvqXnGC8YcO7Hm

Die Sicherheit dürfte nur schwer anzuzweifeln sein.

… und zurück

Jetzt fehlt noch die Möglichkeit den gespeicherten Passworthash mit unserem Passwort zu vergleichen. Jetzt kommen wir zu dem Teil, wo bcrypt von nett, auf cool wechselt.

$2a$08$jb8v67zmCNMO9dlX1tkVqOxGlhQkJNL45AvfpbEWvqXnGC8YcO7Hm

Schauen wir uns doch mal diesen Hash genauer an. Wir haben oben gesehen, der Hash besteht aus den Einstellungen und dem Ergebnis. Anders gesagt, der Hash liefert uns alles, was wir zum Berechnen brauchen. Dazu schreibe ich ihn mal anders, damit es klarer wird.

Einstellungen: $2a$08$jb8v67zmCNMO9dlX1tkVqOx
         Hash: GlhQkJNL45AvfpbEWvqXnGC8YcO7Hm

Der erste Teil entspricht genau dem Code, den wir zur Erzeugung genutzt haben, daher muss auch bei korrekter E-Mail und Passwort und diesen Einstellungen unser Hash heraus kommen. Dass heißt, wenn der hinterlegte hash die Variable $stored hat, dann muss folgende Bedingung wahr sein.

crypt ( $string, substr ( $stored, 0, 30 ) ) == $stored;

Oder übertragen in eine eigene Funktion.

function bcrypt_check ( $email, $password, $stored )
{
	$string = hash_hmac ( "whirlpool", str_pad ( $password, strlen ( $password ) * 4, sha1 ( $email ), STR_PAD_BOTH ), SALT, true );
	return crypt ( $string, substr ( $stored, 0, 30 ) ) == $stored;
}

Der Vorteil erschliesst sich erst auf den zweiten Blick. Während man bei der Umstellung von md5 auf sha1 oder von sha1 auf sha256 Probleme mit bestehenden Benutzerlogins bekommt, weil die alten Passwörter ungültig werden, nimmt uns bcrypt alle nötigen Workarounds ab. Bei der Prüfung ist es nämlich vollkommen egal, was als Ursprungswert an Runden und Salt hinterlegt wurde. Wenn ich irgendwann mal die Sicherheit erhöhen will oder auf einen schnelleren/langsameren Server umziehe, ändere ich den $rounds Wert und trotzdem funktionieren alte Logins weiter. Sobald aber die E-Mail oder das Passwort geändert wird, wird der neue Wert übernommen.

Was noch zu sagen wäre

Bcrypt ist eine schöne Sache, entbindet Euch aber keineswegs von zusätzlichen Sicherheitsüberlegungen. Wer zukunftsorientiert an ein neues Projekt geht oder wer schon beim letzten Artikel überlegt hat, ob seine Passwortspeicherung wirklich so sicher ist, wie er dachte, sollte überlegen, ob der Einsatz lohnt. Ein sicheres Verfahren deshalb abzulösen, ist aber auf jeden Fall unnötig.

Bleibt mir abschliessend nur noch eins zu sagen: „ES HEISST STANDARD!!11“.