Moin Moin ihr Banausen ![Rolleyes](images/smilies/rolleyes.png)
,
Ihr wisst - der Cycy ist Verrückt nach Javascript & dem Reversen von Webanwendungen ![Pirate](images/smilies/pirate.png)
Und da dachte ich mir - zeigste einmal was du so in deiner Freizeit machst & was man mit Javascript Kenntnissen alles so anfangen kann.
Here we go ![Wink](images/smilies/wink.png)
Heute dürft ihr mich auf einer Reise des Reversens eines Werbe Netzwerkes begleiten.
Als "Opfer" dient mir Shorte.st weil ich hier gegen Ende auf Hartes Eisen gebissen habe.. ![Tongue](images/smilies/tongue.png)
Was ich damit im Detail meine, seht ihr dann später. Fangen wir an..
Ziel:
Wir wollen Geld verdienen. Und natürlich Spaß haben.. besonders viel.
Rangehenweise:
Wir (naja, eig ja ich
) reversen per Hand die eingebunden Javascripte und schauen welche Netzwerkkommunikation die Scripte führen.
Zunächst einmal ist es wichtig, zu verstehen was Shorte.st ist.
Shorte.st ist sogesehen ein Linkkürzer, mit dem man Geld verdienen (und ausgeben) kann.
Man kann entweder seine Links kürzen und somit pro Klick Geld verdienen,
oder selbst Werbeplätze ankaufen die dann per Cost-Per-View Modell abgerechnet werden.
Nun - wie können wir nun damit Geld verdienen..?
Damals gingen Leute her, und haben irgendwelche Links gekürzt, und haben sie dann in Traffic Sharing Webseiten eingebunden.
Einige Bekannte davon z.b sind Adf.ly und wie sie sonst noch alle heißen.
Das Problem hierbei ist jedoch, das Webseiten wie Shorte.st dies sehr schnell merken & dann das Geld einbehalten und Accounts sperren.
Das ganze entwickelte sich im laufe der Jahre zu einem Maus & Katz Spiel.. Leute suchen neue Wege zu betrügen,
und die Link-kürzer Anbieter finden neue Wege diese Mittel zu endecken.
Ums kurz zu machen - dieses Katz & Maus Spiel endete damit das Shorte.st nun relativ Clever ist
und sich sehr gut gegen solche Tricks schützt.
Wenn man Heutzutage ein Link aufruft der mit Shorte.st gekürzt wurde, bekommt man eine Meldung die einen anweist 5 Sekunden (15 mit Adblock) zu warten.
Erst ab diesem Zeitpunkt kann man auf einen Knopf drücken, der einen dann zum gekürztem Link weiterleitet.
Austricksen lässt sich dies nicht - denn der Button ist kein Typischer Button.. man findet im Quellcode der Webseite nicht
raus wohin dieser Shorte.st Link denn überhaupt zeigt. Erst nach Ablauf der Zeit, wird der Button freigeschalten & man kann zur eigendlichen Webseite
weiter. Doch wie wird dies gelöst? Nun.. schauen wir uns einmal die Webkonsole an während wir einen dieser Links aufrufen!
![](http://i.imgur.com/g5M1ydg.png)
Ich habe euch einmal den Interessen Part des Bildes mit Rot markiert.
Das Grünmarkierte sind einfach nur Traffic & Verhaltens Analyse Scripte (Google Analytics & NewRelic) und für uns zunächst uninteressant.
Den Link den ihr im Rot Markieren Bereich seht, wird genau DANN geladen wenn die 5 Sekunden Wartezeit vorbei sind.
Was schließen wir daraus? Genau - hier muss eine Kommunikation mit dem Server stattfinden, der dem Server sagt "Die Zeit ist um".
Und da nach diesen 5 Sekunden erst die Vergütung erfolgt, können wir davon ausgehen das genau dieser Aufruf dafür verantwortlich ist,
uns das Geld Gutzuschreiben
Nun wäre es aber zu leicht einfach diesen Link aufzurufen - denn in wirklichkeit ist dieser Link "etwas" länger
als im Bild gezeigt. Schauen wir uns doch einmal den Link im Detail an!
Code:
http://sh.st/shortest-url/end-adsession?adSessionId=3b6a72ec74c9d52f2db23410640ded42c32e0e93&adbd=1&callback=reqwest_1449246988135
Wow, das sieht ziemlich komplex aus.. oder nicht?
Okay, teilen wir den Link zunächst einmal in seine Bestandteile auf damit wir uns das ganze genauer anschauen können.
1)
adSessionId=3b6a72ec74c9d52f2db23410640ded42c32e0e 93
Wir haben also eine Variable mit dem Name adSessionId.. was tut diese? Nunja - sie zeigt dem Server nur von welchem Aufruf dieser Request kommt.
Der Webbrowser bekommt diese Session Id in einer Javascript Variable zugewiesen, und sie dient einfach dafür damit der Server
weiß "aha, dieser Aufruf der end-adsession.php kommt von diesem Computer / Aufruf". Das ganze ist also keine Magie,
sondern wir können diese Session Id einfach selbst leicht auslesen.. kein Problem. Der Server schickt die uns ja zu ![Smile](images/smilies/smile.png)
2)
adbd=1
Na..? Was könnte das für eine Abkürzung sein..? ADBD?
Ob das vielleicht die Abkürzung für ADBlock Detected ist?
Ums kurz zu machen - ja ises. Diese Variable sagt einfach "Hey Server, ich hab ein Adblocker erkannt!".
Wieso wird das getan? Nunja.. mit Adblocker darf man 15 Sekunden anstelle 5 Sekunden warten..
und für Analyse Zwecke will der Server das halt wissen. Nun können wir dem Server einfach sagen das wir Adblock-Clean sind (wir sind schließlich Brave Werbekonsum-Jünger
..*hust*)
3)
callback=reqwest_1449246988135
Hier wird das ganze schon etwas kniffeliger - denn diese Variable ändert sich bei jedem Aufruf, und wird nirgends
im Quellcode der Webseite ausgewiesen. Was könnte also diese Nummern bedeuten..?
Ich habe eine Weile des Nachdenkens benötigt, aber da ich solche Zahlen schon von diversen anderen Projekten kannte, hatte ich einen Verdacht.
Das könnten Unix Timestamps sein. Der Erste Test zu einer Umwandlung von dieser Nummer erbrachte mir leider nur ein falsches Datum & Uhrzeit.
Also lag ich falsch..? Nein. Der Timestamp ist einfach nur in Ms angegeben, und mein Script was die Konvertierung durchführte hatte eine andere
Einheit benutzt. Also.. nochmals Konvertieren und.. was erhalten wir? Genau - Das heutige Datum und Uhrzeit.
Wir können also daraus schließen, das bei einem Request an den Server einfach nur die Aktuelle Zeit & das Datum an den Server geschickt wird.
Doch! Diese Variable dient für noch mehr. Doch zunächst einmal schauen wir uns an, was uns der Server als Antwort gibt wenn wir
solch einen Request abschicken!
Server Antwort:
Code:
/**/reqwest_1449247811098({"destinationUrl":"http:\/\/www.google.de\/","status":"ok"});
Okay, wir sehen hier also das der Server uns in JSON eine Antwort gibt.
Nun sehen wir auch den Grund, warum wir im Quelltext der Webseite nicht die Zielseite finden konnten..
denn sie wird erst nach Ablauf der Zeit vom Server zu uns geschickt!
Zusätzlich erhalten wir noch eine Statusnachricht die uns sagt "alles okay".
Wenn wir uns diese Antwort nun anschauen, sehen wir aber das der Server für das Antworten JSONP benutzt..
Das heißt das vom Server beim Aufruf eines Shorte.st Link eine Javascript Funktion generiert wird,
derren Namen auf dem aktuellen Datum & Uhrzeit basiert..
Beispielweise eine Funktion mit dem Name "reqwest_1449247811098".
Nach dem Ablauf der 5 Sekunden, wird ja ein Request an den Server geschickt.. dieser Bewirkt
sogesehen das unsere Funktion "reqwest_1449247811098" aufgerufen wird.
Hierbei wird unsere Ziel-Url und der Status an diese Funktion übergeben.
Dies wird deshalb gemacht, weil wir ja beim Drücken des Knopfes auf unsere Zielseite weitergeleitet werden wollen.
Also muss ein Script ja wissen was die Zielseite ist.. und der Server schickt diese Daten einfach per JSONP zu unserem Browser ![Wink](images/smilies/wink.png)
Eine Vergütung erfolgt sogesehen nach diesem letzten Request an den Server, der uns dann die Zielseite nennt.
Nun hat Shorte.st aber ein paar Fehler begangen, die wir ausnutzen können um uns Vorteile zu beschaffen.
1) Die Wartezeit bis der Link freigeschalten wird, ist Clientside gelöst.
Man kann durch Manipulation der Javascript Funktion setTimeout, setInterval & co. diese Zeit beeinflussen.
ODER den entsprechenden Link für den Request einfach selbst generieren (alle Daten liegen ja vor) und einfach aufzurufen.
2) Es gibt keinerlei Sicherheitsvorkehrungen die verhindern, das wir die Captcha Sperre umgehen können.
Wir können einfach den Quelltext der Webseite auslesen, den Request selbst abschicken (obwohl das Captcha vor unserer Nase ist).. voila wir sind auf der Zielseite.
Captcha? Fürn Arsch ![Rolleyes](images/smilies/rolleyes.png)
Ein Captcha das man einfach umgehen kann ist ziemlich.. sinnfrei?
3) Keinerlei Obfuscation oder Ansatz von "wir wollen verhindern das jemand das System ausnutzt" im Quellcode.
Jeder Noob der ein paar Wochen Javascript kann, kann diesen Quellcode lesen & dann ausnutzen.
4) Keinerlei Verschlüsslung oder sonstige Sicherheitsmaßnahmen die ein ausnutzen der Serverkommunikation verhindern.
Jeder der sich den Quellcode anschaut, weiß wie die entsprechenden Requests entstehen, und kann sie abschicken.
Es braucht hierfür nicht einmal ein Browser.. lässt sich alles mit normaler Socket Kommunikation lösen.
(Ich habe z.b ein Script geschrieben was automatisiert die Wartezeit umgeht..alles im Hintergrund - nur gibts da ein Problem.. komme ich gleich zu)
JEDOCH.
Rettet Cross Site Origin den süßen netten Hintern von Shorte.st ![Wink](images/smilies/wink.png)
Denn sie haben dann doch etwas implementiert die einem die Suppe versalzen.
- Sie prüfen den Ref.. heißt wenn der Request der am Ende geschickt wird abgeschickt wird, der Ref aber nicht von Shorte.st kommt.. bekommt man ne Fehlermeldung
- Cross Site Origin (ist nicht Shorte.st's verdienst)
Gäbe es diese 2 Punkte nicht, könnte man ein simples Script erstellen das man dann auf seiner Webseite einbinden kann.
Jeder Besucher dieser Webseite würde dann heimlich im Hintergrund diesen Request generieren, und im Hintergrund aufrufen.
Es würde niemals jemand auch nur ein einzigen Werbebanner zu sehen bekommen, oder sonst etwas das auf Shorte.st hinweist..
jedoch würden wir die Vergütung für jeden Aufruf bekommen.
Würde man nun bei diversen Popunder Netzwerken sich super günstig Popunder Werbung kaufen, den Traffic dann auf das Script
leiten, hätte man ein super verdienst
Ums kurz zu machen:
Sie haben sich grad noch ihren Süßen hintern vor Cy retten können.. gäbs die Cross Origin Policity nämlich nicht, hätten sie nun ein enorm krasses Problem.
Abschlusswort..
Wir sehen - Man sollte seine Webanwendungen immer gut absichern, und jede Mögliche Angriffsmöglichkeit in Betracht ziehen.
Wenn es einen Weg gibt eine Webanwendung zu Exploiten um daraus Profit (oder spaß..) zu gewinnen, wird es gemacht.
Auch von mir. Wenn jemandem seine Webanwendung dann Exploitet wird, ist dies die Schuld desjenigen der diese entwickelt hat. Wer seine Web 2.0 Anwendungen nicht gut absichert, hat eben Pech wenn dies exploitet wird. Punkt.
Solltet ihr also selbst ein Produktivsystem für ne Firma entwickeln.. denkt wie ein Hacker und sichert es gescheit ab ![Wink](images/smilies/wink.png)
Ansonsten hoffe ich das euch das ganze zumindestens ein bisschen Spaß gemacht hat beim lesen.. falls nicht basht mich nicht zu hart ![Welcoming](images/smilies/welcoming.png)
Als kleines Goodie noch ne Javascript Funktion womit man den Request von Shorte.st Links sich selbst generieren kann (Webconsole).
Code:
function ShortDaCash()
{
var timestamp = new Date().getTime(); //Timestamp for the Request
var sessionid = app.options.adSessionNotifier.sessionId; //Session Id
var url = 'http://sh.st/shortest-url/end-adsession?adSessionId='+sessionid+'&adbd=0& callback=reqwest_'+timestamp;
return url;
}
Theoretisch hätten wir jetzt noch Spoofed Requests an Google Analytics & NewRelic senden können damit es auch in den Statistiken im Webserver von Shorte.st legit ausschaut.. aber ich schätze dann wäre der Thread zu lang geworden.
Daher gebe ich euch das einfach mal als Fleißaufgabe hinzu
p.s: Ref's lassen sich Spoofen, just sayin ![Redface](images/smilies/redface.png)
![Rolleyes](images/smilies/rolleyes.png)
grüße..