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!

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.

Give them a watch!

Microsoft SDL Requirements Phase: Security Practices
http://technet.microsoft.com/en-us/edge/Gg520839

Applying Microsoft SDL Requirements Practices within Windows Azure
http://technet.microsoft.com/en-us/edge/Video/gg482149

Microsoft SDL Release Phase: Security Practices
http://technet.microsoft.com/en-us/edge/video/gg583895

Applying Microsoft SDL Release Practices within Windows Azure
http://technet.microsoft.com/en-US/edge/Gg583898

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!

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.

Below is an outline of the different components of MVC that are important to look into when reviewing ASP .Net MVC applications. It’s also important to review the normal MVC spec’s to understand context, but here is a “security” minded checklist.

ViewData Dictionary

This is used to pass data from a Controller to the View. It’s extremely important to verify the ViewData on both the View and Controller. The ViewData is a dictionary for passing untyped data to the view. It’s important to make a recommendation that either data is encoded on the input or the output and try not to mix the two as you can get yourself in trouble. I think output encoding is easier to manage than input.
Look at the controller actions and the parameters they receive. If they are strings, verify on the output or input encoding occurs for the appropriate uses.  A grep to look for:

ViewData\[“”

ViewData.Model

The ViewData.Model is a method for passing TYPED objects back to the view. You can specify a ViewPage<T> where T can be a typed to the value of ViewData.Model. In your controller when you return a View you can pass the object to the page. Example would be return View(“Index”, objOfTypeT)

So it’s important to understand the type being used in this case as unencoded data can make it to the view from this object.

AntiForgeryToken Attribute

Any post which would require Anti-CSRF protections should include the AntiForgeryToken Attribute on the controller Action where the post submits to. There is also a requirement on the View side of things to ensure that the AntiForgeryToken is actually used. Make sure that Html.AntiForgeryToken() method is being called within the form definition on the view.

Public Methods in the Controllers

Any public methods contained in the controller are accessible via crafted URLs. Verify there are no unintended consequences from public methods, also validate that authZ occurs on appropriate methods.

Direct browsing View pages

The View directory for the MVC application contains a web.config for blocking access to view pages among other view wide configurations. It’s important to note that by default .aspx pages are blocked, however if there is a custom extension being used you will to ensure they are explicitly blocked via config. Below are the relevant keys

IIS 6
<add path="*.aspx" verb="*" type="System.Web.HttpNotFoundHandler"/>

IIS 7
<add name="BlockViewHandler" path="*.aspx" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>

Controller Action Parameters

Action parameters can be complex types. For example you could have Action with a method signature like below.

[AcceptVerbs("POST")]
public ActionResult Edit(Product product)

In this case Product could have some public properties associated with it like {Name, Id, etc.}. If Price was meant to be set later by the db after a look occurred on the product id you could end up in trouble depending on the logic.

The root problem here is if the complex type exposes a property that was not supposed to be set by the client you could inadvertently end up with a tainted object. Also it introduces a place where unencoded data could make it to the view depending on how the object is used.
Here is a link that explains it better and more in detail.
http://www.codethinked.com/post/2009/01/08/ASPNET-MVC-Think-Before-You-Bind.aspx

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/

So I promised this last week, but I’ve been busy on a new project. Below is some code that shows renaming of methods. This is a solution to renaming classes within namespaces. It iterates over each namespace renaming classes from class1 -> classN. This is more useful for human readability and tracing logic. I leave it as an exercise to the reader to figure out how to rename other parts of the assembly. But hey if you really need it an get stuck, let me know!

I’ll be posting a tool at some point that does all these different actions for you. Hopefully I’ll have a early release out by mid next month. I’m currently learning WPF well enough to build in visulalizations of the control flow graph. That way after a mutator is applied you can visually see the results.

There is a dictionary in the mutator class that uses the namespace string as a key in order to know which class # i left off at. I test on the string length < 2 because the obfuscators I’ve seen that do this trick tend to just rename everything to some obscure unicode code point of length 1. Just a easy stop condition. You can use any stop condition that suits your needs.

public override NamespaceTypeDefinition Visit(NamespaceTypeDefinition namespaceTypeDefinition)
{
  string key = namespaceTypeDefinition.ContainingUnitNamespace.Name.Value;
  if (!classDict.ContainsKey(key))
  {
     classDict.Add(key, 0);
  }
  if (namespaceTypeDefinition.Name.Value.Length < 2)
  {
     int i = classDict[key];
     namespaceTypeDefinition.Name = this.host.NameTable.GetNameFor(String.Format("Class{0}", i));
     i++;
     classDict[key] = i;
  }
  return base.Visit(namespaceTypeDefinition);
}

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.

.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.

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!

So the first thing I decided to try was removing the SuppressIldasmAttribute attribute.  Below is some example code doing just that using CCI and rewriting the file. This produces an executable that works and doesn’t require just hex editing out the attribute leaving an executable that doesn’t run.

static void Main(string[] args)
{
     var host = new PeReader.DefaultHost();
     var module = host.LoadUnitFrom(args[0]) as IModule;
     var attributeRemover = new AttributeRemover(host);
     module = attributeRemover.Visit(module);
     Stream peStream = File.Create(module.Location ".fixed");
     PeWriter.WritePeToStream(module, host, peStream);
     Console.Out.WriteLine("Finished");
}
 
/*
* Removes the static attribute atm SuppressIldasmAttribute.. can be modified to remove any attribute.
*/
 
public class AttributeRemover : MetadataMutator
{
 
     PlatformType pt;
 
     public AttributeRemover(IMetadataHost host)
                              : base(host)
     {
         pt = new PlatformType(host);
     }
 
     public override List<ICustomAttribute> Visit(List<ICustomAttribute> customAttributes)
     {
          for (int i = 0; i < customAttributes.Count; i++  )
          {
               if (customAttributes[i].Type.ToString() == "System.Runtime.CompilerServices.SuppressIldasmAttribute")
               {
                    customAttributes.RemoveAt(i);
                    break;
               }
          }
          return base.Visit(customAttributes);
     }
}

As you can see it requires very little code. Anyways that’s enough for this post. I also have some more code I’ll be posting that uses CCI to rename methods/class/methods from their “mangled names” and code that removes invalid OpCodes so reflector works at the IL level. I’m still working on code that goes through creates a optimized methods to remove the invalid jumps such that C# code can hopefully be reconstructed. We’ll see how that goes.

For critical functions, such as those accepting anonymous Internet connections, strlen must also be replaced.

That’s good advice for cases where you want to operate on untrusted data. In those cases they tell you that you should use strnlen_s. The problem is, banned.h straight out bans strlen. There is no way to tell it that hey, this particular invocation is safe because I control the buffer in all aspects. Nope, sorry. You can’t use strlen. Or can you?

Here is a code sample that uses banned.h to deprecate unsafe APIs, yet still manages to invoke strlen when necessary. The sample works in both Visual Studio on Windows and GCC on UNIX.

 
//
 
//  banned_test.c
//  20091208 ramsey@casabasecurity.com
//
//  A sample program that illustrates how to "grandfather in" banned APIs
//  for use when they are marked deprecated (Windows) or poisoned (UNIX)
//  by the compiler.
//
//  to compile on Windows:
//  cl /GS /W4 /WX banned_test.c
//
//  to compile on UNIX:
//  gcc -Wall -Werror banned_test.c
 
#if defined _WIN32
 
#include <windows.h>
#endif    // _WIN32
 
#include <stdio.h>
#include <string.h>
#if defined _WIN32
 
size_t my_strlen(const char *string)
{
  size_t len;
  #pragma warning(push)
  #pragma warning(disable:4995)
  len = strlen(string);
  #pragma warning(pop)
  return len;
}
 
#else
#define my_strlen strlen
#endif    // _WIN32
 
#include "banned.h"
 
int main(int ac, char **av)
{
  char *str = "foo";
  #if defined _WIN32
  UNREFERENCED_PARAMETER(ac);
  UNREFERENCED_PARAMETER(av);
  #endif    // _WIN32
  #if defined _WIN32
  (void)printf("len is %Id\n", strlen(str));
  #else
  (void)printf("len is %zd\n", strlen(str));
  #endif    // _WIN32
  return 0;
}

Note that this code requires the use of Microsoft’s banned.h header file, which can be downloaded here. Stick it in the same directory as the above source file.

To compile the sample in Windows from a Visual Studio Command Prompt:

cl banned_test.c /GS /W4 /WX

As expected, this program will generate an error when run:

banned_test.c

banned_test.c(50) : error C2220: warning treated as error - no 'object' file generated

banned_test.c(50) : warning C4995: 'strlen': name was marked as #pragma deprecated

Now edit banned_test.c and change the strlen on line 50 to my_strlen and recompile:

cl banned_test.c /GS /W4 /WX

It should compile without error. Now run it and you should see:

len is 3

Nifty.

The same code works without change on UNIX (tested on NetBSD):

gcc -Wall -Werror banned_test.c

As with the Windows example, running the program will generate an error, as expected:

banned_test.c:52:31: error: attempt to use poisoned "strlen"

Again, change the occurrence of strlen (this time on line 52) to my_strlen and recompile. It will work and when run, it will say:

len is 3

What’s going on here is simple. While we are banning use of the strlen function, we are still allowing its use selectively through a wrapper that we have “grandfathered in.” This is easy to accomplish in UNIX: we simply

#define my_strlen strlen

prior to including banned.h and use that function call entry point instead. Problem solved. This is not as easy to accomplish with Windows, however, as cl.exe has no notion of “grandfathering in” deprecated APIs. So what we do is wrap strlen in another function. We ignore the deprecation warning that occurs where we make the call to strlen through the judicious application of some Visual Studio-specific pragma instructions. Now all need to do is call in to our new function entry point. We’re good to go. The Windows solution requires a little more work up front, but turns out to be not so hard to accomplish after all.

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.

Recently I was converting strings using the mbstowcs_s and wcstombs_s functions. (These are from from the bounds checking extensions to the C Library specified in ISO/IEC TR 24731-1.) These functions allow you to convert multibyte character sequences to and from wide character sequences. These functions are available to C and C++ programmers using Microsoft's Visual Studio compiler. (I am not yet aware of any UNIX compatible compiler that supports the draft TR 24731-1 standard.)

Since these two functions convert strings, it is worth looking at the parameters they expect. (Not doing so is a sure fire way to do something stupid, like enable a buffer overflow.) Looking at the relevant parameters for these two functions, we see:

mbstowcs_s:
[in] sizeInWords
      The size of the wcstr buffer in words.
[in] count
      The maximum number of wide characters to store in the wcstr buffer, not including the terminating null, or _TRUNCATE.

wcstombs_s:
[in] sizeInBytes
      The size in bytes of the mbstr buffer.
[in] count
      The maximum number of bytes to be stored in the mbstr buffer, or _TRUNCATE.

Does count in wcstombs_s account for the terminating NULL or not? Failure to account for this could introduce an off-by-one error which, in turn, may lead to an exploitable condition, such as a buffer overflow. How can we determine this from the documentation? Well, in its current state, we can't. This is what we call a “doc bug.”

Luckily, Microsoft includes the source code for the C Runtime with most Visual Studio SKUs. Assuming you installed Visual Studio in Program Files, you should be able to find the CRT source code in Program Files\Microsoft Visual Studio 9.0\VC\crt\src. CRT source code is included with all Visual Studio SKUs except for the Express Editions. Luckily for Express Edition users, the forthcoming Visual Studio 2010 release finally opens up the CRT sources to Express Edition users. If you are using an Express Edition of VS2008 or earlier, consider grabbing the VS2010 Express beta from here.

In any case, if you have the CRT source code, it is easy to track down the source for wcstombs_s and check to see if the terminating NULL is intended to be accounted for or not. Looking into wcstombs.c we discover this bit of text in the comment for the wcstombs_s function:

size_t n = maximum number of bytes to store in s (not including the terminating NULL)


Clearly, the terminating NULL is not meant to be included. This is as we suspected, but now we have verified it instead of blindly assuming that it would be the case. As security practitioners we should be careful not to make assumptions. Verify instead!

This documentation bug has been reported to Microsoft. With any luck it will get addressed prior to the VS 2010 release on March 22, 2010.

While looking over the CERT Secure C Coding Standard I noticed the following recommendation: ERR30-C. Set errno to zero before calling a library function known to set errno, and check errno only after the function returns a value indicating failure. CERT goes on to write, “[s]ome functions lack documentation regarding errno in the C99 standard.” They follow this up with an example for Windows: “[i]n this compliant solution, errno is not checked because fopen() makes no promise of setting it.” This would be fine, were it true. However, it is false. Let us take a closer look.

It is true that the symbol, errno, appears nowhere in the MSDN documentation for fopen. However, one need only look to fopen.c (included with all commercial Visual C implementations) to see that errno.h is #include'd and errno is indeed set for locked streams, bad names (e.g., empty string), et al.

The use of errno is not as robust in the case of Microsoft's fopen implementation as it is in the implementation on my NetBSD box, but that's not the point. The point is that CERT stated something was true based on documentation when in fact, it was not true. The lesson here is that one cannot simply rely on assumptions based on documentation, one must also look to the source to see what is happening.

In the case of Microsoft's C and secure C runtimes, the source code is available for you to look at, provided you have Visual Studio installed. (Caveat: you don't get the CRT source code if you install Visual C++ Express.) I found the code living on my box under Program Files at Microsoft Visual Studio 9.0\VC\crt\src.

