Update #2: Another good post echoing the “MITIGATE” theme (no signs of “PREVENTION” yet.) And some clarification from SO on how machineKey leaves other files (*.config, /bin/*) vulnerable:
“In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application - including web.config file, which often contains passwords.”
This vector was first published in 2002 (8 years ago) and it’s not unique to .NET either – aspects of JSF, Rails, Django all seem to be affected (is the theme really as simple as encrypted data on the client?).
Update #1: Rinat Abdullin and Vlad Azarkhin offer some good details   on this (the only blogs among my subscriptions to even mention the issue so far). Apparently, the difference in response times (among other subtle differences) still allows one to separate errors from accepted responses  – though this would require more of a site-specific attack. And the ability to request *.config files might be a secondary exploit for CMS products like DNN or Sitecore that expose the File System through authoring interfaces – though others are suggesting that it can be obtained through WebResource.axd (which uses some kind of key to authenticate incoming request for arbitrary resources).
For a low-level (detailed) explanation of the issue, see Brian Holyfield’s post .
Here’s a demo of POET  on DNN  – still unclear how this can be used to actually request *.config files though (potentially more serious, IMO):
The suggested fix , part of standard deployment best-practices, is to mask underlying HTTP error codes:
<customErrors mode="On" defaultRedirect="~/error.html" />
That’s the guidance from Microsoft, anyway; the group that released this video claims that “the setting of CustomErrors is _irrelevant_”.
Lots of confusion over this one, let’s hope it gets cleared up ASAP – stay tuned.
 – POET: the tool at the heart of the controversy:
 – Guidance from Microsoft:
 – Details from Rinat:
 – “Padding Oracle” ASP.NET Vulnerability Explanation
 – Automated Padding Oracle Attacks with PadBuster