Mehr Fakten und Spekulationen zu Skypes ominösen Link-Checks

Unsere Entdeckung, dass via Skype verschickte URLs von Microsoft besucht werden, hat für einigen Aufruhr gesorgt. Mittlerweile liegen etwas mehr Informationen dazu auf dem Tisch.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 4 Min.

Zu Beginn der Woche berichtete heise Security, dass Links, die in privaten Skype-Chat-Sitzungen verschickt werden, kurze Zeit später von einem System von Microsoft besucht werden. Wir beobachteten ausschließlich Zugriffe auf https-URLs. Dabei nutzte Microsoft alle übertragenen Informationen – einschließlich der häufig in https-URLs enthaltenen Session-IDs oder Benutzerkennungen. Die Zugriffe erfolgen via HEAD-Request, fragen also lediglich Verwaltungsinformationen ab, nicht jedoch die Inhalte der Seiten.

Diese Fakten wurden nach der Veröffentlichung von mehreren unabhängigen Experten bestätigt. Auch wenn wir keine Zugriffe auf die ebenfalls verschickten, ungesicherten http-URLs registrierten, liegen mittlerweile glaubwürdige Berichte vor, dass Microsoft diese in manchen Fällen ebenfalls abruft.

Darüber hinaus gab es eine Reihe von Spekulationen, dass es sich um eine Sicherheits-Funktion im Rahmen von SmartScreen-Filter handle. Das ist eine durchaus plausible Arbeits-Hypothese, die allerdings mehr Fragen aufwirft, als sie beantwortet. Das beginnt mit der Frage, warum der Test nicht unverzüglich sondern mit einem zeitlichen Versatz von mehreren Stunden stattfindet. Bei einer aktiven Spam- oder Phishing-Kampagne ist Zeit ein kritischer Faktor; ein Test von mehreren Stunden alten URLs hat bestenfalls noch dokumentarischen Charakter.

Als nächstes stellt sich die Frage, wie Microsoft die Seiten bewerten will, ohne den Inhalt zu kennen. Die Verweise auf eine Reputationsdatenbank sind nicht stichhaltig, wenn für die Seiten – wie bei den speziell für den Test erstellten URLs – bislang keinerlei Referenzdaten vorliegen können. Auch der Hinweis, dass es nur darum ginge, mit dem HEAD-Request eventuelle Weiterleitungen auf bekanntermaßen bösartige Seiten zu entdecken, kann nicht überzeugen. Denn zum einen kann eine solche Weiterleitung auch im nicht abgerufenen HTML-Code erfolgen (meta http-equiv="refresh"). Und zum anderen binden viele Web-Seiten den eigentlichen Schadcode etwa über iFrame-Tags ein – ebenfalls in den HEAD-Daten nicht sichtbar.

Und schließlich ist der Einsatz der SmartScreen-Filter-Technik etwa im Internet Explorer dokumentiert und der Anwender hat die Möglichkeit sie abzuschalten. Nicht so bei Skype. Weder gibt es konkrete Hinweise auf den Einsatz von SmartScreen im Rahmen von Skype-Chats, noch kann der Anwender den Einsatz dieser Überwachungstechnik widersprechen.

Alles in allem ist es trotzdem wahrscheinlich, dass die beobachteten Zugriffe im Zusammenhang mit irgendeiner Form von Schutzfunktion stehen. Doch wenn es so ist, ist diese wenig durchdacht. Der mögliche Nutzen ist sehr gering – vor allem in Anbetracht der doch recht gravierenden Eingriffe in die Privatsphäre. Immerhin greift Microsoft dabei auch persönliche, nicht für Dritte gedachte Informationen – also etwa die an die Mutter geschickte URL zum privaten Bilder-Album des Familienausflugs – gezielt ab und speichert diese anschließend auf eigenen Systemen. Da wäre es zum Mindesten angebracht, dass Microsoft den Einsatz solcher Überwachungsfunktionen erstens dokumentiert und zweitens eine Möglichkeit einräumt, auf den gut gemeinten Schutz doch lieber zu verzichten.

Bei unseren letzten Tests mit Links, die wir über Skype verschickten, beobachteten wir keine Zugriffe aus Redmond mehr. Es ist zu hoffen, dass Microsoft die Konsequenzen aus diesem Fiasko zieht und diese Funktion zumindest vorübergehend still gelegt hat. Jetzt ist ein guter Zeitpunkt, in sich zu gehen, Kosten und Nutzen der Überwachung genau zu überdenken und dann zu überlegen, wie man das richtig machen kann. Unsere analogen Tests mit den Chats von Google, Facebook und ICQ erbrachten übrigens keine Ergebnisse – sprich: es erfolgten keine Zugriffe auf die speziellen URLs, die wir dort verschickten. (ju)