Web-Sicherheit

Januar 9, 2012

Shreeraj Shah präsentiert Angriffstechniken auf aktuelle Webtechnologien

Filed under: Allgemein — sebastiankuebeck @ 22:34
Tags: , , , , , , , , ,

Shreeraj Shahs Präsentation von der AppSecUS 2011 (die er auch auf der Blackhat- und OWASP-Konferenz gehalten hat) über Angriffstechniken auf aktuelle Webtechnologien HTML5, XHR and DOM Security ist nun online verfügbar, zusammen mit seinem Paper Reverse Engineering Browser Components – Dissecting and Hacking Silverlight, HTML 5 and Flex.

Wie der Titel schon andeutet, geht es dabei nicht um HTML 5 alleine sondern auch umd das Zusammenspiel von Browsern und Plugins wie Flash und Silverlight. Er beschreibt darin detailliert, wie man aktuelle Webanwendungen gezielt auf Schwachstellen untersucht und diese dann ausnutzt.

Es werden dabei kaum  grundsätzlich neue Angriffstechniken vorgestellt, sondern gezeigt, wie bestehende Angriffstechniken (Cross-Site Scripting, Cross-Site Request Forgery, Clickjacking) mit aktuellen Browsern und Plugins noch wirksamer eingesetzt werden können.

Oktober 25, 2011

Durch Fehler in Flash lassen sich Computerbenutzer über die Webcam ausspionieren

Filed under: Allgemein — sebastiankuebeck @ 14:14
Tags: , , , , , , , ,

In Abschnitt 10.5 meines Buches beschreibe ich Clickjacking, eine Angriffstechnik, mit der Angreifer Teile einer Webseite auf ihrer eigenen einblenden, um Besucher dazu zu bringen, Aktivitäten auf der legitimen Webseite durchzuführen, die der Benutzer gar nicht beabsichtigt. Es ist also eine Variante von Cross-Site Request Forgery für die allerdings gar keine Schwachstelle in der Webanwendung notwendig ist. Damit der Benutzer nur jene Teile zu sehen bekommt, die ihm der Angreifer zeigen will, verwendet letzterer beispielsweise ein DIV-Element das er vor einem IFrame platziert.

„Klassischer“ Clickjaking-Angriff auf Facebook von 2010.

Da sich auch Flash-Inhalte durch ein DIV-Element abdecken lassen, war es bis vor einiger Zeit möglich, den arglosen Benutzer dazu zu bringen, die Webcam aufzudrehen. So konnte der Angreifer alles mitverfolgen, was die Webcam des Benutzers erfasste, wie folgendes Video demonstriert.

Clickjaking-Angriff auf Webcam des Seitenbesuchers 2008.

Inzwischen hat Adobe das Problem durch ein Update das Flash-Plugins behoben, indem das Plugin eine Technik namens Framebusting verwendet, die das Anzeigen des Plugins (genauer gesagt, das Anzeigen der Dialogbox, mit der der Benutzer das Aktivieren der Webcam genehmigt) innerhalb eines IFrames verhindert. Wie sich allerdings inzwischen herausstellt, lässt sich dieser Schutz umgehen. Feross Aboukhadijeh, Student der Stanford Universität, fand einen Weg, den Framebusting-Code des Plugins (Details dazu sind in meinem Buch und in diesem Paper zu finden) zu umgehen: Dazu platzierte er einfach die SWF-Datei für die Einstellungen in einem IFrame, was Clickjaking-Angriffe wieder möglich macht.

Feross Aboukhadijeh’s erweiterter Clickjaking-Angriff, der den Schutz des Flash-Plugins umgeht.

Laut Feross Aboukhadijeh funktioniert der Angriff mit allen Flash-Plugin-Versionen, die er getestet hat, für den Mozilla Firefox und den Safari-Browser auf dem Mac. Durch einen Fehler in der CSS-Implementierung funktioniert der Angriff weder auf dem Chrome-Browser für den Mac noch auf den meisten Windows und Linux-Brwosern. Aboukhadijeh veröffentlichte einen Proof-Of-Concept-Code (PoC) auf seinem Blog, nachdem Adobe nicht auf seinen Fehlerbericht reagiert hatte.
Wie es aussieht hat Adobe inzwischen eine Lösung für das Problem gefunden.

Auch wenn das Problem jetzt behoben zu sein scheint, sollte man die Webcam hardwareseitig (oder softwareseitig, wenn das hardwareseitig nicht möglich ist) deaktivieren, wenn man sie nicht benötigt. In der Vergangenheit wurden Webcams bereits dazu missbraucht, Kinder bei der Bedienung ihrer Notebooks zu beobachten.

März 18, 2011

Rezension

Filed under: Allgemein — sebastiankuebeck @ 07:20
Tags: , , , , , ,

