Archiv für ‘Sicherheit’

Sicherheitslücke in iTunes und iPhone

24. September 2009 04:41 | Autor: Marc | Keine Kommentare | Kategorie(n): Mobile Kommunikation, Sicherheit

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

2. September 2009 08:21 | Autor: Marc | Keine Kommentare | Kategorie(n): Sicherheit

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

28. August 2009 00:04 | Autor: Marc | Keine Kommentare | Kategorie(n): Netzwerke, Sicherheit

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

20. August 2009 19:24 | Autor: Marc | 3 Kommentare | Kategorie(n): Sicherheit

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 <Schlüsselbez.>.private 1024
openssl rsa -in <Schlüsselbez.>.private -out \
<Schlüsselbez.>.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 <Schlüsselbez.>.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 <Schlüsselbez.>._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

30. Juli 2009 15:47 | Autor: Marc | Keine Kommentare | Kategorie(n): Sicherheit

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

21. Juni 2009 13:39 | Autor: Marc | Keine Kommentare | Kategorie(n): Netzwerke, Sicherheit

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