Re: ASP.Net vulnerability

From: Russ (Russ.Cooper_at_RC.ON.CA)
Date: 10/08/04

  • Next message: Drew Copley: "Re: Disclosure policy in Re: RealPlayer vulnerabilities" 
    Date:         Fri, 8 Oct 2004 10:15:56 -0400
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

    In addition to Mark Burnett's excellent message, here are a couple of additional thoughts/observations/comments.

    1. Determining what is vulnerable is still a contentious issue. Granted, Microsoft has stated that "all versions of ASP.Net could be affected." Unfortunately, they have not addressed suggestions being commonly made outside of MS, such as using URLScan, or IIS 6.0's built-in canonicalization handling routines.

    It certainly seems to me that either should effectively prevent exploitation of this vulnerability.

    That said, the fact that Microsoft is NOT recommending that either of these be used as a workaround strongly suggests they are not effective. This raises a rather huge question...WHY NOT?? The commonly accepted functionality of both makes one believe they should intercept the call prior to ASP.Net receiving it, but if that's not the case, we need to know that.

    Microsoft: Please revise your currently available documentation on this issue to state clearly whether URLScan and IIS 6.0's default or configurable options prevent exploitation. If they do not, please provide a roadmap of the processing of a URL delivered to an IIS box with ASP.Net installed to show why they cannot prevent exploitation.

    2. Just in case it wasn't clear from Mark's message, Microsoft have created an additional workaround, beyond the code snippet they suggested you put in your global.asax. This additional workaround is an HTTP Module which operates at the machine level to correctly parse URLs (or more accurately, to correct this current parsing error) being handled by ASP.Net before anything else. The major difference between this and the code snippet is that this HTTP Module does not require you to edit your files and operates against all sites on the machine. Note in the KB article that your site's configuration might make this workaround ineffective.

    3. Barry Dorrans astutely points out;
    -----
    If you're not using authenication you don't need to worry just yet.

    Also, if you're confirming the user's Security Principal and Identity (WindowsPrincipal, FormsIdentity) via code, or are using a custom Principal your code will catch this problem even if ASP.NET Form's Authentication's AuthorizationModule didn't. Blindly checking if a user is authorised and then not checking and working with an actual identity is not a good idea anyway, for any web development environment
    -----
    <Editor's Note: Regarding not needing to worry if you're not using ASP.Net authorization, this is because the current discussions have all been about the canonicalization error being applied to accessing a secured page. Other use of the canonicalization error might lead to other forms of exploitation.>

    4. Adam Tuliper offered a link to a decent blog on the issue;
    -----
    <http://dotnetjunkies.com/WebLog/richard.dudley/archive/2004/10/06/27788.aspx>
    -----

    5. Bil Corry added;
    -----
    I've found the freeware IISShield to be very handy to prevent these types of exploits:

    <http://www.kodeit.org/products/iisshield/default.htm>

    While I can't speak to this specific vulnerability in ASP.NET, I'm wondering if the "failonrecanonurlchange" might prevent it:

    <http://www.kodeit.org/products/iisshield/config.htm#failonrecanonurlchange>

    And FWIW, here's a comparison to IISSheild to MS URLScan:

    <http://www.kodeit.org/products/iisshield/compare.htm>
    -----
    <Editor's Note: Again, as with URLScan and IIS 6.0, a tool such as IISShield may or may not intercept the URL before ASP.Net sees it. Maybe the folks at KodeIT can confirm whether they see the URL before ASP.Net?>

    6. Ben Sisco asked;
    -----
    Having noted that ASP.NET is a requirement for Exchange 2K3 on Win2K3, and the existence of a global.asax file in the root of the OMA (Outlook Mobile Access) site. Does that infer the vulnerability can be used to access the secured (mail) content that OMA provides our users? After some basic searching I found that the OMA application uses C# for which Microsoft has kindly provided sample code to mitigate this issue. Can anyone verify this?

    If this is the case wouldn't it be prudent to mention somewhere in the KB article Microsoft applications which use ASP.Net such as OMA (or more generally E2K3)?
    -----

    7. Adam Tuliper points out;
    -----
    If you have asp.net installed and only serve asp and static html pages then you are not affected by this issue.
    -----
    <Editor's Note: Again, this may or may not be true. If ASP.Net is installed, it is still unclear whether some other exploitation might be possible. If you're only serving up ASP and static HTML pages, then your not using ASP.Net Authorization, so the discussed exploitation can't be done against you.>

    8. Stephan Troxler offered this blog URL, which includes a demonstration of the issue;
    -----
    I've put a Demo in my blog that shows the problem:

    <http://www.dotnetgerman.com/blogs/stephan/PermaLink.aspx?guid=b42e7af9-12a8-487a-bafb-921c7e51413a>
    -----

    Cheers,
    Russ - NTBugtraq Editor 

    --
NTBugtraq Editor's Note:
Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the message and place it in your TO: field.
--
  • Next message: Drew Copley: "Re: Disclosure policy in Re: RealPlayer vulnerabilities"