Tech-Nerds » Sicherheit

Sicherheitslücke in iTunes und iPhone

Marc — Thu, 24 Sep 2009 02:41:11 +0000

Eine Sicherheitslücke in Apples iTunes, sowie dem iPhone, ermöglicht es, beliebigen Code auf dem Gerät auszuführen.

Verantwortlich hierfür ist ein Buffer Overflow, der beim Abspielen manipulierter MP3- und AAC-Dateien auftritt.

In der jeweils neuesten Software-Version soll die Schwachstelle beseeitigt sein. Unterdessen meldet Secunia, dass iTunes ebenfalls mit Playlistdateien angreifbar ist. Auch hier kann beliebiger Code durch einen Buffer Overflow ausgeführt werden.

Sicherheitslücke in wget

Marc — Wed, 02 Sep 2009 06:21:42 +0000

Nachdem die von Moxie Marlinspike entdeckte SSL-Sicherheitslücke in allen gängigen Browsern gepatcht wurde, hat nun Secunia eben diese Lücke auch in wget gefunden. Auch hier werden Teile von Domainnamen hinter einem Null-Zeichen ignoriert.

Ein Update von wget ist bisher nicht erschienen, soll aber in Arbeit sein.

WPA-Verschlüsselung angreifbar

Marc — Thu, 27 Aug 2009 22:04:03 +0000

Forschern der Universtität von Kobe in Japan soll es gelungen sein, die in WLAN häufig eingesetzte WPA-Verschlüsselung zu brechen. Der Angriff auf ein WLAN, welches mittels WPA mit TKIP-Algorithmus gesichert ist, soll nur rund eine Minute dauern. An der Universität von Hiroshima sollen im Rahmen einer Konferenz am 25. September weitere Details bekannt gegeben werden.

Bereits vor einigen Monaten war es gelungen, WPA mit TKIP innerhalb von 12-15 Minuten erfolgreich anzugreifen. Allerdings funktionierte diese Vorgehensweise nur mit einer begrenzten Reihe von Geräten.

Nicht betroffen von den erfolgreichen Angriffen sind RSN(WPA2)- und WPA-verschlüsselte Netzwerke mit AES-Algorithmus. Die meisten Router erlauben einen Mischbetrieb beider Algorithmen im WPA-Modus. RSN unterstützt generell nur AES.

Update:
Golem.de hat inzwischen auch etwas dazu.

DKIM mit Postfix und Spamassassin

Marc — Thu, 20 Aug 2009 17:24:04 +0000

DKIM als Authentifizierungsmechanismus für E-Mails ist ein Zusammenspiel von DNS, MTA und Spam-Filter. Der versendende Mailserver versieht den Header ausgehender Mails mit einer Signatur (Private Key), welche der empfangende MTA anhand eines speziellen DNS TXT-RR (Public Key) verifizieren kann.

Mag kompliziert klingen, ist aber eigentlich ganz einfach umzusetzen, wie das folgende Beispiel auf einem Debian Lenny-Server mit Postfix, BIND und Spamassassin belegen soll. Vorausgesetzt wird hierbei, dass die drei genannten Dienste bereits im Normalbetrieb funktionieren.

Als Erstes muss das Schlüsselpaar erstellt werden. Dies geschieht mit den folgenden Kommandos:
openssl genrsa -out .private 1024 openssl rsa -in .private -out \ .public -pubout -outform PEM

Die Schlüsselstärke von 1024 Bit ist die Minimalanforderung von DKIM, ein längerer Private Key hätte aber naturgemäß auch einen längeren Public Key zu Folge, und hier spielt BIND dann aufgrund einer begrenzten Größe des TXT-RR nicht mehr mit.

Nun kann der Public Key per DNS bekannt gemacht werden. Da dies ohne Zeilenumbrüche geschehen muss, werden eben diese kurzerhand ignoriert:
cat .public | tr -d "\n"

Der reine Schlüssel (ohne Header) kann jetzt in die Zonendatei der Domain kopiert werden, die mit DKIM ausgestattet werden soll. Hierfür wird die spezielle Subdomain ._domainkey verwendet. Ein kompletter TXT-RR für DKIM kann wie folgt aussehen:

mail2009._domainkey IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADC (gekürzt)"

Es macht Sinn, den Schlüssel regelmäßig auszutauschen und dies auch im DNS zu dokumentieren. Statt den alten Schlüssel einfach zu löschen, wird er widerrufen. Einer entsprechender Eintrag im TXT-RR sieht dann so aus: "v=DKIM1\; k=rsa\; p="

Auf dem System kann nun das Paket dkim-filter installiert werden. Dies ist in den Repositories von Debian vorhanden und kann somit per apt installiert werden. Die Konfigurationsdateien sollten in etwa folgendermaßen modifiziert werden (meine Konfiguration ist auch auf dem Gopher zu finden):

/etc/default/dkim-filter: SOCKET="inet:8891@127.0.0.1"

/etc/dkim-keys.conf: *domain.tld:domain.tld:/etc/mail/dkim/mail2009
(eine Zeile für jede Domain)

/etc/dkim-filter.conf: Syslog yes UMask 002 Background yes SubDomains yes KeyList /etc/dkim-keys.conf RequiredHeaders yes OmitHeaders Return-Path,Received,Comments,Keywords,Bcc,Resent-Bcc

Außerdem muss die Postfix-Konfiguration noch modifiziert werden:

/etc/postfix/main.cf (...) smtpd_milters = inet:localhost:8891

Nach dem Restart der Dienste dkim-filter und postfix kann das System bereits für ausgehende Mails genutzt werden. Ob alles funktioniert, kann mit einer Testmail an check-auth@verifier.port25.com überprüft werden. Nach kurzer Zeit erhält man eine Mail mit einem detaillierten Bericht.

Für die DKIM-Integration in Spamassassin wird nun noch das Paket libmail-dkim-perl benötigt und anschließend die Konfiguration angepasst.

/etc/spamassassin/v320.pre: loadplugin Mail::SpamAssassin::Plugin::DKIM

/etc/spamassassin/local.cf: whitelist_from_dkim *@googlemail.com googlemail.com score USER_IN_DKIM_WHITELIST -10.0 score DKIM_VERIFIED -5.0 score DKIM_POLICY_TESTING 0

Die Score-Werte in der local.cf können natürlich angepasst werden. Evtl. ist hier ein wenig Testen erforderlich.

SSL-Zertifikate bei vielen CA manipulierbar

Marc — Thu, 30 Jul 2009 13:47:34 +0000

Moxie Marlinspike hat in seinem Vortrag auf der Black Hat in Las Vegas eine Möglichkeit aufgezeigt, SSL-Zertifikate für beliebige Domains zu fälschen.

Viele Certificate Authorities lassen es demnach zu, vor dem gültigen Domainnamen das Null-Zeichen ‘\0′ und wiederum davor einen beliebigen anderen Doaminnamen zu setzen, welcher dann als Subdomain behandelt wird. Im genannten Beispiel mit Marlinspikes eigener Domain thoughtcrime.org sah das so aus: www.paypal.com\0.thoughtcrime.org

Das eigentliche, gefährliche Fehlverhalten zeigen nun alle verbreiteten Browser (mit Ausnahme des aktuellen Firefox 3.5). Diese interpretieren das Zeichen ‘\0′ als Stoppzeichen. Folglich wird das Zertifikat im o.g. Beispiel für die Domain www.paypal.com als gütig interpretiert.

Firefox 3.5 erkennt die so manipulierten Zertifikate als ungültig. Für den Internet Explorer soll ein Patch in Arbeit sein.

Slowloris fail2ban

Marc — Sun, 21 Jun 2009 11:39:48 +0000

Wie bereits beschrieben, existiert bisher keine wirksame Möglichkeit, einen Apache-Server vor einem Angriff mit Slowloris zu schützen.

Ein Ansatz ist sicherlich, die IP des Angreifers zu sperren. Also im Prinzip die Funktionsweise des Tools fail2ban.

Ich habe ein kleines Script gebastelt, welches den Apache-Errorlog auf Einträge durchsucht, die auf einen Angriff mit Slowloris hindeuten und dann die entsprechenden IP-Adressen per iptables sperrt. Um den Angreifer nicht ewig zu sperren, sollte der Apache-Errorlog natürlich relativ häufig rotieren.

Beide Dateien habe ich auf dem Gopher zugänglich gemacht. Die Firewall-Regeln müssen ggf. angepasst werden (Flush beachten).

DNSSEC mit BIND9

Marc — Wed, 10 Jun 2009 23:00:59 +0000

Da die Verwendung von DNSSEC für die Root-Zone ja momentan heiß diskutiert wird, habe ich mir mal angesehen, wie ich denn meinem DNS-Resolver (BIND9) DNSSEC beibringe.

DNSSEC funktioniert, um es mal ganz grob zu umschreiben, mit zwei Schlüsselpaaren. Einem zone-signing-keypair (ZSK) und einem key-signing-keypair (KSK). Hiervon wird jeweils der öffentliche Schlüssel dem Resolver (aka Client) bekannt gemacht, indem dieser in das Zonefile auf einem DNS-Master integriert wird (hierzu später mehr).

Um das Ganze dann auch wirklich sicher zu machen, wird vom DNS-Resolver die trust-chain in der DNS-Hierarchie "nach oben" aufgelöst. So sucht der Resolver beim Auflösen einer DE-Domain nach den Schlüsseln für die Zone DE und danach für die Root-Zone "."

Klingt erstmal schlüssig. Nur sind weder DE-, noch Root-Zone mit entsprechenden Schlüsselpaaren signiert. Bis jetzt sind dies nur eine handvoll TLDs. Darunter .se, .pl, .gov, .museum und einige weitere. Um dennoch eine trust-chain zu schaffen, gibt es DLV (DNSSEC lookaside validation). Geht es in der normalen DNS-Hierarchie mit der trust-chain nicht weiter, versucht der DNS-Resolver per DLV einen trust-anchor zu finden.

In BIND9 (ab Version 9.3.3) wird das Ganze dann folgendermaßen implementiert (Dateinamen entsprechen Debian-Standardkonfiguration):

Zunächst den public key der ISC herunterladen, ggf. per wget. Ich habe diesen Key dann übersichtshalber in die Datei /etc/bind/named.conf.keys gespeichert. In der /etc/bind/named.conf.options werden dann folgende Zeilen hinzugefügt:
dnssec-enable yes; dnssec-validation yes; dnssec-lookaside . trust-anchor dlv.isc.org.;

Natürlich muss dem BIND noch der public key der ISC bekannt gemacht werden. Und zwar durch folgende Zeile in der /etc/bind/named.conf:
include "/etc/namedb/named.conf.keys";

Nach einem BIND-restart kann nun per dig +dnssec iks-jena.de soa, bzw. dig iks-jena.de soa getestet werden, ob der Resolver DNSSEC spricht. Wird dig die Option +dnssec mitgegeben, sollten RRSIG-resource records ausgegeben werden.

Apache2 mit mehreren SSL-VirtualHosts

Marc — Fri, 06 Feb 2009 16:05:09 +0000

Wer mehrere Domains auf einem Webserver betreibt, wird möglicherweise den Wunsch haben, hier verschiedene SSL-Zertifikate für die jeweiligen Domains zu installieren. Allerdings kann der Server erst nach dem SSL-Handshake entscheiden, welchen Host der Browser angefragt hat.

Abhilfe schafft das die TSL-Erweiterung SNI (Server Name Indication). Unterstützt wird diese doch recht sinnvolle Neuerung aber bisher nur von gnutls. Die Installation auf einem Debian-Server wird hier kurz beschrieben und sollte auch auf anderen Systemen mit geringen Anpassungen machbar sein.

Als Allererstes steht die Installation des Pakets apache2-threaded-dev auf dem Programm (sofern noch nicht geschehen). Dann wird die aktuelle gnutls-Version benötigt. Und zwar von gnu.org. Herunterladen, entpacken, konfigurieren, kompilieren, installieren kennt man ja. Dann benötigen div. Systeme noch einen Aufruf von ldconfig. Anschließend kann dann bereits das Apache-Modul heruntergeladen und installiert werden. Zu bekommen ist es hier.
Die Installationsprozedur verläft hier auch unspektakulär normal. Ich musste configure allerdings den Pfad von apxs2 mitgeben:
./configure --with.apxs2=/usr/bin/apxs2

make install
kopiert das Apache-Modul dann (hoffentlich) an die richtige Stelle. In diesem Fall /usr/lib/apache2/modules

Die Datei /etc/apache2/mods-enabled/gnutls.load wird nun mit folgendem Inhalt erstellt: LoadModule gnutls_module /usr/lib/apache2/modules/mod_gnutls.so
Und auch die Datei /etc/apache2/mods-enabled/gnutls.conf muss erstellt werden. Sie sollte Folgendes enthalten:
GnuTLSCache dbm /var/cache/mod_gnutls_cache GnuTLSCacheTimeout 300

Natürlich müssen die virtuellen Hosts noch angepasst werden. Jeder vHost, der SSL verwenden soll, benötigt folgende Zeilen:
ServerName www.example.de GnuTLSEnable on GnuTLSPriorities NORMAL GnuTLSCertificateFile /etc/certs/example_server.pem GnuTLSKeyFile /etc/certs/example_key.pem DocumentRoot "/var/www/example.de" ...


