Schwachstelle in der myCloud - CORS-Fehler erklärt

Dieser Artikel beschreibt eine Schwachstelle, die sich auf mycloud.ch befand und es unter gewissen Umständen ermöglichte, Dateien von fremden Accounts herunterzuladen und neue Dateien hochzuladen. Die Schwachstelle wurde durch die Swisscom im Rahmen des Bug Bounty Programmes der Swisscom behoben (siehe Timeline).

Was ist CORS?

Greift man auf die myCloud zu, sind, wie bei vielen anderen WebApps auch, mehrere Server beziehungsweise Quellen im Spiel. So liegen beispielsweise die auf der Cloud gespeicherten Dateien auf einem anderen Server als die Webapplikation (das Dashboard) selbst. Damit diese Dateien auch im myCloud-Dashboard aufgelistet werden können, muss der Webbrowser diese (bzw. eine Liste der vorhandenen Dateien) nach dem Aufrufen von mycloud.ch auf diesem externen Server per JavaScript abrufen und mycloud.ch zur Verfügung stellen. Zur Authentifizierung müssen natürlich die Cookies, mit denen der Nutzer eingeloggt ist, mitgesendet werden. Denn die Cookies werden von der Webapplikation dazu verwendet, den Benutzer zu identifizieren, damit z.B. die Dateien korrekt zugeordnet werden können.

Wie weiss nun aber der Webbrowser, dass mycloud.ch tatsächlich dazu berechtigt ist, auf die Dateien, die auf diesem externen Server liegen, zuzugreifen? Würden solche Zugriffe nicht kontrolliert, könnte jede Website mit einem kleinen JavaScript-Script auf die erwähnten Dateien zugreifen.
Hier kommt nun CORS ins Spiel. CORS steht für Cross-Origin Resource Sharing, zu Deutsch etwa Teilen von Dateien zwischen mehreren Quellen. Dabei handelt es sich um HTTP-Headers, die vom Server zurückgesendet werden. Diese bestimmen, ob eine bestimmte Seite auf eine Ressource zugreifen darf und ob die Cookies mitgesendet werden dürfen; die Cookies sorgen dafür, dass der Nutzer als eingeloggt erkannt wird. Wenn also jede Website die Cookies mitsenden darf, kann diese sozusagen im Namen der eingeloggten Personen Aktionen ausführen (und Dateien abrufen).

Dieser Screenshot zeigt die Anfrage an den Server von Swisscom (storage.prod.mdl.swisscom.ch), auf dem die Dateien der myCloud liegen. Für den Browser ist es natürlich nicht selbstverständlich, dass die Website mycloud.ch auf Daten von storage.prod.mdl.swisscom.ch zugreifen darf. Deshalb muss dies mithilfe von CORS erlaubt werden.
In diesem Fall läuft dies wie folgt ab:

• Der Webbrowser sendet einen Request an den Server, auf denen die Dateien liegen und sendet den Origin-Header mit dem Inhalt https://www.mycloud.ch mit (Nummer 1 auf dem Screenshot). Dieser gibt dem Server an, dass die Seite https://www.mycloud.ch per JavaScript auf den Server zugreifen möchte.
• Der Server antwortet mit mehreren CORS-Headern:
  • Der Header Access-Control-Allow-Credentials: true (Nummer 2) gibt dem Browser an, dass bei Requests an den Server die Cookies mitgesendet werden dürfen.
  • Der Header Access-Control-Allow-Origin: https://www.mycloud.ch (Nummer 3) gibt dem Browser an, dass https://www.mycloud.ch auf die Ressource des Servers zugreifen kann.

Die Seite https://www.mycloud.ch darf also per Javascript (XHR) auf storage.prod.mdl.swisscom.ch zugreifen und die Cookies dürfen mitgesendet werden. Also alles so, wie es sein sollte. Oder doch nicht?

Der Fehler

Doch was, wenn die Anfrage von einer anderen Seite stammt?

In diesem Fall stammte der Request von einem Webserver, auf dem das Exploit-Script lag. Die Adresse dieser Seite wurde vom Browser im Origin-Header an den Server (storage.prod.mdl.swisscom.ch) gesendet. Und der Server sendet im Access-Control-Allow-Origin-Header genau das zurück, was im Origin-Header steht. Und auch der Access-Control-Allow-Credentials-Header ist true gesetzt, Cookies werden also mitgesendet.
Ab da war klar, dass ein Fehler vorliegen muss. Denn der Server erlaubte es jeder Seite auf die Dateien der myCloud zuzugreifen.
Allerdings befindet sich noch eine weitere Sicherheitsmassnahme auf dem System. Das Access-Token wird im Authorization-Header gesendet. Dies hätte verhindern sollen, dass genau ein solcher Angriff passieren kann, da das Token nicht von anderen Seiten gesendet werden würde (da das Token nicht in den Cookies sein müsste), selbst wenn der Access-Control-Allow-Credentials-Header auf true gesetzt ist.
Da jedoch das Access-Token (das den Nutzer identifiziert und authorisiert) ebenfalls in den Cookies gespeichert war (Siehe rote Markierung auf dem Screenshot) und der Authorization-Header nicht zwingend gesetzt werden musste, war ein Angriff möglich. Heisst, sobald jemand eine böswillige Seite öffnet, auf der sich ein entsprechendes Script befindet, wäre es möglich, alle Dateien, die sich in der myCloud dieser Person befinden auf einem fremden Server abzuspeichern und / oder neue Dateien hochzuladen. Vorstellbar wären z.B. Erpressungsversuche oder auch “nur” ein Diebstahl von allen Dateien & Fotos. Die einzige Voraussetzung dafür war, dass der Nutzer auf mycloud.ch angemeldet ist. Über Phishingmails oder gut platzierte Links (z.B. im Swisscom-Forum) hätten Nutzer auf Seiten mit verstecktem Exploit-Script gelockt werden können… Doch diese Schwachstelle wurde behoben und es gibt keine Hinweise darauf, dass die Lücke ausgenutzt wurde.

Timeline

• 27.12.2019: Schwachstelle entdeckt
• 27.12.2019: Schwachstelle über das BugBounty-Portal der Swisscom gemeldet
• 30.12.2019: Empfangsbestätigung von Swisscom erhalten (Triagiert)
• 07.01.2020: Analyse der Schwachstelle abgeschlossen
• 14.01.2020: Fix fertiggestellt
• 18.01.2020: Fix deployed; Fehler behoben

Tags:
• Swisscom
,
• Sicherheitslücke
,
• Cors
,
• Mycloud
,
• Write up

Rubrik:
• Sicherheitslücken