HttpOnly Cookies auslesen

Mein Kollege Norman Hippert von sudos.ec hat festgestellt, dass der Apache bei einer Response mit dem Statuscode 400 einen Teil des Request samt den Header zurückgibt. Dabei werden auch die mit einem HttpOnly Flag versehenen Cookies als Teil dieser Response mit ausgeliefert. Dieser Umstand führt dazu, dass ein Angreifer in Kombination mit einer vorliegenden Cross-site Scripting Schwachstelle innerhalb der anfälligen Webapplikation die ansonsten vor dem Auslesen mittels Javascript geschützten Cookies, ausspähen kann. Weitere Details hat Norman auf seinem Blog unter http://fd.the-wildcat.de/apache_e36a9cf46c.php veröffentlicht.

Apple Store ermöglicht Identitätsdiebstahl

Der Apple Store, welcher unter store.apple.com erreicht werden kann, ist derzeit für eine Cross-site Scripting Schwachstelle anfällig, welche es ermöglicht, die Cookies auszulesen und somit indirekt Aktionen im Kontext eines anderen angemeldeten Benutzers auszuführen. Ein derartiger Angriff wird deutlich erleichtert, weil Apple keine Schutzmaßnahmen gegen Framespoofing auf der anfälligen Webseite implementiert hat. Apple sollte serverseitig bei jeder Response den HTTP Header "X-Frame-Options" mit der Option "sameorigin" oder "deny" mitschicken. Darüber hinaus empfiehlt es sich die Cookies mit dem Flag "HttpOnly" vor dem Auslesen mittels Javascript zu schützen. Darüber hinaus besteht die Möglichkeit, weitere Inhalte von einem eigenem, durch den Angreifer kontrollierten Webserver nachzuladen und somit leichtsinnigen Benutzern ihre Benutzername/Passwort Kombination auszuspähen, beispielsweise unter Hilfenahme von HTML5 Features wie beispielsweise history.pushState() oder history.replaceState() .

Proof of Concept

Bild vergrößern

Sicherheitslücke auf Zalando.de - schnelle Reaktion

Anfang Dezember habe ich Sicherheitslücken auf der Webpräzenz von Zalando ausfindig gemacht. Es handelte sich um eine Cross-site Scripting Schwachstelle mit Möglichkeit über Create-Queries eigene Elemente zu bauen und beliebige Inhalte von einem durch den Angreifer kontrollierten Webserver nachzuladen. Hinzu kam, dass die Cookies nicht ausreichend geschützt waren, wodurch in Kombination der Schwachstellen ein Identitätsdiebstahl möglich gewesen wäre.

Als ich den Kontakt mit dem Unternehmen Zalando aufgenommen habe, um ihnen die Details zu den Schwachstellen zu melden, reagierten der CTO von Zalando sowie der zuständige Entwicklungsleiter prompt darauf und baten mich um weitere Details. Nachdem ich ihnen alle notwendigen Details zugeschickt hatte, wurde die Schwachstelle umgehend bearbeitet und bereits am kommenden Tag ein Hotfix dafür auf das Produktivsystem aufgespielt. Das ist vorbildlich schnell. Ich möchte mich daher an dieser Stelle bei Frank Biedka und Arash Yalpani von Zalando für die schnelle Reaktion und freundliche Kommunikation bedanken.

Proof of Concept

Bild vergrößern

Burp Suite Pro 1.4.03 erschienen - nun mit CSRF Generator

Gestern ist die aktuelle Version von Burp Suite Pro veröffentlicht worden. Als besonders nennenswertes Feature empfinde ich dabei den nun in der aktuellen Version 1.4.03 implementierten Cross-site Request Forgery generator. Dieser erstellt für einen beliebigen HTTP(s) Request mittels eines Rechtsklick auf "engagement tools context" -> "generate CSRF PoC" ein lauffähiges Proof-of-Concept in Form einer HTML-Datei, welches man einfach und unkompliziert an den Hersteller / Entwickler der verwundbaren Webapplikation schicken kann.

• http://portswigger.net/burp/download.html
• http://thehackernews.com/2011/11/burp-suite-pro-v1403-released-csrf.html

Charlie Miller zeigt Lücke im iOS-Codesigning

Wie Heise berichtet hat Charlie Miller eine Sicherheitslücke in Apple's iOS-Codesigning entdeckt, die auf Basis eines Problems innerhalb von Apples neuer JavaScript-Engine Nitro dazu führt, dass beliebige Anwendungen remote angesprochen werden können und Schadcode nachgeladen werden kann. Detailierte Informationen möchte Miller erst in der kommenden Woche präsentieren.

DOM-based XSS auf Twitter

