Monday, February 23, 2009

Top Ten Web Hacking Techniques of 2008 (Official)

We searched far and wide collecting as many Web Hacking Techniques published in 2008 as possible -- ~70 in all. These new and innovative techniques were analyzed and ranked based upon their novelty, impact, and pervasiveness. The 2008 competition was exceptionally fierce and our panel of judges (Rich Mogull, Chris Hoff, H D Moore, and Jeff Forristal) had their work cut out for them. For any researcher, or "breaker" if you prefer, simply the act of creating something unique enough to appear on the list is no small feat. That much should be considered an achievement. In the end, ten Web hacking techniques rose head and shoulders above.

Supreme honors go to Billy Rios, Nathan McFeters, Rob Carter, and John Heasman for GIFAR! The judges were convinced their work stood out amongst the field. Beyond industry recognition, they also will receive the free pass to Black Hat USA 2009 (generously sponsored by Black Hat)! Now they have to fight over it. ;)

Congratulations to all!

Coming up at SnowFROC AppSec 2009 and RSA Conference 2009 it will be my great privilege to highlight the results. Each of the top ten techniques will be described in technical detail for how they work, what they can do, who they affect, and how best to defend against them. The opportunity provides a chance to get a closer look at the new attacks that could be used against us in the future -- some of which already have.

Top Ten Web Hacking Techniques of 2008!

(Billy Rios, Nathan McFeters, Rob Carter, and John Heasman)

2. Breaking Google Gears' Cross-Origin Communication Model
(Yair Amit)

3. Safari Carpet Bomb
(Nitesh Dhanjani)

4. Clickjacking / Videojacking
(Jeremiah Grossman and Robert Hansen)

5. A Different Opera
(Stefano Di Paola)

6. Abusing HTML 5 Structured Client-side Storage
(Alberto Trivero)

7. Cross-domain leaks of site logins via Authenticated CSS
(Chris Evans and Michal Zalewski)

8. Tunneling TCP over HTTP over SQL Injection
(Glenn Wilkinson, Marco Slaviero and Haroon Meer)

9. ActiveX Repurposing
(Haroon Meer)

10. Flash Parameter Injection
(Yuval Baror, Ayal Yogev, and Adi Sharabani)

The List
  1. CUPS Detection
  2. CSRFing the uTorrent plugin
  3. Clickjacking / Videojacking
  4. Bypassing URL Authentication and Authorization with HTTP Verb Tampering
  5. I used to know what you watched, on YouTube (CSRF + Crossdomain.xml)
  6. Safari Carpet Bomb
  7. Flash clipboard Hijack
  8. Flash Internet Explorer security model bug
  9. Frame Injection Fun
  10. Free MacWorld Platinum Pass? Yes in 2008!
  11. Diminutive Worm, 161 byte Web Worm
  12. SNMP XSS Attack (1)
  13. Res Timing File Enumeration Without JavaScript in IE7.0
  14. Stealing Basic Auth with Persistent XSS
  15. Smuggling SMTP through open HTTP proxies
  16. Collecting Lots of Free 'Micro-Deposits'
  17. Using your browser URL history to estimate gender
  18. Cross-site File Upload Attacks
  19. Same Origin Bypassing Using Image Dimensions
  20. HTTP Proxies Bypass Firewalls
  21. Join a Religion Via CSRF
  22. Cross-domain leaks of site logins via Authenticated CSS
  23. JavaScript Global Namespace Pollution
  24. GIFAR
  25. HTML/CSS Injections - Primitive Malicious Code
  26. Hacking Intranets Through Web Interfaces
  27. Cookie Path Traversal
  28. Racing to downgrade users to cookie-less authentication
  29. MySQL and SQL Column Truncation Vulnerabilities
  30. Building Subversive File Sharing With Client Side Applications
  31. Firefox XML injection into parse of remote XML
  32. Firefox cross-domain information theft (simple text strings, some CSV)
  33. Firefox 2 and WebKit nightly cross-domain image theft
  34. Browser's Ghost Busters
  35. Exploiting XSS vulnerabilities on cookies
  36. Breaking Google Gears' Cross-Origin Communication Model
  37. Flash Parameter Injection
  38. Cross Environment Hopping
  39. Exploiting Logged Out XSS Vulnerabilities
  40. Exploiting CSRF Protected XSS
  41. ActiveX Repurposing, (1, 2)
  42. Tunneling tcp over http over sql-injection
  43. Arbitrary TCP over uploaded pages
  44. Local DoS on CUPS to a remote exploit via specially-crafted webpage (1)
  45. JavaScript Code Flow Manipulation
  46. Common localhost dns misconfiguration can lead to "same site" scripting
  47. Pulling system32 out over blind SQL Injection
  48. Dialog Spoofing - Firefox Basic Authentication
  49. Skype cross-zone scripting vulnerability
  50. Safari pwns Internet Explorer
  51. IE "Print Table of Links" Cross-Zone Scripting Vulnerability
  52. A different Opera
  53. Abusing HTML 5 Structured Client-side Storage
  54. SSID Script Injection
  55. DHCP Script Injection
  56. File Download Injection
  57. Navigation Hijacking (Frame/Tab Injection Attacks)
  58. UPnP Hacking via Flash
  59. Total surveillance made easy with VoIP phone
  60. Social Networks Evil Twin Attacks
  61. Recursive File Include DoS
  62. Multi-pass filters bypass
  63. Session Extending
  64. Code Execution via XSS (1)
  65. Redirector’s hell
  66. Persistent SQL Injection
  67. JSON Hijacking with UTF-7
  68. SQL Smuggling
  69. Abusing PHP Sockets (1, 2)
  70. CSRF on Novell GroupWise WebAccess