Die möglicherweise bisher vorhandenen Zeilen, beginnend mit SSL, müssen selbstverständlich den neuen Angaben weichen.
Achtung: Die VirtualHosts-Direktiven müssen mit IP-Adresse definiert werden. Ggf. werden also für ein DocumentRoot 2 Einträge erstellt, beispielsweise bei paralleler Verwendung von IPv4 & IPv6.



Mails verschlüsseln mit GnuPG
Marc — Wed, 10 Dec 2008 22:58:58 +0000
Zwar gehe ich nicht unbedingt davon aus, dass das BKA oder sonstirgendwer bewusst meine Mails mitliest, aber man weiß ja nicht, ob der Empfänger einer Mail nicht möglicherweise von solchen Maßnahmen betroffen ist. Und aus diesem Grund habe ich mich nun ein wenig mit dem Ver- und Entschlüsseln von Mails per GnuPG beschäftigt.
Zu aller erst benötigt man ein eigenes Schlüsselpaar. Dieses besteht aus einem privaten und einem öffentlichen Schlüssel. Eine kurze, aber verständige Anleitung zur Erstellung findet sich im Wiki des CCC Mainz.
Um eine verschlüsselte und signierte Mail versenden zu können, benötigt man außerdem den öffentlichen Schlüssel des Empfängern. Und genauso benötigt der Empfänger den öffentlichen Schlüssel des Absenders, um die Mail entschlüsseln zu können.
Zahlreiche Mailprogramme bieten native Unerstützung für GnuPG/PGP. Für die meisten anderen gibt es entsprechende Plugins.
Um die Schlüssel nicht immer manuell austauschen zu müssen, gibt es öffentliche Keyserver, auf denen man in aller Regel fündig wird (vorausgesetzt natürlich, der Mensch auf der Gegenseite hat seinen Schlüssel veröffentlicht).
Um besser einschätzen zu können, ob man veröffentlichten Schlüsseln vertrauen kann, gibt es das GnuPG-Web of Trust. Die Idee basiert auf der Signierung des eigenen Schlüssels durch Personen, die einem (möglichst persönlich) bekannt sind. Wie dies technisch umgesetzt ist, kann im Ubuntu-Users Wiki nachgelesen werden.



SSL-Zertifikate in Symbian
Marc — Mon, 08 Dec 2008 23:48:06 +0000
Die Aktualisierung meiner SSL-Zertifikate auf dem Mailserver stand an. Mithilfe von CAcert war dies auch schnell erledigt.
Zu besagtem Anbieter lassen sich im Internet eigentlich alle notwendigen Informationen finden, darum gehe ich hier nicht weiter auf die Prozedur ein.
Eher wenige Informationen finden sich dagegen zum Import von Root-Zertifikaten auf Geräten mit Symbian-Betriebssystem. Dies ist nämlich nicht so ohne Weiteres machbar, wie ich feststellen musste. Und die CAcert Root-Zertifikate sind, wie auf den meisten anderen Systemen auch, nicht von vornherein enthalten. Somit erhält man bei jedem Verbinden mit dem Server eine Warnmeldung, die eine manuelle Bestätigung erfordert. Und das nervt auf Dauer wirklich.
Ein Download des Root-Zertifikats, in jeglichen zur Verfügung stehenden Formaten, mit anschließender Installation per Browser funktioniert jedenfalls nicht. Und dies ist auch unabhängig vom verwendeten Browser. Meine Hoffnung stützte sich zunächst auf den standardmäßig mitgebrachten Browser meines Nokia E65. Hier schlug der Import des Zertfikats aber genau so fehlt, wie mit Opera oder Skyfire. Das Gerät behauptete, obwohl offensichtlich unwahr, das Zertifikat wäre ungültig.
Die Lösung war allerdings einfacher, als man nun annehmen sollte. Das Zertifikat muss im DER-Format einfach im Telefonspeicher oder – Präsenz vorausgesetzt – der Speicherkarte abgelegt werden. Schon hierfür wird allerdings ein Alternativbrowser benötigt, da der Standardbrowser die Option, Daten einfach nur zu speichern, nicht kennt.
Mit dem Dateimanager (Office -> Dateimanager) kann man dann die abgelegte Datei öffnen; danach wird das Root-Zertifikat installiert. Nachfolgend akzeptieren alle Anwendungen dieses Zertifikat und Verbindungen zum Server werden ohne Notwendigkeit weiterer Interaktion hergestellt.