I might blog about each one of these in turn because they’re each a little different and unfortunately the mitigation is not as simple as “validate input”.

Web Application Configuration Analyzer (WACA) is a tool that scans a server against a set of best practices recommended for pre-production and production servers. It can be used by developers to ensure that their codebase works within a secure / hardened environment (although many of the checks are not as applicable for developers). The list of best practices is derived from the Microsoft Information Security & Risk Management Deployment Review Standards used internally at Microsoft to harden production and pre-production environments for line of business applications. The Deployment Review standards themselves were derived from content released by Microsoft Patterns & Practices, in particular: Improving Web Application Security: Threats and Countermeasures available at: http://msdn.microsoft.com/en-us/library/ms994921.aspx. It uses an agent-less scan that requires the user to have admin privileges on the target server, as well as any SQL Server instances running on that machine.

This release of WACA we included some new features. They include:

• Suppressions – you can now suppress any rule you feel is not appropriate for your scan.
• Saving of suppression files – once you set up a suppression list you want to use you can save it off for future uses.
• You can change the suppressions and regenerate the report without needing to re-run the scan.
• Reporting – Updated the reporting section to include suppression information so you know what passed, failed, was not applicable and what was suppressed.
• Multiple reports – you can view multiple scans of the same machine or view a single machine’s scan and compare it to other machines.
• Export to the Microsoft RED format.
• Scan multiple systems and SQL instances in one bulk scan.
• Additional rules – we’ve added in additional SQL rules.
• And of course bug fixes that were missed in the last release.

I’m attaching two CSV files for use in test cases and tools.  The uni2asc.csv contains all of the Unicode characters that map to something ASCII < 0×80.  The bestfit.csv  contains all of the known best-fit  mappings to dangerous ASCII between legacy charsets and Unicode.

uni2asc.csv – for straight Unicode to Unicode mappings
bestfit.csv – for legacy charset to Unicode mappings

I gave these to Gareth so they may wind up in HackVertor.

The Unicode database contains meta data about every character, including compatibility mappings, normalization mappings, case mappings, and other decomposition data.  It’s useful for testing to know what special Unicode characters may transform to dangerous ASCII.  For example:

• U+2134 SCRIPT SMALL O character will transform to the U+006F LATIN SMALL LETTER in certain cases

Of course, if you’re testing for SQL injection or XSS you probably want to know what transforms to dangerous characters like ‘ and <.  We attempted to automate some of this in our x5s tool which has done a good job so far, and we have a big update for that coming soon.

In the bestfit.csv file you’ll find all of best-fit mappings from Unicode to dangerous ASCII < 0×80 (and vice versa) in many of the legacy charsets from http://unicode.org/Public/MAPPINGS/.  There’s some wild legacy stuff in here.  For example:

• In APL-ISO-IR-68, 0×27 maps to 0x5D in Unicode, and vice versa.

If you put these to use anywhere please let me know so I can pass the word along.

In APL-ISO-IR-68, 0×27 maps to 0x5D in Unicode, and vice versa.

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.

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

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.

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?

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?

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)

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.

Download Watcher from CodePlex. A short list of new features and improvements includes:

• A separate, optional component to export results to Team Foundation Server.
• New check to identify insecure ASP.NET VIEWSTATE configurations subject to tampering and pervasive XSS attacks.
• New check to identify insecure JavaServer MyFaces ViewState subject to tampering and XSS attacks.
• New check for Silverlight EnableHtmlAccess.
• Export results to HTML report.
• Compliance mappings to Microsoft SDL.
• If no origin domain is specified, each response domain will be treated as the origin, enabling better cross-domain analysis.
• Assorted bug fixes and improvements.

Bryan Sullivan and Patrick Toomey’s ViewStateViewer plugin [2] provided inspiration for detecting ASP.NET VIEWSTATE MAC protection. When testing .NET 4.0 we discovered a change in the MAC implementation which has also been accounted for in this check. David Byrne from Trustwave [1] provided most of the methodology ideas for detecting insecure JavaServer MyFaces ViewState.

In addition to the main developers (Robert Mooney and Samuel Bucholtz), we wanted to thank everyone who helped or provided suggestions for this release:

Hidetake Jo
Bryan Sullivan
David Byrne
Jason D. Montgomery
Dave Wichers

[1] Trustwave advisory https://www.trustwave.com/spiderlabs/advisories/TWSL2010-001.txt
[2] ViewStateViewer plugin for Fiddler http://labs.neohapsis.com/2009/08/03/viewstateviewer-a-gui-tool-for-deserializingreserializing-viewstate/

