The three faces. DeepSec Martin Johns University of Hamburg Universität Hamburg

Transcription

1 The three faces of CSRF Universität Hamburg DeepSec Martin Johns University of Hamburg Fachbereich Informatik SVS Sicherheit in Verteilten Systemen

2 Me, myself and I Martin Johns johns at informatik.uni-hamburg.de Security researcher at the University of Hamburg Research focus: Web application security Static analysis of source code Member of the secologic project Research project carried out by SAP, Commerzbank, Eurosec and the University of Hamburg Goal: Improving software security Visit us at Martin Johns, UHH, FB Inf, SVS 2

3 A very short introduction In the beginning was HTTP and HTML HTML == Hyper Text Markup Language HTTP == Hyper Text Transport Protocol The hypertext WWW was and is cross-domain by nature Then there was innovation Meaningful web apps Authentication tracking JavaScript...and everybody somewhat forgot about the cross-domain nature of HTTP/HTML Martin Johns, UHH, FB Inf, SVS 3

4 Agenda A brief introduction to browser security Face 1: Exploiting applications Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 4

5 The Same Origin Policy (SOP) Basically the only security mechanism applicable to webapps Restricts active client-side code Designed to prevent cross-domain read/write access Applies to JavaScript Affects cookie-access, cross-document interaction and networking communication The SOP is satisfied iff the protocol, the domain and the port of two elements match Java and Flash have similar policies Martin Johns, UHH, FB Inf, SVS 5

6 The Same-Origin Policy (II) So, the SOP provides a nice sandbox: 1. No direct access to the local file system (Protocol-rule) 2. No direct access to other hosts (Domain-rule) 3. No direct access to other applications on the same host (Port- and protocol-rule) The SOP restricts JavaScript to its web application... Martin Johns, UHH, FB Inf, SVS 6

7 A loophole in the SOP JavaScript can initiate network communication through dynamic inclusion of elements in the DOM-tree: The script includes a HTML element in the page which references a network resource IMG, STYLE, SCRIPT, IFRAME By this inclusion of such an element the browser creates an HTTP request The targets of such requests are not restricted by the SOP This in fact enables indirect cross-domain communication Outgoing data: URL parameters Incoming data: Side effects of the inclusion process Martin Johns, UHH, FB Inf, SVS 7

8 Agenda A brief introduction to browser security Face 1: Exploiting applications Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 8

9 Implicit authentication Implicit authentication: After the initial authentication step the browser takes care of sending the authentication credentials Methods Cookies HTTP Authentication Client-Side SSL Alternative: Explicit authentication The web application is responsible Methods URL rewriting Form based tracking (hidden form fields) Martin Johns, UHH, FB Inf, SVS 9

10 Session management with cookies After the authentication form the server sets a cookie at the client s browser The browser sends this cookie along with all requests to the domain of the web application Martin Johns, UHH, FB Inf, SVS 10

11 Circumventing the SOP (I) Remember: The SOP prevents cross-domain write access Does it? Cross Site Request Forgery CSRF aka XSRF aka Session Riding aka Sea Surf CSRF exploits implicit authentication mechanisms Creation of hidden, state-changing cross-domain requests These requests are automatically outfitted with the user s credentials The Attack: The attacker creates a hidden http request inside the victim s web browser This request is executed in the victim s authentication context Martin Johns, UHH, FB Inf, SVS 11

12 CSRF (I) Cookie: auth_ok Martin Johns, UHH, FB Inf, SVS 12

13 CSRF (I) GET transfer.cgi?am=10000&an= Cookie: auth_ok Martin Johns, UHH, FB Inf, SVS 13

14 CSRF (II) Cause: The web application does not verify that state changing request were created within the web application Attack methods: Forging GET requests: Image tag with SRC attribute that points to a state changing URL The URL might be obfuscated by a http redirect Forging POST request: Attacker creates an IFRAME (or a pop-up window) The frame is filled with a HTML form This form is submitted via JavaScript Compared to XSS, CSRF s impact is underestimated In 2006 the following numbers were collected by CWE: XSS: 1282 issues CSRF: 5 issues Martin Johns, UHH, FB Inf, SVS 14

15 Agenda A brief introduction to browser security Face 1: Exploiting applications: Examples Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 15

16 Example 1: Breaking Applications Vulnerable: digg.com digg.com s frontpage is determined by the number of diggs a certain story gets Using CSRF a webpage was able to cause the victim s browser to digg an arbitrary URL The demo page digged itself Martin Johns, UHH, FB Inf, SVS 16

17 Example 2: Causing Financial Loss Vulnerable: Netflix.com Add movies to your rental queue Add a movie to the top of your rental queue Change the name and address on your account Change the address and password on your account (i.e., takeover your account) Cancel your account (Unconfirmed/Conjectured) Martin Johns, UHH, FB Inf, SVS 17

