what I've been trying to figure out is why the authors of the exploit, who in thier original paper don't even mention Asp.Net, came out with the the claim that Asp.Net was such an easy target. I'm assuming that is was because of the different error codes
returned by WebResource.axd. As you have pointed out, other features of Asp.Net, such as forms authentication could be used as an oracle using a timing based approach. However, it would seem that once you get into the realm of timing based oracles, any platform
would be vulnurable.
Things brings up another point, trusting data sent from the client. Right now, when using forms authentication, Asp.Net is trusting that the data has not been tampared with, as evident in the poet vs. DNN video. It would seem that forms authentication itself
needs a bit of a fix, possibly in the form of some type of digital signature or other server side validation. An alternative would be to code something yourself on the server side, like sending an extra bit of random information with the forms auth cookie
that you can then verify upcon reciept, or sending your own digital signature.
And of course, there is still the issue of being able to download the web.config file.
So, in summary, the primary attack vector seems to be the WebResource.axd, which makes it easy to launch a padding oracle attack against asp.net sites and obtain the machine key. Once the machine key is obtained, the web.config file can be downloaded, and
the forms authentication cookie modified. There may be other related attack vectors and Microsoft in an effort to keep things somewhat under control has not publically disclosed them. So as many people have already pointed out, follow thier work around for
now.
What I'd like to see from microsoft is a fix that makes WebResource.axd less of an oracle, add a whitelist setting which requires developers to explictly list the files that can be downloaded by these included handlers, and some type of server side validation
that the encrypted data (e.g. forms authentication cookie) has not been compromised. I'd also like to see a white paper that goes into some of these details from Microsoft, once the fix has been made available.
> Once the machine key is obtained, the web.config file can be downloaded, and the forms authentication cookie modified.
Interesting point about forging forms auth cookies: If your user account names are not easy to guess (e.g. admin user is not called "administrator")
then the attacker has a harder time forging the cookies.
Consider a fairly public site that hosts a forum where everyone's username is probably displayed. Pretty easy to figure out who moderators and administrators are. I was looking at the Orchard CMS code and they put the UserId itself in the cookie and I would
not be surprised to see other applications doing that as well.
This has given me a lot to think about in terms of security. I saw another post on here where someone was asking how to remove the WebResource and Script handlers, and if there were any other ones he should be aware of (someone brought up trace.axd). I think
that this would be a worthy topic for someone at microsoft to address.
Regarding your comments on trusting tampered data from the client. It depends on what data you are referring to, as you have among other things, the cookie, viewstate, and postback data.
Postback data "tampering" cannot be detected, because it is itself intended to be specified/provided by the client. You as the programmer writing an ASP.NET application should handle postback data as though it could contain anything, meaning considering
how you use that data and esnuring you are not enabling a CSRF, XSS, or SQL Injection vulnerability by mishandling that data. Unfortunately there are lots of ASP.NET articles that say "always do this and you'll be safe", but generally that is not foolproof.
When you get into complex applications you end up passing user suppled text through many layers where it ends up in a database, and then later might get displayed to some web page. In such a scenario it's easy to forget some weeks down the road when you are
creating a webpage to display some data from the database, and forget that that particular database field contains some user supplied text(a comment on a blog for example) and you procede to display it verbatim, not checking for malicious javascript, etc.
I find many of the mechnism's MS provides for dealing with these vulnerabilities to be useless, as they are provided as magic bullets without accompaning detailed explanations of how they work to prevent the threat. I mean really? We are not stupid, give
us the facts MS.
Viewstate data tampering can be detected and/or encrypted, see the "View State and Security Implications" section here abou signing viewstate(there are more detailed articles but this is the jist of it):
As far as cookies, MS's documentation as far as I've seen is pretty vague and useless.
The amount of misunderstanding of this vulnerability and past vulnerabilities is testament to Microsoft's poor documentation of ASP.NET's security model. In security communities I believe this lack of openess is considered poor because a few malicious hackers
can figure out the details and use them to their advantage, while the masses of uneducated developers lack the understanding of the security principles such that they can implement them properly.
MS's documentation runs along the lines of "do it like this, don't worry about why it is safe, just trust us that it is". Usually this statement is made in the context of ideal conditions. Thus developers don't know how to assess each scenario they encounter
and implement a solution that is secure for the set of threats that the scenario is exposed to. When developers encounter a scenario like this vulnerability, suddenly they don't know what to do because no one is really sure exactly how the pieces fit together,
so that they can't figure out what to fix when one is broken. There are already lots of blog posts on this where the author seems ot think they understand the issue and are giving advice or opinions that reveal them to not understand.
Not too long ago I saw a slashdot post get accepted that basically stated that there was an SQL injection vulnerability in ASP.NET itself. This of course turned out to be completely false, as it turned out to be a misunderstanding on the part of the author
who did not understand that SQL injection vulnerabilities are specific to the implementation of the web application, not of the ASP.NET framework across the board. Of course there were lots of anti-microsoft commenters jumping on the board wagon, and this
was fueled by ASP.NET developers who themselves didn't understand enough about security in ASP.NET applications such that they could reallize for themselves that the article was completely misleading.
It's a really sad state of afairs and very frustrating when you are trying to ensure the applications you work on are secure you run into the same ignorance with coworkers. I personally feel ashamed that I don't understand more about how all the pieces
work together. I have implemented desktop C# applications and PHP applications using various cryptography standards, and I always invested the time in making sure I understood all the pieces of the puzzle and often I found that I was missing something and
could make adjustments. With ASP.NET I instead feel helpless.
I agree the details are thin on the ground but if teh workaround works then it is real issue. The is no evidence at this stage that the workaround doesn't work. Also the workaround is not so complex that an average dev couldn't implement it.
Also I think there could be more potential vulnerabilities rather then what we know how are more obvious routes and the timing issues for asp3.5.1 and 4.0 alude to this.
Oh as you mentioned PHP if you have a php app and asp.net is installed on the server then likely/possibility you also effected.
@schmidt.de - thanks. I too was a bit frustrated by the vagueness, but MS obviously think that the less specific info out there is better. Whether this is the right thing to do is arguable: they'll be damned if they do, damned if they don't.
In my tests ScriptResource.axd appears to always return 404s (on .NET 3.5 SP1 at least), so doesn't appear to act as an oracle in that way, but once the key is compromised can be used to serve
up arbitrary files in the web site (e.g. web.config, etc).
ViewState as padding oracle: maybe
FormsAuthModule: in my tests it always seem to do a 302 redirect, [EDIT: yes: there may be a timing issue there]
I have been studing this a bit and I find that ScriptResource.axd can produce 404 and 500 errors in the wide.
The problem with WebResourceHandler and ScriptResourceHandler is that the solely rely on Page.EncryptString. Page.EncryptString does exactly what is says; it encrypts and does NOT add authentication (Message Authentication Code or MAC). This is one off
the the main reasons why they are vulnerable for padding-oracle-attacks.
The FormsAuthentication.Encrypt(FormsAuthenticationTicket ticket) DOES add authentication to the plain text before it is encrypted using the same algorithms as Page.EncryptString does. Therefore the forms-authentication cookie is NOT vulnerable for padding-oracle
attacks by itself (first authenticate-->then encrypt prevents padding-oracle-attacks, but only IF one cannot differentiate between a padding failure or a message authentication failure. FormsAuthentication.Decrypt returns an Internal Server Error in both cases.
I think (but not sure) this is also the case with ViewState encryption)
I quess this is how POET does it's trick :
- First use WebResource.axd to determine the servers encryptionkey. By now we all know how to do that.
- POET is now able to decrypt an authentication cookie but is unable to change it (due to the last 20 bytes containing a MAC)
- But POET now can use the same padding-oracle techniques to determine the servers validation key (the mac is appended to the authentication-tickets plaintext, last 20 bytes. So use the same techniques on the last 20 bytes. The authentication-cookie HAS
a padding-oracle-exploit for the servers validation key)
- Now knowing both encryption- and validation keys, POET is able to tamper with anything that is protected with these keys, including the authentication cookie and viewstate.
Conclusion: it all starts with WebResource.axd (or ScriptResource.axd) but after that you're lost. Nevertheless I would never rely on just removing these handlers an always implement the Microsoft Workarounds asap! Next to that, Use Reflector just as the
the authors of POET did. Start with methods like Page.EncryptString versus FormsAuthentication.Encrypt.
Authentication-cookies are validated using a hash function, not a real MAC. So they don't use-, and therefore expose, the servers ValidationKey. The servers EncryptionKey (exposed through WebResource) is enough to forge authentication-cookies.
It must be ViewState that exposes the ValidationKey but I can't understand how.
@Rovastar, ScriptResource.axd swallows the HTTP 500 errors and generates 404 in their place. It's not a padding oracle (unlike WebResource.axd) because an attacker can not distinguish between the two; he only sees 404s (except if he is using some timing
mechanism).
@rneinhuis, Using a padding oracle to determine the encryption key is really difficult. It is less difficult to use a padding oracle to forge an encrypted request to ScriptResource to download a particular file (in this case, Web.config).
Rovastar
Member
168 Points
52 Posts
Re: Some more important information and open questions
Sep 21, 2010 12:34 PM|LINK
Thnaks for the replies I thought it would be the case but with so much (mis)information flying around I needed to be sure.
Reklats
Member
13 Points
5 Posts
Re: Some more important information and open questions
Sep 21, 2010 02:48 PM|LINK
what I've been trying to figure out is why the authors of the exploit, who in thier original paper don't even mention Asp.Net, came out with the the claim that Asp.Net was such an easy target. I'm assuming that is was because of the different error codes returned by WebResource.axd. As you have pointed out, other features of Asp.Net, such as forms authentication could be used as an oracle using a timing based approach. However, it would seem that once you get into the realm of timing based oracles, any platform would be vulnurable.
Things brings up another point, trusting data sent from the client. Right now, when using forms authentication, Asp.Net is trusting that the data has not been tampared with, as evident in the poet vs. DNN video. It would seem that forms authentication itself needs a bit of a fix, possibly in the form of some type of digital signature or other server side validation. An alternative would be to code something yourself on the server side, like sending an extra bit of random information with the forms auth cookie that you can then verify upcon reciept, or sending your own digital signature.
And of course, there is still the issue of being able to download the web.config file.
So, in summary, the primary attack vector seems to be the WebResource.axd, which makes it easy to launch a padding oracle attack against asp.net sites and obtain the machine key. Once the machine key is obtained, the web.config file can be downloaded, and the forms authentication cookie modified. There may be other related attack vectors and Microsoft in an effort to keep things somewhat under control has not publically disclosed them. So as many people have already pointed out, follow thier work around for now.
What I'd like to see from microsoft is a fix that makes WebResource.axd less of an oracle, add a whitelist setting which requires developers to explictly list the files that can be downloaded by these included handlers, and some type of server side validation that the encrypted data (e.g. forms authentication cookie) has not been compromised. I'd also like to see a white paper that goes into some of these details from Microsoft, once the fix has been made available.
Thoughts?
Duncan Smart
Member
40 Points
14 Posts
Re: Some more important information and open questions
Sep 21, 2010 03:08 PM|LINK
@Reklats - yes FormsAuth probably needs an HMAC.
Interesting point about forging forms auth cookies: If your user account names are not easy to guess (e.g. admin user is not called "administrator") then the attacker has a harder time forging the cookies.
Blog.dotsmart.net
Reklats
Member
13 Points
5 Posts
Re: Some more important information and open questions
Sep 21, 2010 06:09 PM|LINK
Consider a fairly public site that hosts a forum where everyone's username is probably displayed. Pretty easy to figure out who moderators and administrators are. I was looking at the Orchard CMS code and they put the UserId itself in the cookie and I would not be surprised to see other applications doing that as well.
This has given me a lot to think about in terms of security. I saw another post on here where someone was asking how to remove the WebResource and Script handlers, and if there were any other ones he should be aware of (someone brought up trace.axd). I think that this would be a worthy topic for someone at microsoft to address.
AaronLShumaker
Member
63 Points
23 Posts
Re: Some more important information and open questions
Sep 21, 2010 08:11 PM|LINK
Regarding your comments on trusting tampered data from the client. It depends on what data you are referring to, as you have among other things, the cookie, viewstate, and postback data.
Postback data "tampering" cannot be detected, because it is itself intended to be specified/provided by the client. You as the programmer writing an ASP.NET application should handle postback data as though it could contain anything, meaning considering how you use that data and esnuring you are not enabling a CSRF, XSS, or SQL Injection vulnerability by mishandling that data. Unfortunately there are lots of ASP.NET articles that say "always do this and you'll be safe", but generally that is not foolproof. When you get into complex applications you end up passing user suppled text through many layers where it ends up in a database, and then later might get displayed to some web page. In such a scenario it's easy to forget some weeks down the road when you are creating a webpage to display some data from the database, and forget that that particular database field contains some user supplied text(a comment on a blog for example) and you procede to display it verbatim, not checking for malicious javascript, etc. I find many of the mechnism's MS provides for dealing with these vulnerabilities to be useless, as they are provided as magic bullets without accompaning detailed explanations of how they work to prevent the threat. I mean really? We are not stupid, give us the facts MS.
Viewstate data tampering can be detected and/or encrypted, see the "View State and Security Implications" section here abou signing viewstate(there are more detailed articles but this is the jist of it):
http://msdn.microsoft.com/en-us/library/ms972976.aspx#viewstate_topic12
As far as cookies, MS's documentation as far as I've seen is pretty vague and useless.
The amount of misunderstanding of this vulnerability and past vulnerabilities is testament to Microsoft's poor documentation of ASP.NET's security model. In security communities I believe this lack of openess is considered poor because a few malicious hackers can figure out the details and use them to their advantage, while the masses of uneducated developers lack the understanding of the security principles such that they can implement them properly.
MS's documentation runs along the lines of "do it like this, don't worry about why it is safe, just trust us that it is". Usually this statement is made in the context of ideal conditions. Thus developers don't know how to assess each scenario they encounter and implement a solution that is secure for the set of threats that the scenario is exposed to. When developers encounter a scenario like this vulnerability, suddenly they don't know what to do because no one is really sure exactly how the pieces fit together, so that they can't figure out what to fix when one is broken. There are already lots of blog posts on this where the author seems ot think they understand the issue and are giving advice or opinions that reveal them to not understand.
Not too long ago I saw a slashdot post get accepted that basically stated that there was an SQL injection vulnerability in ASP.NET itself. This of course turned out to be completely false, as it turned out to be a misunderstanding on the part of the author who did not understand that SQL injection vulnerabilities are specific to the implementation of the web application, not of the ASP.NET framework across the board. Of course there were lots of anti-microsoft commenters jumping on the board wagon, and this was fueled by ASP.NET developers who themselves didn't understand enough about security in ASP.NET applications such that they could reallize for themselves that the article was completely misleading.
It's a really sad state of afairs and very frustrating when you are trying to ensure the applications you work on are secure you run into the same ignorance with coworkers. I personally feel ashamed that I don't understand more about how all the pieces work together. I have implemented desktop C# applications and PHP applications using various cryptography standards, and I always invested the time in making sure I understood all the pieces of the puzzle and often I found that I was missing something and could make adjustments. With ASP.NET I instead feel helpless.
Rovastar
Member
168 Points
52 Posts
Re: Some more important information and open questions
Sep 23, 2010 01:28 PM|LINK
I agree the details are thin on the ground but if teh workaround works then it is real issue. The is no evidence at this stage that the workaround doesn't work. Also the workaround is not so complex that an average dev couldn't implement it.
Also I think there could be more potential vulnerabilities rather then what we know how are more obvious routes and the timing issues for asp3.5.1 and 4.0 alude to this.
Oh as you mentioned PHP if you have a php app and asp.net is installed on the server then likely/possibility you also effected.
Rovastar
Member
168 Points
52 Posts
Re: Some more important information and open questions
Sep 24, 2010 07:02 PM|LINK
I have been studing this a bit and I find that ScriptResource.axd can produce 404 and 500 errors in the wide.
So I would remove this too if not needed.
rnienhuis
Member
20 Points
5 Posts
Re: Some more important information and open questions
Sep 25, 2010 08:22 PM|LINK
The problem with WebResourceHandler and ScriptResourceHandler is that the solely rely on Page.EncryptString. Page.EncryptString does exactly what is says; it encrypts and does NOT add authentication (Message Authentication Code or MAC). This is one off the the main reasons why they are vulnerable for padding-oracle-attacks.
The FormsAuthentication.Encrypt(FormsAuthenticationTicket ticket) DOES add authentication to the plain text before it is encrypted using the same algorithms as Page.EncryptString does. Therefore the forms-authentication cookie is NOT vulnerable for padding-oracle attacks by itself (first authenticate-->then encrypt prevents padding-oracle-attacks, but only IF one cannot differentiate between a padding failure or a message authentication failure. FormsAuthentication.Decrypt returns an Internal Server Error in both cases. I think (but not sure) this is also the case with ViewState encryption)
I quess this is how POET does it's trick :
- First use WebResource.axd to determine the servers encryptionkey. By now we all know how to do that.
- POET is now able to decrypt an authentication cookie but is unable to change it (due to the last 20 bytes containing a MAC)
- But POET now can use the same padding-oracle techniques to determine the servers validation key (the mac is appended to the authentication-tickets plaintext, last 20 bytes. So use the same techniques on the last 20 bytes. The authentication-cookie HAS a padding-oracle-exploit for the servers validation key)
- Now knowing both encryption- and validation keys, POET is able to tamper with anything that is protected with these keys, including the authentication cookie and viewstate.
Conclusion: it all starts with WebResource.axd (or ScriptResource.axd) but after that you're lost. Nevertheless I would never rely on just removing these handlers an always implement the Microsoft Workarounds asap! Next to that, Use Reflector just as the the authors of POET did. Start with methods like Page.EncryptString versus FormsAuthentication.Encrypt.
rnienhuis
Member
20 Points
5 Posts
Re: Some more important information and open questions
Sep 26, 2010 09:52 AM|LINK
I was wrong.
Authentication-cookies are validated using a hash function, not a real MAC. So they don't use-, and therefore expose, the servers ValidationKey. The servers EncryptionKey (exposed through WebResource) is enough to forge authentication-cookies.
It must be ViewState that exposes the ValidationKey but I can't understand how.
pitz
Member
54 Points
14 Posts
Re: Some more important information and open questions
Sep 28, 2010 07:53 PM|LINK
@Rovastar, ScriptResource.axd swallows the HTTP 500 errors and generates 404 in their place. It's not a padding oracle (unlike WebResource.axd) because an attacker can not distinguish between the two; he only sees 404s (except if he is using some timing mechanism).
@rneinhuis, Using a padding oracle to determine the encryption key is really difficult. It is less difficult to use a padding oracle to forge an encrypted request to ScriptResource to download a particular file (in this case, Web.config).