The SDL preaches 'secure by default'. When Windows Live moved to ASP.Net MVC, they used that opportunity to build mitigations into the framework that prevent developers from making accidental errors which result in security flaws. Specifically, they targeted these three security issues – XSRF, Open redirects and JSON hijacking.

For XSRF, the mitigation was that all HTTP requests are checked for a canary by default except for HTTP GET requests. Developers can also opt-out specific pages or functionality. This automatic ‘on-by-default’ canary checking prevents accidental errors which lead to XSRF.

For Open redirects, Windows Live added a wrapper around the Redirect result in ASP.Net MVC which checks a list of approved domains. This way when a developer called Redirect and forgot to ensure it was safe, the wrapper would cover them automatically.

For JSON hijacking, they ensure that the JSON result included a canary check by default. This prevented developers from being able to return JSON without a canary, thus preventing JSON hijacking.

You can download the presentation here.

Because it basically bombs a Web-app with a slew of Unicode characters to find XSS bugs we named it the Unibomber.

Appended to the canary is a special character – special because it can transform into a 'dangerous' character through normalization, casing, or best-fit mapping operations. So we end up injecting these special characters all over the place and then detecting where they get transformed and displayed as output.

The beauty is that we can find both reflected and persistent XSS bugs this way. It's not a one-click tool though, this is intended for use by an experienced person who knows how to find and exploit a clever XSS bug.

Anyone who looks for XSS will likely find some good bugs with the Unibomber. We sure have!

Unfortunately CodePlex went down today, even with Microsoft's new release of !exploitable at CanSecWest. Anyhow we're working hard to to add new checks to Watcher and reduce false positives in existing ones. So please grab Watcher from Codeplex and send us any feedback you want.

Slides: Exploiting Unicode-enabled Software at CanSecWest (PDF)

Go get Watcher.

At a high-level Unicode-related security bugs can be categorized into the following root-causes:

Canonicalization

• Interpreting non-shortest form (e.g .UTF-8 encoding trickery)
• Other decoding issues

Absorption (over-consumption)

• Over-consuming invalid byte sequences or correcting rather than failing
• When <41 C2 C3 B1 42>  becomes <41 42>

Character deletion and swallowing

• “deletion of noncharacters” (UTR-36)
• <scr[U+FEFF]ipt> becomes <script>
• Use replacement characters instead!

Interpreting Syntax replacements

• white space and line feeds
• E.g. when U+180E acts like U+0020

Best-fit mappings

• When σ becomes s
• When ′ becomes ‘

Buffer overruns

• Incorrect assumptions about string sizes (chars vs. bytes)
• Improper width calculations

Timing issues

• handling Unicode after security gates
• Sometimes handling Unicode before a gate can be a problem too! E.g. BOM handling

Setting this property ignores validation errors that occur during HTTP parsing. The documentation from MSDN makes it pretty clear. When this property is set to 'true' then many HTTP RFC violations will be relaxed and ignored.

When this property is set to false, the following validations are performed during HTTP parsing:

* In end-of-line code, use CRLF; using CR or LF alone is not allowed.
* Headers names should not have spaces in them.
* If multiple status lines exist, all additional status lines are treated as malformed header name/value pairs.
* The status line must have a status description, in addition to a status code.
* Header names cannot have non-ASCII chars in them. This validation is performed whether this property is set to true or false.

When a protocol violation occurs, a WebException exception is thrown with the status set to ServerProtocolViolation. If the UseUnsafeHeaderParsing property is set to true, validation errors are ignored.

Setting this property to true has security implications, so it should only be done if backward compatibility with a server is required.

Let's keep an eye out for this option when it's set either programmatically or through web.config.


<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing=”true” />
</settings>
</system.net>
</configuration>


http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt

This might not be so surprising to people in tune with Unicode, but it's can lead to huge security problems when security filters are at risk. For example, if you're performing HTML filtering or file canonicalization, you need to perform so after the conversion to LPStr.

This default marshalling behavior is documented at: http://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute(VS.71).aspx

To properly and more safely deal with this, you can use the MarshallAsAttribute class to specify a LPWStr type instead of a LPStr. For example:

[MarshalAs(UnmanagedType.LPWStr)]

Because LPWStr is a pointer to a null-terminated array of Unicode characters, this ensures the Unicode code points are preserved across the marshalling.

For example, your application takes a request from the user, maybe it's a GET request for a certain page. Included in the request is a value indicating the location where the user should be redirected once they've finished on the page. So, the user requests a page like:

http://somesite.tld/page.aspx?name=value&returnUrl=http://somesite.tld/referringpage.aspx

As you can see, the returnUrl takes a value of the redirect location. Then your code acts on it somewhere by redirecting the user with something like:

Response.Redirect(returnUrl);


Spammers and phishers love this, it gives them good camouflage. For example:

http://somesite.tld/page.aspx?name=value&returnUrl=http://evil.tld/installMalware.bad

Now imagine the spammer has crafted up a nice email that looks like it originates from somesite.tld, includes all the logos, fonts, etc. They coerce the victim into clicking this link by saying something like “your account needs immediate attention” or “you've won 500 points”. User clicks the link, gets redirected to evil.tld, and may not realize that the domain has switched before they say Yes to install the thing that the spammer wants them to download.

Tricky, right. In fact this is a favorite of spam, malware, and phish, next to the old XSS bug.

What's the solution
Well, simply, don't redirect openly, rather, implement a SafeRedirect() function that looks something like:


public static SafeRedirect(string url) {
// check that protocol is either http:// https:// ftp:// or other specific protos you want to allow
// check that domain is in fact yourdomain.tld
// If these checks pass, then you can go ahead
Response.Redirect(returnUrl);
// If the checks fail, you can try to clean up the URL, but probably best to just fail and redirect to a safe landing page
}

That's about all there is too it.

1. code flaws have been identified and addressed (buffer overflows, leaks, etc.)
2. repurposing threats have been identified and mitigated (the control should not do anything more than it needs, and should be very careful when performing file, registry, or network operations)

To gain a higher level of assurance that this control won't be exploited, you take more steps to restrict the domains which are allowed to call it.

So without Sitelock for Mozilla, we're in search of an alternative solution that will work across both IE and Mozilla. We know a few things available for the cross-browser domain restriction solution:

• we can use C/C++
• we have access to the DOM
• we have access to COM+
• we'd like access to WININET but that's too far down the stack

Right now, we're primarily interested in getting the true domain which is loading and calling the plugin. How can we gaurantee this? We try getting it from the DOM's document.domain property, but know that the document.domain property has historically been a source of security vulnerability in all major browsers. There have even recently been ways to spoof the address bar, or the domain property using JavaScript and other means, and there likely will in the future. For example:

FireFox
http://www.thespanner.co.uk/2007/11/14/spoofing-firefox-protected-object

IE 6/7.
http://www.0×000000.com/hacks/crossdomain/crossdomain.html

Safari/Windows
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3514

After some research we're testing some other options. Right now our best bet might be looking like:

• using IWebBrowser2::get_LocationURL() for Internet Explorer
• using window.location.href for Mozilla
• InternetCrackUrl() to parse the hostname

After some testing we don't see the document.domain type issues present in window.location.href, so it seems to be holding up short some unknown browser-flaw.

IWebBrowser2::getLocationURL() seems okay but I did find the following issue with get_LocationURL at http://support.microsoft.com/kb/272095.

~Chris Weber

Paper: Analysis of the Storm and Nugache Trojans: P2P Is Here (PDF)

With GetUnicodeCategory you can simply build a whitelist supporting the character categories you want to allow. So get away from thinking you have to write a regEx filter and list out all the character ranges you want to allow in each character set, it’s much simpler than that!

The Unicode standard assigns ever character to one of about 31 categories. They make sense too, for example Other Control charactes (Cc) , Lowercase Letter (Ll), Uppercase Letter (Lu), Math Symbol (Sm). So for example you might want to only allow letters, numbers, and punctuation in your whitelist. This could be achieved with the following snippet:


char cUntrustedInput; // the untrusted user-input
UnicodeCategory cInputTest = CharUnicodeInfo.GetUnicodeCategory(cUntrustedInput);
if (cTestCategory == UnicodeCategory.LowercaseLetter ||
cTestCategory == UnicodeCategory.UppercaseLetter ||
cTestCategory == UnicodeCategory.DecimalDigitNumber ||
cTestCategory == UnicodeCategory.TitlecaseLetter ||
cTestCategory == UnicodeCategory.OtherLetter ||
cTestCategory == UnicodeCategory.NonSpacingMark ||
cTestCategory == UnicodeCategory.DashPunctuation ||
cTestCategory == UnicodeCategory.ConnectorPunctuation)
{
// character looks safe, continue
}
else
{
// character is not allowed, fail
}


Not too bad eh.

First there’s XML. When developers choose to implement XmlTextReader or XmlReader from the .NET Framework, they need to understand the behaviors of these classes. MSDN documents this quite well. I will usually do a quick code review to find implementations of these objects, because the issues can be identified a little faster through code than through testing.

