I've been
researching additional information on the exploit. It seems that changing the web.config and/or adding random delay is not enough to prevent the attacker from using the exploit.
As one of the authors have mentioned:
> error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different
1. Attacker sends request to resource. Records that it costs 500ms;
2. Attacker sends requests to brutforce and just waiting for more then 500ms, and that means error.
Am I correct? Any comment from Microsoftwould be appreciated.
The recommendations from MSFT are not attempting to hide that an error occurred in the page request. Instead, they are recommending that ALL errors result in the exact same error page - so as not to give the attacker any clues as to what caused the error.
abdullin
1. Attacker sends request to resource. Records that it costs 500ms;
2. Attacker sends requests to brutforce and just waiting for more then 500ms, and that means error.
That's not the point though. The default error page itself means error.
abdullin
> error message setting is irrelevant. no error? there's always HTTP status.
The same error page makes the error message irrelevant
The same error page also makes the HTTP status irrelevant as the status will always be the same
abdullin
always the same HTTP status? there's always big timing different
It is the "big timing difference" that the random sleep addresses. Theoretically, the exact same errors should have a response time that repeats. So the attacker could speculate about the nature of the error based on that repeating response time. By adding
in a random sleep, identical errors will have widely varying response times. with no discernable pattern to the response times, the attacker is again prevented from learning or effectively guessing at what the real underlying error was.
But what about running the same request, multiple times just to get the distribution of delays? Isn't there going to be some bias even with RNG?
38000 requests took 300 seconds. Multiply it by, say, 10000 == 830 hours. Split this between 100 async processes (or a few cloud VMs) and you've got 8 hours (unless IIS would not go down because it's threads are sleeping).
BTW, are there any estimates on the patch availability?
BTW, are there any estimates on the patch availability?
There are many configurations that must be tested before Microsoft can release a patch. From Scott Guthrie's
post:
<div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"># re: Important: ASP.NET Security Vulnerability</div> <div style="position: absolute; left: -10000px; top: 0px; width:
1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">Saturday, September 18, 2010 6:54 PM
by ScottGu</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">@Peter,</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x:
hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">>>>>>>>> Can you give us an estimate on the patch? (hours, days, weeks?)</div>
<div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y:
hidden;" id="_mcePaste">We did not receive advance disclosure of yesterday's report, so do not have a patch available yet. We are working hard on one though. There are lots of different platform matrixes and localization languages to build/test/verify which
is why producing a patch with high confidence enough to deploy automatically across millions of machines takes a bit of time to get right. In the meantime we published the above workaround to prevent attacks using the attack approach discussed publicly yesterday.</div>
<div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y:
hidden;" id="_mcePaste">Hope this helps,</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width:
1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">Scott</div>
<ScottGuthrie>
# re: Important: ASP.NET Security Vulnerability
Saturday, September 18, 2010 6:54 PM by ScottGu
@Peter,
>>>>>>>> Can you give us an estimate on the patch? (hours, days, weeks?)
We did not receive advance disclosure of yesterday's report, so do not have a patch available yet. We are working hard on one though. There are lots of different platform matrixes and localization languages to build/test/verify which is why producing a
patch with high confidence enough to deploy automatically across millions of machines takes a bit of time to get right. In the meantime we published the above workaround to prevent attacks using the attack approach discussed publicly yesterday.
Hope this helps,
Scott
</ScottGuthrie>
David L. Penton
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
"You're looking to find the difference between two different types of "bad" responses. One where the padding was invalid (i.e., decryption failed in the block stream decoding), and one where the padding was good but the cyphertext was bad (i.e., decryption
failed in the message validation)."
I believe that the server responds differently (ie. there's s timing difference) if the padding is correct compared to when the padding is invalid. Thus the random delay.
abdullin
Member
8 Points
7 Posts
Web.config change does not prevent the exploit!
Sep 18, 2010 07:22 PM|LINK
Hi all,
I've been researching additional information on the exploit. It seems that changing the web.config and/or adding random delay is not enough to prevent the attacker from using the exploit.
As one of the authors have mentioned:
> error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different
Update: people suggested that random delay would not work either.
1. Attacker sends request to resource. Records that it costs 500ms;
2. Attacker sends requests to brutforce and just waiting for more then 500ms, and that means error.
Am I correct? Any comment from Microsoft would be appreciated.
Rinat Abdullin
http://abdullin.com
mbanavige
All-Star
135166 Points
15505 Posts
ASPInsiders
Moderator
MVP
Re: Web.config change does not prevent the exploit!
Sep 18, 2010 09:18 PM|LINK
The recommendations from MSFT are not attempting to hide that an error occurred in the page request. Instead, they are recommending that ALL errors result in the exact same error page - so as not to give the attacker any clues as to what caused the error.
That's not the point though. The default error page itself means error.The same error page makes the error message irrelevant
The same error page also makes the HTTP status irrelevant as the status will always be the same
It is the "big timing difference" that the random sleep addresses. Theoretically, the exact same errors should have a response time that repeats. So the attacker could speculate about the nature of the error based on that repeating response time. By adding in a random sleep, identical errors will have widely varying response times. with no discernable pattern to the response times, the attacker is again prevented from learning or effectively guessing at what the real underlying error was.
So it's not about hiding that an error occurred.
It's about hiding which error occurred.
abdullin
Member
8 Points
7 Posts
Re: Web.config change does not prevent the exploit!
Sep 18, 2010 09:46 PM|LINK
Mike, thanks for the update.
But what about running the same request, multiple times just to get the distribution of delays? Isn't there going to be some bias even with RNG?
38000 requests took 300 seconds. Multiply it by, say, 10000 == 830 hours. Split this between 100 async processes (or a few cloud VMs) and you've got 8 hours (unless IIS would not go down because it's threads are sleeping).
BTW, are there any estimates on the patch availability?
Rinat Abdullin
http://abdullin.com
Eilon
Contributor
5753 Points
976 Posts
Microsoft
Re: Web.config change does not prevent the exploit!
Sep 18, 2010 10:41 PM|LINK
The RNG used by the recommended fix on ScottGu's blog (http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx) uses a cryptographically secure RNG, so its distribution should be incredibly difficult to predict.
davidpenton
Member
595 Points
100 Posts
ASPInsiders
Re: Web.config change does not prevent the exploit!
Sep 20, 2010 02:35 AM|LINK
There are many configurations that must be tested before Microsoft can release a patch. From Scott Guthrie's post:
<div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"># re: Important: ASP.NET Security Vulnerability</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">Saturday, September 18, 2010 6:54 PM by ScottGu</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">@Peter,</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">>>>>>>>> Can you give us an estimate on the patch? (hours, days, weeks?)</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">We did not receive advance disclosure of yesterday's report, so do not have a patch available yet. We are working hard on one though. There are lots of different platform matrixes and localization languages to build/test/verify which is why producing a patch with high confidence enough to deploy automatically across millions of machines takes a bit of time to get right. In the meantime we published the above workaround to prevent attacks using the attack approach discussed publicly yesterday.</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">Hope this helps,</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste"></div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">Scott</div><ScottGuthrie>
# re: Important: ASP.NET Security Vulnerability
Saturday, September 18, 2010 6:54 PM by ScottGu
@Peter,
>>>>>>>> Can you give us an estimate on the patch? (hours, days, weeks?)
We did not receive advance disclosure of yesterday's report, so do not have a patch available yet. We are working hard on one though. There are lots of different platform matrixes and localization languages to build/test/verify which is why producing a patch with high confidence enough to deploy automatically across millions of machines takes a bit of time to get right. In the meantime we published the above workaround to prevent attacks using the attack approach discussed publicly yesterday.
Hope this helps,
Scott
</ScottGuthrie>
"Mathematics is Music for the mind, and Music is Mathematics for the Soul. - J.S. Bach"
owjeff
Member
136 Points
37 Posts
Re: Web.config change does not prevent the exploit!
Sep 20, 2010 05:27 PM|LINK
With regards to the timing and how that effects it, from what I've read, the issue is with how fast the server responds with regards to the error:
http://www.reddit.com/r/programming/comments/dfhnz/think_the_aspnet_padding_oracle_exploit_is_no_big/
"You're looking to find the difference between two different types of "bad" responses. One where the padding was invalid (i.e., decryption failed in the block stream decoding), and one where the padding was good but the cyphertext was bad (i.e., decryption failed in the message validation)."
I believe that the server responds differently (ie. there's s timing difference) if the padding is correct compared to when the padding is invalid. Thus the random delay.
OrcsWeb: Managed Windows Hosting Solutions
"Remarkable Service. Remarkable Support."