Of course, if you're programming on Windows you should prefer fopen_s to fopen anyway. For the record, the MSDN documentation for fopen_s clearly states that it returns an errno_t, which is the Secure CRT's answer to errno.

Update: I just found out from a source inside the Visual Studio team at Microsoft that Visual Studio 2010 Beta 2's Express Edition SKU contains the CRT source code. That's good news. You can get more information on Visual Studio 2010 Beta 2 here, and you can download it here.

You can download the presentation here.

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

The banned.vim syntax plugin will highlight C function calls that have been banned by the SDL. It adds functionality to the existing C and C++ Vim syntax plugins. Banned APIs, such as strcpy and others, will appear visually in Vim as if they were errors. It is my hope that this extra attention will cause you to reconsider using the banned API and replace it instead with a safer alternative. Although many of these banned function calls are Windows-specific, there are quite a few that are also available in UNIX and should be avoided. Details on the APIs banned by Microsoft's SDL can be found on Microsoft's site.

Here's a screen shot of banned.vim in action. In this case we're editing str_cat.c, one of the entries from the 2008 SANS Awards for Finding Coding Books with Secure programming Flaws. Notice the banned APIs in the code below?

Installing banned.vim is easy. First, you need to know what your runtimepath is, which varies from operating system to operating system. If you don't know what your runtimepath is, check the Vim documentation. Second, create the directory structure after/syntax in your runtimepath directory if it doesn't already exist. Third, copy banned.vim into runtimepath/after/syntax as both c.vim and cpp.vim. That's all there is to installation. There is no need to edit your .vimrc or anything.

