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

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.

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/

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!

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!

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

Unfortunately CodePlex went down today, even with Microsoft's new release of !exploitable at CanSecWest. Anyhow we're working hard to to add new checks to Watcher and reduce false positives in existing ones. So please grab Watcher from Codeplex and send us any feedback you want.

Go get Watcher.

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

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.

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?

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/

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.

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.