dimis linkdump

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.

Eine interessante Idee hatten die Security-Spezialisten von ha.ckers.org. In ihrem aktuellen Blogartikel schreiben sie über eine Möglichkeit wie man z.B das interne Netz eines Surfers über den Browser auf die existenz aktiver Hosts überprüfen könnte.
Hierzu wird natürlich kein echtes ICMP-Packet durch den Browser generiert, sondern ein so genannter Cross-Origin Request an jeden einzelnen Host abgesetzt. Mit dieser Methode will das W3C den Authoren von Webapplicationen eine sichere Möglichkeit bieten, die so geannte Same Origin Policy zu umgehen.

Wie funktioniert das “ping” sweeping?

Diese Methode bediehnt sich eines einfachen Gedankens: Eine IP hinter der ein Host steckt, kann schneller reagieren als eine IP hinter der kein Host steckt. (Wie denn auch, wer soll da reagieren?)

Das W3C verbietet im Entwurf zu Cross Origin Request ganz deutlich, dass keine Informationen an den User ausgegeben werden dürfen, wenn das status flag nicht auf success steht.

Hosting specifications also need to ensure not to reveal anything until the status flag is set to success to prevent e.g. port scanning.

Indirekt tut es der Browser halt trotzdem:

Hier wichtigste Teil des Javascripts:

1:  function processRequest () {
2:    if (req.readyState == 4) {
3:    var d2 = new Date;
4:    var time = d2.getTime() – d.getTime();
5:         if (time < 18000) {
6:             if (time > 10) {
7:                 log (“Exists: ” + url + ” at ” + time + “ms.”);
8:             }
9:         } else {
10:           log (“Doesn’t exist: ” + url + ” at ” + time + “ms.”);
11:       }
12:  }
13: }

Im vorderen Teil des Skripts (hier nicht abgebildet) wird das neue XMLHTTPRequest-Objekt ( req ) sowie die Startzeit des Skripts ( d ) erzeugt.

Wenn der Request beendet ist (Zeile 2) vergleicht das Skript die Anfangs- und Endzeit (d und d2). Wenn die Hosts innerhalb von 10 – 18000 Millisekunden geantwortet haben, dann werden sie als Online deaklatiert.

Diese unterschiedlichen Zeiten entstehen dadurch, dass jeder aktive Host, egal ob er auf Port 80 erreichbar ist oder nicht, dem Browser schneller eine Reaktion auf die Anfrage liefern kann als ein Host der nicht im Netzwerk vorhanden ist. Wenn ein Host nicht im Netzwerk erreichbar ist, läuft der Browser einfach in einen Timeout. Der dauert natürlich deutlich länger…

Es gibt 3 Möglichkeiten, wie ein aktiver Host auf eine Anfrage durch den Browser reagieren kann:

• Er schickt ein RST/FIN-Paket, weil auf diesem Port kein Dienst lauscht.
• Er lässt eine Verbindung zu, weil ein HTTP-Server auf dem Port lauscht.
• Er verwirft das Paket einfach.

Punkt 1 und 3 sind für das Skript ok und geben den Host als aktiv aus. Punkt 3 verfälscht das Ergebnis allerdings enorm. Dieser Fall entsteht durch eine aktive Firewall , die die Pakete einfach verwirft statt diese mit RST zu beantworten. Die Windows-Firewall (ab SP2 XP) ist z.B. so eingestellt. Genauso kann natürlich auch eine iptables-Firewall unter Linux eingestellt sein…

Link zum Test:

http://ha.ckers.org/weird/xhr-ping-sweep.html

Wer selbst ein wenig rumprobieren will, kann sich die Seite einfach abspeichern und im Quelltext das Array “sites”, entsprechend seiner IP-Range im lokalen Netzwerk, anpassen.

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

Eine Attacke mit SSL-Strip könnte so ablaufen:
Zuerst wird, z.B. über ARP-Spoofing, ein Client dazu veranlasst allen Traffic an den Angreifer zu schicken. Näheres dazu in meinem ARP-Spoof-Artikel.
Hier setzt nun SSLStrip an.

Usage: sslstrip <options>
Options:
-w <filename>, –write=<filename> Specify file to log to (optional).
-p , –post                       Log only SSL POSTs. (default)
-s , –ssl                        Log all SSL traffic to and from server.
-a , –all                        Log all SSL and HTTP traffic to and from server.
-l <port>, –listen=<port>        Port to listen on (default 10000).
-f , –favicon                    Substitute a lock favicon on secure requests.
-k , –killsessions               Kill sessions in progress.
-h                                Print this help message.

(weiterlesen…)