Facebook Anwendungen Design-Schwachstelle

Facebook Anwendungen Design-Schwachstelle

Marc Ruef
von Marc Ruef
Lesezeit: 16 Minuten

Das US-amerikanische Unternehmen Facebook stellt mit facebook.com den gegenwärtig populärsten Vertreter sozialer Netzwerke zur Verfügung. Der in erster Linie für Privatanwender ausgerichtete Dienst listet über 400 Millionen Benutzer weltweit, wobei sich davon 50 % einmal pro Tag einloggen und 9 % ihren Status aktualisieren.

Facebook ist darum bemüht, wie auch andere Plattformen, durch offene Schnittstellen die Unterstützung für Applikationen bereitzustellen. Dadurch kann die Funktionalität des Dienstes durch Drittanbieter erweitert werden. In diesem Beitrag werden wir die FQL-Kommunikation mit Facebook erklären und damit eine grundlegende Schwachstelle im Anwendungsdesign aufzeigen:

Schwachstelle: Jede Facebook-Anwendung muss durch einen Benutzer genehmigt werden. Anhand eines API-Schlüssels wird diese dann durch Facebook authorisiert, auf gewisse Datenbestände zuzugreifen. Durch das Auslesen von API-Schlüsseln öffentlichen und durch Benutzer genehmigte Applikationen, können diese emuliert und damit erweiterte Rechte auf Profildaten durch Dritte erlangt werden.

Einführung in FQL

Durch verschiedene Schnittstellen sehen sich Entwickler in der Lage, mit Facebook zu interagieren. Dadurch wird die Grundlage für Games und Anwendungen geschaffen. Einer dieser Mechanismen ist FQL. Dieses Akronym steht für Facebook Query Language, eine stark an SQL angelehnte Sprache für Datenbankabfragen:

Facebook Query Language, or FQL, allows you to use a SQL-style interface to more easily query the same Facebook social data that you can access through other Facebook API methods (assuming your application has access!).

Jedem steht es frei, eine eigene Applikation für Facebook zu schreiben. Hierzu ist es lediglich erforderlich, dass man sich im Besitz eines gültigen Facebook-Kontos befindet. Einmal eingeloggt muss man auf diesem lediglich die Developers Application installieren. Innerhalb dieser können nun neue Anwendungen initialisiert werden. Im Rahmen der Konfiguration einer solchen erhält man daran gebundene Authentisierungs-Daten. Diese bestehen aus einem API-Key (Benutzername) und einem API-Secret (Passwort). Diese werden benötigt, damit die Anwendung durch Facebook identifiziert und im Rahmen des Dienstes agieren kann.

Die Facebook-Libraries stehen für verschiedene Plattformen zur Verfügung (z.B. PHP, Perl und Javascript). Diese erlauben eine sehr einfache Interaktion mit den API-Schnittstellen. Im gezeigten Beispiel werden wir die offizielle PHP5-Library, wie sie von Facebook zum Download angeboten wird, benutzen. Nachfolgendes Skript – es handelt sich dabei um eine sogenannte Desktop Application – zeigt an einem sehr einfachen Beispiel, wie grundlegende Informationen zu einem Benutzer ausgelesen werden können:

<?php

require ‘_inc/facebook.php’;

$apikey = ‘my_public_api_key’; $apisec = ‘my_hidden_api_secret’;

$facebook = new Facebook($apikey, $apisec);

$fql = ‘SELECT uid, first_name, last_name FROM user WHERE uid=123456790’; $result = $facebook->api_client->fql_query($fql); print_r($result);

?>

Zuerst wird mit require die PHP-Library eingebunden. Danach werden in den Variablen $apikey und $apisec die der Applikation zugewiesenen Authentisierungsdaten abgelegt und damit das Objekt $facebook instanziert. Nun wird die FQL-Abfrage vorbereitet. Diese führt eine SELECT-Abfrage für die Felder uid (User-ID), first_name (Vorname) und last_name (Nachname) der Tabelle user durch, wobei jene Datensätze ausgegeben werden sollen, bei denen die uid auf den Wert 1234567890 gesetzt wurde. Dieses FQL-Statement wird dann entsprechend über den API-Client aufgerufen und das in $result ausgegebene Resultat mit der Debugging-Funktion print_r() von PHP ausgegeben.

