Wednesday, December 23, 2009

(Fortify + WhiteHat = Fortify on Demand) or (1 + 1 = 3)

In case you haven’t seen the news, Fortify recently launched a one-stop SaaS shop (Fortify on Demand) for software security testing (support for Java, .NET, and PHP). This snippet from their site spells the offering out nicely:

“Fortify on Demand is a set of hosted Software-as-a-Service (SaaS) solutions that allow any organization to test and score the security of all software with greater speed and accuracy. This automated turnkey service offers an efficient way to test third-party application security or to complete baseline assessments of all internal applications. It is the only offering available on the market that correlates best-of-breed static and dynamic analysis into a single dashboard. Fortify on Demand's robust reports prioritize vulnerabilities fixes based on severity and exploitability, with line of code level details.”

The static analysis technology obviously comes from the market leader’s SCA product line, but guess who’s behind the dynamic part. Give up? :) That would be WhiteHat Security of course!

“Fortify selected WhiteHat Sentinel because it is the only software-as-a-service (SaaS) solution to deliver the highly accurate, verified vulnerability data required to ensure effective website security and actionable information for both developers and security operations as a service.”

Needless to say we are very excited! This technology combination and delivery model addresses a number of under-served customer use-cases, such as third-party validation and testing of COTS. As I’ve blogged before, it’s time to move beyond the nonsensical adversarial debates about which testing methodology (black or white) is best and instead focus on the synergies. We’re putting our R&D money where are mouths are and have grand plans to directly benefit our customers.

Today’s integration is already yielding a solid level of vulnerability correlation, right down to a line or code block, which helps prioritize findings into actionable results -- such as what vulnerabilities are confidently exploitable. Looking ahead, consider that static analysis can measure exactly how code coverage is being realized during the dynamic analysis -- furthermore pointing out the gaps in unlinked URLs, back doors, extra form parameters, etc. This will lead to way better and measurable comprehensiveness for both static and dynamic analysis. And don’t even get me started on the metrics we’ll be able to gather. We’re just at the beginning of understanding what is possible!

This will be the basis of Jacob West and my “Fortify on Demand Launch Webinar” (Jan 14.) and RSA presentation “Best of Both Worlds: Correlating Static and Dynamic Analysis Results” (Mar. 4). We’ll be learning a lot in the coming months and will be ready to share our discoveries with the audience.

Thursday, December 17, 2009

Attention security researchers! Submit your new 2009 Web Hacking Techniques

Update 01.04.2010: Voting process is commencing this week! Expert judges are Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Romain Gaucher, Steven Christey, Jeff Forristal, and Michal Zalewski.

Update
: Awesome news, Black Hat is generously sponsoring the effort! The researcher topping the list will be awarded a free pass to attend the BlackHat USA Briefings 2010!

Just 2 weeks left in 2009. Time to start collecting all the latest published research in preparation for the coveted Top Ten Web Hacking Techniques list!

Every year Web security community produces dozens of new hacking techniques documented in white papers, blog posts, magazine articles, mailing list emails, etc. We are not talking about individual vulnerability instances with CVE numbers, nor intrusions / incidents, but the actual new methods of Web attack. Some target the website, some target the browser, or somewhere in between.

Historically many of these works would permanently reside in obscure and overlooked corners of the Web. Now it its fourth year the list provides a centralized reference point and recognizes researchers who have contributed to the advancement of our industry.

The top ten winners will be selected by a panel of judges (names to be announced soon) on the basis of novelty, potential impact, and overall pervasiveness. Those researchers topping the list can expect to receive praise amongst their peers as have those in past years (2006, 2007, 2008).

Then coming up at IT-Defense (Feb.) and RSA USA 2010 (Mar.) 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. Audiences get an opportunity to better understand the newest attacks believed most likely to be used against us in the future.

To make all this happen we are going to need a lot of help from the community. At the bottom of this post will be the living master list of everything published. If anything is missing, and we know for a fact there is, please comment containing the link to the research. We understand that while not every technique is as powerful as another, please make every effort to include them anyway, nothing should be considered too insignificant. You never know what method might be found useful another researcher down the road.

Thank you and good luck!


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


Tuesday, December 15, 2009

Why Microsoft should consider retroactively installing AdBlocking software by default

I’ve been following the developments of Google Android and Chrome OS with much interest lately. Less from a security/technology perspective and more as a lesson in business. One way Google is expanding Android’s presence in the mobile market is by sharing ad revenue with mobile carriers (ie Verizon). Instead of incurring software licensing costs (of BlackBerry, Windows Mobile, Palm OS, etc) carriers may receive revenue when their Android users click on ads. Carriers love this because they get paid to install an OS rather than the other way around! This business model has been called “Less Than Free” and Microsoft should take notice of it because their Windows / Office business model could be at huge long-term risk. Let me explain.

Microsoft obviously makes significant revenue OEMing Windows to PC manufactures (Dell, etc.). At the same time Microsoft feels some level of price pressure from free good-enough operating systems like Linux installed on ultra cheap PCs. Now imagine for a moment if Google decided to leverage Less Than Free for Chrome OS. Google could feasibly pay PC manufactures to install Chrome OS through an advertising revenue sharing program. PC Manufactures, instead of paying a fee to MS for Windows, get access to a new revenue stream when Chrome OS users click on ads. Additionally, my understanding is you can’t install desktop software on Chrome OS so the huge money maker that is Microsoft Office is gone on that footprint as well. Such movements would not happen overnight, but the writing is on the wall.

Microsoft is of course not without options when it comes to aggressively fending off the Google powerhouse. One way is that Microsoft could leverage their dominant (50%+) Internet Explorer browser market share. They could use Windows Update to retroactively install ad blocking software as a “security feature,” like AdBlocker Plus on Firefox, in all IE versions (6-8). No doubt users the world over would love it! Less annoying ads, less malware distribution (much of which spread by online ads), and a snappier Web experience! How could Google complain, they are all about speed right? :) Oh, right, because it would cut Google and their dual-revenue stream (AdSense / AdWords) off at the knees.

Many users, even Firefox users, might actually flock to Internet Explorer if they knew this feature was available! Most don’t even know AdBlocker Plus exists. This new ad blocking “security improvement” may also pressure Firefox, the other major browser, to do the same as not wanting to be one-up by MS in the security dept. At least one Mozilla exec is encouraging the use of Bing. Giorgio speculates that is might be why Google Chrome doesn’t have NoScript-like support yet, because they can’t figure out how to do it without enabling effective ad blocking. Makes sense.

Sure, Web publishers whose life blood is ad revenue would hate Microsoft, at least temporarily -- but fear not! Those billions in advertising dollars flowing to Google would still need to land somewhere, but where!? MS could open a “blessed” safe, secure, and user targeted advertiser network! So if Google, or anyone else, wants their ads shown to an IE audience they’d have to pay a tax to MS for the privilege. Still I’ve long wondered by pay-wall Web publishers didn’t heavily advocate the use of ad blockers to put pressure on their free content competitors.

I’ve also glossed over a number of important factors that come into play should any of this play out, like antitrust, but Microsoft is presently is 1-0 so maybe that possibility doesn’t scare them. Meanwhile during whatever legal proceedings, Google would be sucking wind revenue wise. As I wrap up this post, please keep in mind that I’m no industry analyst, just a curious observer who hasn’t vetted their ideas nearly enough.