Nette Rezension meines Buches von Mark Buzinkay. Der zweite Teil meines Buches ist in der Tat etwas anspruchsvoller, da nicht alle Angriffstechniken ganz einfach zu erklären sind. Aus den bisherigen Workshops weiß ich, dass besonders Cross-Site Request Forgery für die Teilnehmer anfangs nicht ganz leicht zu durchschauen ist. Das hängt wahrscheinlich damit zusammen, das so wenig HTML-Code notwendig ist, um sie auszunutzen.
Um das Verständnis der Angriffstechniken, die im Buch beschrieben sind, zu erleichtern, habe ich eine kleine Demoanwendung in Java entwickelt, die die Schwachstellen, die im Buch beschrieben werden, demonstriert. Sie ist auf der Seite des Verlages unter „Quelltexte“ zu finden.

Demo-Anwendung zur Demonstration von CSRF-Angriffen

Es gibt auch zahlreiche Videos im Netz (wie beispielsweise dieses), in denen das Ausnützen von Cross-Site-Request-Forgery-Schwachstellen demonstriert wird.

Februar 3, 2011

Missbrauchen von HTTP-Statuscodes um an private Informationen zu gelangen

Filed under: Allgemein — sebastiankuebeck @ 11:05
Tags: , , , , ,

Ein Faszinierender Arikel von Mike Cardwell demonstriert, Seitenbetrieber HTTP-Status-Codes missbrauchen können, um festzustellen, ob sich Besucher bei einer Seite bei Facebook, Twitter, GMail oder Digg angemeldet hat.

Mit diesem Skript kann ein Seitenbetreiber beispielsweise erkennen, ob Sie bei GMail angemeldet sind:

<img style="display:none;"
     onload="logged_in_to_gmail()"
     onerror="not_logged_in_to_gmail()"
     src="https://mail.google.com/mail/photos/static/AD34hIhNx1pdsCxEpo6LavSR8dYSmSi0KTM1pGxAjRio47pofm
E9RH7bxPwelO8tlvpX3sbYkNfXT7HDAZJM_uf5qU2cvDJzlAWxu7
-jaBPbDXAjVL8YGpI"/>

Was hier passiert, ist folgendes: Mike Cardwell hat auf seinem GMail-Account ein Foto hochgelden und öffentlich zugänglich gemacht. Der Image-Tag läd nun das Foto und der Browser schickt dabei die Zugangsdaten des Benutzers an GMail, soferne Sie dort angemeldet sind (der Image-Tag ist von der Same Origin Policy ausgenommen, im Gegensatz beispielsweise zum XHR).

Ist dies der Fall, liefert der Server den HTTP-Statuscodes 200 (also OK) zurück. Sind Sie
nicht angemeldet, schickt er einen anderen Statuscode zurück. Diesen Statuscode kann der Seitenbetreiber natürlich nicht direkt auslesen, allerdings ist es eine Eigenheit von Browsern, dass sie den JavaScript-Code in der Eigenschaft onload ausführen, wenn sie den HTTP-Statuscodes 200 erhalten.

Der Browser prüft den Inhalt der Antwort des Servers weiter nicht. So ist es beispielsweise unerheblich, mit welchem Content-Type der Server antwortet. der Inhalt muss also nicht zwangsläufig ein Bild sein. So kann der Seitenbetreiber sicher sein, dass die Funktion logged_in_to_gmail zuverlässig ausgeführt wird, wenn der Browser den Statuscodes 200 erhalten hat und dass ist nur dann der Fall, wenn der Benutzer bereits bei GMail eingeloggt ist.

Die Technik ist vergleichbar mit Cross-Site Request Forgery, allerdings bekommt der Angreifer mit dieser Technik keine Informationen vom Server zurück. Mit der Erweiterung des Ausnützens der onload ist es zumindest also möglich, Informationen über den Status-Code zu erhalten. Ganz abgesehen von den Implikationen, die das auf die Sicherheit von Surfern hat, ergeben sich hier neue Möglichkeiten für Cross-Site-Request-Forgery-Angriffe.

Im Fall von GMail kann man das Spiel noch weitertreiben, so kann man automatisch die GMail-Adresse des Benutzers mithilfe von jQuery in ein Formular einfügen.

