heute geht es mal um mehrere Sicherheitslücken in trivago.de. Es geht hier um genau 6 XSS Lücken auf 3 Seiten.
Was ist Trivago?
Ich lass mal Wikipedia ran:
trivago ist ein Reiseinformationsportal, welches über eine Metasuche an über 150 verschiedene Buchungssysteme wie zum Beispiel Expedia, Booking.com, otel.com, olotels.com oder Opodo angeschlossen ist und so die Angebote verschiedener Hotels vergleichen soll. Rund 600.000 Hotels können über diese Webseite gefunden werden. Eine Community erweitert die Suchergebnisse mit eigenen Erfahrungsberichten, Fotos oder anderen Informationen. Im Dezember 2012 wurde trivago mehrheitlich von Expedia übernommen. Trivago war die erste Hotel-Metasuchmaschine in Deutschlandund zählt europaweit 18 Millionen Besucher pro Monat. Auf Basis des im Dezember 2012 von Expedia vereinbarten Übernahmepreises von 477 Millionen Euro für 61,6 Prozent der Anteile errechnet sich eine Bewertung von 774 Millionen Euro für das Unternehmen.
Quelle:
Die Lücken
Nachdem wir geklärt haben was Trivago eigtl. ist, falls das einer oder eine nicht wusste, können wir uns jetzt den Lücken zuwenden. Die Lücken sind in der Suche (Startseite und andere), im Login und in den Account Details zu finden. Fangen wir doch am besten mit der Lücke in der Suche an? Die Suche kann man wirklich nicht verfehlen. Einmal die Startseite aufgerufen und schon findet man dort die Suche. Einfach in dem linken Input, wo man die Stadt eingeben tut, unseren XSS Code eingeben und schon wird (denke ich) über Ajax eine Livesuche gestartet. Das bedeutet das wir nicht mal Enter drücken müssen. Falls man UNSEREN XSS Code nicht kennt, das wäre dieser:
<script>alert(/secure-sites.de/);</script>
Der Code funktioniert aber nicht immer. Also nicht wundern falls er auf anderen Seiten nicht funkt. Das Ergebnis hier nocheinmal im Bild:

Soviel zur ersten Lücke. So wo sind denn die anderen Lücken versteckt? Die nächste Lücke ist im Login versteckt. Hier schonmal im Bild:

Um diese Lücke auszuführen, müssen wir oben rechts im Bild auf Einloggen klicken und dann nochmal auf Einloggen. Es öffnet sich ein Fenster, welches sich über die Seite als ???Layer??? sag ich mal legt. Dort ist der Input der für die E-Mail/Nutzername/Alias verantwortlich ist verwundbar. Dort würde unser XSS Code den wir oben benutzt haben schon nicht mehr funktionieren. Wir müssen diesmal eine kleine Abweichung des Codes nutzen. Und zwar schließen wir den ersten Tag und öffnen dann erst unseren XSS Code den wir oben benutzt haben. Damit kann man das ein oder andere mal zum Erfolg kommen, auch wenn der andere Code versagt hat. Und zwar schaut der Code dann im Ergebnis so aus:
"><script>alert(/secure-sites.de/);</script>
Wir können ja mal schauen wir das im Quellcode ausschaut oder? Dazu einfach Strg+U und schon sehen wir dort zuerst unseren Input Code:
<input id="email" class="textfield" type="text" value="" spellcheck="false" autocapitalize="off" autocorrect="off" autocomplete="off" name="_username" tabindex="1"></input>
Dann haben wir unser Script und dann kommt dieser ???verirrte??? Code sage ich mal:
"/>
Soviel zu unserer 2. Lücke. Jetzt kommen wir noch zu der 3. Seite, auf der auch wieder 3 Lücken warten. Und zwar müssen wir uns dazu erst einmal einloggen bzw. registrieren. Nachdem wir uns eingeloggt haben, klicken wir auf unseren Usernamen und dann auf Accounteinstellungen. Dort im Layer dann unter Accountdetails auf Name, E-Mail & Passwort. Dort sehen wir jetzt 4 Input Felder. Alle außer das Input vom Passwort sind verwundbar. Wir müssen wieder unseren abgewandelten Code benutzen.
Das Endprodukt schaut dann so aus:

Der Support wurde mehrmals angeschrieben. Über Facebook sowie per Email. Keinerlei Fixes. Einmal schrieb man mir das man sich melden werde. Das ist auch schon ne halbe Ewigkeit her.
Alle Credits an: Maurice Woitzyk
Quelle:
MfG,
Framerater