Sunday, February 22, 2009

SQL Injection, eye of the storm

Originally published by Security Horizon in the Winter 2009 edition of Security Journal.

In 2008 SQL Injection became the leading method of malware distribution, infecting millions of Web pages and foisting browser-based exploits upon unsuspecting visitors. The ramifications to online businesses include data loss, PCI fines, downtime, recovery costs, brand damage, and revenue decline when search engines blacklist them. According to WhiteHat Security, 16 percent of websites are vulnerable to SQL Injection. This is likely under-reported given that the statistics are largely based on top-tier Web properties that employ a website vulnerability management solution to identify the problem. The majority of websites do not and as such may be completely unaware of the extent of the issue. In addition, some recommended security best-practice have ironically benefited malicious hackers. Websense now reports that "60 percent of the top 100 most popular Web sites have either hosted or been involved in malicious activity in the first half of 2008." Let’s examine the forces that have aligned to create the storm that allows SQL Injection to thrive.

Any custom Web application that lacks proper input-validation, fails to use parameterized SQL statements, and/or creates dynamic SQL with user-supplied data potentially leave themselves open to SQL Injection attacks -- unauthorized commands passed to back-end databases. When Rain Forest Puppy first described SQL Injection ten years ago, on Christmas Day 1998, it was a targeted one-off attack capable of exploiting only a single website at a time. Custom Web applications contain custom vulnerabilities and require custom exploits. Successfully extracting data out of an unfamiliar database is different in each instance and greatly aided by error messages revealing snippets of server-side code.

To solve the SQL Injection problem, preferably in the code, first we must identify what is broken. The easiest method to-date has been through remote black-box testing, submitting meta-characters (single quotes and semicolons) into Web applications. If the website returns a recognizable response, such as an ODBC error message, there is a high probability that a weakness exists. Comprehensive security testing, typically aided by black-box vulnerability scanners, performs the same procedure on every application input-point including URL query parameters, POST data, cookies, etc. and repeated with each code update. This software security testing process is also now one of the assessment options mandated by PCI-DSS section 6.6.

In the wake of highly publicized compromises like the 2006 incident at CardSystems, a back-end credit card transaction processor, in which millions of stolen credit card numbers fell into the wrong hands, website owners were strongly encouraged to update their Web application code and suppress error messages to defend against SQL Injection attacks. Many implemented solely the latter since it only required a simple configuration change, hindering the bad guy’s ability to identify SQL Injection vulnerabilities. Since the vulnerabilities couldn’t be found easily, perhaps this contributed to incorrectly training developers that security through obscurity was enough. Widespread attacks were not seen as prevalent enough to justify a serious software security investment. Despite cutting-edge Blind SQL Injection research helping to improve black-box testing, error message suppression contributed to three very important side effects:
  1. Black-box vulnerability scanner false-positive and false-negative rate skyrocketed.
  2. SQL Injection became significantly harder to identify, but ironically not exploit.
  3. Extracting data out of a database became exceptionally more laborious than injecting data in.
In 2007, cyber criminals in China created a new technique capable of generically exploiting SQL Injection vulnerabilities without reliance on error messages. Perpetrators inserted malicious JavaScript IFRAMEs (pointing to malware servers) into back-end databases, as opposed to pulling data out, and used the capability to exploit unpatched Web browsers and plugi-ins in record numbers. "The scale of this global criminal operation has reached such proportions that Sophos discovers one new infected webpage every 4.5 seconds – 24 hours a day, 365 days a year." No longer limited to one-off hacks, SQL Injection quickly became a method of choice to target anything and everything on the Web. According to Websense, “75 percent of Web sites with malicious code are legitimate sites that have been compromised.” Furthermore, attacks have been widely successful without even needing to authenticate. That means any website functionality beyond a login screen represents further attack targets. Worse still, security pros are unable to leverage these techniques to improve SQL Injection vulnerability detection because doing so risks adversely affecting the website.

For example, when vulnerability assessments are conducted on production systems, a cardinal rule must be followed, “Do no harm.” This often requires that testing rates be limited (X number of requests per second), testing windows be respected (usually during off-peak hours), and tests be nondestructive. It should go without saying that we do not want to crash websites or fill databases with undesirable content. Malicious hackers have no such restrictions as they may test however they want, whenever they want, for as long as they want. The other disadvantage for website defenders is that they must be 100% accurate at finding and fixing every issue all the time, while the attacker need only to exploit a single missed issue. This is an unfortunate, but inescapable reality in Web security and why testing frequency and comprehensiveness approach is vital.

Source code review (aka white-box testing) is the other option to locate SQL Injection vulnerabilities and often able to peer deeper into the problem than black-box testing. Of course you must have access to the source code. Before considering this as a scalable solution begin by asking yourself if executive management would allocate enough resources to perform source code reviews on every website every time they change. Thinking globally, let’s consider that there are over 186 million websites. While not all are “important,” if 16% had just a single vulnerability as previously cited, that means a staggering 30 million issues are in circulation. Would it be reasonable to project that finding (not fixing) each unique issue through white-box testing, even assisted by automation, would require $100 in personnel and technology costs? If so, we are talking about at least a $3 billion dollar price tag to simply locate SQL Injection -- to say nothing about other more prevalent issues such as Cross-Site Scripting and Cross-Site Request Forgery that will be left undiscovered.

Secure software education is another valuable long-term strategy that will help prevent another 30 million vulnerabilities being added to the pile over the next 15 years, but will not provide a short-term fix to the problem. Currently, there are roughly 17 million developers worldwide who are not educated on the basic concepts of secure coding that could help them tackle the SQL injection and other issues. Would $500 per developer be an acceptable rate for professional training (commercial 2-day classes typically start at $1,000 on up)? If so, the market must be prepared to make an $8.5 billion investment and then wait for everyone to come up to speed. Obviously the private sector is not going to shoulder such a financial burden alone, not in any economy, let alone in a recession. The fact is education costs must be shared in amongst colleges, enterprises, vendors, developers themselves, or through materials made freely available by organizations such as OWASP and WASC.

The climate for SQL Injection vulnerabilities has all the makings of a perfect storm, one we are already experiencing. The issue is extremely dangerous, incredibly pervasive, difficult to identify, easy to exploit, and expensive to fix. Over the last 15 years organizations have accumulated a lot Web security debt that eclipses our currently estimated spending of ~$300 million, combining outlays for scanning tools, professional services, training, and Web application firewalls. Perhaps we should ask president-elect Obama for a Web security bailout. Not likely. The fact is not every organization will invest adequately to protect themselves, at least not over night. Those who do not will undoubtedly become the low hanging fruit bad guys target first. The smart money says vast numbers of compromises will continue throughout 2009.

For those wishing to do all they can to prevent compromises, the answer is adopting a holistic approach addressing overall Web security, including SQL Injection. While fully articulating the details of each solution is beyond the scope of this article, it is important to highlight several of the most important and why they are a good ideas.
  • Security throughout the Software Development Life-Cycle, because an ounce of prevention is worth a pound of cure.
  • Education, teach a man to fish.
  • Vulnerability Assessment, because you cannot secure what you cannot measure.
  • Web Application Firewalls, because software is not and will never be perfect.
  • Web Browser security, because one must be able to protect themselves against a hostile website.
This combined strategy will prevent us from having the same conversation about Cross-Site Scripting and Cross-Site Request Forgery in the near future.

Thursday, February 05, 2009

Indirect Hard Losses

