Ein Aspekt am neuesten VeriSign-Schwachsinn, über den ich erst durch Haiko Hebig gestolpert bin, ist die Mailzustellung für nicht-existente Domains. Hier mal eine Analyse was mit einer nicht existenten Domain passiert:
muenster:~# exim -bt gb@blubberfaselblubb.com gb@blubberfaselblubb.com deliver to gb@blubberfaselblubb.com router = lookuphost, transport = remote_smtp host blubberfaselblubb.com [64.94.110.11]
Eine Mail wird also ganz normal auf den A-Record (den mit dem Wildcard) geschickt. Was passiert dort? Das kann man hier sehen:
telnet blubberfaselblubb.com smtp Trying 64.94.110.11... Connected to sitefinder-idn.verisign.com. Escape character is '^]'. 220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready HELO blubberfaselblubb.com 250 OK MAIL FROM: blah@blubberfaselblubb.com 250 OK RCPT TO: blah@blubberfaselblubb.com 550 User domain does not exist. DATA 250 OK quit 221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host.
Es läuft also ein Mail-Rejector auf der Adresse, der jede Mailzustellung mit 550 - User domain doesn't exist abweist.Etwas Paranoia gefällig? Ja? Ok: es ist trivial, den Mail-Rejector so abzuändern, das er die bei MAIL FROM: gelieferten Absenderadressen der irregeleiteten Mails absammelt und archiviert. Ich sage nicht das VeriSign das macht - aber Wildcard-A-Records an so zentraler Stelle sind ein Missbrauch der darauf wartet zu geschehen ...
Hier gibts den Originalartikel.
Bei Forbes kann jeder dem CEO von VeriSign in einem Poll sagen ob er seinen Job gut oder schlecht macht. Komischerweise steht er ziemlich negativ da. Woran das wohl liegt?
Hier gibts den Originalartikel.
Klasse finde ich seinen Antritt, die Karriere nicht ausklingen zu lassen wie ein Cipollini, sondern so aufzuhören wie er immer bekannt war: als Arbeitstier unter den Radsportlern. Und vielleicht darf er ja nochmal zum Ausklang bei der Rheinland-Pfalz-Rundfahrt zulangen. Zu gönnen wärs ihm.
Bei RADSPORT-NEWS.COM - Nachrichten-Gesamtübersicht gibts den Originalartikel.
Das ist das Schöne an der Debian: die aktualisierten Patches stehen auf http://security.debian.org/ schon zur Verfügung, einfach:
apt-get update apt-get install ssh
und schon ist das System wieder auf dem aktuellsten Stand mit allen Patches. So lob ich mir das.
Apple hat bis jetzt noch keinen Software-Update für OS X veröffentlicht ...
Bei heise online news gibts den Originalartikel.
Mitmachen, Brief generieren und abschicken!
Bei Wortfeld gibts den Originalartikel.
Tja - ich hoffe, das das nicht so implementiert ist, wie Jake Savin das auf der radio-dev Liste angekündigt hatte: http://groups.yahoo.com/group/radio-dev/message/7946
Das Problem: man kann bei Weblogs, die noch keine Kommentarbenachrichtigung haben, recht einfach die Kommentarbenachrichtigung hijacken, auch wenn die Option 2 aus der Mail benutzt wird (Option 1 steht wegen der nicht-Änderbarkeit sowieso nicht zur Debatte).
Das Szenario ist recht einfach: da bei der setPrefs Funktion nicht nur das Passwort mitgeschickt wird (bzw. dessen MD5 Hash), sondern auch alle Daten um einen anderen Server nach der Gültigkeit zu fragen, kann man einfach einen kleinen XMLRPC-Server aufsetzen, der generell "ist ok, Passwort stimmt" zurückliefert. Diesen gibt man dann in den setPrefs Aufrufen mit an als Server, den es zu fragen gilt. Und schon kann man mit einer Schleife mal eben alle numerischen Benutzer auf Userland die Kommentarnachrichten klauen. Klassischer Fall von zu kurz gedacht. Es ist schon erstaunlich wie wenig Leute wirklich bei Security nachdenken, was das letzten Endes bedeutet. Viel zu oft stösst man auf so halbe Lösungen. Klar, Kommentarbenachrichtigungen sind nicht wirklich kritisch. Aber die Funktion, die hier abgesichert werden sollte, heisst ja setPrefs. es ist abzusehen, wann die Programmierer da zusätzliche Einstellungen speichern werden, und wie diese dann auch fremdgesetzt werden können.Wo liegt der Fehler hier jetzt wirklich? In der Kommunikation mit dem Server, das ist klar. Aber der eigentliche Fehler liegt darin, das ein sicherheitsrelevanter Bereich in der Authorisierung mittels eines gekoppelten Systems realisiert wird, bei dem die Koppelung der Systeme durch den Endbenutzer bestimmt wird. Und dieser letzte kleine Teil - durch den Endbenutzer - ist das Problem. Systemkoppelungen in sicherheitsrelevanten Bereichen müssen vom Administrator vorkonfiguriert werden, Benutzer dürfen allenfalls aus Optionen wählen können. Denn nur der Administrator kann festlegen welche Quellen für Authorisierungen vertrauenswürdig sind. Bei Der Schockwellenreiter gibts den Originalartikel.
Noch ein paar weitere Kommentare und Meinungen zu dem VeriSign-Unfug.
Bei heise online news gibts den Originalartikel.