Googles 2-Faktor-Authentisierung

Wie ich die Tage ja bereits schrieb, hatte ich mich vor einiger Zeit entschieden, die 2-Faktor-Authentisierung bei Google zu aktivieren. Man kann den zusätzlichen Code entweder als SMS empfangen oder aber auch von einer App, dem Google Authenticator generieren lassen.

Auf die SMS will ich mich nicht verlassen. Beim Ändern wartete ich mal über 10 Minuten, bis die SMS ankam, so dass ich zwischenzeitlich den Mist deaktivierte.

Laut obiger Anleitung kann man den Google Authenticator auch auf mehr als einem Gerät installieren. Allerdings ist der Weg meines Erachtens echt bescheiden: Man muss beim Einrichten des Google Authenticator alle Geräte den Code scannen lassen. Später lässt sich kein Gerät mehr hinzufügen.

Hat man die 2-Faktor-Authentisierung aktiviert, geht’s dran, die diversen Geräte zu konfigurieren. So muss man sich dann auf jedem Gerät, in jedem Browser neu einloggen.

Auch Google Drive, die Synchonisierung von Chrome und diverse Apps müssen angefasst werden.

Google Drive startet man am besten neu. Beim Chrome meldet man sich am besten ab und dann erneut an. Bei Ingress auf iOS deinstalliert man am besten die App und installiert neu, um sich dann neu anzumelden…. intuitiv ist anders.

Zertifikats- bzw. SSL-pinning als Allheilmittel?

Immer wieder liest man, wie der Datenverkehr zwischen Apps und den entsprechenden Servern abgehört wird. Als Gegenmittel bietet sich dafür zunächst SSL-Verschlüsselung an. Damit ist der Datenverkehr verschlüsselt und nicht mehr einzusehen. Allerdings sind SSL-Verbindungen nicht gegen man-in-the-middle-Attacken (mitm-Attacken) geschützt. Dabei schaltet sich der Angreifer zwischen Server und Client. Der Client baut statt zum Server zum Angreifer eine Verbindnung auf. Diese Kommunikation ist zwar verschlüsselt, kann aber vom Angreifer entschlüsselt werden, so dass dieser seinerseits eine verschlüssselte Verbindung zum Server aufbauen kann. Er reicht die Daten transparent durch, liest mit und verändert gegebenenfalls.

Die Verifizierung, dass ich wirklich mit dem Server spreche, kann über SSL-Zertifikate erfolgen. Dabei lässt der Serverbetreiber sich ein Zertifikat von einer Zertifizierungsstelle (CA, Certification Authority) ausstellen, der ich (bzw. mein Browser) vertraut. Das Zertifikat ist an den Servernamen gebunden. Ein Angreifer kann höchstens ein selbst unterschriebenes Zertifikat anbieten. Beim Verbindungsaufbau wird das Zertifikat überprüft und abgelehnt, da die Unterschrift nicht gültig ist.

Bei einem App-Zugriff hat der Nutzer in der Regel keine Möglichkeit, das Zertifikat zu überprüfen. Daher muss dies die App tun. Dies kann durch sogenannten SSL-Pinning geschehen. Die App kennt das zu erwartende Zertifikat und akzeptiert nur dieses.

Nun wird es spannend. An dieser Stelle steigt leider auch der Artikel auf golem.de aus. Es werden die unterschiedlichen Angriffsvektoren durchmischt:

Es wird beschrieben, dass SSL-Pinning auf Android leicht zu umgehen ist. Das mag sein. Aber hier wird auf einmal von anderen Voraussetzungen ausgegangen. Bis eben haben wir dem Client noch vertraut. Als Anwender will ich mitm-Attacken verhindern. Dann ist SSL-Pinning sinnvoll.

Vertaue ich aber nicht mehr dem Client, muss man sich in der Tat etwas anderes überlegen. Dann ist aber das Ziel auch ein anderes: Als Anbieter möchte ich mit einem nicht vertrauenswürdigen Gegenüber Daten austauschen. Solange es nicht irgendeinen vertrauenswürden Kanal gibt, wird dies im Zweifel nicht gelingen.

Die Sicherheitsprobleme des Fingerabdruck-Sensors des iPhone 5S

Ich finde es erstaunlich, dass bei der Betrachtung der Sicherheit des Fingerabdruck-Sensors des neuen iPhone 5S immer wieder getestet wird, wie man den Sensor austricksen kann. So betrachtet auch Jürgen Schmidt auf heise security diesen Gesichtspunkt. Er beschreibt, wie der Senser bereits überlistet wurde. Dennoch wird empfohlen, den Fingerabdruck als Sicherheitsfeature zu nutzen.

Ich sehe das ähnlich. Bevor man keinerlei Zugriffsschutz einsetzt, ist ein schlecher immer noch besser. Und mal ehrlich, welcher „Finder“ eines iPhones macht sich die Mühe, den Fingerabdruck zu fälschen.

Missbrauch der anderen Art

