28C3: Eine Konferenz, viele neue Angriffe

Neues rund um die Websecurity
Kommentare

Entwickler Magazin

Der Artikel „28C3: Eine Konferenz, viele neue Angriffe“ von Carsten Eilers ist erstmalig erschienen im Entwickler Magazin 2.2012
Vom XSS zum Rootkit
Das Rootkit entsteht unter anderem

Entwickler Magazin

Der Artikel „28C3: Eine Konferenz, viele neue Angriffe“ von Carsten Eilers ist erstmalig erschienen im Entwickler Magazin 2.2012

Vom XSS zum Rootkit

Das Rootkit entsteht unter anderem dadurch, dass der Schadcode im Kontext der angegriffenen Webanwendung im clientseitigen Speicher, das heißt im Local Storage oder in der Web-SQL-Datenbank, gespeichert wird. Diesem Schadcode kann das Opfer nur schwer entgehen, da er ein Schließen des Fensters oder das Ausloggen „überlebt“. Der Angreifer hat dann vollständigen Zugriff auf alle in die Webanwendung eingegebenen sowie von der Webanwendung ausgegebenen Daten. Manipulationen durch den Schadcode, beispielsweise eine geänderte Ausgabe der Webanwendung, werden von der Webanwendung selbst nicht bemerkt, es gibt keinerlei Hinweise auf die Manipulationen in den Logfiles von Webserver oder -anwendung. Um jederzeit auf den Schadcode zugreifen zu können, benötigt der Angreifer eine Backdoor. Statt auf dem Webserver wird diese auf dem Client geöffnet, indem entsprechender Schadcode auf dem Client gespeichert wird, zum Beispiel im Mobile-Interface der Webanwendung im Local Storage, in der Web-SQL-Datenbank oder in Flash oder HTML Cookies. Um im Browser aktiv zu bleiben, kann der Schadcode zum Beispiel heimlich ein minimiertes Fenster im Hintergrund öffnen oder iframes in andere Tabs einschleusen.

Aufräumen ist schwierig

Da die Webbrowser keine Möglichkeit haben, nach einem Angriff (sofern er denn überhaupt bemerkt wird) dessen Folgen zu beseitigen, muss die Webanwendung den nötigen Recovery-Prozess selbst in die Hand nehmen. Das stößt auf einige Schwierigkeiten:

  • Solange der Benutzer ein Tab oder ein Fenster zur Domain der Webanwendung mit dem Schadcode offen hat, kann dieser Schadcode laufende Sessions manipulieren.
  • Ein über meta-Tag oder Ajax ausgelöster Refresh der Seite kann vom Schadcode aufgehoben werden.
  • Die Webanwendung kann den Benutzer nicht einmal vor dem laufenden Angriff warnen, da der laufende Schadcode diese Warnung unterdrücken oder manipulieren kann.

Auch ein Benutzer wird den laufenden Schadcode nicht so leicht los, wie man meinen möchte: Das Schließen des Tabs mit der Webanwendung ist nutzlos, wenn der Schadcode in weiteren Tabs oder versteckten Frames im Kontext der Webanwendung läuft. Auch das Schließen aller Browserfenster und das Beenden des Webbrowsers eliminieren den Schadcode nicht, wenn er sich im Local Storage oder im lokalen Cache eingenistet hat. Löscht der Benutzer den Local Storage, bevor er den Browser neu startet, kann sich in noch geöffneten Tabs oder Fenstern laufender Schadcode sofort wieder im Local Storage einnisten. Artur Janc hält folgendes Vorgehen für eine mögliche Lösung:

  1. Schließen aller Browserfenster bis auf eins.
  2. Schließen aller Tabs in diesem Fenster bis auf einen.
  3. In diesem verbleibenden Tab about:blank aufrufen.
  4. Löschen aller Cookies, des Caches, der Einstellungen der Website und der Local Shared Objects des Flash-Players.
  5. Neustart des Browsers.

Alternativ könnte auch einfach das betroffene Browserprofil gelöscht werden. Das alles ist natürlich nutzlos, wenn die Webanwendung selbst eine XSS-Schwachstelle enthält. Oder auch einige andere Schwachstellen, die bisher als „Low Hanging Fruits“ missachtet wurden, wie der nächste Vortrag zeigt.

