Your SlideShare is downloading. ×
Top Ten Web Hacking Techniques of 2012
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Top Ten Web Hacking Techniques of 2012

1,575
views

Published on

http://blog.whitehatsec.com/top-ten-web-hacking-techniques-of-2012/ …

http://blog.whitehatsec.com/top-ten-web-hacking-techniques-of-2012/
Recorded Webinar: https://www.whitehatsec.com/webinar/whitehat_webinar_march2713.html

Every year the security community produces a stunning amount of new Web hacking techniques that are published in various white papers, blog posts, magazine articles, mailing list emails, conference presentations, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and their mobile platform equivilents. Beyond individual vulnerabilities with CVE numbers or system compromises, here we are solely focused on new and creative methods of Web-based attack. Now it its seventh year, The Top Ten Web Hacking Techniques list encourages information sharing, provides a centralized knowledge-base, and recognizes researchers who contribute excellent work. Past Top Tens and the number of new attack techniques discovered in each year:

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,575
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
137
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • According to the provided scenario, the exploit will not work if the victim has already accessed the login.php page. This is not always the case. For example, many web applications have a logout page whose job is to clear session data and to issue either new session cookie or empty session session cookie such as PHPSESSID=deleted. Here, our XSS payload will call this logout page first and then call the login page which issues HttpOnly session cookie.
  • \\
  • Yay HTML5!
  • Transcript

    • 1. TOP TEN WEB HACKINGTECHNIQUES OF 2012
    • 2. ABO U TJeremiah Grossman • Founder & CTO of WhiteHat Security • TED Alumni • InfoWorld Top 25 CTO • Co-founder of the WASC • Co-author: XSS Attacks • Former Yahoo! information security officer • Brazilian Jiu-Jitsu Black BeltMatt Johansen• Head of WhiteHats Threat Research Center• BlackHat, DEFCON, RSA Speaker• Oversees assessment of 15,000+ websites• Background in Penetration Testing• Hacker turned Management• Im hiring… a lot… © 2013 WhiteHat Security, Inc. 2
    • 3. ABO U TWhiteHat Security, Inc.• Founded 2001• Head quartered in Santa Clara, CA• Employees: 260+• WhiteHat Sentinel: SaaS end-to-end website risk management platform (static and dynamic analysis)• Customers: 500+ (banking, retail, healthcare, etc.)© 2013 WhiteHat Security, Inc. 3
    • 4. ABOUT THE TOP TEN© 2013 WhiteHat Security, Inc. 4
    • 5. ―Every year the security community produces a stunning amount of new Web hacking techniques that are published in various white papers, blog posts, magazine articles, mailing list emails, conference presentations, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and their mobile platform equivalents. Beyond individual vulnerabilities with CVE numbers or system compromises, here we are solely focused on new and creative methods of Web-based attack.‖© 2013 WhiteHat Security, Inc. 5
    • 6. H ISTO RYPast Years 2011 • BEAST (51 new techniques) 2010 • Padding Oracle Crypto Attack (69 new techniques) 2009 • Creating a rogue CA certificate (80 new techniques) 2008 • GIFAR (GIF + JAR) (70 new techniques) 2007 • XSS Vulnerabilities in Common (83 new techniques) Shockwave Flash Files 2006 • Web Browser Intranet Hacking / Port (65 new techniques) Scanning© 2013 WhiteHat Security, Inc. 6
    • 7. T H E YEAR 2 0 1 256 NEW Techniques1. CRIME2. Pwning via SSRF (memcached, php-fastcgi, etc)3. Chrome addon hacking4. Bruteforce of PHPSESSID5. Blended Threats and JavaScript6. Cross-Site Port Attacks7. Permanent backdooring of HTML5 client-side application8. CAPTCHA Re-Riding Attack9. XSS: Gaining access to HttpOnly Cookie in 201210.Attacking OData: HTTP Verb Tunneling, etc. http://blog.whitehatsec.com/top-ten-web-hacking-techniques-of- 2012/© 2013 WhiteHat Security, Inc. 7
    • 8. 2 0 1 2 TO P T EN Attacking Odata: HTTP Verb Tunneling, Navigation Properties for Additional Data Access, System Query Options ($select) ―The Open Data Protocol (OData) is an open web protocol for querying and updating data. OData enables the creation of HTTP-based RESTful data services that can be used to publish and edit resources that are identified using uniform resource identifiers (URIs) with simple HTTP messages. This paper looks at OData from a penetration testing perspective and introduces various OData concepts as we progress.‖Gursev Singh Kalrahttp://www.mcafee.com/us/resources/white-papers/foundstone/wp-pentesters-guide-to-hacking-odata.pdf © 2013 WhiteHat Security, Inc. 8
    • 9. 2 0 1 2 TO P T EN XSS: Gaining access to HttpOnly Cookie in 2012‗If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot beaccessed through client side script. As a result, even if a cross-site scripting (XSS) flaw exists, anda user accidentally accesses a link that exploits this flaw, the browser will not reveal the cookie to athird party. The following describes techniques to gain access to HttpOnly cookie data via client-side attack.‖http://seckb.yehg.net/2012/06/xss-gaining-access-to-httponly-cookie.html© 2013 WhiteHat Security, Inc. 9
    • 10. BASIC SHttpOnly cookie flag Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]js> alert(document.cookie);When a cookie has an HttpOnly cookie flag thereturned value is blank.https://www.owasp.org/index.php/HttpOnly© 2013 WhiteHat Security, Inc. 10
    • 11. H ISTO RYCROSS-SITE TRACING (XST) [circa 2003] Force cookie values into the body of the HTTP response where there is no HttpOnly protection. <script> TRACE / HTTP/1.1 var xmlhttp = new XMLHttpRequest(); Host: foo.bar var url = http://foo.com/; HTTP/1.1 200 OK // send cookie header Date: Mon, 02 Dec 2002 19:24:51 GMT xmlhttp.withCredentials = true; Server: Apache/2.0.40 (Unix) xmlhttp.open(TRACE, url, false); Content-Type: message/http xmlhttp.send(); TRACE / HTTP/1.1 </script> Host: foo.com Cookie: httpOnly cookie value Performing an XST attack, at the time, required either a cross-domain browser vulnerability, or an XSS vulnerability in the target website.https://www.owasp.org/index.php/Cross_Site_Tracinghttp://www.cgisecurity.com/lib/WH-WhitePaper_XST_ebook.pdf© 2013 WhiteHat Security, Inc. 11
    • 12. BR O W SER F IXNo TRACE (No TRACK)Today, no modern browser allows javascript to use these HTTP request methods.The same is true of Flash, Silverlight, and Java Applets. Well, almost…© 2013 WhiteHat Security, Inc. 12
    • 13. XST 2 0 1 2Java Applet (PoC)getHeaderField, under the java.net.URLConnection packageApplet requests a URL and reads set-cookie response header alert(new java.net.URL(http://attacker.in/xss/cookie.php).openConnection().getHeaderFi eld(set-cookie));“…a vulnerable page in a real-world application may havealready issued the HttpOnlycookie by the time the script hasexecuted.”Might also be able force out all cookies by overloading them. Cookie Exhaustion.http://www.slideshare.net/jeremiahgrossman/breaking-browsers-hacking-autocomplete-blackhat-usa-2010© 2013 WhiteHat Security, Inc. 13
    • 14. SO L U T ION UNINSTALL JAVA [on the client, not the server] For this and about 1,000 other [zero-day] reasons.© 2013 WhiteHat Security, Inc. 14
    • 15. 2 0 1 2 TO P T EN CAPTCHA Re-Riding Attack―CAPTCHA Re-Riding Attack bypasses the CAPTCHAprotection built into the web applications. The attack exploits thefact that the code that verifies CAPTCHA solutions sent by theuser during form submissions does not clear the CAPTCHAsolution from the HTTP Session.‖ Completely Automated Public Turing test to tell Computers and Humans ApartGursev Singh Kalrahttp://gursevkalra.blogspot.com/2012/03/captcha-re-riding-attack.html© 2013 WhiteHat Security, Inc. 15
    • 16. BASIC SCAPTCHA Protected Registration Flow© 2013 WhiteHat Security, Inc. 16
    • 17. T EL LTAL E SIG N SWhat to look for…1) captcha.php is responsible for updating the HTTP session with correct CAPCHA solution.2) CAPTCHA solution inside the HTTP session is not explicitly cleared during the verification process.3) After registration succeeds, users are redirected to next step and the CAPTCHA generation page (/captcha.php) is not likely called for current SESSION again. Allows CAPTCHA solution to stay stored for as long as SESSION is valid.Two possible vulnerable behavior: a. Web application uses the same SESSIONID for the same HTTP session. b. Web application generates a new SESSIONID for the same HTTP session. In either case, the HTTP Session continues to store the CAPTCHA solution as it is not explicitly cleared by the CAPTCHA verification code….© 2013 WhiteHat Security, Inc. 17
    • 18. AT TAC K3a)1) Load the register page of the target website in a web browser.2) Solve the CAPTCHA manually and submit the form.3) Record form submission using a web proxy. This request contains a valid SESSIONID, valid form fields, and a valid CAPTCHA solution.4) Create a custom script that repeatedly sends this request to the server. With each request change the unique values (like User ID) to create multiple new accounts with a single CAPTCHA solution.© 2013 WhiteHat Security, Inc. 18
    • 19. AT TAC K3b)1) Load the register page of the target website in a web browser.2) Solve the CAPTCHA manually, and submit the form.3) Trap this request in a web proxy and do not allow it to reach the web server. This request contains a valid SESSIONID, valid form fields and a valid CAPTCHA solution.4) Create a custom script that repeatedly sends this request to server.5) Submit one request.6) Upon successful submission, the web application will reset the current SESSIONID and send new SESSIONID back in response headers.7) Change the value of SESSIONID in recorded request (step 3) to the value copied from response in Step 6 above.8) Go to step 5.9) Able to make multiple successful submissions with single CAPTCHA solution.© 2013 WhiteHat Security, Inc. 19
    • 20. D EF EN SE―The best defense is to reset CAPTCHA solution inside the HTTP session during theCAPTCHA verification stage. It is also important to note that when a website relies onthird-party CAPTCHA provider, it does not maintain any session information at its endand CAPTCHA is performed by the CAPTCHA provider. These websites are notvulnerable to CAPTCHA Re-Riding Attack.‖© 2013 WhiteHat Security, Inc. 20
    • 21. 2 0 1 2 TO P T EN Permanent backdooring of HTML5 client-side application―To improve performance, particularly for mobile users, manywebsites have started caching app logic on client devices via HTML5local storage. Unfortunately, this can make common injectionvulnerabilities even more dangerous, as malicious code can invisiblypersist in the cache. Real-world examples of this problem have nowbeen discovered in third-party ―widgets‖ embedded across manywebsites, creating security risks for the companies using suchservices – even if their sites are otherwise protected againstattacks.‖Joey Tysonhttp://securitymusings.com/article/3159/how-a-platform-using-html5-can-affect-the-security-of-your-website© 2013 WhiteHat Security, Inc. 21
    • 22. PR ER EQ U ISIT ESWhat to watch out for…• A Web application caching [javascript] code in HTML5 local storage, rather than routinely downloading it across the network every time the app/page is visited. Developers find doing this may provide a significant performance boost, particularly on mobile devices, where bandwidth and typical caches can be much more limited.What the bad guy may do next…• If the code saved in the local storage is compromised, via XSS exploit for example, an attacker could inject malicious code that persists in the client-side cache. This payload would then be executed by the web app each time a user opens the site – even if they‘d previously closed the browser. A single ―reflected‖ XSS attack can poison the local storage for every following page the user visits on that site.© 2013 WhiteHat Security, Inc. 22
    • 23. M ASS PW N AG EMaking Matters Worse:• Eradicating such [malicious] code can be quite difficult, and the victim website might not even be able to detect an ongoing attack.• Reminder: When a developer includes third-party JavaScript on his or her site, that code has the same capabilities as any other script on the page.• Modifying static file on a remote server is generally not possible, even if cross-site scripting issues are present, but what if a third-party script from a site with XSS problems also stored code in local storage? “If content from the compromised origin is commonly embedded on third-party pages (think syndicated „like‟ buttons or advertisements), with some luck, attacker‟s JavaScript may become practically invincible.” - Michal Zalewskihttp://events.ccc.de/congress/2011/Fahrplan/events/4811.en.htmlhttp://jeremiahgrossman.blogspot.com/2010/07/third-party-web-widget-security-faq.html© 2013 WhiteHat Security, Inc. 23
    • 24. IN - T H E -WILDApture (acquired by Google):• Provided pop-up boxes for exploring content related to highlighted terms in a page.• A 3rd-party ―widget‖ service that used local storage code caching – and a page on the same domain as those scripts had a reflected XSS vulnerability which could be used to inject malicious code in the cache. This code would then be executed in the context of the site using Apture. The problem with Apture‘s service affected the security of many sites across the web.© 2013 WhiteHat Security, Inc. 24
    • 25. U SAG ETo use Apture widgets:• Dynamically loaded an external script hosted on apture.com with a site token specified. This code loaded another script based on the user‘s browser which actually began setting up the framework for Apture to integrate with the site‘s content.• The script inserted an inline frame into the page that loaded a file from cdn.apture.com. A callback function allowed this iframe to pass messages back to the original window context where the script is running (the non-Apture site). This iframe then loaded the actual app logic and passed the code back to the original site via the cross-document messaging interface.• Apture‘s iframe setup allowed them to take advantage of another HTML5 innovation that made their service load much faster. Web storage functionality provides the localStorage object, a place to save key/value data on the client which allows for more space and flexibility than cookies.• Apture used a localStorage object for cdn.apture.com not only to save data, such as an ID for tracking users, but to actually cache their app logic code. If the cdn.apture.com iframe detected that this cache already existed, it would simply load the code from localStorage rather than issue another HTTP request for the 272KB worth of JavaScript – saving time and bandwidth.© 2013 WhiteHat Security, Inc. 25
    • 26. EXPL O ITAT IONEVAL is EVIL Like everyone else, Apture had an exploitable XSS vulnerability. This URL includes a script that appends ―alert(document.cookie)‖ to the app logic in localStorage: http://cdn.apture.com/search/xss?yt=%22%3E%3Cscript%3Eif%28window.x%21%3D1%29%7Blo calStorage%5B%27app-49971756%27%5D%3DlocalStorage%5B%27app- 49971756%27%5D%2b%22alert%28document.cookie%29%3B%22%7Dwindow.x%3D1%3C% 2fscript%3E Once this vulnerability is used to insert attack code into localStorage, visiting any site that had Apture‘s widgets would cause the attack code to be loaded from the Apture iframe and executed in the context of the non-Apture site. Since this is essentially an example of DOM-based XSS (the code is loaded dynamically on the client side), requests sent to those sites‘ servers would not include any XSS fingerprints, such as <script> in a GET or POST parameter. The localStorage code caching turned one reflected XSS vulnerability on Apture’s site into persistent, client-side XSS across all domains using their service.© 2013 WhiteHat Security, Inc. 26
    • 27. D EF EN SENo Simple Answers  Trade-offs between performance and risk • Application cache, another new HTML5 features, is actually geared towards precisely this use case and harder to compromise, but it can create UI warnings in some browsers [Firefox]. (Such warnings are a good practice, but undesirable for third-party widgets.) • Data in local storage should be treated as untrusted, even if it‘s just content instead of code. • If local storage is used for scripts, it should be accessed from a domain only serving static files, which reduces the likelihood of XSS vulnerabilities. • Newer browsers also support features such as sandboxed inline frames and Content Security Policy that could help limit the impact of embedded widgets if they became compromised.© 2013 WhiteHat Security, Inc. 27
    • 28. 2 0 1 2 TO P T EN Cross-Site Port Attacks―Many web applications provide functionality to pull data from otherwebservers for various reasons. Using user specified URLs, webapplications can be made to fetch images, download XML feeds fromremote servers, text based files etc. This functionality can be abusedby making crafted queries using the vulnerable web application as aproxy to attack other services running on remote/local servers.Attacks arising via this abuse of functionality are named as Cross-Site Port Attacks (XSPA).‖―Riyaz Ahemed Walikarhttp://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.htmlRobert Hansenhttp://www.sectheory.com/intranet-hacking.htm© 2013 WhiteHat Security, Inc. 28
    • 29. 3 - T IERXSPA allows attackers to abuse functionality in web applications to:1. Port Scan remote Internet facing servers, intranet devices and the local web server itself.2. Exploiting vulnerable programs running on the Intranet or on the local web server3. Attacking internal/external web applications that are vulnerable to GET parameter based vulnerabilities (SQLi via URL, parameter manipulation etc.)4. Fingerprinting intranet web applications using standard application default files & behavior5. Reading local web server files using the file:/// protocol handler.© 2013 WhiteHat Security, Inc. 29
    • 30. T EL LTAL E SIG N© 2013 WhiteHat Security, Inc. 30
    • 31. C O D E SAMPL E<?phpif (isset($_POST[url])){$link = $_POST[url];$filename = ./curled/.rand().txt;$curlobj = curl_init($link);$fp = fopen($filename,"w");curl_setopt($curlobj, CURLOPT_FILE, $fp);curl_setopt($curlobj, CURLOPT_HEADER, 0);curl_exec($curlobj);curl_close($curlobj);fclose($fp);$fp = fopen($filename,"r");$result = fread($fp, filesize($filename));fclose($fp);echo $result;?> © 2013 WhiteHat Security, Inc. 31
    • 32. R EAL - W ORL D AT TAC K Port Scanning using Google Webmaster Tools © 2013 WhiteHat Security, Inc. 32
    • 33. AT TAC KPort Scanning using Google Webmaster Tools© 2013 WhiteHat Security, Inc. 33
    • 34. AT TAC KPort Scanning using Google Webmaster Tools© 2013 WhiteHat Security, Inc. 34
    • 35. AT TAC KReading local files using file:/// protocolRequest: file:///C:/Windows/win.ini© 2013 WhiteHat Security, Inc. 35
    • 36. AT TAC KAdobes Omniture web application file:///etc/passwd© 2013 WhiteHat Security, Inc. 36
    • 37. D EF EN SE• Response Handling: If a web application expects specific content type on the server, programmatically ensure the data received satisfies checks imposed on the server before displaying or processing the data for the client.• Error handling and messages: Display generic error messages when something goes wrong. If content type validation fails, display generic errors to the client like "Invalid Data retrieved". Also ensure message are the same when the request fails on the backend and if invalid data is received. This prevents the application from being abused as distinct error messages will be absent for closed and open ports.• Restrict connectivity to HTTP based ports: Restrict the ports to which the web application can connect to, such as HTTP ports: 80, 443, 8080, 8090 etc. Doing so can lower the attack surface.• Blacklist IP addresses: Internal IP addresses, localhost specifications and internal hostnames can all be blacklisted to prevent the web application from being abused to fetch data/attack these devices.• Disable unwanted protocols: Only allow http and https to make requests to remote servers. Whitelisting these protocols will prevent the web application from making requests over other protocols like file:///, gopher://, ftp:// and other URI schemes.© 2013 WhiteHat Security, Inc. 37
    • 38. 2 0 1 2 TO P T EN Blended Threats and JavaScript―During 2006, it was shown how common Web browser attacks could beleveraged bypass perimeter firewalls. In the years since, the fundamentalproblems were never addressed and the Intranet remains wide open, probablybecause the attack techniques described had important limitations. Theselimitations prevented mass scale and persistent compromise of networkconnected devices, which include but are not limited to home broadbandrouters. Now in 2012, with the help of new research and next-generationtechnologies like HTML5, browser-based Intranet attacks have overcome manyof the old limitations and improved to a new degree of scary.‖Phil Purviance and Josh Brasharshttps://superevr.com/blog/2012/blended-threats-and-javascript/© 2013 WhiteHat Security, Inc. 38
    • 39. BASIC SWeb Threats -> Network Compromise• Utilize an XSS bug to poke holes in Intranet network• Take advantage of very outdated security in routers• Flash the firmware of that router via XSS, File Upload Abuse, & CSRF• Permanent compromise© 2013 WhiteHat Security, Inc. 39
    • 40. T H E AT TAC KScan The Intranet Yay HTML5!JavaScript Intranet scan, nothing new or fancy butdoes return a list of internal Ips that are up andlistening.© 2013 WhiteHat Security, Inc. 40
    • 41. T H E AT TAC KGain Access The easy way© 2013 WhiteHat Security, Inc. 41
    • 42. Real World Examples© 2013 WhiteHat Security, Inc. 42
    • 43. T H E AT TAC KGain Access The less easy way© 2013 WhiteHat Security, Inc. 43
    • 44. Basic Auth Brute Force© 2013 WhiteHat Security, Inc. 44
    • 45. EXPL O ITHTML5 File Upload Load Malicious Firmware to memory https://github.com/superevr/ddwrt-install-tool© 2013 WhiteHat Security, Inc. 45
    • 46. D EF EN SERouter• Change default passwords!Browser• NoScript, Request Policy, Other XSS & CSRF protections© 2013 WhiteHat Security, Inc. 46
    • 47. 2 0 1 2 TO P T EN Bruteforce of PHPSESSID―...We provide a number of practical techniques and algorithms forexploiting randomness vulnerabilities in PHP applications. We focus onthe predictability of password reset tokens and demonstrate how anattacker can take over user accounts in a web application via predictingor algorithmically derandomizing the PHP core randomness generators.‖Arseny Reutov, Timur Yunusov, and Dmitry Nagibinhttp://blog.ptsecurity.com/2012/08/not-so-random-numbers-take-two.htmlGeorge Argyros and Aggelos Kiayiashttp://crypto.di.uoa.gr/CRYPTO.SEC/Randomness_Attacks_files/paper.pdfhttp://crypto.di.uoa.gr/CRYPTO.SEC/Randomness_Attacks.html© 2013 WhiteHat Security, Inc. 47
    • 48. BASIC SPHPSESSID =md5( client IP . timestamp . microseconds1 . php_combined_lcg() )• client IP is known to the attacker;• timestamp is known through Date HTTP-header;• microseconds1 – a value from 0 to 1000000;• php_combined_lcg() – an example value is 0.12345678.To generate php_combined_lcg(), two seeds are used:S1 = timestamp XOR (microseconds2 << 11)S2 = pid XOR (microseconds3 << 11)• timestamp is the same;• microseconds2 is greater than microseconds1 (when the first time measurement was made) by 0–3;• pid is the id of the current process (0–32768, 1024–32768 on Unix);• microseconds3 is greater than microseconds2 by 1–4.“The greatest entropy is contained in microseconds1, however with the use of twotechniques it can be substantially reduced.”© 2013 WhiteHat Security, Inc. 48
    • 49. T EC H N IQ UE 1Adversarial Time SynchronizationATS: Send a pair of HTTP requests to determine the moment when the second in theDate HTTP header changes.1) Connect to a web server and send request pairs: 1st to a non- existent page so it‘ll take a minimum time for the web-server to return the response. The 2nd to our target web-application. HTTP/1.1 200 OK2) Get an average time interval between sending an HTTP Date: Wed, 08 Aug 2012 06:05:14 GMT request and receiving the response (= RTT) … HTTP/1.1 200 OK3) When the seconds in Date HTTP-header of the two requests Date: Wed, 08 Aug 2012 06:05:15 GMT changed approximate the time of remote microseconds in local time using RTTs of the two requests divided by two and offsetting the delay between requests.4) If session_start() is called somewhere deeper in the code, you may try to install the web-app locally and get the approximate time when it is called.“...the microseconds between our requests zeroed. By sending requests with dynamicdelays it is possible to synchronize local value of microseconds with the server one.”© 2013 WhiteHat Security, Inc. 49
    • 50. T EC H N IQ UE 2 Request Twins Attacker send two requests: the 1st — to reset their own password and the 2nd — to reset that of an administrator. The gap between microseconds will be minimal.To increase speed over thePasswordPro module bytaking advantage of positivelinear correlation betweendeltas ofmicroseconds, they createdtheir own application. 16 million hashes per second, seed calculation takes less than an hour on 3.2 GHz Quad Core i5. Having pid and php_combined_lcg one can compute the seed used in mt_rand. (timestamp x pid) XOR (106 x php_combined_lcg()) “if a web application uses standard PHP sessions, it is possible to obtain the random numbers generated via mt_rand(), rand(), and uniqid().” © 2013 WhiteHat Security, Inc. 50
    • 51. T EC H N IQ UE 3Get mt_rand seed through randomnumbers leakage“The seed used for mt_rand is an unsigned integer 2^32. If a random numberleaked, it is possible to get the seed using PHP itself and rainbow tables. It takesless than 10 minutes.”The scripts to generate rainbow tables, search the seed, and ready-made tableshttp://www.gat3way.eu/poc/mtrt/© 2013 WhiteHat Security, Inc. 51
    • 52. SO L U T IONSWhat to look for and code defense“All the mt_rand(), rand(), uniqid(), shuffle(), lcg_value(), etc. The only securefunction is openssl_random_pseudo_bytes(), but it is rarely used in webapplications.”• MySQL function RAND() — it can be also predicted though.• Suhosin patch — does not patch mt_srand, srand. The Suhosin extension should also be installed.• /dev/urandom — the securest way.© 2013 WhiteHat Security, Inc. 52
    • 53. 2 0 1 2 TO P T EN Chrome addon hacking―Webpages can sometimes interact with Chrome addons and thatmight be dangerous. Chrome addons fingerprinting, universalXSS, bypass AdBlock, Chrome Extension ExploitationFramework, and owning a system.‖―Krzysztof Kotowiczhttp://blog.kotowicz.net/2012/02/intro-to-chrome-addons-hacking.htmlhttp://blog.kotowicz.net/2012/02/chrome-addons-hacking-want-xss-on.htmlhttp://blog.kotowicz.net/2012/03/chrome-addons-hacking-bye-bye-adblock.htmlhttp://blog.kotowicz.net/2012/07/xss-chef-chrome-extension-exploitation.htmlhttp://blog.kotowicz.net/2012/09/owning-system-through-chrome-extension.html© 2013 WhiteHat Security, Inc. 53
    • 54. H ISTO RYHacking Google ChromeOS“Googleʼsdrive to move away from the desktop, and into the cloud results in desktopapplications being replaced with HTML5 & JavaScript rich extensions. These new“desktop programs” seem to be more secure, because they do not have the classicvulnerabilities that desktop applications end services have--buffer/stack/heapoverflows/underflows, format string attacks, plus many more. Since exploitation nolonger leads to shell, the real dangers and implications of any exploit seem to bemitigated.Unfortunately, this is not true. HTML and Javascript applications (Chrome Extensions)are now vulnerable to standard HTML and Javascript attacks. The most serious, in thissituation, is Cross Site Scripting. By utilizing an XSS vulnerability in an extension, anattacker can pivot from that extension, and take advantage of the permissions given toit to attack and gain access to user information loaded in other tabs.”-Matt Johansen & Kyle OsbornBlackHat 2011 WhitePaper© 2013 WhiteHat Security, Inc. 54
    • 55. BASIC SWhy Chrome Extensions?• Basic HTML applications• Access to extensive APIs• Permissions set by 3rd party Dev• Manifest.json• Sandbox side-stepExploitation• Universal XSS via 1 extension bug• chrome.tabs, chrome.history, chrome.cookies, chrome.proxy, API access make for powerful attacks• Filesystem access and remote code execution made easy© 2013 WhiteHat Security, Inc. 55
    • 56. APPL IC AT IO NBeEF & ChEF• You‘ve found XSS in an extension, utilized it to exploit Javascript in any tab. Now what? Browser Exploitation Framework & Chrome Extension Exploitation Framework• BeEF – Metasploit of the web. Makes reflective XSS more persistent and able to replay exploits• ChEF – BeEF for Chrome Extensions. • Monitor current sessions / open tabs • Execute JavaScript on any site in any tab • Access localStorage • Read / write cookies • Manipulate browser history • Take screenshots • Inject BeEF hooks to utilize their payloads and exploits© 2013 WhiteHat Security, Inc. 56
    • 57. C H EFChEF Console© 2013 WhiteHat Security, Inc. 57
    • 58. EXPL O ITAT IONXSS Everywhere• If an extension‘s ‗manifest.json‘ file has permissions set to ‗*‘ you can execute JavaScript anywhere in the browser with ‗chrome.tab.executeScript‘• Bypass AdBlock: By altering the DOM you can create a global whitelist© 2013 WhiteHat Security, Inc. 58
    • 59. D EF EN SE Beware© 2013 WhiteHat Security, Inc. 59
    • 60. 2 0 1 2 TO P T EN Pwning via SSRF (memcached, php-fastcgi, etc)―SSRF, as in Server-Side Request Forgery. A great concept of the attackwhich was discussed in 2008 with very little information about theory andpractical examples. The idea is to find victim server interfaces that will allowsending packets initiated by victims server to the localhost interface of thevictim server or to another server secured by firewall from outside. We havefound various SSRF vulnerabilities which allow internal network portscanning, sending any HTTP requests from server, bruteforcing backed andmore but the most powerful technique was XXE Tunneling.‖Alexander Polyakovhttp://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_12_Polyakov_SSRF_Business_WP.pdfhttp://erpscan.com/press-center/blog/ssrf-via-ws-adressing/http://erpscan.com/wp-content/uploads/2012/11/SSRF.2.0.poc_.pdf© 2013 WhiteHat Security, Inc. 60
    • 61. H ISTO RYSSRF (CIRCA 2008)“The first example of SSRF is an SMBRelay attack discussed by Deral Heiland atShmoocon in 2008 entitled, “Web Portals Gateway To Information Or A Hole In OurPerimeter Defenses.” Some web-interfaces on corporate portals allow loading anyexternal resource like an iframe. The difference was that Web interface allows loadingfiles from other HTTP sources. It was done by portlets that were designed to deliver tothe user the requested information that the user cannot access directly. The portletruns a transaction to a connected system and then runs its response with informationto the portal user. These portlets makes portal a single point of access to internalresources. This was a great example of SSRF attack via URL parameter of vulnerableportlet.”…“Later, other examples of SSRF attacks were shown. Same ideas, but attack wasexecuted through XML External Entity vulnerability. “© 2013 WhiteHat Security, Inc. 61
    • 62. BASIC SAttack Flow• Send Packet A to Service A• Service A initiates Packet B to Service B• Services can be on the same host or on different hosts• We can manipulate some fields of Packet B within Packet A• Various SSRF attacks depend on how many fields we can control in Packet BExploitation• Vulnerabilities like File Include, SQL Injection, XML External Entity or any other vulnerability that allows executing commands that initiate calls to remote systems.• Through enhanced rights in an application, when you can call HTTP pages or UNC paths or use trusted connections.© 2013 WhiteHat Security, Inc. 62
    • 63. C L ASSIF IC AT IONMany classes of SSRF attacks (complicated)• Trusted SSRF: Send requests (Packet B) to remote services, but only to those which are somehow predefined.• Remote SSRF: Requests (Packet B) to any remote IP and port. This type has 3 subtypes depending on how much data we can control: • Simple Remote SSRF: No control on application level of Packet B • Partial Remote SSRF: Control on some fields of application level of Packet B • Full Remote SSRF: Full control on application level of Packet B© 2013 WhiteHat Security, Inc. 63
    • 64. EXAMPL ESTrusted SSRF attacksMSSQL: Need at least public rights to use MSSQL trusted links. Links can be withpredefined passwords. The attacker can use them in Host A to forge requests and obtainresponses from Host B.Select * from openquery(HostB,select * from @@version)]Oracle: Links can be with predefined passwords. The attacker can use them to forgerequests and obtain responses from host B.SELECT * FROM myTable@HostBEXECUTE mySchema.myPackage.myProcedure(someParameter)@HostB© 2013 WhiteHat Security, Inc. 64
    • 65. EXAMPL ESSimple Remote SSRFSAP NetWeaver ipcpricing: Scan an internal network from the Internet by sendingdifferent HTTP requests to JSP pages./ipcpricing/ui/BufferOverview.jsp?server=172.16.0.13&port=31337&dispatcher=&targetClient=© 2013 WhiteHat Security, Inc. 65
    • 66. XXE T U N N EL IN GPartial Remote SSRFXXE Tunneling (via Gopher): XML External Entity (XXE) is a very popular vulnerabilityin XML Parser. External entities force the XML parser to access the resource specified bythe URI, e.g., a file on the local machine or on a remote systems.• Makes a TCP connection with 172.16.0.1 and port 3300 and then send a packet containing string 23456789 (the first symbol will be cut).<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [<!ELEMENT foo ANY ><!ENTITY date SYSTEM ―gopher://172.16.0.1:3300/AAAAAAAAA" >]><foo>&date;</foo>© 2013 WhiteHat Security, Inc. 66
    • 67. D IAG R AM© 2013 WhiteHat Security, Inc. 67
    • 68. AD VAN C EDXXE Tunneling to Buffer Overflow• A buffer overflow vulnerability found by Virtual Forge in ABAP Kernel (fixed in sapnote 1487330)• Shellcode size is limited to 255 bytes (name parameter)• As we don‘t have direct connection to the Internet from the vulnerable system, we want to use DNS tunneling shellcode to connect back© 2013 WhiteHat Security, Inc. 68
    • 69. PAC KET B© 2013 WhiteHat Security, Inc. 69
    • 70. PAC KET AInsert Packet B into Packet A• We need to insert non-printable symbols. Gopher supports urlencode like HTTP• Also help evade attack against IDS systems© 2013 WhiteHat Security, Inc. 70
    • 71. FULL CONTROL© 2013 WhiteHat Security, Inc. 71
    • 72. C O U N T ER -AT TAC KSSRF back connect attackWe send a command from Server A to our Server C using SSRF, and then we generate aresponse which will trigger a vulnerability in an application from Server A.SMB client• DoS by reading huge files remotely• SMBRelay• RCE Vulnerabilities in SMB clientMemory corruption vulnerabilities in FTP clientClient path traversalJAR parsermailto: parserHTTP client• DoS by multiple entities with links to big data• DoS by multiple GZIP bomb© 2013 WhiteHat Security, Inc. 72
    • 73. 2 0 1 2 TO P T EN CRIME―Compression Ratio Info-leak Made Easy (CRIME) is asecurity exploit against secret web cookies over connectionsusing the HTTPS and SPDY protocols that also use datacompression. When used to recover the content of secretauthentication cookies, it allows an attacker to perform sessionhijacking.‖Juliano Rizzo and Thai Duonghttp://netifera.com/research/crime/CRIME_ekoparty2012.pdfhttp://en.wikipedia.org/wiki/CRIME_(security_exploit)http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/© 2013 WhiteHat Security, Inc. 73
    • 74. BASIC SCRIMEDecrypts HTTPS traffic to steal cookies and hijack sessions. Requirements tobecome a victim:1) Attacker can sniff your network traffic.2) Victim visits evil.com3) Both the browser and server support any version of TLS compression or SPDY Previously * Vulnerable Never VulnerableGmail, Twitter, Dropbox, GitHub, etc.“42% of sites surveyed by his service support TLS compression.” Ivan Ristichttps://www.ssllabs.com/index.html© 2013 WhiteHat Security, Inc. 74
    • 75. SID E - C H AN NELCRIME: Chosen Plaintext Attack• Compression reduces the number of bytes contained in a data stream by removing redundant bits. A side effect of compression is it leaks clues about the encrypted contents, providing a "side channel" to those with the ability to monitor the data.• By modifying the clear-text payload hundreds or thousands of times and watching how each one interacts with the encrypted data, attackers can deduce its contents.• An encrypted message is combined with attacker-controlled JavaScript that, letter by letter, performs a brute-force attack on the secret key. When it guesses the letter X as the first character of the cookie secret, the encrypted message will appear differently than an encrypted message that uses W or Y.• Once the first character is correctly guessed, the attack repeats the process again on the next character in the key until the remainder of the secret is deduced. The use of JavaScript isnt necessary, but does make the brute-force attack faster.http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/© 2013 WhiteHat Security, Inc. 75
    • 76. AT TAC K F L O W"Basically, the attacker is running script in Evil.com. He forces the browser to openrequests to Bank.com by, for example, adding <img> tags with src pointing toBank.com," Rizzo said. "Each of those requests contains data from mixed sources.”In these requests, attacker data and data produced by the browser is compressed andmixed together. Those requests can include the path, which the attacker controls, thebrowsers headers, which are public, and the cookie, which should be secret."The problem is that compression combines allthose sources together," Rizzo added. "Theattacker can sniff the packets and get the sizeof the requests that are sent. By changing thepath, he could attempt to minimize the requestsize, i.e., when the file name matches thecookie." http://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312 © 2013 WhiteHat Security, Inc. 76
    • 77. D EMO Video demo shows Github.com, Dropbox.com, and Stripe.com, when visited with a then-patched version of Chrome, succumbing to the CRIME attack. All three of disabled compression and no longer vulnerable.https://www.youtube.com/watch?v=gGPhHYyg9r4 © 2013 WhiteHat Security, Inc. 77
    • 78. D EF EN SEBrowserUpgrade browsers to the latest version.ServerDisable compression.© 2013 WhiteHat Security, Inc. 78
    • 79. WHAT WE’VE LEARNED© 2013 WhiteHat Security, Inc. 79
    • 80. L ESSO N S• What’s old is new and improved: Many Web attack techniques from previous years, including those not appearing on the Top Ten, are constantly being improved. Researchers leverage new technology functionality and combine previously known techniques and produce combinations.• 3-Peat: Encryption related attack techniques, by Juliano Rizzo and Thai Duong, took the #1 spot 3 years in a row (BEAST in 2011 and Padding Oracle in 2010). Web security community respects deep technical research.• Attack and Researcher Diversity: In 2012 we saw attack techniques focused on encryption, HTML5 / client-side, mobile, infrastructure server-side, intranet, session state, etc. The range of expertise to keep up with all the new cutting-edge research is at the very least, a full-time job. And the researchers themselves are located across the globe.© 2013 WhiteHat Security, Inc. 80
    • 81. Thank you to… • All Web security researchers • Panel of Judges: Ryan Barnett, Robert Auger, Robert Hansen (CEO, Falling Rock Networks) Dinis Cruz, Jeff Williams (CEO, Aspect Security), Peleus Uhley, Romain Gaucher (Lead Researcher, Coverity), Giorgio Maone, Chris Wysopal, Troy Hunt, Ivan Ristic (Director of Engineering, Qualys), and Steve Christey (MITRE) • Everyone in the Web security community who assisted with votingJEREMIAH GROSSMAN MATT JOHANSENFounder and CTO Head of the Threat Research CenterTwitter: @jeremiahg Twitter: @mattjayEmail: jeremiah@whitehatsec.com Email: matt@whitehatsec.com