Indirect Hard Losses is an estimation of the decrease in Web transactions of a certain class of customer, specifically those whose security/privacy have been compromised in the past, compared to those who have not. I first learned about this metric from Robert "RSnake" Hansen (SecTheory), but didn’t know it had a name until I spoke with Laura Mather (Silver Tail Systems). Indirect Hard Losses is rarely discussed, though I suspect it is internally measured, but not published publicly. As stated by InformationWeek regarding a Ponemon Institute study on the Cost of a Data Breach, “Customers, it seems, lose faith in organizations that can't keep data safe and take their business elsewhere.” The next logical question is how much?

Web page malware infections, phishing scams, and website data compromises are common and effective cyber crimes. All the largest online brands have suffered at least one incident compromising the security/privacy of some portion of their customer base. While victimized customers can be made whole again by reimbursing money stolen, replacing lost merchandise, restoring account access, and paying for credit monitoring -- the event undoubtedly makes a lasting impression about the brand. A business may not lose the customer completely, but from my conversations, a nontrivial decline in revenue-generating activity can clearly be measured. Unfortunately I’m unable to reveal names or cite figures as evidence.

Consider for a moment if a social network user’s account is taken over and offensive messages are sent, privacy is violated, and general embarrassment ensues. This is a frequent occurrence, just ask Soulja Boy, Kayne West, Lil Kim, Britney Spears, Fox News and scores of other non-celebrities. Would it be unreasonable to expect this might cause a user to spend less time on the website? For banking customers, perhaps they’d carry smaller account balances and refrain from signing up for new services. Ecommerce retail customers could potentially spend less, less often. All these tendencies would lead to Indirect Hard Losses.

Anonymously or otherwise, anyone want to provide some anecdotal loss percentages that they’ve seen?

Who's who and what's what

When it comes to standards (de-facto or otherwise), guidance, terminology, and nomenclature, Web security is an exceptionally confusing and daunting environment. People frequently ask, “What is the difference between the OWASP Top Ten and WASC’s Web Security Threat Classification.” “How does the new CWE/SANS Top 25 now fit in?” “Which should I use?” Also common are questions about the differences between organizations such as MITRE, OWASP, SANS, and WASC whose scope seem to overlap from time to time. The lack of clarity makes it difficult for people to decide what organizations they should devote their time to when and what standards are best used for what purpose. I’m going to do my best to organize and describe some of the more focused terminology/standard/framework public initiatives and how they differ. By no means an exhaustive list.

Web Application Security Consortium (WASC)
An international group of experts, industry practitioners, and organizational representatives who produce open source and widely agreed upon best-practice security standards for the World Wide Web.

A group of industry leading Web security experts whose membership are elected through a meritocracy based system. WASC tends to initiate projects that are of significant importance to Web Security, require high degree of domain expertise, and depend upon a wide collective involvement of key participants -- such efforts not easily performed by wide-open community groups. Upon release these projects are exceptionally well peer reviewed, provide quality results, and typically become immediately supported by the industry at large.

Web Application Firewall Evaluation Criteria (WAFEC)
An industry standard testing criteria for evaluating the quality of web application firewall solutions. The goal of this project is to develop a detailed web application firewall evaluation criteria; a testing methodology that can be used by any reasonably skilled technician to independently assess the quality of a WAF solution.

Web Application Firewalls (WAF) can be an extremely complex set of technology and difficult to evaluate in fair and straightforward manner. The WAFEC v1 provides a framework for how WAFs may be compared and what areas are most important to focus on. Not a product review in and of itself, it’s instead a guideline to follow. A version 2 update should begin sometime early this year.

Web Application Security Scanner Evaluation Criteria (WASSEC)
A set of guidelines to evaluate web application security scanners on their identification of web application vulnerabilities and its completeness. It will cover things like crawling, parsing, session handling, types of vulnerabilities and information about those vulnerabilities. This document shall evaluate the technical aspects of the web application security scanners and NOT the features provided by it. This document should define the minimum criteria to be followed by a web application scanner.

Similar to WAFEC, the Web application vulnerability scanners can be exceptionally complex and difficult to evaluate. The WASSEC, currently in active development, provides framework for how scanners may be compared and what areas should be focused upon. This is not a product review exercise, but instead a guideline to follow, perhaps to perform such reviews.

Web Security Threat Classification (WASC-TC)
A cooperative effort to clarify and organize the threats to the security of a web site. The members of the Web Application Security Consortium have created this project to develop and promote industry standard terminology for describing these issues. Application developers, security professionals, software vendors, and compliance auditors will have the ability to access a consistent language for web security related issues.