Neue Angriffsmethoden

Rich Lundeen, Jesse Ou und Travis Rhodes haben neue Angriffe auf Webanwendungen vorgestellt: „New Ways I’m going to hack your Web App“ [12]. Sie griffen dabei auf (mehr oder weniger alt-)bekannte Angriffe beziehungsweise Schwachstellen zurück und stellten neue Möglichkeiten für deren Einsatz vor:

  • Clickjacking-Angriffe auf Facebook zum Ausspähen von Informationen oder Übernehmen von Benutzerkonten
  • die Manipulation von Cookies zum Aushebeln eines einfachen CSRF-Schutzes im Office365-Portal und Outlook Web Access
  • die Manipulation von Cookies als Einfallstor für XSS-Code
  • XSS-Angriffe über hochgeladene XML-Dateien am Beispiel von wordpress.com

Ausgenutzte Schwachstellen wurden den betroffenen Entwicklern gemeldet und vor ihrer Veröffentlichung auf dem 28C3 behoben. Ziel des Vortrags war es, die Gefahren durch die Low Hanging Fruits zu demonstrieren: Mit Clickjacking lässt sich mehr erreichen als mit einer simplen Verbreitung von Likejacking-Würmern [13], [14], über Cookies ist mehr möglich als über Session Hijacking [15] und Session Fixation [16], über XSS ist mehr möglich als über das Öffnen einer Alert-Box oder das Ausspähen von Cookies [17], über hochgeladene XML-Dateien sind nicht nur DoS-Angriffe möglich. Wenn Sie also das nächste Mal über so eine „harmlose“ Schwachstelle lachen, seien Sie vorsichtig. Sie wissen ja: Wer zuletzt lacht . Aber kommen wir zum nächsten, gar nicht lächerlichen Vortrag.

Kann es sein, dass Schwachstellen anwesend sind?

Von Fabian Mihailowitsch wurden neue Ansätze zum Finden von Schwachstellen in Webanwendungen vorgestellt: „Don’t scan, just ask“ [18]. Ein auf den ersten Blick etwas irreführender Titel. Beim klassischen Ansatz zur Suche nach Schwachstellen in Webanwendungen eines Unternehmens werden zum Beispiel dessen Netzblöcke oder URLs durchlaufen. Die Geschäftsbeziehungen des Unternehmens bleiben im Allgemeinen unberücksichtigt, sodass nicht alle möglichen Ziele gefunden werden. Fabian Mihailowitschs Antwort auf diesen unvollständigen Ansatz ist „Spider-Pig“, ein Tool zur Suche nach mit einem Unternehmen verbundenen Webanwendungen auf Basis einer Keyword-Liste und eines Crawlers.

