Author Archive

We’re Hiring: Application Security Consultant and Researcher

December 18th, 2010 by

Want to put your security research skills to the test in Seattle? We’re looking for junior and senior appsec consultants and vulnerability researchers to join Casaba – good work/life balance, salary plus profit sharing, 100% health coverage, and some other things I’m surely forgetting. Oh ya we’re a small company in our 8th year, there’s no middle management and the only politics are outside the office.

You should fit at least 2 of the following profiles:

- Web-application vulnerability researcher – You’re able to find flaws and exploitable bugs in the most popular and complex products on the Internet. Of course you intimately understand the W3 protocols and can find XSS, CSRF, cross-domain and nasty browser-quirk-related vulns in about the time it takes to pour a cup of coffee. You can also manage a code review of C#, Rails, or Java and document bugs and remediations. When you get bored you spend a night finding cross-domain Same Origin Policy holes in every major browser.

- Reverse Engineer – You’re able to disassemble and debug even hardened binaries, analyze and dissect a black-box communication protocol, and build a rogue client or server. You’re of course a master of your chosen programming language, and can script up IDA, PyDbg, and Immunity. You don’t even need to respond to this job posting, because you’ve already hacked into my laptop and dropped your resume on my desktop.

- Fuzzer - You find more bugs than a pond full of frogs on a warm summer night. At any given moment you have 15 fuzzers running in parallel across a herd of VM’s. You live for finding zero-days in anything that has a network stack or a file parser. If the art of fuzzing suddenly became useless you’d probably leave the tech world behind and move to the beach to surf forever.

- Builder – You like to break stuff but would really rather build it. When there’s a new vulnerability discovered you get excited to build a tool to test for and exploit it. If it’s related to a browser, protocol, or language you never studied before, even better because now you have an excuse to learn something. If a colleague asks if you can help with a test harness you ask for her short list of requirements. Nothing’s out of reach, but you’re not all over the map either. You’re focused and have one or two major research goals of your own.

Please email ‘chris’ (my first name) @casaba.com with at least two profiles that describe you and whether you’re a fit for a junior or senior level position.

Juniors generally have 1-3 years professional experience, have been to some conferences and have released some tool, paper, or vulnerability. Seniors have done those things and are regular speakers at industry conferences, have their name on a book, and are also capable of managing projects, small teams, and client relationships.

Microsoft SDL Requirements Phase: Security Practices

December 14th, 2010 by

Chris Weber, Managing Partner and Robert Mooney, Senior Software Development, Casaba, speak about the security practices of the “Requirements” phase of the Microsoft SDL. Chris and Robert explain the benefits of following the Microsoft SDL to building more secure, reliable, and standard-compliant software.


Whitepaper: The Simplified Implementation of the Microsoft SDL

Applying Microsoft SDL Requirements Practices within Windows Azure

December 14th, 2010 by

Chris Weber, Managing Partner and Robert Mooney, Senior Software Development, Casaba, speak about applying Microsoft SDL Requirements security practices to applications built on top of Windows Azure, focusing on the “Requirements” phase. Chris and Robert stress the similarities of Windows Azure applications to regular web applications, explaining that you won’t be operating in an entirely new environment, talk about decreased need to focus on infrastructure and platform and increased focus on securing the application layer. The presenters explain the similarities and differences in planning for security and privacy when deploying to Windows Azure, and explain how to map the existing and new risks to the cloud-based environment.

Whitepaper: The Simplified Implementation of the Microsoft SDL
Whitepaper: Security Best Practices for Developing Windows Azure Applications

‘Hacktivist’ Jester Claims Responsibility for WikiLeaks Attack

December 3rd, 2010 by

Jason Glassberg interviewed by FOX News on “‘Hacktivist’ Jester Claims Responsibility for WikiLeaks Attack

Why Microsoft has been a leader in responding to cyberattacks

December 1st, 2010 by

Chris Weber’s guest blog post on The Last Watchdog concerning Microsoft’s leadership in responding to threats and vulnerabilities in “Why Microsoft has been a leader in responding to cyberattacks.”

Microsoft wins legal dispute over Bing.com IDN lookalike

November 3rd, 2010 by

A couple years ago I tried registering IDNs (Internationalized Domain Names) that were visually identical or similar to popular sites like mozilla.org, bing.com, and google.com. What I found was that I wasn’t the only one doing this. For me, it was just to demonstrate the possibilities for visual spoofing in modern user-agents, similar to what we saw in 2005 with the paypal.com spoof.

I don’t think this recent legal decision made the news anywhere, but Microsoft filed a complaint that a registered domain name www.bıng.com was confusingly similar to its www.bing.com brand. In case it’s hard to see, the issue here is with the dotless ‘i’ in the lookalike domain. In that domain, the registrant used Unicode character U+0131 LATIN SMALL LETTER DOTLESS I in place of the usual U+0069 LATIN SMALL LETTER I in bing.com.

Microsoft won the case on valid merits, and as far as we know there was no harm done. That is, I haven’t heard any news of a phishing attack that utilized this domain name. It’s easy to imagine the extent of harm possible through a phishing/luring/schmoozing/whatever attack that utilizes confusing IDNs across the context of email clients, web browsers, and other user-agents. A well-thought attack could be surprisingly effective.

Detecting malicious URL obfuscation techniques in spam

October 12th, 2010 by

URLs offer loads of fun for pranks, hacks, and spam.  The reasons are numerous and inherent in their structural and visual complexity.  Add IDNs to the mix and the fun-factor just doubled.  But this isn’t about IDNs.  It’s recently been noted by Symantec that spammers are using the soft hyphen character to obfuscate URLs and bypass anti-spam filters.

It’s a neat trick that plays into the widely divergent implementation details of this specific character.  In Unicode the soft hyphen is U+00AD but its problem handling in browsers and email clients involves some confusions around its specification in other character sets such as ISO-8859-1 as well as HTML 4. 

The fun shouldn’t stop with soft hyphens though.  There seem to be many interesting ways content inspection filters could be bypassed using characters with special meanings and others with special transformative properties.  I haven’t taken the time to do any thorough testing here, but my IDN and IRI spoofing test page has some examples of what I’m talking about.  If you think of the test cases as plain string content instead of IDNs you can imagine some of the other ways which content filters might be confused.

Looking at the Normalization tests on that page one can see that valid Unicode characters like the Ⓞ get normalized (as hyperlinks) to a Latin small letter ‘o’ by Web browsers through a standard process defined by IDNA2003, namely stringprep with a nameprep profile applied.  That’s just the tip of the iceberg, and still more possibilities for abuse exist.

These issues are why we created the UCAPI library for detecting string confusability.  I wonder how many content inspection products are looking at strings in this way?

IDNA2008 hits the standards track – visually confusing strings remain a threat

August 31st, 2010 by

After many years of engineering efforts, the Internationalizing Domain Names in Applications (IDNA) protocol had a major update released from its original 2003 standard. Although named IDNA2008, it hit the standards track in August 2010. It’s worth noting in section “4.4 Visually Confusable Characters” of RFC 5890:

It is worth noting that there are no comprehensive technical solutions to the problems of confusable characters. One can reduce the extent of the problems in various ways, but probably never eliminate it.

Taken out of context this may sound hopeless, but the RFC goes on to reference Unicode TR36 as providing a set of suggestions for mitigating string confusability. It’s in this vein that Casaba has built UCAPI which provides an implementation of the Unicode Consortium’s suggestions as well as defensive techniques from our own learnings.

I can imagine that we will one day see a wide-spread attack that leverages string confusability – or maybe – we won’t see it because it’ll blend in so well as to be undetectable.

New registrations of Internationalized Domain Names are expected to increase radicallly over time as ICANN has opened up ccTLD support for Unicode and IDN, as well as gTLD. As more TLDs become provisioned in native scripts, it’s expected that they will support the expansion of many more internationalized domain names.

What are registrars doing now to protect customers from lookalike attacks on their brand? Is it their responsibility? Who’s is it? Many organizations including ICANN are making suggestions, but is anyone listening?

Hacking IRL: Crafting for the Modern Geek at OSCON

July 21st, 2010 by

Casaba Security joins the Open Source Convention (OSCON) lineup as Mary Kelly presents Hacking IRL: Crafting for the Modern Geek.

What do you get when you mix fractals, 3D printers, robotics, open source, high-powered lasers, and non-orientable surfaces with wood, plastic, textiles, steel, cloth… and lots of coffee? A completely new range of geek fabricated items and appliances. It’s hacking in real life.

Presentation: Hacking IRL: Crafting for the Modern Geek (ZIP)

Watcher 1.4.0 released

May 25th, 2010 by

A new update to the Watcher passive Web-vulnerability scanner has been released. Based on user feedback we’ve built out the Wiki documentation on Codeplex with more details about the issues identified by each Watcher check. Inside the tool, a reference is now included as a link back to the Wiki. I hope to improve the documentation on the Wiki and welcome all your suggestions.

A new check has been added to detect when domain lowering occurs through javascript, typically done by setting document.domain equal to the parent domain. We’ve also made some more efforts at noise-reduction, by enabling some of the noise-reduction configurations by default, namely in the cookie and VIEWSTATE checks.