security

Vor ein paar Wochen wurden ja auf mehreren Webseiten in erheblichen Ausmaß Passwörter entwendet. Betroffen waren unter anderem Linkedin und last.fm.

Das sollte man zum Anlass nehmen, sofort seine Passwörter bei diesen Diensten zu ändern. Leider erfährt man auf den Webseiten selber gar nichts von dem Vorfall und wie man darauf reagieren soll. Wenigstens gibt es eine Mitteilungsseite (last.fm, LinkedIn), nur verharmlosen diese den Vorfall und man findet man diese auch nicht auf der Startseite. Mittlerweile hat zumindest last.fm reagiert und E-Mails mit der Aufforderung dass Passwort zu ändern an seine Mitglieder verschickt. Man hätte aber gleich nach dem Vorfall reagieren müssen ohne dass man seine Mitglieder 2 Wochen (oder war es eher 1 Jahr?) in falscher Sicherheit wiegt.

Bei last.fm sollen ja angeblich 17 Millionen Passwörter abhanden gekommen sein (vermutlich bereits letztes Jahr) und bei LinkedIn auch 6.5 Millionen. Das ist ja immerhin mal eine Ansage. Es wäre aber eigentlich mal an der Zeit, dass diese Dienste genauso professionell reagieren, wie sie uns immer glauben lassen.

Möchte man einen PC verschrotten oder muß man mal die Festplatte zur Reparatur schicken (RMA) oder auch verkaufen, dann sollte man dafür sorgen, dass eventuell vorhandene Daten möglichst sicher gelöscht werden. Es gab bereits Fälle, wo Daten auf bei Ebay ersteigerten Festplatten gefunden wurden.

Denn man möchte vermutlich weder, dass irgendwelche geschäftlichen Daten Fremden in die Hände kommen, noch wird man scharf drauf sein, die privaten Bilder von Tante Erna aus ihrem Urlaub in Hinterzupfingen anderen Menschen zu präsentieren.

Dabei geht es nicht um sensible private Daten wie Lebensläufe, Bankdaten, Kontoauszüge oder wichtige geschäftliche Daten, nein vielmehr geht es um alle vorhandenen Daten, bzw. auch vermeintlich schon gelöschte Daten. Gelöscht heißt nämlich, dass das Betriebssystem nur den Verweis auf die Daten löscht bzw. den Bereich intern als leer markiert, so dass dort neue Daten gespeichert werden können.

Diese Daten sind nicht umsonst privater Natur und genau das sollen sie auch bleiben. Das heißt nicht, dass man etwas zu verstecken hat, denn schließlich laufen wir ja auch alle nicht grundlos mit Kleidung rum.

Nach gängiger Meinung genügt zum sicheren Löschen das Überschreiben der kompletten Festplatte mit einem Zufallsmuster. Gerüchte, wonach selbst überschriebene Daten aus "Restmagnetspuren" der Spurränder von Festplatten wiederhergestellt werden konnten, gehören wohl ins Reich der Verschwörungstheorien und scheinen nur Spekulationen zu sein. (Update: Ein entsprechender Artikel von Peter Gutmann, beschreibt daher eine Methodik zum sicheren Löschen von Daten durch mehrmaliges Überschreiben mit unterschiedlichen Bitmustern. Zu beachten ist aber, dass dieser Artikel von 1996 stammt und wohl mittlerweile durch die vergrößerte Speicherdichte heutzutage nicht mehr allgemein gültig ist. Es stellt sich sogar die Frage, ob einfaches Überschreiben durch Nullen nicht sogar eine ausreichende Sicherheit beim Überschreiben verspricht.)

Um das zu erreichen, genügt bei einer gängigen Linuxdistribution der dd Befehl. Damit kann man sehr einfach Daten auf die Festplatte schreiben. Die gängige Empfehlung ist dabei, dd if=/dev/urandom of=/dev/sda bs=1M auszuführen. Damit liest man aus dem Pseudo-Zufallspool des Systems und schreibt die Daten als 1 MB große Blöche auf das Gerät /dev/sda. Das ist grundsätzlich auch ok, das einzige Problem, was man dabei hat ist, dass der Zufallspool normalerweise nicht sehr gut gefüllt ist und nur relativ langsam gelesen werden kann.

Bei heutigen Festplattengenerationen mit mehreren hundert Gigabyte Speicher, kann da schon einmal ein Nacht für das Überschreiben drauf gehen (oder vielleicht sogar mehr, ich habe das noch nicht so genau getestet).

Schneller und äquivalent sicher ist es dagegen, die Festplatte mit Nullen zu beschreiben, die danach verschlüsselt werden. Dazu kann man cryptsetup verwenden, was mittlerweile wohl bei allen modernen Linux Distributionen dabei sein sollte:


Hier legt man eine logische Blockschicht über dem Gerät /dev/sda an, dass mit einem Zufallsschlüssel, der aus dem Zufallspool /dev/random kommt, verschlüsselt wird. Alles was auf dem neuen Blockschicht /dev/mapper/sda geschrieben wird, wird intern verschlüsselt auf das eigentliche Gerät /dev/sda geschrieben. Der Schlüssel ist eigentlich egal, er wird im Prinzip nur genutzt, um ein zufälliges Bitmuster aus den Nullen zu generieren und zu schreiben.

Damit braucht das System nicht auf den langsamen Zufalls-Entropiepool zu warten (es muß nämlich von dort nur zur Erstellung des Schlüssels einmalig 256bit lesen), sondern kann sehr schnell lesen die Nullen lesen. Durch die Verschlüsselung verlangsamt sich die Schreibgeschwindigkeit zwar, ist aber dennoch größer als bei der vorherigen Methode. In Zeiten immer schnellerer CPUs (zumindest in Desktop System) fällt der Geschwindigkeitsverlust wahrscheinlich immer geringer aus und wer von Anfang an ein verschlüsseltes Gesamtsystem verwendet, der wird gar keine Geschwindigkeitseinbußen bemerken.

Getestet habe ich das Ganze auch mal mit einer leeren 10GB Partition:


Wie man sieht, habe ich hier eine durchschnittliche Schreibgeschwindigkeit von 5,9MB/s mittels der traditionellen Methode erhalten. Durch das Verschlüsseln, konnte die Schreibgeschwindigkeit fast verneunfacht werden. Noch drastischer sind die absoluten Zeiten: fast 30 Minuten anstelle von 3,5 Minuten.

Das ist natürlich kein Benchmark, sondern soll nur zeigen, welch drastischen Unterschiede zwischen den Methoden existieren. Spielen kann man eventuell noch mit dem Blocksize Parameter, der in diesem Beispiel auf 1 Megabyte gesetzt war. Es ist nicht auszuschließen, dass es mit einem anderen Verschlüsselungsalgorithmus (hier aes-xts-plain) sogar noch schneller geht. (einfahcer Benchmark verschiedener Verschlüsselungsalgorithmen und noch ein Benchmark, ausführlicher)

Disclaimer: Unbedingt zweimal prüfen, auf welches Gerät man schreibt, bevor man sich sein System zerschießt. Dieses Gerät sollte auch nicht anderweitig parallel verwendet werden, sonst besteht die Gefahr, dass noch etwaige Daten nicht überschrieben werden konnten, weil sie noch geöffnet waren.

Nette Idee:
Mit sslh kann man sowohl ssh als auch einen Webserver mit https auf dem gleichen Port laufen lassen. Das ist ein kleiner Daemon, der auf Port 443 (https) lauscht und bei eingehenden Verbindungen entscheidet, ob es die Verbindung dann an den ssh-Server weiterreicht oder an den Webserver. Damit könnte man dann z.B. aus einem restriktiven Netz über eine scheinbare https Verbindung mit ssh raustunneln bzw. trotzdem per https den Webserver erreichen.

Äh, ich bin Web2.0 mäßig nicht so recht auf dem Laufenden, aber sofort-überweisung.de scheint ja lustig zu sein.

Dabei handelt es sich um einen Online-Dienst, über den man seine Überweisungen abwickeln kann. Das heißt, wenn man bei einem Referenz-Onlineshop einkauft (siehe Referenzen), dann wählt man als Zahlungsmethode sofort-überweisung aus und muß dann auf der Webseite von Sofort-Überweisung nur noch seine eigenen Bankdaten angeben. Also Bankleitzahl, Kontonummer, PIN und natürlich TAN.

Anstatt also meine wichtigsten Bankdaten nur in meiner bekannten, gesicherten Onlinebanking - Session einzugeben, soll ich sie anstatt dessen auf einem wildfremden Server in ein wildfremdes Formular eintippen.

Ja wohl, richtig für mich als Kunden gibt es keinen zusätzlichen Komfort und nur zusätzlicher Unsicherheit. Das richt geradezu nach Phishing im Zusammenhang mit Cross-Site Scripting.

Dabei sollte man doch mittlerweile wirklich die Sicherheitshinweise beachten, die seit Jahr und Tag kommuniziert werden.

Oder kurz: Nie, wirklich NIE seine Bankdaten nicht vertrauenswürdigen Portalen/Webseiten oder Formularen anvertrauen. Und zwar auch dann nicht, wenn die Seite bekannt aussieht.

Weiter Infos drüben im Netplanet blog und bei der Verbraucherzentrale Sachsen

