Thursday, January 28, 2010

WASC RSA Meet-Up 2010!

For those attending RSA Conference 2010 (San Francisco / March 1 – 5) and want to mingle with fellow Web application security people, the Web Application Security Consortium (WASC) luncheon is the place to be. Free drinks and appetizers will be served (sponsored by WhiteHat Security). WASC meet-ups are rare opportunities to shake hands with like minded people we only otherwise communicate with virtually. We'll shoot some pool, chit chat, 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 quickly if you want to get in.

To attend please go directly to Jillian's to check-in with WhiteHat staff and then you will be granted access to the party.

WASC RSA 2010 Meet-up
Wednesday, March 3, 2010
Lunch served: 12:00 PM to 2:00 PM
101 Fourth Street | 415.369.6101
RSVP by February 26, 2010*

Wednesday, January 13, 2010

Web-based systems vs. Advanced Persistent Threat

Everyone is giving their $0.02 on the Google v. China situation, and while I normally shy away from blogging about late breaking news, a term Richard Bejtlich used really resonated with me. "Advanced Persistent Threat" (APT). Doesn’t that just capture the essence of the type of attacker we’re up against perfectly? An attacker utilizing 0-day vulnerabilites, spear phishing tactics, one-off malware, and with little time, money, or legal constraints. Now, not all people or organizations using web-based systems are going to be the targets of APTs, but clearly some will be.

Lets broaden out our thinking beyond Google, as the problem is larger than they are, to include other “free” web-based services such as Facebook, Yahoo, Twitter, Microsoft, etc. I believe there is no way the average user can be considered reasonably safe from an APT on these systems. To be fair, these providers make no such claim as they are only built to withstand the lowest-common-denominator of attacker -- not APTs. Since all potential victims are equidistant, practically speaking all it really takes is a username/password or a bit of malware for any online account to be compromised. A very low bar and clearly no amount of SSL, firewalls, Anti-Virus, or CAPTCHA technology is going to raise it.

Secondly, an APTs target is unlikely to have any idea when/if their online accounts are being attacked. The infrastructure is not theirs to monitor. Web-based systems have no real notion of intrusion detection (or even a delete key) unless you include those emails when your account is locked out or password is changed without your knowledge. Even more troubling, victims will not have any idea when/if the threat succeeded in their mission. Next, as if there was any question, these web-based system not legally or fiscally accountable for breaches -- whether it was their fault of not. And finally, APTs will not stop no matter who lays down the ultimatum.

When everything is taken into consideration, any user who believes they are going to be a target of an APT should not be using these systems for anything they can’t afford to lose control over. The fact that the U.S. government is moving their system in this direction really concerns me. Perhaps there is a silver lining. These events could be the stimulus required for a new breed of web-based services to rise up and differentiate based upon security and maybe willing to take on some liability.

Tuesday, January 12, 2010

Top Ten Web Hacking Techniques of 2009 (Official)

Every year the Web security community produces dozens of new hacking techniques documented in white papers, blog posts, magazine articles, mailing list emails, etc. Not to be confused with individual vulnerability instances brandishing CVE numbers, nor intrusions / incidents, but actual new methods of Web attack. Some techniques target websites, others Web browsers, and the rest somewhere in between. Historically much of this research would unfortunately end up in obscure corners of the Web and become long forgotten. Now it its fourth year the Top Ten Web Hacking Techniques list provides a centralized repository for this knowledge and recognize researchers contributing to the advancement of our industry. 2009 produced ~80 new attack techniques (see below).

The diversity, volume, and innovation of the research was impressive. Competition was as fierce as ever and the judges had their work cut out. Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Romain Gaucher, Steven Christey, Jeff Forristal, and Michal Zalewski were tasked with ranking the field based upon novelty, impact, and overall pervasiveness. For any researcher simply the act of creating something unique enough to appear on the list is itself an achievement. Today the polls are close, votes are in, and the top ten list has been finalized. Researchers making the cut can expect to receive praise amongst their peers and take their place amongst those from previous years (2006, 2007, 2008).

Top honors go to Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger for their work on “Creating a rogue CA certificate.” The judges were convinced by no small margin that this entry stood head and shoulders above the rest. The team will be awarded a free pass to attend the BlackHat USA Briefings 2010! (generously sponsored by Black Hat)

Top Ten Web Hacking Techniques of 2009!

1. Creating a rogue CA certificate
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