$('').hide()
   .attr('src','https://mail.google.com/mail/photos/static/AD34hIhNx1pdsCxEpo6LavSR8dYSmSi0KTM1pGxAjRio47pofm
E9RH7bxPwelO8tlvpX3sbYkNfXT7HDAZJM_uf5qU2cvDJzlAWxu7
-jaBPbDXAjVL8YGpI')
   .load(function(){
      $('a[href^="mailto:"]').each(function(){
         var email = $(this).attr('href').replace(/^mailto:/,'');
         $(this).attr('href','https://mail.google.com/mail/?view=cm&fs=1&tf=0&to='+escape(email));
      });
   })
   .appendTo('body');

Da dieses möglich ist, ist es auch kein Problem, dass der Webseitenbetreiber alle E-Mail Adresse der eingeloggten GMail-Benutzer an seinen Server verschickt. Somit ist der Seitenbetreiber automatisch im Besitz ihrer E-Mail Adresse, wenn Sie seine Seite besuchen!

Januar 31, 2011

Bankenseiten weiterhin unsicher

Filed under: Allgemein — sebastiankuebeck @ 16:32
Tags: , , , , , ,

Gefunden auf heise Security:

Im September berichtete das Computermagazin c’t über ungenügende Sicherheit bei Banken-Websites. Der 16-jährigen Schüler Armin Razmdjou hatte auf den Web-Seiten von 17 Banken Cross Site Scripting Lücken entdeckt. Als er drei Monate später die Web-Auftritte der Banken nochmals testete, fand er in jedem Web-Auftritt erneut ernst zu nehmende Sicherheitslücken.

Weiter heißt es:

Bei der DKB-Bank und Cortal Consors ging es sogar ans Eingemachte. Über geschickt gewählte URLs konnte man Zugriff unter anderem auf Systemdateien des Servers erlangen [Anm: siehe das Kapitel Fehlerhafte Autorisierung in meinem Buch]. Über derartige Lücken lassen sich oft wichtige Daten auf den betroffenen Systemen ausspionieren. Die anderen Lücken ermöglichten vor allem wieder so genanntes Cross Site Scripting, das sich etwa für raffinierte Phishing-Attacken ausnutzen ließe. Häufige Ursache waren Zusatzangebote wie Börsenkurse (Hypo Vereinsbank, DAB), Finanzberatung (Postbank) oder ein Stellenmarkt (Allianz). Aber bei der WestLB, der HSH Nordbank und der Bank of Scotland waren sogar die Login-Seiten nicht ausreichend gesichert.


Hier wurde ein iFrame in die Seiten der Allianz eingeschmuggelt. Weitere Beispiele befinden sich hier. Frame-Spoofing ist übrigens ein Spezialfall einer unsicheren Weiterleitung, welche ich in meimem Buch im gleichnamigen Abschnitt ausführlich behandle.

Ich bin mir ziemlich sicher, dass das nur die Spitze des Eisbergs ist. Wenn Unternehmen bereits Probleme haben, diese relativ einfach zu erkennenenden Schwachstellen zu vermeiden, lauern da sicher noch zahlreiche schlimmere. Ich Tippe einmal blind auf Session-Fixation und CSRF.

Noch schlimmer wiegt, dass es bei den betroffenen Banken offenbar überhaupt kein Problembewusstsein gibt…

Nachdem heise Security die Banken über die Probleme unterrichtete, wurden diese innerhalb weniger Tage behoben. Das gilt im Übrigen auch für ein Sicherheitsproblem auf den Seiten der Credit Europe Bank, auf das der Sicherheitsberater Dirk Wetter die Bank zuvor bereits neun Monate auf verschiedenen Wegen aufmerksam macht.

Diese Banken reagieren offenbar wirklich nur dann, wenn etwas passiert oder wenn jemand mit schlechter Presse droht. Es ist also leider wieder die gesetzliche Keule nötig, damit sich Bankmanager kurzzeitig von ihren Bonuszahlungen abwenden um sich zumindest Kurzfristig der Sicherheit ihrer Kunden zu widmen…

Januar 21, 2011

Sicherheitsprobleme von Browsern

Filed under: Allgemein — sebastiankuebeck @ 15:16
Tags: , , , , ,

Interessante Präsentation über Browser(un)sicherheit von Collin Jackson, Dozent am Carnegie Mellon University Silicon Valley Campus.


Er behandelt speziell die Themen Cross-Site Request Forgery (CSRF) und Probleme beim Session-Management und geht dabei über die Themen hinaus, die ich in meinem Buch beschrieben habe. Das Problem „Login CSRF“ ist dabei eine Kombination von unsicherem Session-Management und mangelhaftem Schutz vor CSRF.

Ich habe auch ausschließlich die Verteidigung mittels Token beschrieben, da das nach Meinung der OWASP und meiner Meinung die Sicherste Lösung darstellt. Die Idee, die Restriktionen beim Setzten von HTTP-Headern durch die Same Origin Policy zu verwenden, um Ajax-Anwendungen vor CSRF-Angriffen zu schützen, war mir neu, ist aber eine interessante und vor allem innovative Idee! Lediglich die Überprüfung des Referrers scheint mir etwas gefährlich zu sein.

Auf der Homepage der Universität stehen übrigens zahlreiche interessante Papers zur freien Verfügung. Unter anderem auch das Busting-Frame-Busting-Paper (an dem Collin Jackson auch beteiligt war) auf dessen Inhalt ich in Kapitel 10 mit einem konkreten Beispiel eingehe.

Bloggen auf WordPress.com.