Wird nun dieses Skript aufgerufen, kann offensichtlicherweise gesehen werden, dass Vor- und Nachname des Benutzers mit der uid 1234567890 (dies ist ein fiktiver Beispielbenutzer) ausgelesen werden kann. Im zurückgegebenen assoziativen Array werden in den Feldern $result[0]['first_name'] der Wert Alan und in $result[0]['last_name'] der Wert Turing abgelegt:

maru@debian:~/labs/facebook$ php fql_userdata.php
Array
(
    [0] => Array
        (
            [uid] => 1234567890
            [first_name] => Alan
            [last_name] => Turing
        )
)

Automatische Datensammlung

Durch ein solches Skript kann nun eine automatisierte Auswertung von Facebook-Usern umgesetzt werden. Die folgende Anpassung der Abfrage führt dazu, dass für sämtliche Benutzer mit den User-ID 10000 bis 20000 der Name und die URL des Profilbilds (pic) ausgelesen und in einer CSV-Liste dargestellt werden:

for($i=10000; $i<20000; ++$i){
	$fql = 'SELECT uid, name, pic FROM user WHERE uid='.$i;
	$result = $facebook->api_client->fql_query($fql);
	echo $result[0]['name'].';'.$result[0]['pic']."\n";
}

Die Definition der WHERE-Klausel lässt sich nur auf indizierbare Datenfelder anwenden (Indexable). Im Fall der Tabelle User sind dies uid (User-ID), name (kompletter Name) und username (Benutzername). Ein Filtern nach Geschlecht oder Religionen ist aus Sicherheitsgründen innerhalb des FQL-Statements nicht möglich.

$fql_uid = 'SELECT uid FROM user WHERE uid=123456790';
$fql_name = 'SELECT uid, name FROM user WHERE name="Alan Turing"';
$fql_user = 'SELECT uid, username FROM user WHERE username="turing1912"';

Durch die Iteration der User-ID, dies kann durch eine simple for-Schleife geschehen, können schnell und effizient die Daten verschiedener Personen zusammengetragen werden (ein Filtern der Datensätze kann anhand der Rückgabedaten geschehen). In der gezeigten Fassung des Skripts können jedoch nur jene Felder der Tabelle ausgelesen werden, die durch die Benutzer in ihren Privatsphäre-Einstellungen für Alle freigegeben wurden. Dies sind einerseits die für die Suche indizierten Grunddaten:

Zusätzlich sind dies aber seit den umstrittenen Anpassungen der Freigabemöglichkeiten Ende 2009stetige Anpassungen an den Privacy-Einstellungen können dies aber in Zukunft ändern – ebenfalls standardmässig (können jedoch individuell angepasst werden):

Jenachdem wenn ein Benutzer ein Mehr an Freigaben umgesetzt hat, können ohne weiterführende Authentisierung auch auf diese zugegriffen werden. Das Skript kann jedoch dahingehend erweitert werden, dass es einen Login für einen legitimen Facebook-Account vornimmt und damit mit einer Session samt session_key aufwarten kann. Stehen das eigene Konto und das Konto der Zielperson in Beziehung zueinander (Freundschaftsanfrage angenommen), dann kann im Rahmen des erweiterten Kontext agiert werden. Damit werden Zugriffe auf Bereiche möglich, die nur für Freunde einsehbar sind (standardmässig sind dies Kommentare zu Beiträgen). Das Auswerten der eigenen Freunde oder das Heranziehen eines populären Fake-Accounts können Zugriffe also massgeblich optimieren.

