OAuth 2.0 und OpenID: Sicherheitslücke gefunden
von caschy | 13 Kommentare
Nach OpenSSL mit dem Heartbleed-Bug hat es anscheinend die nächste Open Source-Lösung getroffen. Die von Google, Facebook und unzähligen anderen Diensten genutzten Login-Verfahren via OpenID und OAuth sollen eine Sicherheitslücke aufweisen, wenn Anbieter die Implementierung nicht korrekt absichern. Die Sicherheitslücke, gefunden von Wang Jing, Student an der Nanyang Technological University, hört auf den Namen Covert Redirect und soll Angreifern das Ausspähen eurer Daten erlauben.
Einige Dienste bieten das Login via Google, Twitter oder Facebook an und eben hier soll sich die Sicherheitslücke verbergen – nicht in der Lösung, wohl aber in der Implementierung der einzelnen Dienste.. Ein Angreifer könnte mit einem speziellen Phishing-Link das Opfer dazu bringen, sich via Facebook einzuloggen – hierzu bedient sich der Angreifer einer legitimen Adresse und eines legitimen App-Logos – stellt euch hier irgendeinen Dienst vor, zum Beispiel Foursquare oder ESPN.
Autorisiert sich der Angegriffene via der Methode, so hat der Angreifer Zugriff auf Daten, die zum Beispiel bei Facebook hinterlegt sind. Prinzipiell werden also die Daten freigegeben, die die App beim Login beim OAuth- oder OpenID-Provider einfordert. Bei Facebook könnte das eure Telefonnummer sein, eure Mail-Adresse, euer Geburtstag oder ähnliches – auch das Weiterleiten auf eine mit Malware verseuchte Seite könnte möglich sein, oder das Verwalten eures Accounts.
Wang Jing kontaktierte bereits Facebook, von dort wurde ihm mitgeteilt, dass eine Behebung lange Zeit dauern könnte, man sei sich der Gefahr bewusst. Benutzer sollten in Zukunft sehr genau aufpassen, ob nach dem Klicken eines Links eine Seite dazu auffordert, sich via Facebook, Google und Co zu authentifizieren, wie man bei Cnet mitteilt. Heißt: jeder Brain 1.0-Nutzer sollte sicher sein.
Unternehmen, die die Methode anbieten, müssen jetzt bestenfalls Redirect-URLs registrieren, Linkedin hat Entwickler dahingehend schon aufgefordert. Interessant ist dahingehend, dass Google erste neulich mitteilte, dass man Entwickler zu OAuth 2.0 zwingen wollte. Wang schreibt in seinem Blog, wie die einzelnen Firmen geantwortet haben.
https://www.youtube.com/watch?v=HUE8VbbwUms
Wird geladen ...
OpenSource ist eben leider doch keine Gewähr für mehr Sicherheit.
@Besucherpete Das war es auch nie. Nicht in dem Sinne, wie es seit dem OpenSSL Bug totgeritten wird. Aber es geht auch darum, wie mit Problemen umgegangen wird und wie sie aufgedeckt werden. Und die Argumentation dann von einigen „Spezialisten“, dass dann ja kommerzielle (closed source) Software so viel besser ist, weil mehr Geld vorhanden und die Entwickler bezahlt, (beliebige Gründe einfügen), … ist eben leider auch Augenwischerei. Denn bei deren Produkt muss ich der Firma vertrauen, dass sie mir erzählt wenns ein Problem gibt. Da ist es mir lieber, jemand deckt überhaupt die Probleme auf, als dass sie jahrelang einfach existieren und man sie totschweigt und sich in (Schein-)Sicherheit wiegt.
Und was ist bitte an Phishig neu?
Nix als Panik mache…
Jeder halbwegs Tech-versierte kann sowas mit brain 1.0 erkennen…
@Fogel: Problem ist nur, dass viele leider noch Brain v0.9 beta benutzen und nicht auf die Final Version upgraden.
@cashy: Im ersten Satz setzt du es in Folge von Harthbleed und nennst OAuth eine „Software“? Da stimmt doch was nicht, OAuth ist keine Software sondern eben nur ein Verfahren oder irre ich mich da?! Und das in den Kontext mit Harthbleed zu setzen, klingt auch nicht wirklich koscher. Diese Sicherheitslücke ist soweit ich weiß vielmehr das Konzept von OAuth und einige Anbieter wie Google zeigen bei jedem Request auch direkt an, wohin der Nutzer weitergeleitet wird. Facebook hatte das früher glaube ich auch mal angezeigt. Ich verstehe also diese plötzliche „Sicherheitslücke“ irgendwie nicht.
@Peter: habe es durch „Lösung“ ersetzt. Und auch ein Verfahren ist eigentlich im gewissen Sinne eine Software-Lösung.
Nach „Ein Angreifer könnte mit einem speziellen Phishing-Link das Opfer dazu bringen…“ habe ich nicht mehr weitergelesen
@Fogel: In Kombination mit einem XSS auf einer seriösen Seite, die du gar besuchen wolltest, wird das auch dein Brain 1.0 nicht checken! 😉
@Caschy: Jetzt nennst Du es „Open-Source-Lösung“, aber der Begriff trifft es auch nicht. Der richtige Begriff ist „Offenes Protokoll“, so wird es übrigens auch in der Wikipedia definiert.
Wäre schön, wenn Du das korrigieren könntest, sonst ensteht ein völlig falscher Eindruck.
Also für mich ist ein Anmelden auf einer Fremdseite mit z.B. Google Account schon eine Sicherheitslücke durch die Funktion. Ich meine, die Grundidee dahinter ist eben nichts anderes als Pishingmails, die einem zum Anmelden auf z.B. der Bankseite auffordern. Der Link zeigt dann die vermeintliche Bankseite, die Anmeldedaten werden abgefangen. Das Protokoll macht doch eigentlich nichts anderes. Es tunnelt die Anmeldung auf der Drittseite über Google. Nur ist nicht wirklich erkennbar, ob der Tunnel auch bei Google landet, es also echt ist.
Der Artikel ist leider wirklich schlecht. Hier wird von open source gesprochen obwohl kein Code involviert ist, sondern nur das Verfahren.
>Nach OpenSSL mit dem Heartbleed-Bug hat es anscheinend die nächste Open Source-Lösung getroffen.
OAuth ist, wie schon von anderen Kommentatoren angemerkt, ein standardisiertes, offenes Protokoll. Ob die konkreten Implementationen Open Source sind oder nicht, hat mit dem beschriebenen Problem nichts zu tun.
Sofern ich es richtig verstanden habe, handelt es sich hier nicht um eine Sicherheitslücke im klassischen Sinn, sondern bloß um einen (offenbar weit verbreiteten) Implementierungsfehler. Im OAuth-Standard wird auf das Problem hingewiesen:
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-4.1.5
Wenn auf der Seite einer Drittanbieteranwendung ein offener Redirect ist, kann dieser dazu genutzt werden, um an den Token der Anwendung zu gelangen. Das war vorher schon bekannt. OAuth-Provider wie Google können hier nicht viel mehr tun, als die Anwendungsentwickler auf das Problem hinzuweisen und die entsprechenden Möglichkeiten zum Einschränken der Redirect-URLs anzubieten.
Ich kann aber die Aufregung nicht ganz verstehen. Es ist gut und richtig, auf die Gefahr hinzuweisen, aber es handelt sich hier nicht um eine neu entdeckte, kritische Sicherheitslücke in einer Open Source-Komponente wie bei OpenSSL.