Dipl.-Inform. Carsten Eilers

Googles Glass wirft viele Fragen auf, zum Beispiel wie es mit dem Datenschutz der damit Beobachteten aus sieht, und welche Daten denn Google so sammelt. Der US-Kongress hat Google dazu einen Fragenkatalog geschickt ( PDF, via Sophos Naked Security).

Besonders interessant finde ich die Frage, wie Google dafür sorgen will, dass Nicht-Googlenutzer von einer möglichen Gesichtserkennung ausgenommen werden. Eigentlich kann das technisch ja nur so funktionieren, dass erst mal alle Personen erfasst und erkannt werden, um dann die nicht erkennbaren oder die Google-Nutzer mit Opt-Out-Einstellung auszublenden. Aus Datenschutz-Sicht liegt das Kind dann aber schon tief unten im Brunnen. Eine wirklich spannende Frage: Wie erkennt man Personen, die man nicht erkennen darf?

Und wie will man Aufnahmen verhindern, die die Privatsphäre Dritter verletzen? Die sind zwar auch bisher schon möglich, mit Glass aber dann direkt mit Google verknüpft. Noch kann man Glass-Benutzer bitten, ihr Gadget abzunehmen, bevor sie eine Wohnung oder welchen Raum auch immer betreten. Aber was wird, wenn Glass irgendwann Bestandteil normaler Brillen wird? Wie will man ein normales, extravagantes Brillengestell von einem mit integriertem Rechner samt Google-Anbindung unterscheiden? Und eine normale Brille kann man nicht einfach mal so abnehmen.

Rund um Schadsoftware

Tim Rains geht im Microsoft Security Blog der Frage "Are Viruses Making a Comeback?" nach. Eigentlich galten Computerviren ja mehr oder weniger als ausgestorben, nachdem die Cyberkriminellen inzwischen vor allem auf Drive-by-Infektionen zur Verbreitung ihrer Schadsoftware gesetzt haben. Aber anscheinend finden sie immer wieder ihre mehr oder weniger großen Nischen zum Überleben.

Und was die Drive-by-Infektionen betrifft: Die werde ja zur Zeit gerne über Java durchgeführt. Was Microsofts Security Intelligence Report eindrucksvoll zeigt. Java läuft sogar HTML/JavaScript den Rang ab. Übrigens war nur eine von vier ausgenutzten Schwachstellen eine 0-Day-Schwachstelle. Was nach wenig aussieht. Aber 1 von 4 - das sind auch 25%, und der Wert sieht schon wieder größer aus. Trotzdem bleibt das Ergebnis gleich: 3 von 4 Angriffen erfolgt auf eigentlich bereits behobene Schwachstellen - und ist meist erfolgreich. Was zum Schluss führt, dass die meisten Benutzer Java nicht oder zu spät updaten. Vielleicht sollten sie es dann besser ganz löschen oder zumindest das Browser-PlugIn ausschalten.

Nart Villeneuve und Kyle Wilhoit von Trend Micro haben einen neuen Advanced Persistant Threat untersucht: Safe (Whitepaper als PDF, via Trend Micros Security Intelligence Blog). APTs scheinen in letzter Zeit "in" zu sein. Oder der Begriff wird mal wieder überstrapaziert.

Gabor Szappanos (Szappi) von Sophos hat die Schädlingsfamilie PlugX untersucht, die zum Beispiel im September 2012 über eine 0-Day-Schwachstelle im Internet Explorer verbreitet wurde. Konkret geht es um die aktuelle Version 6.0 (Whitepaper als PDF, via Sophos Naked Security). PlugX verwendet übrigens eine legitime, digital signierte Anwendung zum Einschleusen eigenen Codes: Die Anwendung verwendet einen unsicheren Suchpfad zum Laden von Libraries. Ein weiterer Grund, warum man Code Signing nicht überbewerten sollte: Auch signierte Anwendungen können natürlich Schwachstellen enthalten, die ausgenutzt werden können.

Und weil ich gerade beim Code Signing bin: Es gibt auch mal wieder einen Schädling mit gültiger Signatur. Eingesetzt im Rahmen gezielter Angriffe. Die diesmal nicht von China, sondern von Indien ausgehen sollen. Oder haben die Chinesen da einfach Aufgaben nach Indien ausgelagert?

Rund um SSL

In Firefox Aurora wurde das "Mixed Content Blocking" eingeführt. Dadurch wird verhindert, dass über HTTPS geladene Seiten Inhalte über HTTP nachladen, was einige Angriffe verhindert. Das Ganze ist aber noch experimentell, da viele Seiten ohne den "Mixed Content" nicht richtig funktionieren. Das ist aber ein Fehler der betreffenden Websites und nicht von Firefox. HTTP-Ressourcen haben auf HTTPS-Seiten nichts zu suchen!

Johannes Ulrich weist im ISC Diary auf ein mögliches Problem mit IPv6 und SSL hin: Wird ein Webserver über einen Proxy IPv6-fähig gemacht, erfordert das zwei SSL-Zertifikate: Eines für den IPv6-Proxy, eines für den IPv4-Webserver. Was generell unschön ist, eigentlich sollte die Regel "Ein Hostname, ein Zertifikat" gelten, und auch zu echten Problemen führen kann. Zum Beispiel, wenn eines der beiden Zertifikate unbemerkt abläuft. Wie zum Beispiel für www.socialsecurity.gov, wo das IPv6-Zertifikat ungültig ist.

Carsten Eilers