In Bezug auf die Zugriffsrechte ist eine interessante Diskrepanz zwischen FQL und der offiziellen Facebook-Webseite zu beobachten. So sei ein Foto-Album nur für Freunde einsehbar. Ein Darin gepostetes Foto ist jedoch für Alle einsehbar. In diesem Fall kann über die Webseite nicht auf das Foto zugegriffen werden, da immer zuerst die Rechte des Eltern-Objekts (in diesem Fall das Foto-Album) mitberücksichtigt werden. Durch einen Zugriff über FQL wird es möglich, diese Einschränkung zu umgehen, indem direkt auf das Bild zugegriffen und damit das Album nicht tangiert wird.

Genehmigung von Facebook-Anwendungen

Doch noch auf einer weiteren Ebene müssen Zugriffsberechtigungen berücksichtigt werden. Und zwar erlaubt Facebook, dass eine Anwendung autorisiert wird. Bei der Installation bzw. ersten Nutzung dieser durch den Anwender kann sie sich um eine entsprechende Freigabe bemühen. Der Benutzer geht mit der Applikation eine ähnliche Beziehung ein, wie durch das Akzeptieren einer Freundschaftsanfrage. Dabei kann der Benutzer um das Zulassen unterschiedlicher Zugriffe (extended permissions) erfragt werden. Für eine Desktop-Anwendung wie die unsere wird es beispielsweise erforderlich, dass offline_access unterstützt wird. Damit können Zugriffe getätigt werden, auch wenn der Benutzer offline ist und keine Session besteht.

Wird einer Anwendung durch einen Benutzer erweiterte Rechte beigemessen, können diese von nun an gebraucht werden. Dabei identifiziert Facebook anhand des eingehend beschrieben API-Key, welche Anwendung einen Zugriff durchführen möchte. Gehört diese zu den beglaubigten Applikationen, wird der Zugriff, sofern der das richtige API-Secret mitgeliefert wird, erlaubt. Das grundlegende Problem ist nun, dass ein böswilliger Entwickler darum bemüht sein kann, eine den Zugriff einer legitim beglaubigten Applikation vorzutäuschen. Zu diesem Zweck muss er lediglich Key und Secret in Erfahrung bringen und in seiner Anwendung nutzen. Hierzu können verschiedene technische Möglichkeiten verfolgt werden:

Der API-Key wird als öffentlich verstanden. Er ist beispielsweise für sämtliche Applikationen im Feld api_key in der Tabelle application ausgewiesen. Das Risiko des Diebstahls des API-Secret ist Facebook bewusst und wird in den Developer-Dokumenten an verschiedenen Stellen hervorgehoben:

When you configure an application with the Facebook Developer application, you are given an API key and an application secret. You can disregard the application secret and you should never include it in your desktop application’s code, as it can be decompiled and used maliciously.

Ein typisches Beispiel für eine quelloffene Applikation, aus der man Key und Secret einfach auslesen kann, ist die offizielle Facebook-Toolbar für Firefox. Standardmässig findet sich im Verzeichnis der Extension das Unterverzeichnis components. In diesem ist die Datei facebook.js enthalten. Wird diese in einem Dateieditor geöffnet, kann die Funktion facebookService() gesucht werden. Zu Beginn dieser werden die beiden Werte in den jeweiligen Variablen festgelegt (getestet in Version 1.4.2):

this._apiKey = '8d7be0a45c164647647602a27106cc65';
this._secret = 'c9646e8dccec4c2726c65f6f5eeca86a';

Diese Werte können nun in die eigene Applikation übernommen werden, indem die ursprünglich für sich selbst vorgesehenen Werte überschrieben werden. Von nun an hält Facebook unsere Applikation für eine Ausgabe der Facebook-Toolbar. Erlaubt ein Anwender erweiterte Zugriffe für diese Anwendung, können wir von dieser vorangegangenen Autorisation profitieren. Auf der Seite der Applikation findet sich eine Liste sämtlicher Fans eben dieser (über 20’000 Fans, 15’500 Benutzer pro Monat, Stand April 2010). Es bietet sich sodann an, all jene mit einer erweiterten Auswertung über FQL anzugehen. In der Tabelle user kann das bool’sche Datenfeld is_app_user ausgelesen werden, um zu erkennen, ob ein Anwender die eigene Applikation benutzt. Die Tabelle permissions kann genutzt werden, um die vom Benutzer genehmigten Zugriffe zu identifizieren.

