#!/bin/blog

October 10, 2008

Untote Exploits

Filed under: Security, UNIX & Linux — Tags: , , , — martin @ 5:55 am

Jahrelang habe ich auf dem K. herumgehackt, weil “sein” IPS immer Verbindungen unterbrochen hat, nachdem es Bytefolgen auf der Leitung gesehen hatte, mit denen man vor etlichen Jahren mal irgendwelche archaischen Exploits (konkret erlebtes Beispiel: Sendmail decode vulnerability) triggern konnte. Denn mal ehrlich: Wie obskur kann’s noch werden?

Heute bin ich in gewisser Weise einen Schritt weiter, denn bei einem Kunden wurde ein SLES9 aus dem Internet gecrackt, weil der Angreifer sich über einen PHP-Exploit die /etc/passwd herunterladen konnte und darin Passwort-Hashes vorgefunden hat, die ein Administrator beim Anlegen von Usern per Copy&Paste dort eingebaut hat. Die hat er dann auf dem üblichen Weg mit etwas Geduld per Brute-Force geknackt. Ein Szenario aus den 1980ern. Ekelhaft.

Advertisements

August 24, 2008

Port 80 und 443 unter Windows Vista

Filed under: Security — Tags: , — martin @ 8:19 am

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!™

July 10, 2008

Verisign und OCSP

Filed under: Security — Tags: , , , , — martin @ 9:36 pm

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?

July 2, 2008

SGC(“Step-Up”)-Zertifikate

Filed under: Security — Tags: — martin @ 10:12 pm

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:

  • Internet Explorer 5 (Aktuelle Version: 7)
  • Netscape 4 (Aktuelle Version: 9, Entwicklung ist eingestellt)
  • Opera 3 (Aktuelle Version: 9)

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. 😉

June 21, 2008

Surfin’ the post 5/13 world.

Filed under: Security — Tags: , , , — martin @ 11:27 pm

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?”

June 4, 2008

OpenSSL: Key, CSR und Zertifikat auf Übereinstimmung prüfen

Filed under: Security — Tags: , — martin @ 6:17 pm

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. 😉

June 3, 2008

Massengenerierung von PGP-Schlüsseln

Filed under: Security — Tags: , , , — martin @ 4:50 pm

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.

May 15, 2008

Wenn der Glaube schwindet

Filed under: Security, UNIX & Linux — Tags: — martin @ 5:48 am

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.

May 13, 2008

Das jüngste Gerücht

Filed under: Security — Tags: — martin @ 5:50 am

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. 😦

April 18, 2008

Der Inside-Job

Filed under: Security — Tags: , — martin @ 10:06 pm

$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.

« Newer PostsOlder Posts »

Create a free website or blog at WordPress.com.