18 Example 3: Owning the Server Vulnerable: Wordpress 2.02 Wordpress theme editor was susceptible to CSRF Wordpress theme-files can be php-files Via CSRF an attacker could modify those files to contain arbitrary php-code Martin Johns, UHH, FB Inf, SVS 18

19 A CSRF exploit in less than 10 seconds exploit-o-mat.py Small script by Justus Winter Functionality: Bookmarklet finds all HTML forms in the page The respective action-urls are changed to point to exploit-omat.py This way the script receives all parameters that would have been sent to the original action exploit-o-mat.py creates automatically an attacking HTMLpage... Profit Martin Johns, UHH, FB Inf, SVS 19

20 Agenda A brief introduction to browser security Face 1: Exploiting applications: Avoidance Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 20

21 CSRF (III) General problem: CSRF vulnerabilities are NOT caused by programming mistakes Completely correct code can be vulnerable The reason for CSRF lies within http: No dedicated authentication credential State-changing GET requests JavaScript Preventing CSRF is actually fixing the protocol Martin Johns, UHH, FB Inf, SVS 21

22 Avoidance Assures that the POST request s origin was an HTML form that was provided by the web application in the first place Switch to explicit authentication Combine implicit and explicit auth Use nonces Example: <form action="submit.cgi" method="post"> <input type="text" name="foo"> <input type="hidden" name="nonce" </form> value="xulkjsf22enbsc"> Martin Johns, UHH, FB Inf, SVS 22

23 Agenda A brief introduction to browser security Face 1: Exploiting Applications Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 23

24 JSON (and associates) Disclaimer: Not everything discussed in the following slides is JSON in a strict sense However all techniques follow the same patterns: Designed for asynchronous communication Data encapsulated in executable code Advantage of this approach: No client-side parser necessary Disadvantage: Communicating data through executable code? Come on... Martin Johns, UHH, FB Inf, SVS 24

25 JSON-driven data communication Situation: The web application dynamically requests further data from the server without a page refresh... Variant A: XMLHttpRequest: The received data is evaled var p = eval("var a =" + JSON_text ); Variant B: <script>-tag: The received data is automatically executed Via new global variables Via callback function <script src="json.php?data=foo"></script> Martin Johns, UHH, FB Inf, SVS 25

26 Frequently used patterns There are 4 commonly used techniques: 1. Array format (*) 2. Object format (*) 3. Variable setter format 4. Callback function (*) To be precise, only these two are officially JSON (according to RFC 4627) [ [ ] ] "Joe Smith", "London", "Apples" Martin Johns, UHH, FB Inf, SVS 26

27 Data leakage attack Loading the data s URL in a <script>-tag The script-tag s URL is not subject to the SOP If the data is indeed executable, it is executed in the securitycontext of the attacker s domain <script src= Martin Johns, UHH, FB Inf, SVS 27

28 CSRF (I) Cookie: auth_ok Martin Johns, UHH, FB Inf, SVS 28

29 CSRF (I) Data GET private_stuff_in_json.php Data Cookie: auth_ok Martin Johns, UHH, FB Inf, SVS 29

30 Data leakage attack <script src= Exploitation: Array format Overwriting of the global Array()-Object Variable setter Access the new global variable Callback function Provide an own function with the same name Object format Redefine the definesetter () funtion of the global Object()-object modern browsers only Martin Johns, UHH, FB Inf, SVS 30

31 Example: GMail Adressbook disclosure Address-book data was communicated in JSON But this URL content could also be accessed via script injection <script src=" By overwriting the global array-constructor this data could be read cross-domain Martin Johns, UHH, FB Inf, SVS 31

32 Defense Make sure that your DATA is not EXECUTABLE!!!!!! The correct JSON-object notation is actually safe: { } "person":{ "name":"joe Smith", "location":"london", "fruit":"apples" } Other techniques: Start data with while(1){} Enclose data in /*... */ Use a different format Something that is not eval()-ed is not so prone to XSS Martin Johns, UHH, FB Inf, SVS 32

33 Agenda A brief introduction to browser security Face 1: Exploiting Applications Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 33

34 Circumventing the SOP (II) Remember: The SOP prevents cross-domain data-retrieval Does it? The basic reconnaissance attack (BRA) Question: Does the element with URL U exist? Method: Construct URL U pointing to the target of the examination Start a timeout-event t Include a suiting network aware element using U Use JavaScript s eventhandler-framework to determine the result: The timeout t occurs The target does not exist onload() event The target exists onerror() event (specific result depends on the element and target - stay tuned) Martin Johns, UHH, FB Inf, SVS 34