An extremely comprehensive taxonomy of all the Web-based attacks a website might expect to endure, with a strong emphasis on agreed upon terminology, definition, and structure. The Threat Classification may be considered a superset to the OWASP Top Ten. The content has been heavily vetted and is widely supported by vulnerability scanners, Web application firewalls, consultants, and enterprises. The TC purposely left out notions or vulnerability prevalence and default severity rating. Version 2 is presently in active development and nearing completion, expected to be a substantial improvement upon the original.

Open Web Application Security Project (OWASP)
The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.

An organization focused largely on the software development aspects of Web Application Security, spanning across several continents through locally organized member chapters and conferences, and enjoys a large membership base. OWASP is an excellent resource for developers and security practitioners, especially those who are new to Web Security and looking to get engaged with like-minded peers working on similar efforts.

Top Ten
Provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.

Designed to be an awareness building document, the Top Ten list is a combination of Web-based vulnerability prevalence tempered by expert analysis taking likely impact and exploitation into consideration. The Top Ten is not mean to be comprehensive or foundation of any standards, however it is cited as such in the PCI-DSS standard. Technically the document should be considered a subset of the Web Security Threat Classification. For security managers requiring something simple to pass around to upper management or developer groups unaccustomed to Web security, this is a great resource.

A not-for-profit organization chartered to work in the public interest. As a national resource, we apply our expertise in systems engineering, information technology, operational concepts, and enterprise modernization to address our sponsors' critical needs.

Provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design.

A dictionary of software weakness terminology intended for developers and security practitioners. While CWE includes many aspects of Web security, its scope is much larger. In many ways this can be considered a superset of the WASC Threat Classification, even while the terminology might not map identically. Expect an increasing number of industry projects and standards to adopt this nomenclature when discussing security topics or organizing and naming findings.

A dictionary of publicly known information security vulnerabilities and exposures. CVE's common identifiers enable data exchange between security products and provide a baseline index point for evaluating coverage of tools and services.

Publicly disclosed vulnerabilities in commerical and open source software are captured by CVE in a dictionary with numbered identifiers. CVE does not include vulnerabilities in custom web applications. Most network vulnerability scanners will map their finding to CVE IDs.

CWE/SANS Top 25 Most Dangerous Programming Errors (2009)
A list of the most significant programming errors that can lead to serious software vulnerabilities. They occur frequently, are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

MITRE (via CWE) and SANS (via SANS Top 20) joined forced to create a Top 25 list out of the hundreds of issues listed within the CWE. About half of the list is Web-based, roughly similar to the OWASP Top Ten, and rest deal with memory handling issues common to commercial and open source software. Again, not meant to be comprehensive, only a list of the more common and damaging issues. Think OWASP Top Ten in focus, but for all software types.

Established in 1989 as a cooperative research and education organization. Its programs now reach more than 165,000 security professionals around the world.

Top 20
A consensus list of vulnerabilities that require immediate remediation. It is the result of a process that brought together dozens of leading security experts. They come from the most security-conscious government agencies in the UK, US, and Singapore; the leading security software vendors and consulting firms; the top university-based security programs; the Internet Storm Center, and many other user organizations.

The “20” seems to be a misnomer now, the list is segmented into a variety of categories including client-side, server-side, network devices, etc. Each category lists a handful of major pressing threats that are a combination of prevelance, likely severity and odds of exploitation based upon an analysis of experts. For instance, in “ Web Applications “ listed is is PHP Remote File Includes, SQL Injection, Cross-Site Scripting, and Cross-Site Request Forger. Not meant to be comprehensive, but certainly things not to be overlooked. The 2008 release is expected to be forthcoming.

WASC RSA Meet-Up 2009!

For those going to the RSA Conference (San Francisco / April 20 – 24) and want to mingle with fellow Web application security people, the WASC meet-up is the place to be. Free drinks and appetizers will be served (sponsored by WhiteHat Security), and if its anything like last year its sure to rock! WASC meet-ups are rare opportunities to see those we only otherwise communicate with virtually, shoot some pool, and generally have a good time with people of similar security interests. Everyone is welcome, but remember the space at Jillan's is extremely limited. RSVP soon by filling out the form.

WASC RSA Meet-up
Wednesday, April 22, 2009
12:00 pm to 2:00 PM

Jillian's @Metreon
101 Fourth Street, San Francisco
RSVP by April 17, 2009*

*Please stop by the WhiteHat booth to receive your special entry pass into the party.