2. HTTP Parameter Pollution (HPP)
Luca Carettoni, Stefano diPaola

3. Flickr's API Signature Forgery Vulnerability (MD5 extension attack)
Thai Duong and Juliano Rizzo

4. Cross-domain search timing
Chris Evans

5. Slowloris HTTP DoS
Robert Hansen, (additional credit for earlier discovery to Adrian Ilarion Ciobanu & Ivan Ristic - “Programming Model Attacks” section of Apache Security for describing the attack, but did not produce a tool)

6. Microsoft IIS 0-Day Vulnerability Parsing Files (semi‐colon bug)
Soroush Dalili

7. Exploiting unexploitable XSS
Stephen Sclafani

8. Our Favorite XSS Filters and how to Attack them
Eduardo Vela (sirdarckcat), David Lindsay (thornmaker)

9. RFC1918 Caching Security Issues
Robert Hansen

10. DNS Rebinding (3-part series Persistent Cookies, Scraping & Spamming, and Session Fixation)
Robert Hansen

Congratulations to all!

Coming up at IT-Defense (Feb. 3 - 5) and RSA USA 2010 (Mar. 1 - 5) it will be my great honor to introduce each of the top ten during my “2010: A Web Hacking Odyssey” presentations. Each technique 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.

The Complete List
  1. Persistent Cookies and DNS Rebinding Redux
  2. iPhone SSL Warning and Safari Phishing
  3. RFC 1918 Blues
  4. Slowloris HTTP DoS
  5. CSRF And Ignoring Basic/Digest Auth
  6. Hash Information Disclosure Via Collisions - The Hard Way
  7. Socket Capable Browser Plugins Result In Transparent Proxy Abuse
  8. XMLHTTPReqest “Ping” Sweeping in Firefox 3.5+
  9. Session Fixation Via DNS Rebinding
  10. Quicky Firefox DoS
  11. DNS Rebinding for Credential Brute Force
  12. SMBEnum
  13. DNS Rebinding for Scraping and Spamming
  14. SMB Decloaking
  15. De-cloaking in IE7.0 Via Windows Variables
  16. itms Decloaking
  17. Flash Origin Policy Issues
  18. Cross-subdomain Cookie Attacks
  19. HTTP Parameter Pollution (HPP)
  20. How to use Google Analytics to DoS a client from some website.
  21. Our Favorite XSS Filters and how to Attack them
  22. Location based XSS attacks
  23. PHPIDS bypass
  24. I know what your friends did last summer
  25. Detecting IE in 12 bytes
  26. Detecting browsers javascript hacks
  27. Inline UTF-7 E4X javascript hijacking
  28. HTML5 XSS
  29. Opera XSS vectors
  30. New PHPIDS vector
  31. Bypassing CSP for fun, no profit
  32. Twitter misidentifying context
  33. Ping pong obfuscation
  34. HTML5 new XSS vectors
  35. About CSS Attacks
  36. Web pages Detecting Virtualized Browsers and other tricks
  37. Results, Unicode Left/Right Pointing Double Angel Quotation Mark
  38. Detecting Private Browsing Mode
  39. Cross-domain search timing
  40. Bonus Safari XXE (only affecting Safari 4 Beta)
  41. Apple's Safari 4 also fixes cross-domain XML theft
  42. Apple's Safari 4 fixes local file theft attack
  43. A more plausible E4X attack
  44. A brief description of how to become a CA
  45. Creating a rogue CA certificate
  46. Browser scheme/slash quirks
  47. Cross-protocol XSS with non-standard service ports
  48. Forget sidejacking, clickjacking, and carjacking: enter “Formjacking”
  49. MD5 extension attack
  50. Attack - PDF Silent HTTP Form Repurposing Attacks
  51. XSS Relocation Attacks through Word Hyperlinking
  52. Hacking CSRF Tokens using CSS History Hack
  53. Hijacking Opera’s Native Page using malicious RSS payloads
  54. Millions of PDF invisibly embedded with your internal disk paths
  55. Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection
  56. Pwning Opera Unite with Inferno’s Eleven
  57. Using Blended Browser Threats involving Chrome to steal files on your computer
  58. Bypassing OWASP ESAPI XSS Protection inside Javascript
  59. Hijacking Safari 4 Top Sites with Phish Bombs
  60. Yahoo Babelfish - Possible Frame Injection Attack - Design Stringency
  61. Gmail - Google Docs Cookie Hijacking through PDF Repurposing & PDF
  62. IE8 Link Spoofing - Broken Status Bar Integrity
  63. Blind SQL Injection: Inference thourgh Underflow exception
  64. Exploiting Unexploitable XSS
  65. Clickjacking & OAuth
  66. Google Translate - Google User Content - File Uploading Cross - XSS and Design Stringency - A Talk
  67. Active Man in the Middle Attacks
  68. Cross-Site Identification (XSid)
  69. Microsoft IIS with Metasploit evil.asp;.jpg
  70. MSWord Scripting Object XSS Payload Execution Bug and Random CLSID Stringency
  71. Generic cross-browser cross-domain theft
  72. Popup & Focus URL Hijacking
  73. Advanced SQL injection to operating system full control (whitepaper)
  74. Expanding the control over the operating system from the database
  75. HTML+TIME XSS attacks
  76. Enumerating logins via Abuse of Functionality vulnerabilities
  77. Hellfire for redirectors
  78. DoS attacks via Abuse of Functionality vulnerabilities
  79. URL Spoofing vulnerability in bots of search engines (#2)
  80. URL Hiding - new method of URL Spoofing attacks
  81. Exploiting Facebook Application XSS Holes to Make API Requests
  82. Unauthorized TinyURL URL Enumeration Vulnerability

Wednesday, January 06, 2010

In absense of a security strategy

From experience working with all manner of organizations there are a number of unique security strategies present in the industry. Since every business operates differently, perhaps there is no right or wrong approach. That is, as long as the approach is properly aligned with the goals of the business. If not, the end result will lead to failure and in my opinion represents one of the largest, if not the largest, challenges presently facing the industry. That along with “justification,” which is probably the same thing.

Here are the strategies I’ve managed to identify:

Incident Response (aka: public relations)
Ensure that the exact types of previous break-ins, that have also been publicly attributed to the organization, will (hopefully) never happen again. Organize a set of public relations talking points for media inquiry in case it does.

Compliance (aka: satisfy the checkbox)
Satisfy audit requirements for any/all applicable regulations where failure will result in significant business loss. Ignore the rest until they do. Decisions on whether a particular security safeguard is required should be left to the discretion of the on-site auditor, but only after appropriate organizational push back.

Risk Management (aka: control-based)
Implement minimum industry accepted best-practices controls that establish a defensible due diligence posture in the event of incident or public inquiry. Engage with a well-known security consultancy that may positively attest to your organizations adherence via a thorough risk assessment.

Business Continuity (aka: keep the boss happy)
Address any security issues that have previously inhibited managements ability to use email or view online adult entertainment. Other outstanding risks are considered secondary and should be revisited periodically by the security steering committee.

Identify and categorize the various threat agent that must be successfully defended against. Actively monitor threat agent activity, implement security control that limit their capabilities, and generate business-level activity reports.

Competitive Advantage (aka: customer-based)
Obtain a list of essential security controls from key customers/prospects, competitor technical literature, and provide assurance to customers that these highest standards of due care have been implemented.

Obviously many of these descriptions are meant to be humors while still reflecting some resemblance of today's organizational reality. Most organization adopt more than a single strategy to form their own unique hybrid approach to information security.

To disable IE8's XSS Filter or not?

Since this article was published, Major IE8 flaw makes 'safe' sites unsafe, I’ve fielded a number of inquiries asking for guidance. Should they follow Google’s lead and proactively disable IE8’s XSS Filter (X-XSS-Protection: 0) until a patch is made available or leave it enabled? Without getting into any technical detail, here are my thoughts on the matter:

If your organization is REALLY concerned about XSS attacks, is VERY confident the website in question is one of the very few completely free from XSS issues (as apparently Google is), and is prepared to fix any XSS issues that surface within DAYS -- then you may consider disabling the XSS Filter to reduce any remaining attack surface until a patch arrives.

On the other hand if you are like most who have XSS, or don't know if they do or not, then leave the XSS Filter alone to do its job -- give your IE8 users a fighting chance.

Monday, January 04, 2010

WASC Threat Classification to OWASP Top Ten RC1 Mapping

Update 01.05.2009: From feedback received, added some TCv2 classes that also map.

With most of the work done by Bil Corry (@bilcorry), here is a solid first pass at creating a mapping between the newly released WASC's Threat Classification v2 and OWASP's Top Ten 2010 RC1. This should help those actively using one or both of use documents.