35 IP based authentication Intranet webserver Firewall Martin Johns, UHH, FB Inf, SVS 35

36 Subverting the Firewall with CSRF Firewall == implicit mean of authentication Susceptible to CSRF Malicious host Firewall Intranet Server ( ) Martin Johns, UHH, FB Inf, SVS 36

37 Putting it all together By looking at a webpage we allow JavaScript-execution within the intranet... As we have just discussed, JavaScript can do Reconnaissance (BRA) Exploiting (CSRF) Martin Johns, UHH, FB Inf, SVS 37

38 Intranet exploration with the BRA <img src= > onload()/onerror()/timeout()-events, Host / URL / element exists Intranet Server ( ) Firewall Malicious host Martin Johns, UHH, FB Inf, SVS 38

39 But where to start? My hosts are NATed and use obscure private IPs Java to the rescue: Java applets provide low level sockets The target of these sockets is restricted by the SOP This does not matter as we are interested in the origin of the connection (the local IP) On modern browsers even more convenient with LiveConnect: function natip() { var w = window.location; var host = w.host; var port = w.port 80; var Socket = (new java.net.socket(host,port)).getlocaladdress().gethostaddress(); return Socket; } Martin Johns, UHH, FB Inf, SVS 39

40 Intranet exploration with the BRA (II) Ping sweep / http-server discovery: Iterate through the subnet using the BRA E.g. using images: <IMG src= >, <IMG src= >, <IMG src= >,... Events (depend on element type): Timeout-event: Host does not exist OnLoad-event: Host probably runs a webserver IFrame can confirm OnError-event: Host exists but the port is closed (RST package) OnError fires on most browsers only for the IMG element Varying the port might locate https or development servers Martin Johns, UHH, FB Inf, SVS 40

41 Intranet exploration with the BRA (III) Server/application discovery/fingerprinting Known special DNS names <IFRAME src= > (home router) Known image-urls <IMG src= > (Apache) Web page fingerprinting based on JavaScript errors <SCRIPT src= > <script> function err(msg, url, code) { if ((msg == "missing } in XML expression" ) && (code == 1)) { // Wordpress } else if ((msg == "syntax error" ) && (code == 3)) { // Squirrelmail } else // unknown } window.onerror = err; </script> Martin Johns, UHH, FB Inf, SVS 41

42 Intranet exploration with the BRA (IV) HTTP-authentication If the scanned server is protected by HTTP-auth the browsers displays a login-dialogue This should at least startle the browser s user Avoiding HTTP-authentication pop-ups (Stefan Esser) The trick is to cause the server to drop the request before it is processed This can be achieved by malformed URLs Incomplete entities: Excessively long URLs AAA Breaks fingerprinting Martin Johns, UHH, FB Inf, SVS 42

43 Exploiting the intranet The attacker is able to: locate intranet hosts and fingerprint applications/routers/devices Several promising points for CSRF attacks: Unchanged default passwords on appliances Drive by Pharming Unpatched servers The old and almost forgotten IIS in the basement Outdated intranet applications Wordpress 2.0 for internal communication With DNS rebinding things get ever more interesting...but this is a different talk Martin Johns, UHH, FB Inf, SVS 43

44 Some limitations... Timing Working with timeout-events takes... Time Using parallelization can speed the process up But various restrictions on connections limits exit Windows XPSP2 and later Port restrictions Most browsers only allow HTTP and high-number ports Martin Johns, UHH, FB Inf, SVS 44

45 Agenda A brief introduction to browser security Face 1: Exploiting Applications Face 2: Information leakage Face 3: Exploring the intranet Countermeasures Martin Johns, UHH, FB Inf, SVS 45

46 Client-side protection Why at the client-side CSRF is a client-side attack Many web apps still don t consider CSRF Protecting against intranet attacks on the server-side not always possible RequestRodeo Strips implicit authentication information from cross-domain requests LocalRodeo Segmentation based on the origin of webpages (local/remote) Requests with a remote origin and a local target are denied Martin Johns, UHH, FB Inf, SVS 46

47 More protection NoForge [1] Reverse Proxy Positioned between web application and internet Parses http responses and adds tokens to all internal URLs Drops requests, that do not contain a token Only protects applications that use cookies for session tracking OWASP CSRF Guard [2] J2EE Filter Adds tokens to HTML Forms automatically [1] Nenad Jovanovic, Engin Kirda and Christopher Kruegel, Preventing Cross Site Request Forgery Attacks, IEEE International Conference on Security and Privacy in Communication Networks (SecureComm), Baltimore, MD, August 2006, [2] Martin Johns, UHH, FB Inf, SVS 47

48 Thank you Thanks for listening. Questions? Comments? Martin Johns, UHH, FB Inf, SVS 48