Zugriffsrechte einer Facebook-Anwendung

Es liegt mitunter an den Entwicklern von Anwendungen, dass sich diese nicht in unnötiger Weise um erweiterte Zugriffsmöglichkeiten bemühen sowie ihre geheimen API-Informationen öffentlich machen (letzteres ist bei quelloffenen Projekten leider nicht wirklich verhinderbar; es ist anzunehmen, dass irgendwann geheime Keys getauscht werden). Die benannte Toolbar ist ein Lehrstück darin, wie nur die wirklich benötigten Genehmigungen eingeholt werden. So werden nicht einfach pauschal sämtliche Zugriffsmöglichkeiten angefragt.

Genehmigung der Facebook-Symbolleiste für Firefox

Eine Anwendung kann über verschiedene Mechanismen eine Autorisierung erfragen. Bei Desktop-Applikationen – wie unseres PHP-Skripts – bietet sich hierfür der Browser-Zugriff über eine präparierte URL an. Ruft ein Benutzer diese Seite auf, muss er sich zuerst auf Facebook einloggen (falls keine authentisierte Session besteht), um dann die Autorisation zu beglaubigen:

http://www.facebook.com/login.php?api_key=my_public_api_key&connect_display=popup&v=1.0&next=http://www.facebook.com/connect/login_success.html&cancel_url=http://www.facebook.com/connect/login_failure.html&fbconnect=true&return_session=true&session_key_only=true&req_perms=read_stream,publish_stream,offline_access

Das Erstellen und Verschicken solcher URLs kann eigentlich autonom von der eigenen Anwendung geschehen. Zum Beispiel könnte im Rahmen eines zielgerichteten Social Engineering-Zugriffs oder einer breitflächigen Phishing-Attacke die entsprechenden Genehmigungen (auf Vorrat) eingeholt werden. Wird eine Applikation einem Benutzer schmackhaft gemacht, könnte dieser in seiner Leichtgläubigkeit die erweiterten Zugriffsrechte ohne Bedenken vergeben. Weiterführende Zugriffe mit den erweiterten Rechten werden dadurch möglich.

Auch wenn einer Applikation gewisse Zugriffsrechte eingeräumt wurden, kann diese dann nicht ohne weiteres nach Belieben agieren. Für gewisse Zugriffe ist eine Authentisierung mit den legitimen Benutzerdaten des zu tangierenden Kontos erforderlich. Zum Beispiel für das Auslesen des Nachrichteneingangs oder das Erstellen von neuen Statusmeldungen.

Fazit

Dieses erweiterte Angriffsszenario illustriert ein generelles Problem von Facebook. Eine ausgeführte Anwendung, dies kann auch Online-Applikationen betreffen, nimmt für sich ein relativ hohes Mass an Zugriffsrechten in Kauf (mindestens jene aus User.getStandardInfo). Werden gar zusätzliche Rechte während der Autorisation eingeräumt, kann diese Anwendung genutzt werden, um ein regelmässiges und umfassendes Ausspionieren des Benutzers voranzutreiben. Data Mining einer Zielperson wird damit sehr einfach und effizient umsetzbar. Erste Forschungsresultate wurden in den letzten Wochen veröffentlicht und die Angriffsmöglichkeiten lassen sich noch weiterspinnen.

Dubiose Applikationen werden voraussichtlich einen grossen Teil des Angebots auf Facebook ausmachen. Die Identifikation dieser durch Anwender wird aufgrund der fehlenden Quelloffenheit nicht ohne Weiteres möglich sein. Verdachtsmomente sollten jedoch dringend berücksichtigt und auf das Installieren unnötiger Anwendungen verzichtet werden. Das Umsetzen von Schutzmassnahmen in Sozialen Netzen muss also sowohl für Anwender als auch für Applikationen durchgesetzt werden.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie wollen die Awareness Ihrer Benutzer prüfen?

Lassen Sie durch uns einen Social Engineering Test durchführen!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv