Archive for the ‘Code Review’ Category

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

February 18th, 2010 by John Hernandez

Renaming parts of the assembly.

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.

View Code CSHARP
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);
}

Tags: , , ,
Posted in Code Review, Debugging, Development, Malware, Nebulous, Reverse Engineering | 1 Comment »

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC

November 23rd, 2009 by Chris Weber

Casaba had the opportunity to contribute to a new Microsoft paper regarding ASP.NET MVC security. It's online through the SDL pages, and here's the paper's direct link. A short summary of the paper follows.

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.

Tags: ,
Posted in Code Review, Development | No Comments »

useUnsafeHeaderParsing = what?

June 5th, 2008 by Chris Weber

As software security people we usually like input restrictions to be tight. With .Net's HttpWebRequestElement.UseUnsafeHeaderParsing Property you can loosen up the way HTTP requests get parsed.

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>

Tags: ,
Posted in Code Review, Security Testing | No Comments »

Handling Unicode when marshalling from .Net to a platform invoke

April 22nd, 2008 by Chris Weber

By default, the .Net runtime will marshall a string (and files in a value type) as a LPStr to a platform invoke (p/invoke) function. By default the .Net framework and runtime handles strings as UTF-16. That's two bytes representing a single Unicode 'code point', and more familiar, a single character. An LPStr on the other hand, is an ANSI character, so in order to convert, the runtime will perform a best-fit conversion to the classic windows-1252 code page. This conversion is well-documented here:

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.

Tags:
Posted in Code Review, Security Testing, Unicode | No Comments »

Open redirects – what’s the problem?

March 2nd, 2008 by Chris Weber

Been getting this question a bit lately. First off, what's an open redirect? It's a function in your application which sends the user to some other location. The redirect could be a response from the server, such as an HTTP 301 or 302 response code, or a META redirect. The redirect can be delivered in several forms, the important part is that when an attacker can control the redirect location, they can exploit it for nefarious purposes – usually this means spam or phishing attacks.

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.

Tags:
Posted in Code Review, Security Testing | No Comments »