I would like to thank Rob Mooney for suggesting this plugin in the first place.

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.

I have found a few techniques that I would like to share to help smooth communication and help the professionals and non- profesionals to get their respective jobs done.

1. Talk slow. This one should be self evident. Discussing subject matter that is new or confusing to someone is only made more difficult if you talk fast. Listeners have no time to process the new ideas and are instead just trying to keep up.
2. Be a dictionary. Computer Security contains a vast array of concepts and domain specific jargon. In security it is often difficult to adjust terminology to an audience, so instead, try to gauge the audience and go back and explain or define the words, acronyms, or concepts that they may not be familiar with. The critical point here is to do it immediately after use rather than waiting until the end of the conversation. By that point, it is usually too late and the definition may not be properly associated with the item.
3. Ask questions. It is very important that you are constantly gauging your audiences comprehension. This does not mean using the Socratic method to lead them in their own exploration of ideas, but rather inquiry for the purposes of confirming that you have successfully conveyed meaning to them. Remember, that in almost all cases, incomprehension on their part is a failure on yours. Questions help to highlight to listeners what elements of the discussion you, yourself, consider important. Also, try asking questions from different angles. Asking oblique or tangentially related things can often spur a better understanding in the audience, just make sure it is not something that would appear out of left field to them.
4. Do not accept nods. Similar to #3, you need to be able to tell when people really understand and can follow what you are saying. I have found many times when a person would nod as I explained a specific security concept to them or spit back the exact language I used, but when I try to get them to describe the implications or rephrase in their own words, it is evident that they are still confused.
5. Reiterate. Repetition can be critical to ensuring that concepts "sink in". Note, though, that I used the word reiterate. The reason for this is that you should change the way you say it and words you use when repeating the concept or idea. This can be one of the trickiest techniques, because it is easy to over do it and cause more harm than help. I find it works best when sprinkled into a long conversation, especially if the conversation keeps getting sidetracked by definitions, clarifications, or completely external items.
6. Make lists. This is probably the favorite for most PMs out there. PMs love lists. There is nothing they want more than to break all this complicated, confusing security stuff into small, easily managable chunks. Lists also help people to take notes by calling out concepts that can be grouped or ordered together. A list of bullet points (even in a conversation) are usually more important than the text before or after. I am not and have never really been a PM, but I think this is part of he genius that makes a good PM. PMs usually have too many things to do and items to keep track of, the only way they can handle it all is to be insanely organized and maintain lists. Helping them or any other detail oriented note taker to do this makes your job easier as much as it does theirs. 
7. Clarify language. This is similar to #2, but is targeted at the way you discuss things rather that words you may use. Make sure relationsips between things are explicitly called out (ex. First a, second b rather than this…then that). Use active rather than passive forms of verbs and try to minimize wishy washy or otherwise indecisive language. Avoid implications, exaggerations, and make clear when somethin is a WAG (wild assed guess). This can be very challenging for people to do during a spoken conversation so I usually recommend you start by practicing over e-mail. Being careful and spending time picking out the right words and phrasing can double or triple the amount of time it takes to write an e-mail, however in the long run, the amount of time saved due to fewer misunderstandings and resulting errors will make it worth it.
8. Anticipate. Finally, try to think ahead. As a security professional, you know the processes and outcomes far better that the people you are working with do. Try to divine what might confuse, hinder, or block the people you are working with and try to provide them answers or solutions before the need them. Remember that in most cases you are not a teacher and they are not working with you to learn by trial and error. Sending them off with a hint and letting them waste time trying to discover things on their own is not how tehy should be handled. Instead, inform them, point them at learning resources, or provide a solution and spend time explaining the reasoning behind it. Do you have any that I have missed?

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

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.

WinHttpReceiveResponse in C++ will return FALSE if the certificate has one of the following errors:

WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED

Certification
revocation checking has been enabled, but the revocation check failed to verify
whether a certificate has been revoked. The server used to check for revocation
might be unreachable.

WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CERT

SSL certificate is invalid.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_REVOKED

SSL certificate was revoked.

WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA

The function is unfamiliar with the Certificate Authority that generated the server's certificate.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID

SSL certificate common name (host name field) is incorrect, for example, if you entered www.microsoft.com and the common name on the certificate says www.msn.com.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID

SSL certificate date that was received from the server is bad. The certificate is expired.

WINHTTP_CALLBACK_STATUS_FLAG_SECURITY_CHANNEL_ERROR

The application experienced an internal error loading the SSL libraries.

However, WinHttpReceiveResponse does not return these errors directly as a call to GetLastError() will only return ERROR_WINHTTP_SECURE_FAILURE if there is a problem with the server's certificate. You must use the CallBack WINHTTP_STATUS_CALLBACK to access the specific errors listed above.


public WINHTTP_STATUS_CALLBACK myOwnAsyncCallback( __in HINTERNET hInternet,
__in DWORD_PTR dwContext,
__in DWORD dwInternetStatus,
__in LPVOID lpvStatusInformation,
__in DWORD dwStatusInformationLength)
{
if (dwInternetStatus == WINHTTP_CALLBACK_STATUS_SECURE_FAILURE)
// We have a certificate issue but which one? Take action before each break. This function must be thread safe and reentrant.
switch(*(DWORD*)lpvStatusInformation)
{
case WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED:
break;
case WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CERT:
break;
case WINHTTP_CALLBACK_STATUS_FLAG_CERT_REVOKED:
break;
case WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA:
break;
case WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID:
break;
case WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID:
break;
case WINHTTP_CALLBACK_STATUS_FLAG_SECURITY_CHANNEL_ERROR:
break;
}
}
HINTERNET hSession = WinHttpOpen(L"A WinHTTP Example Program/1.0",
WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS, 0);
WINHTTP_STATUS_CALLBACK isCallback = WinHttpSetStatusCallback( hSession, WINHTTP_STATUS_CALLBACK)myOwnAsyncCallback,WINHTTP_CALLBACK_FLAG_SECURE_FAILURE,
NULL);
//The rest of your code including call WinHttpReceiveResponse


For more information see
http://msdn.microsoft.com/en-us/library/cc185684(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa383917(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa384266(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa384115(VS.85).aspx

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>


Here is my code for grep the way i like it. I just created a PS1 file and added it to my “bin” dir… which is just a directory mapped to my path variable for command line programs. Anyways this looks through code files only based on the $filetypes… handy.. really it is…

$searchstr = $args[0]
$searchdir = $args[1]

$filetypes = “*.cpp”, “*.hpp”, “*.c”, “*.h”, “*.cxx”, “*.hxx”, “*.cs”, “*.aspx”,”*.asmx”, “*.html”, “*.js”, “*.vbs”, “*.vb”, “*.xml”, “*.txt”

if($searchdir -eq “” )
{
$searchdir = “.\”
}

get-childitem $searchdir -include $filetypes -recurse | select-string -pattern $searchstr | Format-Table -property FileName, LineNumber, Line -Autosize

CTRL-I : brings up the favorites menu, this is useful on those pop-ups that dont have upper menus to enable right clicking for viewing source…

Bookmarklet for enabling right click: javascript:void(document.oncontextmenu=null)

Bookmarklelt for enabling the Firebug Lite console: http://remysharp.com/2007/03/13/firebug-in-ie-for-any-web-site/

Also another useful setting is setting in ie options that new windows open in tabs verse a pop up. This helps by
allowing you to quickly/easily access bookmarklets/plug-ins like ie dev bar.

The first takeaway is the importance of understanding and implementing the fundamentals. The exploit above occurs because of a NULL dereference triggered by an out of memory return by malloc(). I remember in my first C programming class when I was working with a partner an a project and he was trying to properly implement malloc(). I had already been using C for a few years and always checked the return of a function. I could not figure out why he was not checking to make sure sufficient memory had been allocated. He gave me the excuse that it would require a lot of code to check the return value and that since the data structure was small the allocation would fail. Nonsense, as I demonstrated by filling up the 640K of standard memory. He then argued that we would be better off implementing XMS or EMS to access the other 3MB of "high" memory, a silly argument if ever there was one.

When non-security professionals describe what hackers do they often say that hackers look for ways to bypass restrictions and go around roadblocks. This is a somewhat fair description, but what they may not know is that often hackers are merely taking advantage of mistakes or the faulty reasoning of programmers who tried to skip or work around something simple or basic that they felt would be too much work to implement properly. The original "hacks" were simply ways of getting things done quicker, easier, or more elegantly but sometimes there is a fundamental reason for doing things one way and the "hack" just gets you into hot water. Anyone who has ever picked up a C programming book and looked at the function info for malloc() knows that it is NOT guaranteed to return the memory requested. Obviously, it is a BAD idea to simply assume that it succeeded in allocating all the memory requested. Know your functions/methods and how to properly implement them.

The second takeaway for the average programmer is the need to integrate and leverage the latest in security functionality in your code from the ground up. What do I mean by this? Follow-up research on the exploit has shown that if DEP had been turned on and opted-in the exploit would not have worked. DEP marks portions of memory as NX (No Execute). Such areas in memory will trigger a processor fault if an attacker attempts to execute shellcode they have somehow loaded into such memory. Is DEP a panacea- No. But it provides a second layer of defense. Now you might say- DEP is a system setting that users or admins or Microsoft can turn on or off, there is nothing I can do as a programmer. This is not true. First of all, you need to write your application to make sure it works properly with DEP turned on. You need to test your application to verify this. You need to inform users so they know they can safely use DEP with your application.

A number of other features like ASLR (Address space layout randomization), /GS (canary based buffer overflow detection), etc. are provided now by Visual Studio and other compilers or by the latest versions of the Windows operating system. Developers should be building their code to use these basic security tools that are in most cases so easily integrated. None of these features can prevent all security threats, but there are many applications out there using outdated compilers or failing to implementeven the simplest of automated defenses for lack of awareness or a fear of performance degradation. To the former- browse through just a few of the numerous security respurce out there and then review your compiler/linkers security related flags; to the latter- given the massive code bloat in this object oriented development world compared with the (good) old days of hand tuned assembly in a COM file what is a one or two percent more overhead .

The MSDN docs don't really have the answer. A cursory reading of the “security enhancements in the CRT” page as well as others may lead you to believe that format string vulnerabilities are a thing of the past. One example shows a call to 'sprintf_s(buf,_countof(buf), “%s”,NULL)' and remarks that this results in a runtime error. Looks like they do some kind runtime-validation. However, unless they added magic pixie dust to their compiler that sends cosmic rays from outer space to fix up malicious format strings at runtime, it isn't really possible to have strongly-typed printf-style format strings in C.

So let's investigate how far the parameter validation will get you. Here is a little sample program I wrote to send nasty format strings to sprintf_s:


#include
#define OUT_SIZE 0x1000
int main(int argc, char** argv) {
char * out = new char[OUT_SIZE];
sprintf_s(out, OUT_SIZE, OUT_SIZE, argv[1]);
printf("%s\n", out);
return 0;
}


So let's try this with a couple of format strings:

Input: "%s"
Output: Error: ("Buffer too small", 0)

So far so good… but buffer too small?
What about just dumping stack variables?

Input: "%p %p %p %p %p %p"
Output: 00344FD0 00344FD0 0012FFB8 004019D3 00000002 00343728

Interesting… so looks like this type checking is not so robust after all. We've just dumped the stack.
Let's see if we can crash the program. Looks like there is a 0000002 on the stack… that probably won't appreciate being dereferenced.

Input: "%p %p %p %p %s"

Ok so we can crash the program. Can we do anything more interesting?
Let's say there was some interesting data somewhere in the program. To simulate this, I'll put my bank account number on the stack with the following line of code at the beginning of “main” “volatile char * bankAccount = “Account#123-456-7890″;” (the volatile helps convince the compiler not to throw it away since I don't use it).

Now when I call the function with the right input, I can dump my bank account number:

Input: test.exe "%p %s"
Output: 00344FD0 Account#123-456-7890 00344FD0


Ok but nobody really cares about Denial-of-service and Information-disclosure. Those are sooooo pri-3. Can we use take over the machine? As everyone knows, the hacker's favorite format string character is '%n'. '%n' writes the number of bytes written so far to the param from the stack. Let's try a '%n':

Input: test.exe "%p %n"
Output: Error: (state != ST_INVALID)


Blast! Foiled! It turns out Microsoft decided that %n was too much power, and that we mere mortals couldn't handle it. Good for them. There is an override, but it turns out to not be available using the Safe CRT. The moral of the story? The safe crt is a wonderful and powerful tool to help prevent buffer overruns. But there is no excuse for letting a user control a format string.

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.

ASP.Net offers two methods of tracking session state- URL or cookie. URL based methods are used in cases where it is expected that some users will have disabled cookies and still need a server-side session to track state. This has become less common as more and more of the web relies on cookies. In addition the URLs look ugly and are considered unacceptableby many usability gurus.

The second method is a cookie sent as a header to the server. This cookie is sent over HTTP or HTTPS and is used by ASP.net to link an incoming request to the server-side state. So you are running your site on SSL, where is the problem? By default, the SessionID is just a cookie the browser sends it when making any response to the domain. If you go to https://yourapp/application, you will be sent a cookie over SSL that I cannot see. If I e-mail you a link to click for http://yourapp/application, I will see the cookie sent over HTTP as long as your server responds on port 80.

What you want to do is set the 'secure' flag on the cookie. You have many options for doing this: adsutil set w3svc/1/AspKeepSessionIDSecure 1 will tell ASP.net to mark the session cookie as Secure. When a cookie is marked as secure it will not be sent by the web browser unless the connection to the server is over https. You must be aware that the user will now have no session state if they browse to the site using http your application will need to redirect http requests to https in order to access the session state.

Is the ASP.Net session ID the only cookie I can protect in this way? No. You can use a web.config configuration to customize the security of all your cookies (http://msdn2.microsoft.com/en-us/library/ms228262.aspx). You will also be able to set cookies to be HttpOnly which adds its own element of security and is supported by newer browsers.

Finally, you can set both the secure flag and the HttpOnly flag for any other cookies you set programmatically through ASP.Net with http://msdn2.microsoft.com/en-us/library/ms228262.aspx.

A few other things to remember-

ASP.Net sessions expire after 20 minutes UNLESS a new request is seen. Otherwise they can remain until the server is recycled.

SessionIDs can be reused. When stored as a cookie the sessionID will go to any machine hosting the same parent domain. They will NOT have the server-side state though unless some clustering or back-end logic handles sharing state across servers. If you want to ensure that reuse does not happen, rather than using Session.Abandon you must overwrite the ASP.Net session cookie with an empty cookie value. To properly end a session or force a user to start a new one use Session.Abandon.

For more information checkout – http://msdn2.microsoft.com/en-us/library/ms972969.aspx

The CERT/Coordination Center at the Software Engineering Institute at Carnegie Mellon University has lead a community effort to develop secure coding standards for the C and C++ programming languages. This work is being performed on the secure coding wiki at
www.securecoding.cert.org. In particular, we have made significant
progress on the CERT C Programming Language Secure Coding Standard since work first begun over a year and half ago and our progress as been reviewed by the ISO/IEC WG14 international standardization working group for the programming language C at both the London and Kona meetings.

This has probably been a long time coming, and I will be interested to see what, if any, review tools come out to compare a code base against the standard.

Links:

C – https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secu…

C++ – https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageI…

1. "We may use logs to analyze trends, administer the Site, track user movement in the aggregate, and gather broad demographic information for aggregate use. We may associate this information with your Personal Information to resolve technical issues and support security for our users."

What exactly is the company gathering in those logs? Who has access to these logs? Do third parties analyze the data and if so what do they do with it?

2. "We may share, in aggregate form, information collected from surveys with advertisers, partners, affiliates and the general public, but will not share survey information containing personally identifiable information with any third party without your prior consent."

Make darn well sure you understand how and where you give consent to allowing PII to third party sites. Does the company use auto opt-ins, do you opt-out by default, is it a combination or are you not even given the chance to opt-out?

3. "We link cookies to your unique registration number and use them to enhance and personalize your experience on the Site. We also use cookies to deliver information and fresh content specific to your interests."

There is no mention of third party cookies… are third party cookies used and if so, how does that affect your privacy?

4. “We only share Your Information with others when we have your permission or under the types of circumstances described in this Privacy Policy.”

Read the rest of the Privacy Policy carefully to understand the circumstances where your information could be shared with others

5. “Upon removal of membership from the Site, we may retain Your Information for a period of time in our internal databases and systems.”

Not a particularly specific timeframe… how long? For what purpose is this information being retained?

6. “You should be aware that despite our efforts, factors beyond our control may result in disclosure of Your Information. Accordingly, we are not in a position to guarantee that Your Information will be secure under all circumstances.”

So what circumstances are they responsible for? Is that information outlined specifically or is this a carte blanche for deniability? What exactly is a factor beyond their control? Be skeptical and ask questions.

7.”We may update this policy from time to time as our information practices are modified or changed. It is strongly suggested that you regularly visit this privacy policy for updates to its contents.”

Better policy would dictate the company notifies its customers whenever a change to the policy is made.

8. “We may, without your consent, access and disclose Your Information, any communications sent or received by you, and any other information that we may have about you or your account if…”

For what? Requests by the government? Actions that appear illegal? A threat is made? How comfortable are you with who they detailed could request or be provided this information? Is there any ambiguity to the list? Is there actually a list provided?

9. “We may share Your Information with third parties that are subject to privacy policies that protect your personally identifiable information from disclosure to other third parties in a similar manner to our privacy policy.”

What does a similar manner mean? If they cannot disclose the exact privacy policy these third parties are using, you cannot be assured they are using your information in a manner you would agree to.

10. We and our third party advertisers may use web beacons to compile aggregate statistics about which advertisements and promotions users have seen and how users responded to them.

Beacons can also be referred to as web bugs, 1×1 gifs, clear gifs, tracking bugs, and tracking pixels. Are these beacons associated to individuals and how does the company handle this information? As mentioned before, are third parties beholden to a privacy policy and if so, what is it?

It's pretty simple… always read the privacy policy. Be skeptical, ask questions, read between the lines and walk away from a site that sinks below your "I don't feel so good about what this company is all about" threshold. Be wary of privacy policies and terms of use that make you jump around from one document to another or from one paragraph to another in a non linear manner. Refuse to accept ambiguity. Write to the company. An electronics firm in Brooklyn selling a camera for 1/2 of what everyone else is selling it for is probably performing a bait and switch and probably doesn't care about your PII… use your brain. Remember, you CAN fight back with your wallet. You don't like how the company protects your data then don't reward them with your patronage and let others know.

Of course the Intermediate Language (IL) can be looked at with it's rich meta data with ILDASM. It's kind of odd looking at “machine” intructions for a virtual machine. As far as I can tell there's close to no documentation about their OP codes or a language reference. The one (and only) great book I've found is …Expert .NET 2.0 IL Assembler
by Serge Lidin, S. Lidin

The much easier way to wander around is Reflector. You'll want the file disassembler add-in (let's you save all the files in an assembly).

I've wandered around in the framework a good deal and for the most part it isn't ….mmmmm…. productive. Some beanhead professor once upon a time decided that everything possible should be private. I'm not sure what this accomplishes except that it kills all kinds of code reuse. For example you want the listbox control to handle hotkeys or whatever just a tad differently for your application. You should just be able to overload the “broken” part of .Net. No can do, private. Don't get me wrong, on occasion you can redo some function. You borrow the code in Reflector, modify the part that doesn't work for you, and then you have to figure out how to get it's 4 uses of private calls fixed. Copy the whole object you say! Good idea. Now you have 4 other internal objects to copy. Lame lame lame. It's a big ole spider web.

The best cheat is to add yourself a CustomAttribute listing your assembly as a a “friend”. Of course this makes the signature invalid, so not exactly distributable. You could really cheat and sign your own version! Ahah. Who knows what's next? Mmmhmm, you have to drag all the other Microsoft Internal Friends with you. It's a tar baby I tell ya.

Who want's to talk about COM and application integration now? Makes you love those little itty bitty tools that don't depend on a thing. I wish thee were more.

Unfortunately it went missing over a year ago and has not returned. The best alternative I have found is using the IANA list at http://www.iana.org/assignments/port-numbers and doing a manual search. Not ideal, but it works. Maybe we will put a little database up on this site in the future.

You chose the search engine the Privacy Finder will use; put your search term in the dialog box, select your Privacy Preference Threshold Level and the results of the search are provided. If the search comes back with a website that has a P3P compliant privacy policy, a “privacy meter” is shown. The number of green boxes in the “privacy meter” shows how closely the privacy policy matches up with the privacy preference level set when doing the search. A link next to the search results brings another page neatly and succinctly showing why the privacy policy does or does not match the preference level and another link to the sites entire policy.

The P3P standard has been around since 2002, but it hasn't really caught on with the web community at large for a number of reasons:

-Some argue it's too complex
-Non code compliance does not necessarily mean poor privacy standards for a company
-There are currently no laws which require a company to comply specifically with a privacy policy
-Poor support from the web browser community

These issues do not remove the need for companies to provide clearer explanations of how it handles a customer’s information and P3P, while not perfect certainly is better than no standard. What privacy finder does is present the compliant privacy policy to the consumer in an easy to read and standardized output, giving consumers more information to make more informed choices.

For more information:
http://www.privacyfinder.org/
http://www.w3.org/P3P/
http://cups.cs.cmu.edu/

How so?

Well, Tivo now offers Amazon Unbox downloads, Yahoo Weather/Traffic, etc. All of these services require you to store your credentials on the device or on Tivo's website. Imagine what might happen if an attacker can break into the device and gather such information. With an Amazon account an attacker has access to any stored credit cards for purchases on the site. Even if an attacker cannot hack into your private network and break into the Tivo, what happens when the Tivo is put into the trash at the end of its life?

Here's what your compiler will give you.


12>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration
12> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\stdio.h(350) : see declaration of '_vsnprintf'
12>Generating Code...


Now this looks like a no brainer, I mean the two declarations are 8 lines apart! So I stare for a while. (Looks the same to me). Hmmmm. Then I try following a few MACRO's, often futile if you don't have browser symbols built yet. Perhaps I have some crazy path with my includes!? I only have 12 SDKs or something installed. So I turn on /showIncludes (how did it take 20yrs to add this option?) Looks good again…..

Crap time for the Big Guns — If you love MACRO programming you know what's next. Turn on the C++ listing output. The listing output is what the compiler really compiles are the preprocessor has had it's merry way with the code. 2MB of the finest night time reading you'll ever find. Per source file of course. I was kinda dreading trying to find the function after all it's beautification had been stripped.

I've read a lot of code over the years. I'm not even sure what this is…much less what it would preprocess out to.


__DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_ARGLIST_EX(int, __RETURN_POLICY_SAME, _CRTIMP, _snprintf, _vsnprintf, _Pre_notnull_ _Post_maybez_ char, _Out_cap_(_Count) _Post_maybez_, char, _Dest, _In_ size_t, _Count, _In_z_ _Printf_format_string_ const char *, _Format)


I digress…

It just compiles when you turn on the listing output.

I'll type it more slowly this time, in case that didn't sink in. The compiler switch, that just spits out more information, changed things just enough to have everything compile. Neato, unless that sort of thing keeps you up at night.

btw, the fix, if you've been reading this far, is to not #define vsnprintf in _your_ project. The CRT must redefine it once or thrice.

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

Command and Control Structures in Malware: From Handler/Agent to P2P

Check it out:
Analysis of the Storm and Nugache Trojans: P2P Is Here

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.

If you try and use this class or function you get this result.


c:\dev\test\private test.cs(10,9) : error CS0122: 'Microsoft.CLRAdmin.Fusion' is inaccessible due to its protection level


Turns out using this function is pretty easy in theory. .Net only checks permissions at link time. You could do get around this the hard way by using ILAsm, or Reflection in C#.

Here's how you would do this using Reflection.

Well that just opens up about a million possibilities. Just try and “fix” one class from the ASP.NET framework and you have to drag in 12 million interfaces. Now you are set, just use the same one's that it was using. This is going to save me tons of time. There's no way I'm writing a million Reflection proxy interfaces. Nevermind the fact that you can just call the interface using IL. There just has to be a good way to do this from C#. Worse case we could lie/cheat to the compiler.

The C# team has added a nice Attribute for us to do this.

[InternalsVisibleTo("AndrewsAssembly, PublicKeyToken=0b00fde735121dcc")]

You can read up on it viewing InternalsVisibleToAttribute.

So ILDasm System.Web.dll, or your favorite assembly, and recompile adding this CustomAttribute. Compile your assembly and you are off and running.

Here's a view from Lutz Roeder's Reflector of my test app using an internal System.Web enum.

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/

Vance Morrison's Weblog

Vance Morrison is currently an Architect on the .NET Runtime Team, specializing in performance issues with the runtime or managed code in general.

Digging deeper into managed code with Visual Studio: Using SOS

I have let my blog laps for too long.    I am back to blogging.   I realized reciently that we have simply not written down many interesting facts about how the runtime actually works.  I want to fix this.   Coming up in future blogs I am going to be doing a bit of a 'architectural overview' which describe the differences between managed and unmanaged code, but before I do that I realized that I have not even finished a blog entry I started in March.

In my blog How to use Visual Studio to investigate code generation questions in managed code, I talk about the how to configure Visual Studio so that you can actually look at optimized code in the debugger (which sadly is not as trivial as you would like), and showed how to look at the disassembly of managed code.    Unfortunately manage code is hard to read without a guide, and so in this blog I will show you some very useful tips for reading managed assembly code.

In this blog entry I will show you the instructions ACTUALLY need to get executed to do something as simple as assigning a string to field of a class. Note that I am assuming a familiarity with X86 assembly code. If you are the type who never wants to read assembly code, you should stop reading now, because most of this blog is a step-by-step explanation of it.

I have attached the file InspectingManageCode.zip, which contains a (trivial), project that I used for this example.  You are STRONLY encouraged to open it (you can browse it the main file is Program.cs).  Copy the files (simply drag the 'InspectingManagedCode directory inside the ZIP to a directory of your choosing), launch the InspecingManagedCode.sln file and run the example.   While the project is already set to build and run optimized code, you will still need to turn off ‘just my code’ and turn on JIT optimization as described in my previous blog to follow along.

The code in the attached example is pretty trivial.
class Program
{
    string myString;
    private Program()
    {
        myString = “foo”;
    }
    static void Main(string[] args)
    {
        Program p = new Program();
   }
}

If you were to follow the instructions in the previous blog to see what code was generated for the body of ‘Main’ you would find the following code.

00000000  push       esi
00000001  mov        ecx,9181F4h
00000006  call       FFCB1264
0000000b  mov        esi,eax
0000000d  mov         eax,dword ptr ds:[0227307Ch]
00000013  lea         edx,[esi+4]
00000016  call        79222B78
0000001b  pop         esi
0000001c  ret

At first glance this code has little similarity to the source code: the original source has a call the constructor ‘Program’ and the assembly code has two calls to strange hex addresses.  There are also references to magical numbers like 9181F4H and 0227307CH.   In this case the disassembly has not proven to be very valuable.    What can we do?   

Sadly if we try to peer into these CALL instructions we cannot, the debugger comes back with the very unhelpful message ‘There is no code at the specified location’.   Actually Visual Studio is LIEING to you. There really is code there, but it simply will not show you. I will show you techniques to get around this.

The key to unlocking mysteries of managed code, is a debug helper called SOS.DLL (it is a dll that is shipped with the runtime). The DLL is what is called a ‘debugger extension’. Basically it implements functionality that is useful in a debugger implementing
functions that are useful for debugging code associated with it (in this case the
runtime).   Other bloggers have
also commented on the use of this DLL (do a web search of SOS.DLL for more).

In Visual Studio, you load SOS.DLL by
opening the immediate window (Ctrl-D I) and typing

.load SOS.dll

If you do this you may get the message

SOS not available while Managed only debugging. 
To load SOS, enable unmanaged debugging in your project properties.

This message is actually reasonably
helpful.  By stopping
the debugger (Shift F5) going to Solution Explorer (Right hand pane), right clicking
on the InspectingManagedCode project file, and selecting Properties, you will get
the properties pane for the project. 
If you select the ‘Debug’ tab on the left side you will find 3 check boxes
at the bottom, one of which is labeled ‘Enable unmanaged code debugging’  If you check this, you put the debugger
into a mode where it can debug both mananged and unmanaged code, (which means you
can then use SOS.DLL).   
I have already done this on the InspectingManagedCode project, but you will
have to repeat this any time you need to use SOS.
  (Sadly the instructions for setting the debugger mode are different
for C++).    Note that running
the debugger to debug both managed and unmanaged code will slow the debugger down
a bit (it loads the symbols for all the unmanaged DLLS), so you probably only want
do this on projects like this one where you want to use SOS.DLL. 

Now you should be able to set a breakpoint
in Main(), run the program (F5), and go to the immediate window (CTRL-D I) and type

.load SOS.dll

And get the message

extension C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded.

If you are curious the SOS.DLL has reasonably
good help, if you type the command

!Help

It will give you a list of commands,
and you can get help on individual commands by specifying the name eg.

!Help u

It will give you help on the ‘u’ (unassembled)
command.   
All SOS commands need to be prefixed by a ! character so that the Visual Studio
Debugger knows that it is an SOS command and not an immediate value to be interpreted
(the normal meaning of text typed in the immediate window).

The unassemble SOS command is the command
we are interested in.  
It will disassemble a managed routine, but do a much better job than Visual Studio
presently does.  
Unfortunately, we need the address of the routine we want disassemble, and Visual
Studio goes to some length to hide this information. 
If you look at the disassembly for the code (CTRL-ALT-D), you will see that
the address of the routine is never given, only the offset from the beginning of
the method. 

The way around this is to use the ‘Registers
window’ (Ctrl-D R). 
I happen to like to put this window just above the immediate window and shrink it
so that only the two lines that actually show values are showing. 
 One of the registers is ‘EIP’ which stands for Extended Instruction
Pointer’.  It is
the address of the current instruction pointer.
  In my particular invokaction EIP has the value of 00DE0071, so
I can do the command

!u 00DE0071

Which will disassemble the ENTIRE routine
that the address 00DE0071 lives in. 
I like to right click in the immediate window and select ‘Clear All’ before
I do this so the only thing in that window is the disassembly.   On my machine I get the result

Normal JIT generated code

Program.Main(System.String[])

Begin 00de0070, size 1d

00DE0070 56      
        push
      
esi

>>> 00DE0071 B904309100
      mov
        ecx,913004h

00DE0076 E8A11FB2FF    
  call    
   0090201C (JitHelp: CORINFO_HELP_NEWSFAST)

00DE007B 8BF0      
      mov
        esi,eax

00DE007D 8B053C302B02    
mov      
  eax,dword ptr ds:[022B303Ch]

00DE0083 8D5604      
    lea  
      edx,[esi+4]

00DE0086 E8A5380979    
  call    
   79E73930

00DE008B 5E      
        pop
        esi

00DE008C C3      
        ret

It is not unlike the version the Visual
Studio produced, but there are differences

1.     
You will note that the ‘call instruction
is annoted with ‘JitHelp: CORINFO_HELP_NEWFAST’, which makes it at least a bit clearer
that this helper is used to create a New object (and is the fast version, we have
many variations).

2.     
It printed the whole routine that 00DE0071
lives in and prints a >>> 
on the instruction corresponding to the 00DE0071 address. 

3.     
While it did not print the name for
the ‘call 79E73930’, notice that the HEX value is different than the value in the
Visual Studio Disassembly (79222B78). 
The value in the 
VS disassembly is simply WRONG (it is bug no one bothered to fix). 

So let’s take a look at the first two
instructions.

00DE0071 B904309100    
  mov    
    ecx,913004h

00DE0076 E8A11FB2FF    
  call    
   0090201C (JitHelp: CORINFO_HELP_NEWSFAST)

I mentioned that this helper call creates
a new object from the GC heap. To do so it needs to know that type of the object
to be created. This is what the magic number 913004 does.  Internally in the runtime types are
described by a structure called a MethodTable, and 913004 is the address of the
MethodTable to create. 
We can find out what type 913004 corresponds to by using the !DumpMT (dump Method
Table) SOS command. 

!DumpMT 913004h

Produces the output

EClass: 00911254

Module: 00912c14

Name: Program

mdToken: 02000002 
(C:\Documents and Settings\vancem\My Documents\Visual Studio 2005\Projects\InspectingManagedCode\bin\Release\InspectingManagedCode.exe)

BaseSize: 0xc

ComponentSize: 0×0

Number of IFaces in IFaceMap: 0

Slots in VTable: 6

The only output of this that is interesting
at this point is the ‘Name’ field, which as you can see, indicates that 913004 cooresponds
to the ‘Program’ type.  
Thus these first two instructions create a program object.   This program object comes back from
the helper with all its fields zeroed, so the next instructions in the program are
the body of the constructor (the Program() constructor has been inlined into the
body of Main(). 

The next instructions

00DE007B 8BF0      
      mov
        esi,eax

00DE007D 8B053C302B02    
mov      
  eax,dword ptr ds:[022B303Ch]

00DE0083 8D5604      
    lea  
      edx,[esi+4]

00DE0086 E8A5380979    
  call    
   79E73930

Basically implement the statement ‘myString
= “foo”’ The helper returns a pointer into the
uninitialized object in the EAX register. 
The mov saves this into the ESI register. 
EAX is then loaded with what is at the address 022B303Ch.  This happens to be the string “foo”
(more on how it go there in a later blog).
  You can confirm this by going to the disassembly code, setting
a breakpoing right after the eax,dword ptr ds:[022B303Ch] instruction and looking
at the value of the EAX register in the ‘registers’ window. 
 In my example it happens to be the value 012B1D44.   You can then use the command

!DumpObj 012B1D44

Which will dump the managed object at
this address.  This
will print .

DumpObj 012B1D44

Name: System.String

MethodTable: 790fa3e0

EEClass: 790fa340

Size: 24(0×18) bytes

 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

String: foo

Fields:

     
MT    Field   Offset                
Type VT    
Attr    Value
Name

790fed1c  4000096       
4        
System.Int32  0
instance       
4 m_arrayLength

790fed1c  4000097       
8        
System.Int32  0
instance       
3 m_stringLength

790fbefc  4000098       
c         
System.Char 
0 instance      
66 m_firstChar

790fa3e0  4000099       10       
System.String  0   shared   static Empty

    >>
Domain:Value  0014c550:790d6584
<<

79124670  400009a       14       
System.Char[]  0   shared   static WhitespaceChars

    >>
Domain:Value  0014c550:012b186c
<< Basically

 Again, most of the output is uninteresting at this point, except
the Name field (which says its a string), and the ‘String’ field (which shows the
string value is ‘foo’). 
So we have confirmed that this instruction loads up the address of the ‘foo’ string
into the EAX register. 
 What is left is

00DE0083 8D5604      
    lea  
      edx,[esi+4]

00DE0086 E8A5380979    
  call    
   79E73930

The first instruction ‘LEA’ may not
be familiar to you. 
It is Load Effective Address (LEA). 
Basically it works just like a MOV instruction, but instead of moving what
was AT the memory specified, it loads the ADDRESS of the memory.   Another way of looking at this is to
imagine a MOV instruction with the [] dropped (which represent memory fetching).  Thus

00DE0083 8D5604      
    lea  
      edx,[esi+4]

Can be thought of as

00DE0083 8D5604      
    mov  
      edx, esi+4

That is it adds 4 to ESI and places
it in EDX.   Now
remember ESI points at our newly created ‘Program’ object.   We could find out all the fields of
this object by dumping it, 
In my debugger ESI has the value of 012B1D5C so I can do

!DumpObj 012B1D5C

And get

Name: Program

MethodTable: 00913004

EEClass: 00911254

Size: 12(0xc) bytes

 (C:\Documents and
Settings\vancem\My Documents\Visual Studio 2005\Projects\InspectingManagedCode\bin\Release\InspectingManagedCode.exe)

Fields:

     
MT    Field   Offset                
Type VT    
Attr    Value
Name

790fa3e0  4000001      
 4    
   System.String 
0 instance 00000000 myString

Which tells us that ESI points at a
‘Program’ object and that the total size of the object is 12 (more on that in a
later blog), and that at offset 4 there is a field calls ‘myString’ of type System.String
that currently has the value of 0 (null).
 

So now we can make a pretty good guess
that the LEA instruction is setting EDX to the address of the ‘myString’ field of
the program object. 
EAX has been set to the ‘Foo’ String, and next comes the mysterious

00DE0086 E8A5380979    
  call    
   79E73930

Ideally SOS would have annotated this
helper.   It is
what we call a ‘WriteBarrier’.  
More on exactly what a write barrier is later,
 but for now the important thing to know is that ALL updates to
OBJECT REFERENCES that live in the GC heap need to be done by calling a write barrier
helper.   
Since the Program object lives in the heap, and we are updating a object reference
pointer inside it we need to use the write barrier.
 

The runtime actually has many write
barriers.  All the
write barriers have an unusual calling convention. 
They all take the address to be updated in the EDX register.   Then depending on the write barrier,
they take the value to update in some other register (this particular write barrier
is the most commonly used, and takes its argument in the EAX register).    Logically all the write barrier
does is do (*EDX = EAX) 
(that is update what EDX points at to be the value in EAX).

That is about it for this example  The only instructions
 we did not cover
are the PUSH ESI, and POP ESI at the beginning and end of the routine.  As anyone who deals with assembly code
this is simply saving and restoring ESI since we used it in the routine itself. 

To recap here are the instructions that
actually got executed in the ‘Main’ program and what they do. 

push    
   esi      
                       
         // save ESI
mov         ecx,913004h
                      
// ECX = MethodTable(Program)
call        0090201C
                       
     // EAX = New Object (Program)
mov         esi,eax
                       
        // ESI = this (new object)
mov         eax,dword ptr ds:[022B303Ch]      // EAX = “foo”
lea         edx,[esi+4]
                       
    // EDX = &this.myString
call        79E73930
                       
     // this.myString = EAX (“foo”)
pop         esi
                       
                // restore ESI
ret          
                       
                    
// return.

We just understood very deaply EXACTLY
what happens when a particular piece of managed code executes. 
 Hopefully that wasn’t so bad.
    Next time we will dig a bit into this WriteBarrier
is and exactly what it does (how expensive is it?).
  We will also dig into exactly what went on inside the ‘New’ helper.    In later blogs I will go into
how exactly other run time features get converted to native code. 

I hope you are enjoying this peek under
the hood of the .NET Runtime. 

Published Tuesday, September 05, 2006 7:55 PM by vancem

Filed under: Tools

Attachment(s): InspectingManagedCode.zip

Comments

barrkel said:

Great info! Thanks.

BTW, when using windbg + sos to debug, what breakpoint (native: bp / bu) is best
to set in order to use managed breakpoints (thus both !name2ee and !bpmd probably
needed)? With a breakpoint on loading of mscorwks or calling of various CLR functions,
when is the CLR booted up enough so that !name2ee etc. can work?

September 6, 2006 4:14 AM

vancem said:

The subject of using SOS in windbg will be the subject of a future blog, however,
I can quickly answer your question.    

The !bpmd (Breakpoint MethodDescriptor), is a command that will set a breakpoint
on a managed method by name.   For example in the example the command

   !bpmd  InspectingManagedCode.exe Program.Main

Will set a breakpoint in the ‘Main’ routine of the example program in the ZIP file.
  Note that UNLIKE the !name2ee SOS command (which looks up a method, or class
by name), the method being referenced in the !BPMD command does NOT need to be loaded
to work (it sets a ‘deferred’ breakpoint).

However to use ANY SOS command, you need to load SOS, and it turns out that SOS
needs the .NET runtime dlls ‘mscorwks.dll’ to be loaded before it can load.  
There are a variety of techniques you can use.    The one I use is

   bu mscorwks!EEStartup

This sets a breakpoint at the ‘EEStartup’ method in the .NET runtime DLL ‘mscorwks.
  When this breakpoint hits you can do the command

   .loadby sos mscorwks

Which tells windbg to load the sos.dll by searching the in the directory where mscorwks
lives.  Once loaded you can execute a ! bpmd  command.

Finally if you need !name2ee to work and the module is not yet loaded, you should
set a breakpoint (using !bpmd  command), in the module of interest, run to
that breakpoint (now it is loaded), and then do the !name2ee command.  

September 6, 2006 12:46 PM

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.