Ich sehe die Problematik aber an ganz anderer Stelle: Wer garantiert mir denn, dass nicht irgendeine App den Sensor im Hintergrund mitnutzt? Da hilft es auch nicht, dass Apple beteuert, dass immer nur ein Hashcode gespeichert wird. Der Sensor muss per se den gesamten Fingerabdruck aufnehmen. Was dann die Software daraus macht, steht auf einem anderen Blatt.

Vielleicht speichert Apple auch den gesamten Fingerabdruck — vielleicht überträgt das iPhone die Daten auch zu Appe. Und wer da alles mitliest, wissen wir ja mittlerweile nur zu gut.

Man sollte vielmehr den ursprünglichen Preis nicht für das Überlisten des Sensors ausschreiben. Eher sollte dies für das (unberechtigte) Nutzen des Sensors aus einer App heraus geschehen.

geklautes Adressbuch bei Twitter löschen

Seit einigen Tagen überschlagen sich die Ereignisse rund um das Klauen der Adressbuchdaten diverser Apps auf dem iPhone und dem iPad. War es anfangs die App von Path, so folgten schnell die Apps von Twitter, Foursquare und Angry Birds.

Bei Twitter lassen sich angeblich die Adressbuchdaten wieder löschen, indem man auf diese Seite bei Twitter geht. Dies geht interessanterweise nicht mit dem Mobil-Gerät. Sitzt man dann endlich an einem passenden Endgerät, gibt’s dort leider nur eine Fehlermeldung.

Fehlermeldung beim Löschen der geklauten Adressbuch-Daten

 

 

 

Woran liegt’s? Müssen die Daten erst bei der NSA abgeholt werden? Oder war’s das Department for Homeland Security? Oder sind’s die Chinesen?

Naja, zu erwarten war das ganze ja schon. Das ist auch kein neues Problem. Wer weiß, was alles irgendwelche Freeware auf dem PC gemacht hat….

iOS Anwendungen mit dem mitmproxy debuggen

Folgendes Problem: eine externe Agentur entwickelt im Auftrag eine iOS-App, um darüber via API auf die eigene Website zuzugreifen. (Der Klassiker — der 250. RSS Reader, aber immer wieder gern genommen.)

Es kommt, wie es kommen muss: Irgendetwas funktioniert nicht, wie man sich das gedacht hat. Die Agentur sagt, der Webserver liefert das Falsche, der Webmaster schaut ins Logfile und sagt, da kommt erst gar nicht der richtige Request an. Was tun?

Erster Schritt: ein Hub und Wireshark

Bis vor kurzem habe ich dann immer zu einem betagten Hub gegriffen, diesen zwischen WLAN-Router und Internet-Gateway gestellt. An diesen habe ich dann an einen weiteren Port einen „echten“ Rechner angeschlossen und via Wireshark den Netzwerkverkehr mitgeschnitten und analysiert.

Dabei entstehen ein paar Probleme:

  1. Wer hat immer einen Hub griffbereit? Solche prähistorischen Geräte hüte ich zwar wie meinen Augapfel (man weiß nie, wann man sie mal wieder gebrauchen kann), aber in der Regel hat man doch keines zur Hand.
  2. Die nächste Stufe wäre dann ein managebarer Switch, dem man einen Monitoring Port konfigurieren kann.
  3. Es ist nicht jedermanns Sache, den Netzwerkverkehr auf Höhe der Grasnarbe zu analysieren.

mitmproxy

Solange es sich um http/https Verkehr handelt, kann man einen anderen Weg beschreiten. Man lässt einen Proxy-Server laufen, der die Netzwerkdaten ausgibt.

Ein solcher Proxy ist zum Beispiel mitmproxy. mitm steht hierbei für man in the middle.

Die Installation unter Mac OS X 10.6 läuft recht einfach ab:

git clone git://github.com/cortesi/mitmproxy.git

In das nun entstandene Verzeichnis kopiert man nun noch von http://excess.org/urwid/ das innere urwid Verzeichnis, sodass das Verzeichnis wie folgt aussieht:

Nun kann man bereits den Proxy starten:

./mitmproxy -p 8080

Auf dem iOS Gerät selbst stellt man nun den Rechner als Proxy ein. Wichtig ist dabei, dass das iOS Gerät den Rechner „sehen“ kann, sie also zum Beispiel im selben WLAN sind.

Via

ifconfig

kann man auf dem Rechner die eigene IP-Adresse ermitteln.

Unter Einstellungen-> WLAN -> eigene SSID lässt sich unten der HTTP-Proxy einstellen. Hier trägt man nun die IP-Adresse des Rechners unter Server ein und 8080 den Port.

Der Aufruf von Google sieht dann beispielsweise so aus:

Über die Return-Taste lassen sich nun Requests genauer anschauen:

 

 

 

 

 

(Mit der q-Taste kommt man wieder zurück. Mit der tab-Taste kann man sich den Response-Body genau ansehen.)

SSL-Verschlüsselung

Soweit so gut. Doch was macht man, wenn die App via SSL/https mit dem Webserver spricht? Kein Problem:

