So over the past few months we’ve been working to port more of Watcher’s passive Web scanning checks to theModSecurity open source Web Application Firewall.  It seems to be working out, as some of the rules have made it into the latest release of ModSecurity’s Core Rule Set v2.2.3 as well as some earlier rule sets.  There’s more to come.  Please send any feedback to me or Ryan, and look for more rules to be added very soon.

I wanted to get my hands a little dirty and play with the new API. I’ve been meaning to look into Managed DLL injection for a while to get code execution for process interrogation. There are times when we’re testing that we want to interrogate a process for framework level information. For whatever reasons we sometimes can’t compile the target with hooks. So it would be nice to have a way to execute code. Roslyn’s CSX files look like a great way to accomplish this so that’s what I’m trying to expose.

Currently this only works on 32 bit processes.

Let’s start by describing the architecture as there are 3 things going on. The major components are the Injector, Unmanaged Injectee and Managed Injectee. The injector is the controller in this scenario; he’s responsible for the injection into the managed process and communication between the components. Communication is handled via named pipes.

The injector uses a well-documented dll injection technique via CreateRemoteThread and LoadLibrary. This loads the unmanaged dll into the Managed process. The unmanaged DLL actually handles the Managed DLL injection. I wont go into unmanaged dll injection as it’s pretty well document technique. I assume the reader understands these concepts.

From this point I assume the unmanaged DLL has been injected into the managed process.

After the unmanaged DLL is injected I need to make sure the correct version of the CLR is loaded. To accomplish this use the CLR hosting API’s to determine the version of the CLR that is loaded by the process (Provided there is one loaded). The host process must be running .Net 4.0 to support the Roslyn API. Because the early versions of the hosting API’s are deprecated I need to check to see if the .net 4.0 mscoree is loaded “msvcr100_clr0400.dll”. I check via a GetModuleHandle. If it exists we know we are running .Net 4.0 and know the CLR is already running. Two birds down with a single stone.

hMod = GetModuleHandle(L"msvcr100_clr0400.dll");

Once we know the CLR is loaded and it’s 4.0 we can get a handle to the CLSID_CLRMetaHost via:

hr = CLRCreateInstance( CLSID_CLRMetaHost,
IID_ICLRMetaHost,
(LPVOID*)&pMetaHost );

From the meta host we can get a handle to the running RunTimeHost via:

ICLRRuntimeHost *pClrHost = NULL;
runTimeInfo->GetInterface(CLSID_CLRRuntimeHost, IID_ICLRRuntimeHost, (LPVOID *)&pClrHost);

This will return a handle to the current RuntimeHost (Or load the runtime if it isn’t running). The next call is to load my Managed DLL plus call the entry method.

pClrHost->ExecuteInDefaultAppDomain(L"InjectedManagedDll_Net_4.dll", L"InjectedManagedDll_Net_4.InjectedClass", L"Test", L"TestArg" , &ret);

This loads the Managed DLL into the process. Once the Managed DLL’s Test method is called I create a managed thread.

public static int Test(string param)
{
new Thread(new ThreadStart(ThreadFunc)).Start();
return 666;
}

This thread then generates a few more threads and sets up the NamedPipe communication pipe and reports to the server things are setup.

static void ThreadFunc()
{
try
{
PipeClient.Instance.Start("CNIPipe");
}
catch (Exception e)
{
PipeClient.Instance.LogMessageToServer(e.Message);
}
}

I then expose some simple messages back and forth between the injector and injectee and expose a simple REPL loosely based on this guy’s implementation: http://visualstudiomagazine.com/articles/2011/11/16/the-roslyn-scripting-api.aspx.

private ScriptHost()
{

HashSetassemblys = new HashSet();
assemblys.Add(Assembly.GetCallingAssembly());
assemblys.Add(Assembly.GetEntryAssembly());
assemblys.Add(Assembly.GetExecutingAssembly());

Listnamespaces = new List() { "System", "System.Collections", "System.Collections.Generic" };

ScriptEngine = new ScriptEngine(assemblys.ToList(), namespaces);

Session = Session.Create(this);
}

public object Execute(string code)
{
return ScriptEngine.Execute(code, Session);
}

This gets you a basic REPL inside another process. Next steps include making sure the communication API between the host and injectee are more well formed and able to handle both 32 and 64 bit processes. Stay tuned!

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.

Some of the improvements include:
* Better Algorithms for doing checks
* Better output format .. Now uses a tree view.. Going to add better support for reporting too..
* Cleaner UI (Easier to use)
* Re-factored the code to be cleaner/make more sense and easier to maintain. It’s much easier to understand/work with.. before was mostly prototyped code/ Alpha code.
* Changed how test cases are defined for more control over the types of injects
* Added a fuzzing mode that will take data from a file and inject it where canaries would normally be injected. (This can be slow with lots of injections)
* Added a replay from Fiddler capture.. (Replays the capture while fuzzing/injecting on the requests).

* many many more minor/significant changes.. =)

Check back soon for a release date!

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?

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/

For more information checkout: http://websecuritytool.codeplex.com/

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.

Go get Watcher.