Der Researcher "fool not open" hat auf dem aus China stammenden Forum www.wooyun.org ein Proof-of-Concept einer von ihm entdeckten DOM-basierten Cross-site Scripting Schwachstelle veröffentlicht. Dabei wird zur Laufzeit auf Twitter's "localStorage" innerhalb des DOMs zugegriffen. Wenn man die User-id des anzugreifenden Benutzers kennt, ist es auch möglich die DOM-based Attacke zu einer persistenten Cross-site Scripting Schwachstelle umzuwandeln.

iOS ist sicherer als Android ( sagt Charlie Miller )

Charlie Miller, seines Zeichens anerkannter IT-Sicherheitsforscher und mehrmaliger gewinner des Pwn2Own Wettbewerb hat kürzlich einen Vergleich der aktuellen Versionen von Apple's iOS und Google's Android Mobilbetriebsystems unternommen und kam dabei zum Entschluss, dass das iOS derzeit sicherer ist als Android.

• http://packetstormsecurity.org/news/view/20038/Charlie-Miller-On-Android-Vs-iOS-Security.html

neue Features in iOS 5 - erste Analyse ( Datenschutz )

Seit dem Wochenende habe ich nun die Möglichkeit einen Blick auf Apple's neue iOS in der Version 5 zu werfen. Einige Punkte empfinde ich bereits aus Sicht des Datenschutzes bedenklich.

Das sogenannte "iMessages", welches unter iOS 5 bereits standardmässig aktiviert ist, ermöglicht es, Nachrichten zwischen iOS 5 Nutzern kostenlos zu verschicken, sofern man einen entsprechenden Datentarif hat. Hier ist es funktional so, dass beim Verschicken einer SMS zunächst überprüft wird, ob der Empfänger der Nachricht ebenfalls iMessages benutzt. Technisch wird dies umgesetzt, indem ein Request an die Server von Apple verschickt wird, auf dem man mit seiner iTunes-ID oder Apple-ID und vermutlich auch Handynummer registriert ist. Dort wird geprüft, ob der Empfänger ebenfalls in der Apple-Datenbank mit einem installierten iOS 5 gelistet ist und auf dem iPhone/iPad zu diesem Zeitpunkt iMessages aktiviert hat. Ist dies der Fall, wird keine herkömmliche SMS verschickt, sondern es wird automatisch ( ohne Rückfrage oder Hinweis an den Absender ) eine iMessage an den Empfänger verschickt. Optisch unterscheidet es sich darin, dass eine herkömmliche SMS einen grünen und die iMessage einen blauen Hintergrund hat. Für mich stellt dies jedoch ein Information-Leak dar - denn ein potentieller Angreifer kann genau dies nutzen, um im Vorfeld zu ermitteln, ob der Empfänger ein aktuelles iOS 5 oder ein älteres iOS im Einsatz hat. Darüber hinaus sollten sich Benutzer darüber im Klaren sein, dass die iMessages stets über die Apple-Server übermittelt werden und hierdurch die Gefahr besteht, dass diese protokolliert und für einen ungewissen Zeitraum gespeichert werden. Dies sollte jedem Benutzer von iMessage bewusst sein -> man darf hier nicht nur auf den Kostenfaktor achten.

Ebenfalls bedenklich empfinde ich die Einführung der ortsbezogenen Erinnerungen. Dabei handelt es sich um eine mit dem iOS 5 ausgelieferten App von Apple, die anhand des Standorts gewisse Meldungen und Erinnerungen anzeigt. So kann man beispielsweise einstellen, dass das iPhone einen daran erinnern soll, den Fahrschein für die Bahn zu kaufen, wenn man in der Nähe des Bahnhofs ist oder einem die Einkaufsliste anzeigt, wenn man den eingespeicherten Supermarkt betritt. Im ersten Moment klingt dies für viele Benutzer nach einer guten, sinnvollen Idee. Wenn man das Ganze jedoch mit dem Fokus auf Sicherheit und Datenschutz betrachtet, so wird schnell klar, dass hierdurch auch ein personenbezogenes Geo-Tracking erfolgen kann. Wenn man nun daran denkt, dass diese Daten an die Apple-Server geschickt werden ( könnten ), so lässt sich hieraus sehr gezielt ein Map mit Aufenthaltsorten von Personen zusammenstellen. So raffiniert wie Apple ist, könnten die dies dafür nutzen, um daraus Ortsbezogene Werbung in Apps anzuzeigen etc etc - mal ganz davon abzusehen, dass es natürlich auch möglich wäre, derartige Geo-Daten auch an Behörden zu übermitteln oder diese auf dem iPhone so abzuspeichern, dass im Falle einer IT-Forensic die Daten problemlos ausgelesen werden könnten.