Der mitmproxy erzeugt beim ersten Starten unter ~/.mitmproxy ein SSL-Zertifikat, das man nun dem iOS Gerät als vertrauenswürdig geben muss.

Das macht man so: Man schickt sich die Datei mitmproxy-ca-cert.pem. Diese öffnet man dann auf dem iOS Gerät und bestätigt, dass man diesem Zertifikat trauen will.

Schon kann man sämtlichen https-Verkehr einsehen.

Dies funktioniert natürlich nur soweit, wie die App auf die globalen http-Einstellungen für Proxies zurückgreift und nicht selbständig Zertifikate überprüft. Da man als Entwickler aber am liebsten auf bereits gelöste Probleme zurückgreift, dürften die meisten iOS-Apps den internen Safari für http(s)-Anfragen nutzen.

Erfahrungen aus dem Einsatz von https-everywhere

Seit einigen Tagen setze ich das Firefox-add-on HTTPS-Everywhere ein, um automatisch auf die verschlüsselte Variante einer Website zuzugreifen.
Das funktioniert auch sehr gut, doch bin recht erstaunt, an wievielen Stellen ich nun Warnungen erhalte, dass Seitenbestandteile bzw. Zielseiten nicht verschlüsselt sind.

Man sieht dies zum Beispiel an den Seiten von WordPress.org. Diese sind auch via https erreichbar. Doch nutzt man die Suche der Seite, so werden diese Anfragen unverschlüsselt verschickt. Das mag in diesem Fall ziemlich harmlos sein, macht aber deutlich, dass es nicht einfach damit getan ist, „noch ’nen https-Prozess aufzusetzen“.

Google DNS-Server – Ein Schelm wer Böses dabei denkt

Google tritt an, um das Internet (hier vor allem das WWW) schneller zu machen. Dazu stellt Google zwei DNS-Server bereit: Unter den IP-Adressen 8.8.8.8 und 8.8.4.4 stehen die beiden Server zur Verfügung. Hier hat Google eine gute Wahl getroffen. Diese Adressen lassen sich gut merken.

Google beschreibt auch ausführlich, wie die einzelnen Betriebssystem zu konfigurieren sind.

Google versucht die Namensauflösung dadurch schneller zu gestalten, dass Einträge kurz vor Ablauf ihrer Gültigkeit neu geholt werden, so dass sie dann wieder aus dem lokalen Cache des Nameservers beantwortet werden können.

Auch versucht Google, Spoofing dadurch zu erschweren, dass die Anfragen zufällig in Groß- und Kleinbuchstaben gestellt werden.

Was aber bleibt, ist die Frage nach dem, warum Google diesen Service anbietet. Im englischen Sprachraum kennt man den Spruch There ain't no such thing as a free lunch. Auf deutsch könnte man ihn sinngemäß so übersetzen: Nichts ist umsonst, nur der Tod, und der kostet das Leben.

Auf die Google Nameserver übertragen heißt das, dass man Google sehr wohl für die Nutzung ihrer Nameserver bezahlt. Google erhält nämlich dadurch nicht nur Kenntnis über unsere Suchanfragen sondern auch noch über jede einzelne Domain, die wir besuchen. Was man damit anfangen kann? Nun, lassen wir die Phantasie von Google mal spielen …

„Mailstrorm“ von Per Helge Sørensen

Nach langer Zeit des Suchens habe ich mal wieder einen spannenden Internetthriller gelesen. Es handelt sich um den Roman Mailstorm von Per Helge Sørensen. Betrachtet wird hierbei die Welt der Kryptografie im Internet. Wie wichtig ist eine Hintertür für die erfolgreiche Verbrechensbekämpfung? Hilft diese auch, wenn die "echten Verbrecher" sowieso Software ohne Hintertür nutzen?

Diese Fragen werden in eine Handlung eingebettet, die fessend geschrieben ist und ohne irgendwelche Phantastereien auskommt. Die Handlung könnte sich so wirklich abspielen oder bereits abgespielt haben. Vor dem Hintergrund des kassierten Verfassungsschutzgesetz in NRW ist die Geschichte aktueller den je.

Bundestrojaner: Was geht und was geht nicht

Auf heise.de gibt es einen guten Artikel über den Bundestrojaner. Er beleuchtet die einzelnen Aspekte differenziert: Wie soll der Bundestrojaner installiert werden? Über Lücken im System und prarierte Links oder doch zwangsweise über einen Zwangsproxy….

Auch auf die Problematik der Virenscanner wird eingegangen. Wann darf ein Virenscannner anschlagen? Gibt es Virenscanner, die auf diesem Auge blind sind? Wird es somit eine Deutschland-Version eines jeden Scanners geben? Wird der Einsatz in eines anderen Scanners verboten?

Damit kommt man sofort zu der Frage: Lassen sich die "Bösen Buben" davon abhalten? Wer Bomben in Menschenmengen zündet, wird sich sicherlich nicht davon abhalten lassen, einen "richtigen" Virenscanner zu benutzen.