Best of Application Security (Friday, Jan. 29)

Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.

• Gunnar Peterson on APTs: What Infosec Should Learn & Are Coming from Inside the House!
• Umm…TechCrunch? Defacement Two in 24 Hours
• Congressional Web Site Defacements Follow the State of the Union
• Google to Pay For Bugs Found in Chromium
• Chromium Security in Depth
• WASC RSA 2010 Meet-up
• Facebook sandbox escape
  
• Dasient Q4'09 web-based malware data and trends
• CSS History Hack In Firefox Without JavaScript for Intranet Portscanning
• Segmented Web Browsing Will Be the DMZ of the 2010’s

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
Jillian's@Metreon
101 Fourth Street | 415.369.6101
RSVP by February 26, 2010*

Best of Application Security (Friday, Jan. 22)

Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.

• Is APT After You?
• Microsoft: Introducing Quick Security References (QSRs)
• Missed pages and the usefulness of "site maps" for web app vuln scanning
• Private browsing in Flash Player 10.1
• Presentation about WAFs in the cloud
• How Often Should I Reassess My Web Applications?
• A Fantasy Explanation of Standard vs. Blind SQL Injection
• Researcher demos clickjacking attack on Facebook
• Analysis of 32 million breached passwords
• The Fallacy of Secure Software

Best of Application Security (Friday, Jan. 15)

Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.

• Top Ten Web Hacking Techniques of 2009 (Official)
• Default https access for Gmail
• new static analyzer from Google
• Purported Interview With Facebook Employee Details Use Of ‘Master Password’
• Software testing firm says no to responsible disclosure
• Web-based systems vs. Advanced Persistent Threat
• The Three Domains of Application Security
• How to Use the Adobe JavaScript Blacklist Framework
• CSS History Knocker (sites you've visited)
• Threat Classification 'Cross Reference View' (TCv2.1 Inclusion Proposal

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.

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

Best of Application Security (Friday, Jan. 8)

Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.

• WASC Threat Classification v2.0 & OWASP Top Ten Mapping
• Thoughts on an AppSec Program (p1, p2, p3, p4, p5)
• Mr Bean replaces Spanish PM on EU presidency site
• Hacker pilfers browser GPS location via router attack & XSS PoC
• Looking at what makes good Application Security knowledge
• Research page on Web Security Ratings and Disclosure Policies
• NAT Pinning & NoScript's ABE
• Secure Storage using the OWASP ESAPI
• Java EE 6: Web Application Security made simple!
• Ruby on Rails: Secure Mass Assignment

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.

Threat-based
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.

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.

Best of Application Security (Friday, Jan. 1)

Ten of Application Security industry's coolest, most interesting, important, and entertaining links from the past week -- in no particular order.

• My Personal Security Guiding Principles
• Popup & Focus URL Hijacking
• Exploiting Microsoft IIS with Metasploit
• Results of Investigation into Holiday IIS Claim
• Cryptographic Storage Cheat Sheet
• WAF vs IPS (or Four Things Your IPS Can’t Do)
• Generic cross-browser cross-domain theft
• Twitter bans obvious passwords
• Web Attacks and Defenses that Could Affect Users in 2010
• SQL Injection Resources