Irritation beim Portscan:
$ nmap macbook
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-08-24 09:08 CEST
Interesting ports on macbook (192.168.1.207):
Not shown: 1678 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Nmap finished: 1 IP address (1 host up) scanned in 31.606 seconds
Und der Verursacher:
Ächz!™
Was mir heute nicht so gut in den Kram gepaßt hat:
$KUNDE warf mir nochmal 50 SSL-Zertifikate vor die Füße, zwecks Überprüfung, von denen 38 für das Debian-SSL-Problem empfänglich waren. Aber ich hab ja mittlerweile Routine.
Also wurden neue CSRs generiert, welche er bei Verisign (RSA/”Secure Server Certification Authority”) zum Re-Issue eingereicht hat. Minuten später kam der erste mit einer Firefox-Fehlermeldung um die Ecke:
Die verantwortliche Konfigurationsoption war dann auch schnell identifiziert:
Willkommen im Dilemma. So schwer es mir fällt, zu bestreiten, daß diese Voreinstellung in Firefox 3.0 auf den Tag genau zur rechten Zeit kommt, so unangebracht finde ich es, daß Verisign ein Zertifikat, dessen Austausch es gerade mal so mit Ach und Krach in die Mailbox der Administratoren geschafft hat, sofort per OCSP als gesperrt propagiert.
Gerade weil es jetzt so weit ist, daß OCSP, das Online Certificate Status Protokoll, tatsächlich genutzt wird, wäre eine gewisse Galgenfrist von mindestens 1 Tag bis vielleicht 1 Woche mehr als angemessen. Insbesondere bei einer Massenaktion mit einem Umfang von mehreren Dutzend Zertifikaten ist mir persönlich nämlich schleierhaft, wie man die Zertifikate im Rahmen von Change-Prozessen derart schnell auf die Produktivserver katapultieren soll.
Wenn man nochmal 30 Sekunden drüber nachdenkt, kommt man übrigens zur Erkenntnis, daß es auch mit einem einzigen Zertifikat kaum sauber hinzubekommen ist. Auf einer hochgradig produktiven SSL-Site muß man, wenn die CA einen OCSP Distribution Point bereitstellt, in Zukunft auf den Re-Issue verzichten und additiv ein neues Zertifikat dazukaufen, um es überhaupt ohne Ausfall tauschen zu können. Ob das wirklich im Sinne des Erfinders ist?
Verlautbarung von heute an einen Kunden, der SGC-Zertifikate einsetzen will, um möglichst lückenlos alle Browser zu unterstützen:
“Vom Einsatz von Step-Up/SGC-Zertifikaten, die die Verwendung von Browsern ermöglichen, die der vor dem Jahr 2000 gültigen Exportbeschränkung der USA unterliegen, wird abgeraten. Es wird empfohlen, die Unterstützung veralteter Browser, für die keinerlei Updates mehr verfügbar sind, aus Sicherheitsgründen einzustellen.”
Mit den SGC-Zertifikaten (“Server Gated Cryptography“), je nach Marketingmasche auch “Step-Up” genannt, ist das so: Bis Anfang 2000 gab es seitens der USA diese beschränkte Exportbeschränkung, nach der “starke” Verschlüsselung als Kriegswaffe zu behandeln war und deshalb nur unter strengsten Auflagen aus den USA ausgeführt werden durfte. Nun kamen aber alle halbwegs relevanten Web-Browser aus USA (Netscape, Internet Explorer). Wegen der Ausfuhrbeschränkung war in diesen die Schlüssellänge für SSL auf 40 Bit begrenzt. Weil man aber auch schon in den 1990ern Knete mit E-Business machen wollte, gab es verschiedene CAs, die mit Segen der US-Regierung für Banken & Co. Zertifikate ausstellten, bei deren Anblick der Browser seine Exportbeschränkung vergaß und auf 128 Bit Schlüssellänge umschaltete. Das war dann die “Step-Up”-Security.
Die Exportbeschränkung ist 2000 gefallen, aber die CAs bieten die SGC-Zertifikate noch immer an und lassen sie sich fürstlich bezahlen. Thawte nimmt für ein Jahr Laufzeit z.B. lässige 699 US-Dollar und haut mächtig auf die Sahne:
Provide the best encryption available for each site visitor. Without an SGC-enabled certificate on your site, your visitors using certain older browsers and many Windows 2000 users will only receive 40- or 56-bit encryption.
Ich halte ja nicht extrem viel von diesem hysterischen Getue, nach dem jedes irgendwo greifbare Security-Update sofort installiert werden muß, auch wenn es für einen obskuren Teil des Betriebssystems gilt, den man im ganzen Leben noch nicht benutzt hat. Hier geht es nun aber um Web-Browser und somit um die Killerapplikation der letzten Dekade. Wer SGC einsetzt, unterstützt aktiv folgende Browserversionen:
Als gut abgehangener Linux-User bin ich es ja gewohnt, jahrelang aktiv von irgendwelchen Webseiten ausgesperrt worden zu sein. Solche Unverschämtheiten vergißt man nicht. In diesem Fall ist es allerdings mehr als angebracht, die eigenen Kunden vorm Gebrauch dieser antiken Exploit-Schleudern zu schützen.
Ich mußte mich da auch erstmal reinlesen, da ich mich nicht erinnern kann, selbst Erfahrungen damit gesammelt zu haben, abgesehen von einem total inoffizellen Patch für den Netscape Navigator, mit dem man diese Exportgeschichte irgendwie global abschalten konnte.
Der Kunde von oben zeigt auf seiner Homepage übrigens ein Flash-Video an und weist ausdrücklich darauf hin, daß die Seite nur mit IE ab Version 6, Netscape ab Version 6 oder Mozilla ab Version 1.0 benutzbar ist. Das ist dann der Punkt, an dem die Sache ins Absurde übergeht. 
Das audit-ssl-Script (.tar.gz) ist funktional in der Lage, Seiten mit angreifbaren SSL-Zertifikaten zu erkennen. Komfortabler und plattformübergreifend tut es aber die SSL Blacklist Extension für den Firefox:
Auch zu empfehlen als kleiner Warnschuß an Anwender, die sich weigern, Zertifikate auszutauschen: “Firefox zeigt bereits eine Warnmeldung an. Was wirst Du Deinen Kunden erzählen, wenn der Internet Explorer das nach dem nächsten Microsoft-Patchday ebenfalls macht?”
Der 13. Mai hat mein ohnehin schon verpfuschtes Leben in eine verdammte Hölle aus Zertifikaten, Keys und Certificate Signing Requests verwandelt. Und dann heute mal was neues: Beim Kunden wollte ein Webserver mit einem der von der CA neu ausgestellten Zertifikate nicht mehr starten. Key und Zertifikat paßten nicht zusammen.
Wie man ermitteln kann, ob ein Zertifikat zum CSR paßt, klingt z.B. hier oder in der Apache-FAQ an:
# openssl x509 -in example.com-cert.pem -noout -modulus | openssl sha1
5ba93c9db0cff93f52b521d7420e43f6eda2784f
# openssl req -in example.com-req.pem -noout -modulus | openssl sha1
5ba93c9db0cff93f52b521d7420e43f6eda2784f
So ließ sich dann recht einfach ermitteln, daß die CA tatsächlich nicht den neuen, sondern einen dort gespeicherten alten Certificate Signing Request für die Neuausstellung des Zertifikats benutzt hatte. Worauf dann unmittelbar die Frage folgte, ob davon vielleicht auch noch andere der 50 neu ausgestellten Zertifikate betroffen sein könnten.
Also mußte ein Script her, das weniger sperrig war als die o.g. OpenSSL-Aufrufe, und dem man vorzugsweise nicht sagen muß, um was es sich bei der jeweils präsentierten Datei handelt:
#!/bin/sh
# Script: ssl_matchchk
for i in "$@"
do
openssl x509 -in $i -noout >/dev/null 2>&1 &&
echo `openssl x509 -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
openssl req -in $i -noout >/dev/null 2>&1 &&
echo `openssl req -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
openssl rsa -in $i -noout >/dev/null 2>&1 &&
echo `openssl rsa -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
done
Mit diesem Script, dem es zugegebenermaßen an einer sauberen Fehlerbehandlung fehlt, und mit einem kleinen weiteren Shell-Einzeiler ließ sich dann relativ flott sicherstellen, daß nur ein einziges Zertifikat von einer solchen Verwechslung betroffen war. Schwein gehabt.
Wenn man jemandem ins Pflichtenheft geschrieben hat, daß seine Software unter der Last von 10.000 PGP-Keys nicht schwächeln darf, muß man irgendwann auch mal ins kalte Wasser springen und tatsächlich 10.000 Keys generieren:
#!/bin/sh -e
export LANG=C
for I in `seq 1 10000`
do
NUMBER=`printf "%5.5d\n" $I`
USERNAME="Testuser #$NUMBER"
COMMENT="auto-generated key"
EMAIL="testuser-$NUMBER@pgp-loadtest.example.com"
(
cat <<EOF
%echo Generating Key for $EMAIL
Key-Type: DSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: $USERNAME
Name-Comment: $COMMENT
Name-Email: $EMAIL
Expire-Date: 2009-01-01
Passphrase: foo
%commit
EOF
) | gpg --gen-key --batch --no-default-keyring \
--secret-keyring /var/tmp/gpg-test.sec \
--keyring /var/tmp/gpg-test.pub
done
Die schlechte Nachricht: Spätestens nach dem dritten Key wird GnuPG eine Pause einlegen, weil der Entropie-Pool ausgelutscht ist. Ich habe meine Lösung für dieses Problem gefunden, indem ich (und das ist wirklich sehr, sehr böse, bitte auf keinen Fall zuhause nachmachen) /dev/urandom zu /dev/random umgelötet habe. Kreative alternative Lösungsvorschläge für das schmutzige kleine Entropie-Problem werden auf jeden Fall gern entgegengenommen.
Oh weh. Vorgestern glaubte ich noch, ich sei auf der sicheren Seite. Gestern fiel mir dann der Kunde ein, der Kommerzzertifikate im Gesamtwert von ca. 10.000 Euro auf einer Debian-Gurke generiert und verteilt hat. Gleich geht’s hin. Die Begeisterungsstürme werden gewaltig sein.
Aus dem Ding kommt Debian so schnell nicht raus. Nach dem allgemeinen Security-Debakel von vor drei Jahren ist man, nüchtern betrachtet, auch nicht gut damit beraten, Debian noch immer die Treue zu halten.
Der Amerikaner bemüht gern ein angeblich chinesisches Sprichwort: “Fool me once, shame on you. Fool me twice, shame on me.” – Dem ist in diesem Fall nichts hinzuzufügen.
Bei mir kam gerade das Gerücht vorbei, es solle heute bei Debian ein Announcement hinsichtlich eines nur relativ aufwändig zu fixenden Sicherheitsproblems durchkommen. Ich selbst habe derzeit kein Debian am Internet. Nur ein internes System, das per Jumpserver erreicht wird. Wer Debian am Start hat, sollte heute wohl besser Augen und Ohren offenhalten und den Nachmittag nicht zu straff durchplanen.
Update, 15:00, da isses:
------------------------------------------------------------------------ Debian Security Advisory DSA-1571-1 security@debian.org http://www.debian.org/security/ Florian Weimer May 13, 2008 http://www.debian.org/security/faq ------------------------------------------------------------------------ Package : openssl Vulnerability : predictable random number generator Problem type : remote Debian-specific: yes CVE Id(s) : CVE-2008-0166 Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable. This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them. It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation. The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected. Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though. A detector for known weak key material will be published at: (OpenPGP signature) Instructions how to implement key rollover for various packages will be published at: This web site will be continously updated to reflect new and updated instructions on key rollovers for packages using SSL certificates. Popular packages not affected will also be listed. In addition to this critical change, two other vulnerabilities have been fixed in the openssl package which were originally scheduled for release with the next etch point release: OpenSSL's DTLS (Datagram TLS, basically "SSL over UDP") implementation did not actually implement the DTLS specification, but a potentially much weaker protocol, and contained a vulnerability permitting arbitrary code execution (CVE-2007-4995). A side channel attack in the integer multiplication routines is also addressed (CVE-2007-3108). For the stable distribution (etch), these problems have been fixed in version 0.9.8c-4etch3. For the unstable distribution (sid) and the testing distribution (lenny), these problems have been fixed in version 0.9.8g-9. We recommend that you upgrade your openssl package and subsequently regenerate any cryptographic material, as outlined above. [...]
Betroffen sind also alle SSH-Keys (Host und Identity), und alle X.509-/SSL-Zertifikate, egal ob Server-, Client- oder CA-Zertifikat, die auf einem Debian-System erstellt wurden. Nur GnuPG ist sauber, da man sich dort nicht auf fremde Crypto-Libs verläßt.
Das riecht nach richtig viel Arbeit, Leute. 
$KUNDE hielt heute mit der Freitagnachmittags-Bierflasche in der Hand eine bewegende Rede ans Volk, an deren Rande er betonte, daß er jedem aus seiner bunten Beratertruppe, der sich auf “Hackerkongressen” aufhält, während gegen seine Infrastruktur irgendwelche Angriffe gefahren werden, auf der Stelle Hausverbot erteilen wird.
Später habe ich dann erfahren, daß ein ehemaliger freier Mitarbeiter des Ladens, kein pickliger Jüngling, sondern ein Kollege im gestandenen Mannesalter (ich durfte ihn vor seinem Abschied noch kurz kennenlernen), es tatsächlich geschafft hat, mit seinem Insiderwissen vom 24. Chaos Communication Congress aus eine Webserverfarm des Kunden auszuknipsen, für deren Inbetriebnahme er zuständig gewesen war. Daraufhin kam die Welt zum Stillstand und wegen der Urlaubssaison war niemand zu erreichen, so daß die Website einen Tag lang offline war. Der Experte, der am meisten über die Serverfarm wußte und sie wieder auf die Beine hätte stellen können, war der Angreifer ja immerhin selbst, und der weilte auf Urlaub in Berlin.
Anschließend hat er alles zugegeben, als “Penetration Test” deklariert und zu seiner Verteidigung vorgebracht, daß der dämliche ISP des Kunden überreagiert habe und das alles doch nur Spaß und Spiel war. (Die Story ist plausibel und ich hatte sie bereits aus anderer Richtung schonmal so ähnlich gehört.)
Oh, verdammt.
1) Hat er als Insider das Vertrauen seiner Kundschaft nicht nur mißbraucht, sondern diese auch noch vorsätzlich geschädigt.
2) Wie das technisch aussah, spielt dabei eigentlich keine Rolle. Wenn er Sicherheitsprobleme kennt, sollte er sie nicht exploiten, sondern fixen. Das ist seine Pflicht.
3) Ist der CCC, der noch nie ein “Chaos-Club” war und sich derzeit notgedrungen vom “Computer-Club” zur techniklastigen Bürgerrechtsorganisation umzubauen scheint, in den Augen dieses Kunden eine kriminelle Chaosgruppe. Wie aus dem dümmsten Klischeebaukasten der Achtziger, und das auch noch verständlicherweise.
4) Hat er dafür gesorgt, daß Personen aus dem CCC-Umfeld bei diesem Kunden nun unter Generalverdacht stehen.
Das schlimme ist nicht, daß er das ganze rumerzählt hat, sondern das schlimme ist, daß er es getan hat. Wirklich eine grandiose Leistung. Eines Hackers ist das nicht würdig.
Over at Denny, I discovered that OpenSSH, since version 4.8, supports chrooted SFTP operation. This is, of course, a feature that many of us have been waiting for, so I immediately gave it a try, using a somewhat adventurous manually compiled OpenSSH on CentOS 5. (Update, February 27, 2009: See Packaging OpenSSH on CentOS for a more coherent installation method.) I also had a little help from the Debian Administration Blog.
In order to enable chrooted SFTP for some users, we’ll first create a separate group for users that will get the chroot treatment. I named this group chrooted, for no obvious reason. This group will be assigned as a supplementary group for chroot users.
The common application for this will be virtual WWW hosting, so I started with the assumption that a website called www.example.com will be accessed by SFTP. The directory /vhost/www.example.com will therefore serve as the user’s home directory. In order to make chrooting work along with key-based authentication, I found that it neccessary to make the user name and the name of his home directory identical, so the user was named www.example.com as well (login shell: /bin/false), along with a similar user private group www.example.com. This looks as if it may have a tendency to get awkward, but it really only is a first test. I’ll have to invest a bit more thought before this goes into production.
The directory /vhost/www.example.com was created and populated like this:
drwxr-xr-x 5 root root 4096 Apr 5 22:01 .
drwxr-xr-x 3 root root 4096 Apr 5 21:22 ..
drwxrwxr-x 2 www.example.com www.example.com 4096 Apr 6 08:45 htdocs
drwxr-xr-x 2 root root 4096 Apr 5 21:22 logs
drwxr-xr-x 2 www.example.com www.example.com 4096 Apr 5 22:02 .sshWith the user created and his directory populated, we’ll now edit sshd_config as follows:
#Replace the OpenSSH sftp-server backend with its internal SFTP engine:
#Subsystem sftp /opt/openssh/libexec/sftp-server
Subsystem sftp internal-sftp
# Configure special treatment of members of the group chrooted:
Match group chrooted
# chroot members into this directory
# %u gets substituted with the user name:
ChrootDirectory /vhost/%u
X11Forwarding no
AllowTcpForwarding no
# Force the internal SFTP engine upon them:
ForceCommand internal-sftpI actually had a quite hard time figuring out the proper constellation of user name, user home directory and ChrootDirectory. ChrootDirectory applies after the user has been authenticated. Before that, his home directory from /etc/passwd still applies. In order to enable the user to maintain his SSH key and to enable sshd to find the key, both environments must be congruent. However, the chroot destination must not be owned by the user for security reasons; the user’s home directory therefore belongs to root. Tricky, isn’t it? I must admit, though, that this would have been a lot more intuitive if I hadn’t strayed away from /home on the very first test. Doh! 
Here’s a sample session with the user “www.example.com”, authenticated by public key:
$ sftp www.example.com@192.168.1.24
Connecting to 192.168.1.24...
sftp> ls -la
drwxr-xr-x 5 0 0 4096 Apr 5 20:01 .
drwxr-xr-x 5 0 0 4096 Apr 5 20:01 ..
drwxr-xr-x 2 59984 59984 4096 Apr 5 20:02 .ssh
drwxrwxr-x 2 59984 59984 4096 Apr 6 07:32 htdocs
drwxr-xr-x 2 0 0 4096 Apr 5 19:22 logs
sftp> pwd
Remote working directory: /
sftp> cd ..
sftp> ls -la
drwxr-xr-x 5 0 0 4096 Apr 5 20:01 .
drwxr-xr-x 5 0 0 4096 Apr 5 20:01 ..
drwxr-xr-x 2 59984 59984 4096 Apr 5 20:02 .ssh
drwxrwxr-x 2 59984 59984 4096 Apr 6 07:32 htdocs
drwxr-xr-x 2 0 0 4096 Apr 5 19:22 logs
sftp> pwd
Remote working directory: /
sftp> ls -la .ssh
drwxr-xr-x 2 59984 59984 4096 Apr 5 20:02 .
drwxr-xr-x 5 0 0 4096 Apr 5 20:01 ..
-r-------- 1 59984 59984 601 Apr 5 20:02 authorized_keys
sftp> byePay attention to the UIDs, 0 and 59984: The SFTP subsystem, running under chroot, doesn't have access to /etc/passwd from the user's environment.
I am convinced that this is the most important update to OpenSSH for at least the past five years. This has the opportunity to entirely eradicate authenticated FTP from the internet, just as it has already happened with Telnet.
Thanks a lot to the OpenSSH developers for making this happen!
Theme: Shocking Blue Green. Blog at WordPress.com.