in iOS 5 wurde durch Apple nun auf die "iCloud" standardmässig eingeführt. iCloud speichert dabei Musik, Fotos, Apps, Kalender, Dokumente sowie ein komplettes Backup auf Apple-Servern, welche mit dem iTunes/Apple Benutzerkonto verbunden werden. Aufgrund der Rechtslage wird es hier im Zweifel recht schwierig Daten im Nachhinein endgültig löschen zu lassen, sobald Apple diese erstmal auf den nicht in Deutschland befindlichen Webservern gespeichert hat. Wer also dieses Feature nutzen möchte, sollte sich den Konsequenzen bewusst sein.

Staatstrojaner bei "phoenix Runde" - erste Zusammenfassung

Uwe Schünemann ( Innenminister Niedersachsen ), CDU sagte in der Sendung "phoenix Runde", dass sich das Land Niedersachen von der DigiTask GmbH getrennt hat und nun mit einem anderen Unternehmen zusammenarbeiten werde. Darüber hinaus hat Schünemann dementiert, bei den Israelis eingekauft zu haben - dies war seine Reaktion darauf, dass Andi Bogk vom CCC einen möglichen Namen des neuen Auftragnehmers für das Land Niedersachen in den Raum geworfen hatte.
Dabei sollte man wissen, dass die von Andi Bogk genannte Firma ihren Namen in der Vergangenheit geändert hat, da diese bereits in den USA für einen großen Skandal gesorgt hatte, nachdem bekannt geworden ist, dass diese im Grunde eine Software gebaut hatte, die es ermöglichte die dortigen Abhörer abzuhören.
In diesem Kontext sagte Schünemann auch, dass er sich an den Namen des Unternehmens mit denen Niedersachsen in Zukunft zusammenarbeiten werde, nicht erinnern kann, dies aber noch nachliefern könnte.

Im weiteren Verlauf der "phoenix Runde" wurde hin und wieder versucht vom eigentlichen Thema rund um den "Staatstrojaner" abzulenken, indem man plötzlich über Facebook sprach - und hier insbesondere darüber, dass dort mehr als 700 Millionen freiwillig ihre personenbezogenen Daten preisgeben.
Und Andi Bogk vom CCC ging dabei somit zu äußern: "Facebook ist ja von der CIA finanziert". Dies ist durchaus nachweisbar, da eine Tochtergesellschaft des CIA zu den Investoren von Facebook gehört. Und der Polizeigewerkschaftler in der phoenix Runde gibt sich dabei ganz unerschrocken und meint "ja, natürlich".

DigiTask - unfähig die eigene Webseite zu schützen !

Inzwischen hat sich bestätigt, dass die DigiTask GmbH für mehrere Behörden Software zur Telekommunikationsüberwachung ( und Staatstrojaner / Bayern-Trojaner ) entwickelt hat.
Darüber hinaus haben zwischenzeitlich dutzende Reverse-Engineering / Anti-Malware Experten die Binaries der vom CCC bereitgestellten Version des Staatstrojaners analysiert. Viele Experten sind sich dabei einig, dass keine besonderen Sicherheitsmaßnahmen implementiert worden sind. Dieser Umstand hat die Neugier in mir geweckt.
Daher habe ich beschlossen, mir die Webpräsenz von DigiTask genauer anzuschauen und die dort befindlichen Texte aufmerksam durchzulesen.
Dabei fiel mir direkt nach 2 Klicks anhand der Parameter in der URL auf, dass es sich vermutlich um ein Standard-CMS wie Typo3 oder Joomla handelt. Ein Blick in den ausgelieferten HTML-Quelltext bestätigte meine Vermutung - sie benutzen Joomla in der Version 1.5. Die Version 1.5.0 stammt aus dem Jahr 2008, es ist jedoch nicht klar ersichtlich, ob sich hier um die ".0" oder eine aktuellere Version der 1.5er Serie handelt. Hier war für mich nun also klar, dass ich die DigiTask Webpräsenz mal genauer unter die Lupe nehmen muss.
Dabei stand meinerseits aber definitiv fest, dass ich keinerlei Angriffe durchführen möchte und auch nicht vorhabe etwaige öffentlich verfügbaren Exploits auszuprobieren, sondern lediglich Informationen über die im Einsatz befindlichen Frameworks und Systeme sammeln möchte. Diese Informationen liste ich in der folgenden Tabelle auf. Vorab schonmal ein Hinweis: die Konfiguration des Systems ist einfach peinlich. Heutzutage bekommt man selbst bei kleineren Webspace-Anbietern für weniger als 5,00 Euro im Monat bereits Systeme mit deutlich sicherer Webserverkonfiguration sowie aktuellen Content Management Systemen ...

• Full Path Diclosure:
  http://digitask.de/templates/business_blue/index.php?sec=alert führt zu:
  Fatal error: Call to undefined function: mosshowhead() in /homepages/15/d247092081/htdocs/digihp/templates/business_blue/index.php on line 4


