Picks for BlackHat 2009

One of the things that makes Black Hat so friggin’ awesome is the quality of the speakers and their presentations. Bleeding-edge material, theoretical and applicable, seen no where else covering everything including technology, business, legal, social and political arenas. Unfortunately this also forces you to make tough choices about what talks to see. No matter which one you choose, you are bound to miss something cool taking place in another room. The largest time block for me though is the undocumented hallway track. Taking the time to meet people I know and those I don’t to learn new things and exchange ideas is what it is all about! Fortunately, conference videos are made available so nothing is really missed. My picks for Black Hat that I’m going to do my best to see as many as possible. What are you wanting to see?

Day 1
The Laws of Vulnerabilities Research Version 2.0
Sniff keystrokes with Lasers /Voltmeters
Analyzing Security Research in the Media
There's a Fox in the Henhouse
Hacking Capitalism '09
Pwnie Awards

Day 2
Cloud Computing Models and Vulnerabilities - Raining on the Trendy New Parade
Mo' Money Mo' Problems *only because I have to be there. ;) *
Clobbering the Cloud!
Breaking the Security Myths of Extended Validation SSL Certificates
Reconceptualizing Security

The Best of Application Security 2009 (Mid-Year)

Every year the application security industry receives a number of phenomenal research papers and other great contributions. Even for those dedicated to appsec as their primary job function it is challenging to stay up-to-date, which means resources to help track them become extremely valuable. As such Ivan Ristic and I have been working on the "The Best of Application Security", a list of the ten most remarkable contributions (in no particular order) published bi-annually and then combined at year end. Obviously some painful, but necessarily omissions had to be made. If readers disagree with the list, great! Please comment your suggestions for consideration. Lastly this effort will be different from the annual Top Ten Web Hacking Techniques, which is solely dedicated to breaking stuff.

• Typing The Letters A-E-S Into Your Code? You’re Doing It Wrong!
• Mozilla Content Security Policy proposal
• Software Security Maturity Models (BS-IMM & OpenSAMM)
• Verizon 2009 Data Breach Investigations Report
• Vulnerability Prevention Cheat Sheets (XSS & SQL Injection)
• Creating a rogue CA certificate
• HTTP Parameter Pollution
• CWE/SANS TOP 25 Most Dangerous Programming Errors
• Socket Capable Browser Plugins Result In Transparent Proxy Abuse
• Anti-Clickjacking w/ Internet Explorer 8, NoScript and Safari 4.0

The Most (Potentially) Lucrative Vulnerabilities

I think few vulnerability researchers look for them, are unlikely to understand their potential value if found, and probably wouldn’t disclose them anyway. The vast majority of researchers focus on memory corruption issues, browser cross-domain leakage, custom Web application attacks, or flaws in online business logic processes. While all of those vulnerability types are important, subtle issues remain unexplored -- ignored, which could enable one to generate huge dollar figures with no one being the wiser. Oh, and no malware required! An example of one of these vulnerabilities is Cross-Site Cooking (circa 2006) found by Michal Zalewski. Remember it? Fortunately for many, Michal publicly disclosed and vendors patched causing it to be a forgettable non-issue going forward.

Cross-Site Cooking enabled a website (ie http://www.example.com/) to set arbitrary cookies associated to an entire domain with a foreign TLD such as *.com.pl or *.com.fr. The cookie value would be sent to every website having those TLDs. This could lead to delete stored preferences, session identifiers, authentication data, cart contents, etc. Now assume for a moment a similar browser bug existed where a website could set arbitrary cookies for generic *.com, *.net, *.gov, *.mil, or better yet perhaps just *. That cookie value would be sent to all those TLD, or in the latter case all sites. If such a bug existed it would seriously impact all websites not reissuing a session ID post authentication. Forcefully load up (PHP|JSP|ASP)SESSIONID to website visitors and then walk into any account you’d like! While bad as that is defrauding affiliates and affiliate networks is another possibility.

For those unfamiliar, affiliate revenue is BIG business, and generates money based upon cost-per-click and cost-per-conversion. Five and six figures per month is not unheard of and commissions owed are largely tracked through the use of cookies. For a fraudster imagine being able to simultaneously load your Amazon, eBay, Google, etc. affiliate cookie into tens or even hundreds of thousands of browsers in a single banner campaign. Anytime they purchase something on those sites you get paid because your affiliate cookies was received -- stepping on any others if they exist. Kaaachink! Websites receiving unexpected affiliate cookies would more than likely not even see or log it. The same for the user-side of the connection. Plus, cookies have no information on what website set the cookie. All nicely invisible. The reality is we really have no idea if this hasn’t already happened. We do know is some browser plug-ins and ISPs do this sort of thing already (load up their affiliate cookies).

Other targets such as (transparent) proxies could be targeted in a similar way. I'm also keeping my eye on Cross-Origin Resource Sharing, Flash Cookies, and clever timing attacks. Oh, and all the new browser standards coming out. Guaranteed goodness inside. Happy hunting!

Why vulnerable code should be fixed even after WAF mitigation

Websites have vulnerabilities, vulnerabilities that are found by vulnerability assessment solutions, which are then communicated to Web Application Firewalls (WAF) for virtual patch mitigation. Given the extremely heightened activity of our adversaries, compliance requirements, volume of existing vulnerabilities, and money/time/human resource constraints this approach is becoming more common every day. What also becomes common is the question management and development groups ask of IT Security, “If the vulnerability is patched by a WAF, then why do we need to fix the code?” A reasonable question and one we need to be prepared to answer with something better than proclaiming, “Because it is the right thing to do!” Obviously this is unconvincing as it provides no reasonable business justification. Here are some ideas:

1. Developers really like to copy code, even insecure code, which may eventually lead to new vulnerable Web applications launched outside deployed WAF protection.
2. WAFs, like code, are not perfect and cannot always compensate for complex encoding/decoding application interactions, which could open the door to bypassing security rules.
3. A vulnerable Web application feature may be delivered now or in the future via XML APIs, Flash, iPhone application, etc. and by extension live beyond WAF protection.
4. WAFs tend to fail open, and when they do, it would be preferable not to have vulnerabilities as an active risk of exposure indefinitely.
5. A WAF may not be positioned to protect against the insider threat.
6. WAF rules are often exploit and not vulnerability focused, so may protect against some specific attack variants, but miss others. For the same reason, non-exploitable vulnerabilities may continue to be reported by vulnerability assessment solutions.
7. Fixing a vulnerability in the code *right* will often systematically resolve an entire class of issues both now and take them off the table in the future.
8. Compliance or customer security standards may require an application be tested without the WAF protection.

WhiteHat is Hiring

We are growing, fast, and need more exceptional people to join our team. The things we work on, people we worth with, and organizations we work for are completely unique. Check out our job listings, and if something looks like its for you, let us know!

Application Security Specialist
For the up-and-coming security specialist: this is an amazing opportunity to flex your creative muscles as you take a crack at poking holes in websites, actively searching for security vulnerabilities that you can exploit.

Customer Support Engineer
Looking for an experienced customer support engineer to provide exceptional services to our customers and business partners in supporting our Sentinel Service offering. We are Software as a Service (SaaS) provider.

Legalize It (Hacking GOV and MIL website)

Update 06.20.2009: Jack Mannino offers very well-thought and persuasive counterpoints to my suggestion below. I'll have to take some time to consider his arguments and respond accordingly. Boiled down Jack is reminding us that private websites are different in purpose than government systems, which exist for totally different purposes and may not automatically benefit from pen-test crowd-sourcing. The second main point is one of saturating already limited resources with respect to incident response.

I’d wager fewer than ten percent of United States .GOV and .MIL websites are professionally tested for custom Web application vulnerabilities. The reasons why are probably the same as in the private sector. Those responsible don’t know or don’t want to know that problems exist. Statistically of course they do, and our statistics are validated by a recent Federal Aviation Administration security report indicating that 70 of its websites tallied thousands of vulnerabilities. Those who do acknowledge and wish to address the problem often lack the budget or authority to initiate a project. Consequently, enemies both foreign and domestic are likely to know more about what and where our government’s website vulnerabilities are located than the defenders do.

This is a vital concern and an issue I think could be solved through policy or legislation. I believe there are hundreds, maybe thousands, of vulnerability researchers ready and willing to volunteer themselves to find and disclose vulnerabilities -- for free -- if only allowed to do so. What every information security professional knows is there are the penetration tests you pay for and those that you get everyday for free, no matter who you are. What they also know is that testing anything you don’t own or have written consent to test runs the risk of legal prosecution. You are especially not supposed to touch government or military systems, as these organizations have an infinite amount of time and money to go after someone. This is vastly different from the approach of a private enterprise whose investigation eventually has a cost-benefit analysis attached. Generally, no more is invested than the amount lost.

Even so, some researchers are comfortable with harmlessly poking at private sector websites for Cross-Site Scripting, Cross-Site Request Forgery, SQL Injection, and other bugs. XSSed.com serves as good examples of open disclosure, which also demonstrates that no top-level domain is off limits despite the legal consequences. It is time to do something new because we know Web applications are the biggest InfoSec risk we face. This is an extraordinarily large problem. And so, what if, to meet this challenge, we leveraged people’s willingness to find vulnerabilities on their own time, eliminated their risk of prosecution, and instead provided a mechanism for disclosure like a government version of the MSRC? That’s right, let us hack .GOV and .MIL as a veritable army of volunteer pen-testers. How cool would that be! It is not like anyone is being prosecuted for simply finding a government website vulnerability, so no loss there. Sound crazy? Maybe, but here me out first.

Consider that several prominent websites such as PayPal, Microsoft, and Google have already successfully taken such measures. I have first hand knowledge that more are on the way. Their policies state that as long as the researchers follow the rules of engagement -- essentially not doing any damage or defrauding the system, and discreetly disclosing their findings so the companies can create a fix, no legal measures will be taken. These organizations have matured and learned to work with the community. After a fix has been issued, the researcher may tell the world to bolster his reputation in the security community. No dollars are exchanged, but impressive work has led companies to single out a specific researchers thank them. Yes, there are potential downsides, but in my humble opinion the gain more than justifies the risks.

Assuming reported vulnerabilities are fixed promptly, a similar approach would benefit the government while measurably raising the bar for the bad guys. Currently, it seems that for many governmental Internet-connected systems the bar is set quite low. By allowing the good guys to assist them, the government could get access to a qualified pool of security talent to fill their internal security positions. Wasn’t the Pentagon looking to hire high school students for this sort of thing anyway? Open source and commercial vendors could get a new playground to test and improve their vulnerability scanning products. Hard to beat free pen-tests. College students and security training professionals could apply and safely hone their skills. Fake websites are nice and all, but nothing in Web application security compares to experience on real systems. Everyone wins!

I know I’ve painted some broad strokes, but I’d very much like to hear what others think. If reasonable, perhaps this is something Jeff Moss, our de-facto hacker representative to the Department of Homeland Security, could run up the flag pole.

Results, Unicode Left/Right Pointing Double Angel Quotation Mark

A while back 3APA3A and Arian Evans (Director of Operations, WhiteHat Security) left off a full-disclosure thread about an interesting encoding bypass attack, Unicode Left/Right Pointing Double Angel Quotation Mark.

Dear full-disclosurelists.grok.org.uk,

By the way: I saw Unicode Left Pointing Double Angel Quotation Mark (%u00AB) / Unicode Right Pointing Double Angel Quotation Mark (%u00BB) are sometimes translated to '<' and '>'. Does somebody experimented with

%u00ABscript%u00BB

in different environments to bypass filtering in this way?

Arian promised to get back to 3APA3A after scanning several hundred production websites using WhiteHat Sentinel. A huge R&D benefit of the platform. Two years later there is data to share. We’ve been busy, but hey, better late the never right? :) As it turned out 3APA3A was correct! Arian discovered a small number of Web applications vulnerable to the encoding technique and they add up if the sample pool is large enough. Samples ranging from 300 to roughly 1000 websites. Remember these are collapsed numbers. Meaning multiple vulnerability inputs on the same Web application are grouped together.

11 exploitable XSS in 8 websites:
%u00ABscript%u00BB

15 exploitable XSS in 12 sites:
&#x3008 ;script&#x3009 ;

2 in 2:
U%2bFF1CscriptU%2bFF1E

1 in 1:
&#x2039 ;script&#x203A ;

1 in 1:
&#x2329 ;script&#x232A

1 in 1:
&#x27E8 ;script&#x27E9 ;

*whitespace before semi-colons are added purposely to prevent formatting blog formatting glitches.

Arian Evans, in his own words...

These are exploitable conditions where this was the ONLY way that arbitrary HTML could be created. There were are many more sites that normalized these and the same encoding could be used for filter-evasion/exploitation, but they were not the ONLY way to create arbitrary HTML in the application. Unfortunately the dataset does not count all of the ANDs/combinations right now, just the ONLYs. So if there was a simpler way to create arbitrary HTML, that is the only way it was counted. The rabbit hole goes much deeper. Dozens of combinations and permutations that lead to exploitation and not just for XSS. For many types of syntax-attacks. Still researching.

There are also MANY more of these in international language code pages. Browser behavior gets really unpredictable with foreign-language character sets which increases XSS and HTTP/RS exploit options even more. There are also many more ways to use these when you start layering your encoding techniques. Yosuke Hasegawa did a great presentation on Japanese/Kanji character sets @ BlackHat Tokyo 2008. For example I found many of these attack vectors work at an even higher percentage when URI-escaped or combined with other Hex-encoding formats (or Decimal, Base64, etc. etc. etc.).

3APA3A, thanks for opening my mind up to some new angles on filter-evasion tricks! :)

Clickjacking 2017

The future: Long standing Web application security scourges such SQL Injection (SQLi), Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) are finally under control. Remaining buffer overflow issues are considered fossilized evidence of a prior era. Cyber criminals out of necessity have evolved their attack portfolios to include Clickjacking as a preferred method for tricking their victims into propagating malware, defrauding themselves, and initiating other forms a malicious acts. Clickjacking, a long-known and fundamental design problem in the way the Web works, had not until 2017 garnered the respect necessary to be taken seriously. Now with significant damage increasing and loses mounting, the issue has forced website owners and browser developers to scramble for solutions to a problem nearly a decade in the making. Or so the story may go should history repeats itself.

By tracking the seminal papers/events of the more widely used attack techniques, it takes somewhere between 6 and 9 years for the bad guys to scale their exploits and cause enough damage where defenders are compelled to react. For example, Aleph One’s “Smashing The Stack For Fun And Profit” was published in 1996, but it wasn’t until 2002 that Microsoft’s then CEO Bill Gates issued the famous “TrustWorthy Computing Memo.” A six year gap sparking the software security revolution. XSS experimentation began around 1997 with few appreciating its true power until 2005 (8 years). The Samy Worm, the first mass scale JavaScript malware Web Worm, infected over 1 million MySpace users in under 24 hours. In 1998 rain.forest.puppy published the first research into SQL Injection. Nine years later marked the beginning of mass Web page malware infections proving how truly vulnerable websites were. The first CSRF papers began appearing around the turn of the century, but no convincingly evidence of catastrophic attacks has yet to appear justifying remediation investment. So we wait, knowing full well it is only a matter of time.

Clickjacking, an issue known by some for at least several years as UI Redressing, it was not fully explored or advertised until 2008 with the Flash videojacking demonstration. While non-malicious experimentation is taking place targeting those such as Twitter, no major damaging incidents can be referenced. And perhaps there won’t be until sometime between 2014 and 2017 if historical timelines hold. If so, the upside is we have time to deal with the issue, but I doubt we will be any more prepared by then. More likely the problem will scale well beyond our control, just like the others, as Web-enabled devices increase exponentially built upon a system where security fundamentals are difficult to change. In the meantime I’m sure we will be having a lot of fun times dealing with XSS, SQLi, CSRF, Intranet Hacking, Flash Malware, Business Logic Flaws, and so on.