|
|
 |
|
Project: OWASP Source Code Center: Mailing Lists
|
|
|
|
|
Summary |
Admin |
Home Page |
Forums |
Tracker |
Bugs |
Support |
Patches |
RFE |
Lists |
Tasks |
Docs |
Screenshots |
News |
CVS |
Files |
From: Dinis Cruz <dinis@dd...>
 New Vulnerablility in Asp.Net Forms Authentication
which allows malicious users to read "private pages"
2004-09-29 15:58
|
Hello
Probably most of you are already aware of this, but here it goes:
**************************************************************************
I) earlier yesterday (Tue 14th of September) Toby Beaumont posted to
NTBugTraq
(http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind0409&L=ntbugtr
aq&F=P&S=&P=9884) this message:
**************************************************************************
Date: Tue, 14 Sep 2004 12:42:28 +0100
From: Toby Beaumont <toby:nospam.CREATOR.CO.UK>
Subject: Security bug in .NET Forms Authentication
Hi
We believe we have discovered a serious flaw in .NET forms authentication
when used to secure sub folders.
A standard forms authentication setup requires the presence of "web.config"
to set the authentication method and login procedure. The presence of this
file prevents access to certain files (.aspx files for example) unless
authenticated.
Example
-------
The webroot for your website is:
c:\inetpub\wwwroot\mysite
You want to secure files in a sub directory "secure"
c:\inetpub\wwwroot\mysite\secure\web.config
A request to http://localhost/secure/somefile.aspx would then redirect the
user to a predefined authentication page, as defined in web.config, before
allowing the user access to "somefile.aspx".
Bug
---
1. Using Mozilla not IE, you make a request to
http://localhost/secure\somefile.aspx The use of a backslash rather than a
forward slash appears to bypass the expected authentication model invoked in
.NET forms authentication
2. Using IE, you make a request to http://localhost/secure\somefile.aspx -
IE automatically replaces the backslash "\" with a forward slash "/" and
everything appears fine. However, replace the backslash "\" with %5C (%5C
being hex value for \) and all is not so fine:
http://localhost/secure%5Csomefile.aspx
----
Interestingly (and I guess now somewhat amusingly) Microsoft point out in
the article "Design Guidelines for Secure Web Applications"
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/h
tml/THCMCh04.asp):
"Be Careful with Canonicalization Issues:
Data in canonical form is in its most standard or simplest form.
Canonicalization is the process of converting data to its canonical form.
File paths and URLs are particularly prone to canonicalization issues and
many well-known exploits are a direct result of canonicalization bugs. For
example, consider the following string that contains a file and path in its
canonical form."
And then goes on to define the exploit ;-)
(Russ - I have not posted this message anywhere as yet, nor have I contacted
Microsoft. If you indeed confirm this exploit, you are the first to know).
Regards,
==
Toby Beaumont
Director of Technology
Creator
**************************************************************************
II) then Sunny [sunny@as...] posted this POC to list@Ms...
**************************************************************************
Finally I recreated this problem on my dev pc. The way I configured and used
my web.config made my server secure. In my project I need to secure all the
folders except one folder. So my web.config file denies access to all
folders for all users but only allows access to home folder, default.aspx
and login.aspx page.
So the following web.config file is not vulnerable:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="login.aspx" name=".ASPXAUTHLIVE"
protection="None" path="/" timeout="60" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>
<location path="login.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="default.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="home">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
</configuration>
But this web.config file is vulnerable:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="login.aspx" name=".ASPXAUTHDEV"
protection="None" path="/" timeout="60" />
</authentication>
<authorization>
<allow users="*" />
</authorization>
</system.web>
<location path="secure">
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
</configuration>
Sunny
**************************************************************************
III) to which Phil Winstanley [phil@wi...] replied with
**************************************************************************
To: list@Ms...
In my opinion, this bug will have been the biggest breach of Microsoft"s
security systems in recent years - it"s very messy and has the potential to
do a lot of damage.
It adds a whole new attack vector to ASP.NET sites, one which is more-a-less
undetectable to the site Administrator, check out these Scenarios: -
1. I have an e-commerce site, I log my clients usernames and passwords and
have an administration interface for managing users. I"ve protected this
interface with forms authentication and my site is not patched and is
running on IIS5.x. A Hacker decides to try this new exploit on
"/admin/default.aspx" where there"s a good chance the administration
interface is hosted. The Hacker gets in. They have the usernames and
passwords for all the sites users. They login as a user, change the delivery
address, order something, this uses the cached credit card details that user
trusted the site with (Amazon one-click for example) and hey presto, I"ve
used an exploit in ASP.NET to break open a whole site and then cost it"s
members money and the site customers.
2. I have a company web site that uses a hand rolled CMS to manage the
content on the pages. I"ve protected this interface with forms
authentication and my site is not patched and is running on IIS5.x. An
employee at a competitor decides to try this new exploit on
"/admin/default.aspx" where there"s a good chance the administration
interface is hosted. The Hacker gets in. They add a new entry to my "Press
Release" section saying we"re closing down and going to go in to
Liquidation. My Share price falls through the floor when people read it, I
don"t know about it until I read the site and spot it"s been done.
I really would advise ALL list members to check their Server Environments
for the vulnerability and use URLScan where possible.
1. Confirm a user is who they should be, use the roles system in ASP.NET on
EVERY page that should be secured.
2. Ask people to re-enter their username and password to perform sensitive
operations.
3. Do not just rely on the Web.Config settings
4. Make sure you"re not placing your administration pages in obvious places
and don"t link to them from any public sites.
5. TEST to make sure you cannot break in.
Plip.
--
Phil Winstanley [MVP - ASP.NET]
mailto:phil@wi...
**************************************************************************
IV) and I (Dinis) replied with
**************************************************************************
To: list@Ms...
I agree with Phil that this is a big problem, since anything that allows the
bypass on existing security layers is something very serious (although I
still think that the Full Trust Asp.Net vulnerabilities that I have
disclosed are much worse J)
BTW, as anybody looked at the .Net Framework code to see what is causing
this problem? Or is this an IIS problem?
Also (as soon as I have some time) I want to add a test for this
vulnerability to SAM"SHE which will be used to detect if a website is
vulnerable, does anybody here want to participate in its development?
Dinis
**************************************************************************
**************************************************************************
Best regards
Dinis Cruz
.Net Security Consultant
DDPlus
|
From: Dominick Baier <dotnet@le...>
RE: New Vulnerablility in Asp.Net Forms
Authentication which allows malicious users to read "private pages"
2004-09-30 06:53
|
I could reproduce this on plain 1.1 (1.1.4322.532) but not on 1.1 SP1
(1.1.4322.2032)
dominick
http://www.leastprivilege.com
-----Original Message-----
From: owasp-dotnet-admin@li...
[mailto:owasp-dotnet-admin@li...] On Behalf Of Dinis Cruz
Sent: Donnerstag, 30. September 2004 00:59
To: owasp-dotnet@li...
Cc: tony@CR...; sunny@as...; phil@wi...
Subject: [Owasp-dotnet] New Vulnerablility in Asp.Net Forms Authentication
which allows malicious users to read "private pages"
Importance: High
Hello
Probably most of you are already aware of this, but here it goes:
**************************************************************************
I) earlier yesterday (Tue 14th of September) Toby Beaumont posted to
NTBugTraq
(http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind0409&L=ntbugtr
aq&F=P&S=&P=9884) this message:
**************************************************************************
Date: Tue, 14 Sep 2004 12:42:28 +0100
From: Toby Beaumont <toby:nospam.CREATOR.CO.UK>
Subject: Security bug in .NET Forms Authentication
Hi
We believe we have discovered a serious flaw in .NET forms authentication
when used to secure sub folders.
A standard forms authentication setup requires the presence of "web.config"
to set the authentication method and login procedure. The presence of this
file prevents access to certain files (.aspx files for example) unless
authenticated.
Example
-------
The webroot for your website is:
c:\inetpub\wwwroot\mysite
You want to secure files in a sub directory "secure"
c:\inetpub\wwwroot\mysite\secure\web.config
A request to http://localhost/secure/somefile.aspx would then redirect the
user to a predefined authentication page, as defined in web.config, before
allowing the user access to "somefile.aspx".
Bug
---
1. Using Mozilla not IE, you make a request to
http://localhost/secure\somefile.aspx The use of a backslash rather than a
forward slash appears to bypass the expected authentication model invoked in
.NET forms authentication
2. Using IE, you make a request to http://localhost/secure\somefile.aspx -
IE automatically replaces the backslash "\" with a forward slash "/" and
everything appears fine. However, replace the backslash "\" with %5C (%5C
being hex value for \) and all is not so fine:
http://localhost/secure%5Csomefile.aspx
----
Interestingly (and I guess now somewhat amusingly) Microsoft point out in
the article "Design Guidelines for Secure Web Applications"
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/h
tml/THCMCh04.asp):
"Be Careful with Canonicalization Issues:
Data in canonical form is in its most standard or simplest form.
Canonicalization is the process of converting data to its canonical form.
File paths and URLs are particularly prone to canonicalization issues and
many well-known exploits are a direct result of canonicalization bugs. For
example, consider the following string that contains a file and path in its
canonical form."
And then goes on to define the exploit ;-)
(Russ - I have not posted this message anywhere as yet, nor have I contacted
Microsoft. If you indeed confirm this exploit, you are the first to know).
Regards,
==
Toby Beaumont
Director of Technology
Creator
**************************************************************************
II) then Sunny [sunny@as...] posted this POC to list@Ms...
**************************************************************************
Finally I recreated this problem on my dev pc. The way I configured and used
my web.config made my server secure. In my project I need to secure all the
folders except one folder. So my web.config file denies access to all
folders for all users but only allows access to home folder, default.aspx
and login.aspx page.
So the following web.config file is not vulnerable:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="login.aspx" name=".ASPXAUTHLIVE"
protection="None" path="/" timeout="60" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>
<location path="login.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="default.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="home">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
</configuration>
But this web.config file is vulnerable:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="login.aspx" name=".ASPXAUTHDEV"
protection="None" path="/" timeout="60" />
</authentication>
<authorization>
<allow users="*" />
</authorization>
</system.web>
<location path="secure">
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
</configuration>
Sunny
**************************************************************************
III) to which Phil Winstanley [phil@wi...] replied with
**************************************************************************
To: list@Ms...
In my opinion, this bug will have been the biggest breach of Microsoft"s
security systems in recent years - it"s very messy and has the potential to
do a lot of damage.
It adds a whole new attack vector to ASP.NET sites, one which is more-a-less
undetectable to the site Administrator, check out these Scenarios: -
1. I have an e-commerce site, I log my clients usernames and passwords and
have an administration interface for managing users. I"ve protected this
interface with forms authentication and my site is not patched and is
running on IIS5.x. A Hacker decides to try this new exploit on
"/admin/default.aspx" where there"s a good chance the administration
interface is hosted. The Hacker gets in. They have the usernames and
passwords for all the sites users. They login as a user, change the delivery
address, order something, this uses the cached credit card details that user
trusted the site with (Amazon one-click for example) and hey presto, I"ve
used an exploit in ASP.NET to break open a whole site and then cost it"s
members money and the site customers.
2. I have a company web site that uses a hand rolled CMS to manage the
content on the pages. I"ve protected this interface with forms
authentication and my site is not patched and is running on IIS5.x. An
employee at a competitor decides to try this new exploit on
"/admin/default.aspx" where there"s a good chance the administration
interface is hosted. The Hacker gets in. They add a new entry to my "Press
Release" section saying we"re closing down and going to go in to
Liquidation. My Share price falls through the floor when people read it, I
don"t know about it until I read the site and spot it"s been done.
I really would advise ALL list members to check their Server Environments
for the vulnerability and use URLScan where possible.
1. Confirm a user is who they should be, use the roles system in ASP.NET on
EVERY page that should be secured.
2. Ask people to re-enter their username and password to perform sensitive
operations.
3. Do not just rely on the Web.Config settings
4. Make sure you"re not placing your administration pages in obvious places
and don"t link to them from any public sites.
5. TEST to make sure you cannot break in.
Plip.
--
Phil Winstanley [MVP - ASP.NET]
mailto:phil@wi...
**************************************************************************
IV) and I (Dinis) replied with
**************************************************************************
To: list@Ms...
I agree with Phil that this is a big problem, since anything that allows the
bypass on existing security layers is something very serious (although I
still think that the Full Trust Asp.Net vulnerabilities that I have
disclosed are much worse J)
BTW, as anybody looked at the .Net Framework code to see what is causing
this problem? Or is this an IIS problem?
Also (as soon as I have some time) I want to add a test for this
vulnerability to SAM"SHE which will be used to detect if a website is
vulnerable, does anybody here want to participate in its development?
Dinis
**************************************************************************
**************************************************************************
Best regards
Dinis Cruz
.Net Security Consultant
DDPlus
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use
IT products in your business? Tell us what you think of them. Give us Your
Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet@li...
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
|
From: Dominick Baier <dotnet@le...>
RE: New Vulnerablility in Asp.Net Forms
Authentication which allows malicious users to read "private pages"
2004-09-30 23:22
|
it seems that there is also a OS dependency (or rather a IIS version
dependency)
I can repro on XP with and without SP1
but I can"t repro on W2K3
so IIS6 seems to do some pre-processing of the URL that is more framework
friendly.
also - would be also interesting to try that with windows auth, too.
I guess it is more a problem of UrlAuthorization than FormsAuth
dominick
-----Original Message-----
From: owasp-dotnet-admin@li...
[mailto:owasp-dotnet-admin@li...] On Behalf Of Dinis Cruz
Sent: Freitag, 1. Oktober 2004 00:22
To: owasp-dotnet@li...
Cc: sunny@as...; phil@wi...; "Dominick Baier"
Subject: RE: [Owasp-dotnet] New Vulnerablility in Asp.Net Forms
Authentication which allows malicious users to read "private pages"
> I could reproduce this on plain 1.1 (1.1.4322.532) but not on 1.1 SP1
> (1.1.4322.2032)
>
> dominick
> http://www.leastprivilege.com
I can confirm this (on a Windows 2000 box).
Also, check this other vulnerability posted here to owasp-dotnet by Gery D.
Dorazio last September 10th (
http://sourceforge.net/mailarchive/forum.php?thread_id=5547177&forum_id=2475
4) which I forwarded to secure@mi...
I am not sure if the problem is the related, but there are definitely some
serious problems with the way the Forms Authentication is implemented in
V1.1
Gery, was this vulnerability fixed with the .Net SP1?
I am currently doing some research on the main vulnerability (Forms
Authentication bypass) and hopefully soon will be able to post some more
information here.
Best Regards
Dinis Cruz
.Net Security Consultant
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use
IT products in your business? Tell us what you think of them. Give us Your
Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet@li...
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
|
From: Dominick Baier <dotnet@le...>
RE: New Vulnerablility in Asp.Net Forms
Authentication which allows malicious users to read "private pages"
2004-09-30 23:31
|
....but it is definitely good to see - that the last messages on the blog of
the guy who runs the msdn security center were about which friend bought
which laptop and links to widescreen displays ... :)
dominick
-----Original Message-----
From: owasp-dotnet-admin@li...
[mailto:owasp-dotnet-admin@li...] On Behalf Of Dominick
Baier
Sent: Freitag, 1. Oktober 2004 08:22
To: "Dinis Cruz"; owasp-dotnet@li...
Cc: sunny@as...; phil@wi...
Subject: RE: [Owasp-dotnet] New Vulnerablility in Asp.Net Forms
Authentication which allows malicious users to read "private pages"
it seems that there is also a OS dependency (or rather a IIS version
dependency)
I can repro on XP with and without SP1
but I can"t repro on W2K3
so IIS6 seems to do some pre-processing of the URL that is more framework
friendly.
also - would be also interesting to try that with windows auth, too.
I guess it is more a problem of UrlAuthorization than FormsAuth
dominick
-----Original Message-----
From: owasp-dotnet-admin@li...
[mailto:owasp-dotnet-admin@li...] On Behalf Of Dinis Cruz
Sent: Freitag, 1. Oktober 2004 00:22
To: owasp-dotnet@li...
Cc: sunny@as...; phil@wi...; "Dominick Baier"
Subject: RE: [Owasp-dotnet] New Vulnerablility in Asp.Net Forms
Authentication which allows malicious users to read "private pages"
> I could reproduce this on plain 1.1 (1.1.4322.532) but not on 1.1 SP1
> (1.1.4322.2032)
>
> dominick
> http://www.leastprivilege.com
I can confirm this (on a Windows 2000 box).
Also, check this other vulnerability posted here to owasp-dotnet by Gery D.
Dorazio last September 10th (
http://sourceforge.net/mailarchive/forum.php?thread_id=5547177&forum_id=2475
4) which I forwarded to secure@mi...
I am not sure if the problem is the related, but there are definitely some
serious problems with the way the Forms Authentication is implemented in
V1.1
Gery, was this vulnerability fixed with the .Net SP1?
I am currently doing some research on the main vulnerability (Forms
Authentication bypass) and hopefully soon will be able to post some more
information here.
Best Regards
Dinis Cruz
.Net Security Consultant
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use
IT products in your business? Tell us what you think of them. Give us Your
Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet@li...
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use
IT products in your business? Tell us what you think of them. Give us Your
Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet@li...
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
|
| |
