Archive for the ‘Security Testing’ Category

Watcher 1.4.0 released

May 25th, 2010 by Chris Weber

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.

Watcher 1.3.0 released

February 25th, 2010 by Chris Weber

A new update to the Watcher passive vulnerability detection and security testing tool has been released. Watcher is an open source addon to the Fiddler Web proxy that aids developers, auditors, and penetration testers in finding Web-application security issues as well as hot-spots for deeper review. Among other things, we’ve added new checks to identify the insecure ViewState issues as recently reported by Trustwave’s SpiderLabs [1].

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/

Microsoft CCI Framework for Deobfuscating .Net binaries. (Part 2)

February 4th, 2010 by John Hernandez

So yesterday I talked a about using CCI to remove attributes from .Net binaries. Specifically the SupressIldasm attribute. I promised I’d put up some more code highlighting the framework’s benefits. So some more detail on the binary I’m working with. It has been ran through Babel -> Netz -> Babel again. My goals have been to reverse Debabel-> Unpack Netz -> Rebuild the .exe -> debabel again, although the first stage of babel could be skipped, but why not analyze it.

Babel uses a couple of simple techniques to prevent programs like reflector from analyzing protected binaries. These techniques are also found in other protections, so it’s useful to understand why the work and how they work, they are really very simple.

Today I’ll cover a simple but annoying technique being employed; inserting junk bytes. Babel inserts junk bytes into the IL stream of each method. When reflected it causes the disassembler to fail as it does not recognize the byte sequences it can’t continue.

Below is an example of a method ildasm’ed after removing the “suppressIldasm” attribute from the previous post.

View Code CSHARP
.class public auto ansi beforefieldinit netz.NetzStarter
       extends [mscorlib]System.Object
{
  .field private static initonly string Property0
  .field private static initonly string Property1
  .field private static initonly string Property2
  .field private static class [System]System.Collections.Specialized.HybridDictionary Property3
  .field private static class [mscorlib]System.Resources.ResourceManager Property4
  .field private static class [mscorlib]System.Collections.ArrayList Property5
  .field private static bool Property6
  .method public hidebysig specialname rtspecialname
          instance void  .ctor() cil managed
  {
    // Code size       14 (0xe)
    .maxstack  8
    IL_0000:  br         IL_0007
 
    IL_0005:  unused
    IL_0006:  unused
    IL_0007:  ldarg.0
    IL_0008:  call       instance void [mscorlib]System.Object::.ctor()
    IL_000d:  ret
  } // end of method NetzStarter::.ctor

As you can see it does an absolute jump over some “unused” bytes which are really invalid bytes. This way the logic of the program is maintained while confusing the disassembler. One technique I’ve read to handle this is to use a hex editor to look for the absolute jump op code and nop out those bytes. However this is unreliable as babel inserts bytes not just at the start of the method.

Microsoft CCI to the rescue again!.

So lets use CCI to handle rebuilding the binary by replacing invalid bytes with nops. This way we can now view this application in reflector and be able to navigate it. Below is the mutator class i wrote to handle NOP’ing invalid bytes. Again a very simple solution. Now the code is visible in reflector using the IL view. At least you get the “browsing” functionality and easily go to functions and view their dependencies and cross-references.

View Code CSHARP
public class InvalidCodeNOPReplace : MetadataMutator
{
	public InvalidCodeNOPReplace(IMetadataHost host)
	    : base(host)
	{
 
	}
 
	public override List<IOperation> Visit(List<IOperation> operations)
	{
	    operations = Utilities.ReplaceInvalidOpCodeAsNOP(operations);
 
	    return base.Visit(operations);
	}
}
 
public static List<IOperation> ReplaceInvalidOpCodeAsNOP(List<IOperation> ops)
{
    List<IOperation> newOps = new List<IOperation>();
    foreach (IOperation op in ops)
    {
 
	if (!IsValidOpCode(op.OperationCode))
	{
	    Operation o = new Operation();
	    o.Location = op.Location;
	    o.Offset = op.Offset;
	    o.OperationCode = OperationCode.Nop;
	    o.Value = 0x0;
	    newOps.Add(o);
	}
	else
	{
	    newOps.Add(op);
	}
    }
    return newOps;
}
 
private static void populateOpCodeDic(){
   OpCodes = new Dictionary<OperationCode,int>();
   foreach(int i in Enum.GetValues(typeof(OperationCode)))
   {
     OpCodes[(OperationCode)i] = i;
   }
}
public static bool IsValidOpCode(OperationCode opCode)
{
       if (OpCodes == null)
       {
            populateOpCodeDic();
       }
       return OpCodes.ContainsKey(opCode);
}

Unfortunately reconstructing the C# source doesn’t work at this stage due to the nops and invalid branching structure. However, I’m trying to work out a middle layer which can take a methodbody’s operations list, abstract it out, turn it in to a control flow graph, optimize it and rewrite. However i’m still stuck at the rewriting part. I hit a small snag in the logic I haven’t had time to work out just yet. Hopefully then the C# can be reconstructed.

Tomorrow I’ll post some simple methods to get readable names out of the method/properties/class names to make following logic easier.

*Edit forgot to add the IsValidOpCode method.

**Edit had to readd disappearing generic types.. Ugh!

Unibomber tool for specialized XSS testing

July 28th, 2009 by Chris Weber

John Hernandez has been working hard at Casaba to build a specialized testing tool that automates some of the unique techniques we use to find cross-sites scripting bugs (XSS). At Black Hat I'm planning to demo what we have so far. It automates the testing process greatly, by auto-injecting a canary and ID into each input be it query string, HTTP header, or POST parameter. By combining injection with 'output encoding' detection, you get automation that assists pen-testers in finding vulnerability hotspots.

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!

Watcher v1.1.0 released

April 12th, 2009 by Chris Weber

We've made some significant improvements to the Watcher web security and compliance auditing tool in version 1.1.0. Some new checks have been added, bug fixes, and performance improvements.

I wanted to point out that Watcher helps not only in testing and auditing Web applications, but it has checks to assess the security strength of the operational configurations as well, such as the SSL version being used. We've also added a check for SharePoint related assessment, and are working to add more Sharepoing security tests in the next version.

Eric Lawrence introduces Watcher tool at MIX09 Conference

March 21st, 2009 by Chris Weber

I'm happy to say IE8 Security Program Manager and Fiddler author Eric Lawrence announced our Watcher tool at MIX09 today. Check out his talk at http://videos.visitmix.com/MIX09/T54F it's an eye opener for Web developers – introducing us to the new features of IE8 while also covering state-of-the-art secure development practices for today's Web applications.

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.

Watcher security tool for web applications

March 12th, 2009 by Chris Weber

Watcher is being released under an Open Source license. With over 30 checks in its first release, it helps you find issues in your web-apps fast and effortlessly. Watcher is a Fiddler plugin that passively audits a web application for a variety of security issues. It acts as an assistant to the developer, tester, or pen-tester, by quickly identifying issues that commonly lead to security problems in web apps. Integrate it into your test passes to achieve more coverage of security testing goals.

Go get Watcher.

Generating test cases for Unicode-enabled software

September 10th, 2008 by Chris Weber

When it comes to Unicode implementations, there’s a rich set of test
cases to perform. Realizing it is the start. Automating it is the next
step.

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

Unicode formatter characters lead to cross-site scripting in popular browsers

September 5th, 2008 by Chris Weber

I'll be discussing some of the issues recently reported to Opera, Apple, and Mozilla at the 32nd Unicode Conference in San Jose next week. We discovered some issues with the way certain Unicode characters could be leveraged to enable cross-site scripting attacks in popular web browsers (aka User-Agents). These issues involve utilizing Unicode characters in ways which might bypass most filters, IPS, and IDS systems.

Cisco Type 7 is as bad as you can possibly get.

August 7th, 2008 by Samuel Bucholtz

I always love learning cool new little features in the software I use. In this case, my coworker Ramsey came across a great Blog (http://blog.ioshints.info) on Cisco IOS and we picked up a new trick for decrypting Type 7 passwords.

Cisco IOS has always supported a few encryption mechanisms for local passwords on the device. The first is Type 7 which uses a reversible encryption, about as difficult as ROT13 to break. The second is Type 5, which uses an MD5 hash to make the password irreversible (it is vulnerable to dictionary attacks). I see Type 7 passwords used in cases where they are not required, more often than I would reasonably expect. To quickly and easily decrypt the password and demonstrate why it is such a bad idea I have found this cool little trick:

R1(config)#key chain decrypt

R1(config-keychain)#key 1

R1(config-keychain-key)#key-string 7 <encrypted string>

R1(config-keychain-key)#do show key chain decrypt

 

Another item people are often not aware of is Type 6 encryption. Type 6 encryption is reversible encryption like Type 7 but uses AES and supports a supplied salt. This allows for significantly better security on newer IOS versions that support it.