Der Google Chrome Browser hat ein paar interessante Eigentümlichkeiten, die uns die wahre Intention von Google deutlich zeigen:
Klar ist natürlich, daß alle Suchanfragen immer automatisch bei Google landen. Irgendwoher müssen die Suchresultate ja kommen.
Das gleiche gilt vermutlich auch für alle anderen aufgerufenen URLs, da ja sowas wie die Google Toolbar integriert ist.
Ok, das unterscheidet sich jetzt nicht von anderen Browsern, wenn ich so blöd bin, ne Toolbar zu installieren. Egal ob Google, Yahoo oder Aks.com. Aber jetzt kommt der spannende Teil.
Jede Google Chrome Installation hat lt. Datenschutzbeauftragter Online eine eindeutige ID, die bei jeder Anfrage an Google mitgeschickt wird. Dann genügt es einmalig, sich bei irgendeinem Google Dienst (iGoogle, Google Mail, …) anzumelden und Google hat eine eindeutige Zuordnung der Chrome ID zum User. Selbst wenn man nicht angemeldet ist, kann das gesamte Surfverhalten anhand der Chrome ID nachvollzogen werden und die Zuordnung zum realen Nutzer bleibt ja erhalten.
Oder anders ausgedrückt: Mit Google Chrome hat Google bessere Möglichkeiten zur individuellen Profilierung aller Nutzer als je zuvor. Und das ist 100% Evil.Ich weiß schon mal was definitiv nicht auf irgendeinen meiner Rechner kommt!
Das gilt sogar für jedes einzelne Zeichen(!) das man in die Chrome-Adresszeile eingibt. Jeder Tippfehler landet also auch bei Google. Andreas Krennmair von synflood.at hat das entdeckt und dokumentiert.
Problem:
An issue exists in how chrome behaves with undefined-handlers in chrome.dll version
0.2.149.27. A crash can result without user interaction. When a user is made to visit
a malicious link, which has an undefined handler followed by a ’special’ character,
the chrome crashes with a Google Chrome message window “Whoa! Google Chrome has crashed. Restart now?”. It lies in dealing with the POP EBP instruction when pointed out by the EIP register at 0×01002FF4.
Proof of Concept:
http://evilfingers.com/advisory/google_chrome_poc.php
und soll Chrome heißen. Bei Blogoscoped gibt es die ersten Screenshots und sowohl Heise als auch Spiegel Online hat bereits einen ähnlichen Artikel aus dem ich gerne zwei Sätze zitieren möchte:
“Microsoft hatte erst vor wenigen Tagen die zweite Testversion seines neuen Internet Explorer 8 vorgestellt, der nach Einschätzung von Experten mit den aktuellen Ausgaben von Firefox und Safari mithalten kann. Einige Beobachteter merkten dazu an, neue Datenschutz-Optionen im Internet Explorer könnten Google das Geschäft mit sogenannter Kontext-bezogener Werbung erschweren.”
Google ist böse, der Konzern verschenkt nichts. Wann immer es etwas umsonst gibt, nimmt es sich Google an anderer Stelle wieder. Gmail gibt es nur mit dem Einverständnis, die dort erhaltenen Mails automatisch scannen und Werbung einblenden zu lassen. Das Versprechen Googles, die Mails nicht zu “lesen” bedeutet außerdem nicht, die Kommunikationsbeziehungen (also wer schreibt wem) nicht zu analysieren. Ich wette, daß in Googles Browser die Google Toolbar integriert ist, die einerseits verhindert, daß andere Toolsbars (von Yahoo, Ask oder anderen Datenspionen) installiert werden können und andererseits das Surfverhalten noch detaillierter an Google zurückmeldet. Und bestimmt kann man die Google-Cookies nicht einfach löschen oder Google Adsense Werbung mit Adblock blockiere.
Wer, außer ein paar Fanboys braucht so einen Browser?
Inzwischen trifft es vermehrt seriöse Webseiten, die von irgendeiner dritten Seite Inhalte, beispielsweise Werbebanner einblenden. Eigentlich ist das Thema nicht neu, die erste große Runde machte das Problem 2004 durch die Firma Falk eSolutions. Inzwischen werden gezielt bösartige Werbebanner eingeblendet. Entweder, um nur Nagware auf die Rechner der Nutzer zu bringen wie Heise berichtet oder, was eher wahrscheinlich ist, um die aktuellen Sicherheitslücken in diversen Webbrowsern, in Quicktime oder Java auszunutzen und Schadprogramme direkt auf dem Rechner zu installieren. Selbst Microsoft Expedia war davon betroffen.
Interessant ist die Reaktion der diversen Computerzeitungen. Mit konkreten Hilfestellungen hält sich beispielsweise Heise sehr sehr vornehm zurück. Die britische The Register empfiehlt den Lesern immerhin, Firefox zusammen mit NoScript einzusetzen. Der Grund ist klar. Idealen Schutz bringt erst die Kombination aus Firefox, NoScript und Adblock/Adblock Plus, am besten noch kombiniert mit einer restriktiven Hosts-Datei. Werbebanner die gar nicht erst geladen werden, können nämlich keinen Schaden anrichten und außerdem lädt die Seite deutlich schneller, wenn nicht von diversen anderen Servern irgendwas dazugeladen werden muß. Das Problem dabei, solche Hinweise würden das werbefinanzierte Geschäftsmodell vieler Webseiten zerstören.
Ich persönlich halte solche Drive-by-Schadprogramme für viel gefährlicher als Sicherheitslücken im Internet Explorer oder Klickbetrug bei Google-Ads. Wenn erstmal dem normale Internetsurfer bewußt wird, welche Gefahr durch Werbebanner auf eigentlich harmlosen und seriösen Seiten entstehen kann, dann ist das Geschäftsmodell “werbefinanzierte Webseite” tot. Und das wäre meines Erachtens schade.
Lösungsansätze?
Nun ja, eigentlich sehe ich nur wenige. Am besten wäre es, zurück zu (relativ) statischer Werbung zu kommen. JPGs und GIFs kann man relativ einfach kontrollieren und richten nur wenig Schaden an. Inzwischen dominieren aber Javascript-aufgemotzte Layer-Ads und Flash-Movies den Werbemarkt und diese Entwicklung läßt sich kaum zurückdrehen. Den Anbietern von werbefinanzierten Seiten bleibt nur, sich den Werbeanbieter genau anzusehen und jede veröffentlichte Werbung bei der Freischaltung und regelmäßig zu kontrollieren. Da jedoch auch das keine 100%ige Garantie gibt rate ich persönlich ja dazu, sich selbst zu schützen. Und das geht anscheinend nur in der Kombination Firefox + NoScript + Adblock/Adblock Plus.
In der Präsentation “Unusual Web Bugs” von kuza55 ging es Schlag auf Schlag mit den unterschiedlichen Sicherheitslücken in Browsern und Servern, in PHP und anderen Sprachen. Das ging so schnell, viele Punkte konnte ich gar nicht mitschreiben, ich hoffe die FeM-Leute kriegen das Video bald (und brauchbar) kodiert. Die folgenden Stichpunkte sind daher lediglich meine eigene Gedächtnisstütze, schaut Euch das Video selbst an.
XSS bei angemeldeten Benutzern
Mißbrauch des Passwort-Managers
Automatisches Einfügen von Passwörtern in Formulare
Session Fixation
Abhängig von Cookies und Regeneration der Cookies
Cache auslesen (nur IE)
mittels XMLHttpRequest
Sonstige Cookie-Spiele
Logout durch blockieren des Cookie (CSRF/Flash, Firefox-Tool)
Login als der Angreifer (Cookie via Flash in Header einschleusen)
Hilfreich ist, daß die Cookie Policy schwächer als die Same Origin Policy ist
IE FindMimeFromData
Encoding-Angriffe gegen SQL-Server (Multibyte-Char)
und vieles mehr
Ferruh Mavituna hat einiges in diesem Bereich gemacht und bietet u.a. ein SQL Injection Sheet auf seiner Homepage an. Eine andere Quelle ist Ha.ckers.org.
Für meinen Geschmack richten sich die meisten Probleme jedoch gegen den Browser und nicht gegen den Server und die Webapplikation. Angriffe gegen Browser sind mehr für Leute, die Schadprogramme auf die Clients bekommen wollen und ich bin sicher, einige der Angriffe sind bereits im berüchtigten MPack implementiert. Für meine Pentest-Arbeit sind jedoch Lücken in Serverapplikationen nützlicher, da läßt sich auch legal (§ 202c StGB) noch der eine oder andere Exploit anwenden.
Na gut, das kommt vor. Eigentlich ist das auch keine Nachricht wert. Ich hab’s zufällig bei The Register gelesen.
Aber es gibt ein Video auf YouTube bzw. hier die hochauflösende Fassung (17,1 MB .mov) von jemandem, der auf die Seite geklickt und die Malware analysiert hat:
Fukami ist einfach gut. Der Vortrag über Testing und Exploiting Flash Applications war allererste Sahne. Am Anfang kurz die Grundlagen erklärt, dann typische Problemklassen beschrieben, die Sicherheitsrisiken an konkreten Beispielen vorgeführt und das alles so, daß der HighLevel-Betrachter verstehen konnte, daß Flash ein Problem sein kann aber gleichzeitig mit so vielen Details, daß mir jetzt auch klar ist, wo genau die Probleme sind.
1. Die Grundlagen
Von Flash gibt es eine Reihe von Generatoren, die Flash-Movies erzeugen können jedoch nur den offiziellen Player von Adobe, da keine weiteren Player erlaubt sind. Flash besteht aus einer Skriptsprache (ActionScript, aktuell ist v2 weit verbreitet und v3 kommt gerade mit neuen Funktionen). Flash ist u.a. für Audio/Video-Anwendungen sehr beliebt. Zu Flash kommt Flex dazu, eine SDK mit IDE, im Grunde besteht das aus Flash 9, Interface Libraries und einem Eclipse Plugin. AIR ist die Adobe Integrated Runtime für Desktop-Anwendungen. Bereits wenn man an dieser Stelle auf Flash kuckt, fallen ein paar gefährliche Eigenschaften auf: Flash kann HTTP Request Forgery, kann JavaScript, … äh
2. Die Sicherheit
Flash hat seit Version 7 ein Security Modell, das hauptsächlich auf der “Same Origin Policy” basiert. In Version 8 und 9 wurde das Modell vereinfacht, aber auch ein Player Version 9 wendet die alte Policy an, wenn ein Flash Version 7 Movie abläuft. Darüber hinaus gibt es in Flash einen Persistent Local Datastore für Shared Objects. Da kann der Flash-Movie beliebige Daten reinlegen, maximal jedoch 100 KB. Die Daten haben kein Expiration Date, sind nicht einfach löschbar und auf einigen Plattformen sogar Cross-Browser erhalten. Damit hat man schon einen krass permantenten Speicher, wenn man einen Webseitenbesucher wieder identifizieren will.
3. Die Angriffe
Das fängt schon mal an mit Local Connection Objects die verwendet werden, damit zwei Flash-Movies miteinander Nachrichten austauschen können. Die Nachrichten werden nicht gefiltert, da kann mal also sehr gut XSS oder JavaScript durchschleusen. Und Flash kann ja bekanntlich Javascript. Lustig ist es auch mit den Variablen. Für uninitialisierte Variablen gilt in etwa das gleiche wie bei PHP mit register globals. Da man Variablen über die URL, FlashVar oder localVars.AS-Objekt übergeben kann, ist jede uninitialisierte globale Variable eine potentielle Gefahr. Die Sandbox in der Flash abläuft ist zwar ganz sinnvoll, aber weitgehend beschränkt auf die Same Origin (FQDN) Policy sowie eine Cross Domain Policy, die als XML-File geladen werden kann.
4. Client Side Attacks
Auf Client-Seite ist vieles möglich, XSS, XSF (Cross Side Flashing), Mass Exploits, Backdoors und vieles mehr. Die Funktion getURL() in ASv2 erlaubt beispielsweise JavaScript- und DOM-Aufrufe. Fukami spricht hier von PDNF (Potentially Dangerous Native Function). Außerdem gibt es HTML in Flash (HTML-Injection beispielsweise durch das CreateTextField oder den Anchor-Tag), dafür muß die Anwendung aber als Flash 7 kompiliert werden.
5. ActionScript v3
Noch viel lustiger wird es mit ActionScript Version 3, da gibt es lustige neue Funktionen. Auf jumperz.net gibt es einen in Flash programmierten Portscanner, der vom Client aus die IP-Adresse 127.0.0.1 scannt. Die Gefahr von Socket-Operationen sollte eigentlich bekannt sein, JavaScript verzichtet aus gutem Grund darauf.
6. Tools
Flare - Decompiler
MTASC - Compilter
Flasm - Disassembler
SWFmill - SWF/XML-Converter
Debugger-Version des Flash Players
SWFTools - Programme zur SWF-Manipulation, z.B. swfcombine
Jesse Ruderman von der Mozilla Foundation hat eine Reihe von Fuzzern zur Prüfung von Webbrowsern veröffentlicht, schreibt Heise. Die beiden Tools jsparsefuzz.js und jsfunfuzz.js erzeugen fehlerhaftes Javascript und können damit potentielle Sicherheitslücken aufdecken. Im Grunde nichts neues, Fuzzer für Webbrowser gibt es eine Reihe, beispielsweise die Browser Crash Test Suite von JdM.
Erstaunlich ist eher, daß Mozilla nicht früher selbst aktiv geworden ist sondern lange Zeit das Feld anderen überlassen hat. Von HD Moore, Michal Zalewski und eben JdM gibt es schon seit geraumer Zeit Fuzzer für Browser und bisher waren die Browser-Hersteller immer in der defensive. Das kann sich vielleicht nun ändern.
Im Grunde bestätigt das aber nur meine Meinung vom Juli. Browser Fuzzing ist kein relevanter Security Markt mehr. Die Fuzzer für Netzwerkprotokolle finde ich viel spannender. Bei VoIP und VPN geht bestimmt noch was. Und nicht zu vergessen, Milosch Meriac braucht dringend jemanden, der einen RFID-Fuzzer programmiert. Da geht noch viel!
Meine Firefox-Extensions, nur so als persönlicher Merker:
Adblock (nicht Adblock Plus)
Add N Edit Cookies
DOM Inspector
Exif Viewer
Fasterfox
FlashGot
FoxTorrent
NoScript
SEO For Firefox
Server Spy
ShowIP
Tamper Data
bisher tun die es für mich. Standard-Theme. Fertig. Insbesondere das Server Spy und Tamper Data finde ich sehr praktisch. Und ohne Adblock und NoScript kann man eigentlich gar nicht mehr im Internet surfen. Der Rest sind Gimmicks.