Beim klassischen Erkunden möglicher Ziele werden NIC- und RIPE-Datenbanken durchsucht, DNS-Einträge ausgewertet, „Google Hacking“ wird eingesetzt usw. usf. Damit wird nur ein Teil der möglichen Ziele gefunden, im Allgemeinen die Server des Unternehmens selbst und der Tochtergesellschaften. Dienstleister wie Payment Provider, externe Webhoster, Service Center etc., über die das Zielunternehmen ebenfalls angegriffen werden könnte, bleiben dabei außen vor. Hier setzt Spider-Pig an, das versucht, in vier Schritten in eine Webanwendung eines Unternehmens einzudringen:

  1. Model Business: Webanwendungen, die zu einem bestimmten Unternehmen gehören, enthalten in der Regel Begriffe wie den Unternehmensnamen, Produktbezeichnungen usw. Während einige davon, z. B. die Produktbezeichnungen, im Allgemeinen zu sehr vielen Fundstellen führen (man denke nur an all die eBay-Auktionen etc., die man dabei meist zuerst findet), gibt es für andere, wie den genauen Unternehmensnamen samt Rechtsform, meist nur sehr wenige Fundstellen, normalerweise auf Websites, die mit dem Unternehmen verbunden sind. Manuell wird eine Liste solcher spezifischen Begriffe erstellt. Zusätzlich werden sie mit einer Bewertung versehen, wie eindeutig sie sind.
  2. Perform Search: Mit verschiedenen Suchmaschinen wird nach den im ersten Schritt gesammelten Begriffen gesucht: „Don’t scan, just ask“. Alle Fundstellen werden in einer Liste zusammengefasst, in der der vollständige Domainname (Fully Qualified Domain Name, FQDN) als Index dient. Jedes mal, wenn der FQDN Teil des Suchergebnisses ist, wird die Bewertung des zugehörigen Suchbegriffs zu dem ggf. bereits vorhandenen Wert hinzuaddiert. Für IP-Adressen und Domainnamen wird eine Whois Query gestartet. Enthält der Whois-Eintrag den Unternehmensnamen, die Adresse oder einen Suchbegriff, gilt der FQDN als Treffer. Von der erstellten Liste mit FQDNs wird dann auf die Domains mit einer hohen Bewertung ein Crawler angesetzt, der nach weiteren, mit dem Unternehmen verbundenen, Webanwendungen sucht. Dabei kann auch schon der erste Schritt zur Suche nach möglichen Schwachstellen, das Sammeln von Informationen, durchgeführt werden.
  3. Calculate Results: Jetzt haben Sie eine Liste aller erkannten Ziele, versehen mit Bewertungen. Diese Liste wird ungefiltert sehr lang sein, sodass die interessanten Ziele herausgefiltert werden müssen. Einträge mit einer niedrigen Bewertung sind vermutlich nicht relevant, ebenso Einträge mit einer besonders hohen Bewertung (die im Allgemeinen zu Onlineshops, Portalen etc. führen). Am Ende bleibt eine relativ geringe Zahl interessanter Ziele übrig.
  4. Exploit: Die interessanten Ziele können nun genauer untersucht werden. Die während des Crawlens gesammelten Informationen dienen dabei als Ausgangsbasis und können als Grundlage eines ersten, automatisierten Schwachstellenscans dienen.

Fabian Mihailowitsch hat Spider-Pig gegen ein großes, bekanntes Unternehmen eingesetzt und damit gute Erfolge erzielt. Wenn Sie es gerne selbst testen möchten, haben Sie Pech: Aufgrund des „Hackerparagraphen“ hat Mihailowitsch das Tool nicht veröffentlicht. Da hilft dann nur „Do it yourself“, die nötigen Informationen zur Entwicklung eines eigenen Tools sind ja bekannt.

Fazit

Wirklich Neues gab es im Bereich der Websecurity auf dem 28C3 nicht, dafür deutliche „Wake up Calls“ sowohl für die Entwickler von Webanwendungen als auch für die Entwickler der dafür verwendeten Skriptsprachen und Plattformen. In CRuby 1.9 werden Hash-DoS-Angriffe schon seit 2008 durch Verwendung einer Randomized Hash Function verhindert, aber warum sind die anderen Ruby-Varianten 2011 noch angreifbar? Und in Perl gibt es den Schutz bereits seit der 2003 veröffentlichten Version 5.8.1, das grundlegende Problem ist also seit Langem bekannt. Alle anderen Sprachen und Plattformen müssen jetzt zügig nachziehen. Und wie sieht es eigentlich mit den Programmiersprachen und -umgebungen für Desktopanwendungen aus? Und was die Webanwendungen betrifft: Wenn Sie XSS, Clickjacking und Co. bisher für mehr oder weniger harmlos gehalten haben, sollten Sie diese Einschätzung noch einmal überdenken. Und dann ist da noch Spider-Pig, ein interessantes, neues Tool und ein interessanter, neuer Ansatz für die Suche nach Schwachstellen. Auch für Webentwickler ist Spider-Pig von Bedeutung: Sie müssen dafür sorgen, das alle Komponenten einer Webanwendung sicher sind, auch die, mit denen sie selbst nichts zu tun haben. Sonst kann es passieren, dass ein Angreifer quasi „über die Bande“ spielt und die von Ihrer Anwendung genutzten Dienste eines Dritten gegen Ihre Anwendung einsetzt.

Dipl.-Inform. Carsten Eilers ist als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz tätig und als Autor verschiedener Artikel und des Buchs „Ajax Security“ bekannt. Zu erreichen ist er unter www.ceilers-it.de, sein Blog finden Sie unter www.ceilers-news.de.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -