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!

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!

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

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.

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

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

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