Dipl.-Inform. Carsten Eilers

Ed Felten ist der Ansicht, das eine Anweisung eines Gerichts einem internen Angriff entspricht: "A Court Order is an Insider Attack". Damit hat er im Grunde Recht, aber gegen einen internen Angreifer kann man sich in Grenzen schützen, eine Gerichtsanweisung muss man befolgen. Oder, wie von Lavabit vorgemacht, den Laden dicht machen.

Dokumentierte Standard-Schwachstellen

Das für Industriesteuerungen zuständige ICS-CERT ist der Ansicht, dokumentierte Standardpasswörter wären keine Schwachstellen, wenn in der Dokumentation auch steht, dass man sie ändern muss und wie das geht. Das ist theoretisch vielleicht richtig, praktisch aber totaler Blödsinn. Denn viel zu viele Admins ändern die Standardpasswörter nicht. Jetzt könnte man argumentieren, dass dann der Admin die Schwachstelle ist. Aber das Standardpasswort widerspricht der zum Beispiel in Microsofts Security Development Lifecycle und auch vom "gesunden Menschenverstand" gestellten Forderung, dass ein System in der Default-Konfiguration sicher sein muss. Außerdem möchte ich an dieser Stelle an Stuxnet erinnern, dem ein Default-Passwort, dass nicht geändert werden sollte, die Arbeit erleichterte. Was spricht (außer dem zusätzlichen Aufwand für den Hersteller) dagegen, für jedes System ein zufällig erzeugtes, individuelles Passwort zu verwenden, dass nur in der zum jeweiligen System gehörenden Dokumentation angegeben ist?

iMessage ist sicher - solange Apple es ist

Die Quarkslabs haben Apples iMessage untersucht: "iMessage Privacy". Das Ergebnis in Kurzform: Grundsätzlich wird die Kommunikation sehr gut und für jeden Benutzer individuell Ende-zu-Ende verschlüsselt, so dass sie nicht belauscht werden kann. Da aber Apple die Key-Server betreibt, von denen die benötigten Schlüssel bereit gestellt werden, kann Apple sich als Man-in-the-Middle in die Kommunikation einschalten und diese belauschen. Selbst wenn man Apple vertraut sind das angesichts der NSA-Spionage keine sehr erfreulichen Aussichten.

Google: Bärendienst oder nützliche Hilfe für XP?

Google dehnt den Support von Chrome für Windows-XP-User bis April 2015 und damit weit über das Support-Ende für XP selbst am 8. April 2014 aus. Erweist Google uns allen damit einen Bärendienst, wie Graham Cluley meint, oder muss man das differenzierter sehen, wie Chester Wisniewski und John Hawes von Sophos meinen? Betrachten wir es doch mal realistisch: Wer immer noch Windows XP nutzt, tut das kaum freiwillig. Entweder kann er kein neueres System installieren, zum Beispiel weil er auf die Funktion bestimmter Programme angewiesen ist oder auf seinem Rechner nichts neueres läuft, oder er will kein neues System installieren. Daran wird das Support-Ende in den allermeisten Fällen rein gar nichts ändern.

Der Webbrowser ist seit langem eines der Haupteinfallstore für Schadsoftware, und der IE hatte dieses Jahr ja schon mit 4 0-Day-Schwachstellen zu kämpfen. Chrome übrigens noch mit keiner. Daher finde ich es nicht verkehrt, wenn es für das nicht mehr unterstützte XP dann wenigstens noch einige Zeit einen sicheren Browser gibt. Die Frage ist nur, ob die XP-Benutzer, die jetzt noch den IE verwenden, nach dem Support-Ende wirklich zu Chrome wechseln. Womöglich nutzen viele weiter den IE 6, weil sie genau darauf angewiesen sind. Aber zumindest alle anderen haben die Möglichkeit, ihre Angriffsfläche durch den Wechsel zu Chrome zu reduzieren. Wobei ich persönlich dann wohl eher auf das Surfen mit diesem Rechner verzichten würde, bevor ich mir die Web-Laus Chrome installiere.

Ein ganz besonders genau gezielter Angriff

McAfee berichtet, dass gezielte Angriffe noch gezielter werden: "Targeted Attack Focuses on Single System". Man hat einen Schädling entdeckt, der nur auf einem ganz bestimmten Rechner ausgeführt wird. Dazu wird durch Aufruf von http://checkip.dyndns.com/ die IP-Adresse des Rechners, auf dem der Schädlings-Installateur ausgeführt wird, abgefragt. Nur wenn die IP-Adresse mit der erwarteten Adresse überein stimmt, wird der enthaltene Schadcode entschlüsselt und installiert. Bisher wurden bei gezielten Angriffen E-Mails mit Schadsoftware oder Links zu Drive-by-Infektionen versendet, auf welchem Rechner der Schadcode dann landete, war den Angreifern egal. Ich wüsste ja gerne, ob da ein Cyberkrimineller schlechte Erfahrungen gemacht hat und sicher gehen wollte, dass wirklich zum Beispiel der Rechner in einem Unternehmensnetzwerk infiziert wird und nicht das private Notebook des Mail-Empfängers, oder ob das einfach nur ein zusätzlicher Schutz vor der Entdeckung durch die Antivirenhersteller ist. Denn wenn die richtige IP-Adresse nicht bekannt ist, lässt sich der Schadcode ja nicht entpacken und damit auch nicht analysieren.

TrueCrypt wird unter die Binär-Haube geguckt

Der Quelltext von TrueCrypt ist zwar öffentlich und gilt auch als recht gut untersucht, aber wurden die zum Download bereitgestellten Binärdateien wirklich mit diesem Sourcecode erstellt, oder gibt es darin womöglich in den veröffentlichten Quelltexten nicht enthaltene Hintertüren? Diese Frage wollen nun Kenn White und Matthew Green klären, die ein entsprechendes Projekt ins Leben gerufen haben. Außerdem soll die von TrueCrypt verwendete Lizenz auf ihre Kompatibilität mit dem bekannten Open-Source-Lizenzen geprüft werden. Beides halte ich für eine gute Idee, denn so lange man nicht einfach die Quelltexte kompilieren kann um selbst eine lauffähige Version zu erstellen, besteht die Gefahr, dass die bereit gestellten Binärdateien manipuliert sind.

Auf Slashdot gibt es aber auch schon die üblichen Verschwörungstheorien, in diesem Fall dass die Untersuchung eine FUD-Aktion ("Fear, Uncertainty and Doubt") der NSA ist, um das Vertrauen in TrueCrypt zu erschüttern. Wenn wir schon bei Verschwörungstheorien sind, würde ich da aber noch einen drauf setzen: Die NSA kann TrueCrypt nicht brechen. Sagt die NSA. Warum sollte man das glauben? Wäre es nicht viel besser für die NSA, in diesem Fall zu lügen?
Ach, ich liebe Verschwörungstheorien, die kann man so schön hochschaukeln...

Carsten Eilers