XmlTextReader defaults to allowing external DTD’s to be specified. This leads to a whole enchilda of issues, and gives attackers a nice bit of control over the host server. Be sure to set the ProhibitDTD property equal to true. Furthermore, there’s no strict schema validation unless the developer implements one.SOAP is fine, but developers need to implement a custom SOAP extension to enforce strict schema validation. Otherwise it gets pretty easy for an attacker to abuse the WS by embedding things like:

• large payloads
• large number of elements
• nested elements
• malformed data

To name a few… Without strict validation, I’ve seen web services easily abused. For example, by sending a few large requests, it becomes trivial to consume memory on the host server which eventually leads to resource starvation. To learn more about implementing a custom SOAP Extension to tackle this problem, read the MSDN article:

http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/

1. Has threat modeling been done or is this my job?
2. How much time and budget do we have for a security review?
3. How complex are the web services? e.g. how many parameters do they take and in what format
4. Are the web services written in managed code?
5. Is user-input passed to unmanaged code?

Let’s take these answers from a common scenario:

1. Yes threat modeling is complete
2. We have about 2 or 3 weeks that you can use to test
3. Very complex, they use WS-Security, take hundreds of parameters, some encrypted, using custom formats, SOAP, as well as embedded XML blobs
4. Yes, they’re written in C# using the .NET Framework
5. Some specific elements of user-input are handled by unmanaged code modules

Some things not obvious in these questions are:

• that the client is highly interested in finding Denial of Service (DoS) issues
• that millions of people will be using these Web Services whether they know it or not
• that no input fuzzing has been done to date

With 2-3 weeks we could get a lot done in a security review focused just one the web services. It’s becoming clear that fuzzing input would be a worthwhile venture. We’ll likely turn up some DoS issues, possibly some unmanaged code issues as well. Since we have a decent timeframe, we’ll be checking for the following issues, not all of which fuzzing is good for:

• elevation of privilege (EoP)
• repurposing attacks
• cross-site scripting (yes, even web services in some cases)
• information disclosure
• session replay
• SQL Injection
• DTD attacks
• XML validation
• script injection
• repudiation
• denial of service
• buffer overrun

Fuzzing will help with some of these, so at this point the answer is yes, let’s do it. We’ll also be doing some code review, which is great for identifying issues such as DoS, XML validation, and DTD attacks quickly. And we’ll be studying the specs and architecture along the way to keep a clear understanding of the system and help identify repurposing attacks, which will be tested for confirmation.

Ok let’s go!

You’re testing a web app that has an input field. Some script tags are allowed but <img src=”something”> is not. By replacing the whitespace with a comment, your code is accepted. When returned to the browser, IE 6.x, the comment is interpreted as whitespace and the code is executed fine. Test it out:

//Start HTML
<html>
<body>
<img/*comment*/src=”javascript:alert(’img tag’)”>
</body>
</html>
//End HTML

This trick can be useful for more than just bypassing filters…

http://somesite.iis/query=unicode-character-%u0073
http://somesite.iis/query=unicode-character-%u0022
http://somesite.iis/query=unicode-character-%u043E

This is controlled by the following registry key and is enabled by default:

HKLM\System\CurrentControlSet\Services\HTTP\Parameters\PercentUAllowed

A Boolean value. If non-zero, Http.sys accepts the %uNNNN notation in request URLs.

1. Allow users access to their local drive content within a defined scope (e.g. either the entire drive, or the My Documents folder only)
2. Prevent users from accessing files outside of the defined scope. So they shouldn’t be able to access network drives, USB keys, etc.

To acheive this, the shell constants were used, as defined in the Windows SDK.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/enums/csidl.asp

This worked well, and after we looked at the code we actually ran a battery of tests to confirm. So for example we tried the following types of canonicalizations:

• \\host\share\file
• \\?\folder\file
• \\10.10.10.10\share\file
• \\.\folder\file

We kept going, and tried breaking out of the local scope as well:

• ..\..\..\..\boot.ini
• ../../../../boot.ini
• ..%2fboot.ini

And all that sort of stuff. Using the CSIDL constants proved successful, and we could see this through debugging. Everything we entered was merely relative to the constant value, there was no way to change it.

It’s documented:

http://msdn2.microsoft.com/en-us/library/system.web.ui.page.viewstateuserkey.aspx

ViewStateUserKey mitigates XSRF by including a unique identifier in the user’s request.

This protection mechanism has been available for many years when Microsoft identified the one-click attack, now more commonly referred to as XSRF.