• Ungeschütztes Admin-Login-Interface: http://digitask.de/administrator/
  Anmerkung: bei einem Unternehmen sollte ein solches Interface ausschließlich über das Firmen-Intranet oder mittels eines VPN-Zugangs verfügbar sein -> nicht jedoch für jedermann über das Internet
  


• Veraltete Joomla! Version im Einsatz ( vermutlich aus dem Jahr 2008 ): <meta name="generator" content="Joomla! 1.5 - Open Source Content Management" />
  Update: es ist möglich, dass hier eine aktuellere Version als die ".0" im Einsatz ist. Anhand von Information Leaks lies sich jedoch ausgrenzen, dass es sich um die aktuelle 1.5.23 aus der 1.5er Serie handelt ):
  


• Offiziell nicht mehr unterstützte Version von PHP mit zahlreichen öffentlich bekannten Schwachstellen ( vom 07-Aug-2008 ) im Einsatz:
  X-Powered-By: PHP/4.4.9


• Kontaktformular wird ausschließlich über das Klartext-Protokoll HTTP angeboten ( Ob denen wohl ein SSL-Zertifikat bei ihren Umsätzen im Millionenbereich zu teuer ist - oder liegt's einfach daran, dass DigiNotar keine mehr ausstellen darf *facepalm* )


• Gemäß den Angaben von DigiTask werden unter anderem folgende Daten von ihnen erhoben:
  
  • Browsertyp/ -version
  • verwendetes Betriebssystem
  • Referrer URL (die zuvor besuchte Seite)
  • Hostname des zugreifenden Rechners (IP Adresse) -
    Anmerkung: hierzu macht DigiTask aber keine Angaben, ob diese vollstädig oder nur gewisse Teile protokolliert werden
  • Uhrzeit der Serveranfrage


• PHP easter egg ( deutet auf eine Standardkonfiguration von PHP hin ) :
  http://digitask.de/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42

Die DigiTask GmbH sollte ihre Webpräsenz als digitale Visitenkarten ansehen und sich dessen bewusst werden, dass Websicherheit in der heutigen Zeit ein ernst zu nehmendes Thema ist. Dabei gilt es auch, eine Unternehmenswebseite klar von einer privaten Webseite abzugrenzen. Dies bedeutet auch, dass man administrative Interfaces durch zusätzliche Schutzmaßnahmen, wie beispielsweise Basic Auth / HTTP Digest absichern sollte. Schliesslich kann ein Defacement der Unternehmens-Webseite das Image beeinträchtigen - auch wenn sonst keinerlei sensitive Untermensdaten oder Kundendaten auf dem Server gespeichert und somit auslesbar sind. Beim Security-Marketing haben sie meiner Ansicht nach mit dieser Standkonfiguration des Webservers sowie veralteter Webserver- und CMS-Version einfach alles falsch gemacht. Ich kann DigiTask nur empfehlen, einen professionellen Penetrationstest durchführen zu lassen -> und nein, ich stehe DigiTask hierfür KEINESFALLS zur Verfügung, da ich nach dem Staatstrojaner es weder moralisch vertreten noch mit meinem Gewissen in Einklang bringen kann, einem Unternehmen zu helfen, dass Millionen Euro Umsatz macht, indem Programme erstellt werden, die lediglich das Ziel haben, Bürger ohne deren Wissen und vorallem ohne deren Erlaubnis auszuspionieren..

Es gibt inzwischen eine erste Reaktion und Rückmeldung seitens DigiTask.
Sie haben die veraltete PHP Version inzwischen aktualisiert, leider haben sie dabei jedoch gleich wieder ins Leere gegriffen. Denn sie verwenden nun nicht die aktuelle Version 5.3.8 ( vom 23-Aug-2011 ), sondern setzen erneut auf eine veraltete und vom PHP-Team offiziell nicht mehr unterstützte Version, nämlich 5.2.17. Dass diese nicht mehr unterstützt wird, hat das PHP Team in den Release Notes vom 23-Aug-2011 schriftlich mitgeteilt: "All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.8.". Siehe hierzu auch : http://www.php.net/archive/2011.php#id2011-08-23-1 . Hier hat DigiTask nun also wieder ins Leere gegriffen und sich für eine Version entschieden, die ihrerseits ebenfalls öffentlich bekannte Schwachstellen aufweist. Ein erster Schritt wurde getan, aber leider direkt wieder gestolpert. Hoffentlich werden hier weitere Schritte zur Steigerung der Sicherheit durchgeführt.

Inzwischen gab es ein erstes Echo seitens der Medien und von anderen Bloggern zu diesem Beitrag.

• http://winfuture.de/news,65991.html


• http://blog.fefe.de/?ts=b06b2375


• http://www.gulli.com/news/17328-digitask-trojaner-hersteller-unfaehig-php-zu-installieren-kommentar-2011-10-13