How to pick a Kensington lock in 60 seconds
Örgs, und ich verlaß mich normalerweise auf diese Schlösser.

Ein kostenloses Web-Book zum Thema Forensic-Discovery von Dan Farmer und Wietse Venema.
Wenn ich mal viel Zeit habe, dann muß ich das mal lesen.

Ah, das ist irgendwie beruhigend:


Fail2ban ist in Debian Unstable enthalten, scannt verschiedene logfiles und sperrt IPs (mittels iptables), die zu oft fehlerhafte, also abgelehnte Logins verursachten.

Nun ist Sarge seid einem knappen Monat released und Security Updates scheinen immernoch nicht möglich.

Zunächst hieß es, technische Probleme wären die Ursache, danach hieß es, es liegt an der Überlastung des "Security Teams" aka Martin "Joey" Schulze, der zusätzlich noch den Linuxtag mitorganisierte. Und nun also wieder technische Probleme.

Scheint, als disqualifiziere sich Debian langsam als ernsthafte Alternative zu den großen kommerziellen Distributionen. Muß man sich jetzt wirklich selber um Sicherheitsupdates kümmern? Dann kann stable ja jetzt in Ruhe vergammeln...

Die aktuellen ungefixten Schwachstellen gibt es hier.
Hilfe zur Selbshilfe:

• Spamassassin aus testing/unstable einspielen
• Clamav
• sudo

gefunden im Heise-Forum.

Hört sich alles nicht so schlimm an?
Nun stelle man sich vor, es gäbe einen kritischen Security Bug, der remote ausgenutzt werden kann und der im Idealfall zur Kompromittierung der Maschine führt...

Ich möchte übrigens nicht dem 1-Mann-Team Joey die Schuld geben, aber es hieß doch immer Team...? Bei so einem Projekt kann doch nicht nur einer alleine für die Sicherheitsupdates verantwortlich sein.

Erwähnte ich schon, dass WEP tot ist? Hier ein Flash-Video: Cracking WEP in 10 minutes.

Via blog.planet-uwe.de

Ein interessanter Artikel, über die Anfälligkeit von Linux gegenüber forkbombs.
Argl, wieso gibt es standardmäßig eigentlich keinen Schutz vor forkbombs?

Dafür gibt es doch ulimit. Sowas sollte doch standardmäßig aktiviert sein...
Continue reading "Linux Security" »

Bruce Schneier hat in seinem Weblog Details zur Auswirkung der Attacke auf SHA-1 bekannt gegeben.

Hauptsächlich geht er auf die Details der durch das chinesische Team gefundene Schwäche ein. Es scheint, als wäre SHA-1 nicht kollisionsfrei, so dass nunmehr mit einem Aufwand von 2^69 Versuchen ein gleicher Hash zu einem vorgegeben gefunden werden kann. Das heißt, es ist ca: 2000facher reduzierter Aufwand (2^11 weniger als bei Brute-Force: 2^80) notwendig. Er geht weiter auf die Bedeutung dieser Entdeckung ein, und was ein Aufwand von 2^69 bedeutet.

Leider gibt es immernoch keine Details.

To be continued ...

Es scheint, dass uns so langsam die vertrauenswürdige Hash-Algorithmen ausgehen.

Bruce Schneier schreibt dazu:



Nachdem im August letzten Jahres bereits Zweifel an MD5 laut wurden, schein nun auch SHA1 gebrochen zu sein.

Der Aufwand, um SHA1 zu brechen, soll von 2^80 (Brute-Force) Versuchen auf 2^69 gesunken sein. Details sucht man leider bis jetzt vergeblich.

Einschränkend kommt hinzu, dass es sich um theoretische Angriffe handelt. Bis zum praktikablen Angriff dürfte es wohl noch ein Weilchen dauern. Dennoch sollte man sich vielleicht nach anderen Verfahren umschauen.

Alternativen?

• MD5 (128bit hash), broken
• SHA1 (160bit hash), broken
• RIPEMD160 (160bit hash)
• Tiger (192bit hash)
• Whirlpool (512bit hash)
• AESHash

Nachdem SHA1 und MD5 relaitv gut untersucht wurden, die anderen Hash Verfahren jedoch weniger gut, ist natürlich unklar, wie sicher diese sind.

Unklar ist weiterhin, wie sich dieser Angriff auf die darauf basierenden Verfahren SHA256/SHA384 auswirken. Der längere Hashwert könnte durchaus anfällig sein, und dem Sicherheitsanspruch nicht mehr genügen, und nur eine scheinbare Verbesserung bringen.

Vielleicht wäre ein Hash-Wettbewerb à la AES keine schlechte Idee...