ASP.NET padding oracle vulnerability, the video

A video of the POET-tool — used to exploit the ASP.NET padding oracle vulnerability — have been published to show the tool in action. The video shows the steps taken by the tool to compromise the web.config file of the application, which in this example contains the ASP.NET machine keys.





Following the results presented in the Usenix paper by Rizzo and Duong, the tool does not compromize the keys directly, but rather relies on the oracle to create a valid ciphertext which in turn can be used to retrieve the web.config from the application. The machine keys are not completely lost until the web.config is served as a regular file by ASP.NET.

Access to the machine keys enables forging of viewstates — as well as Forms authentication cookies. Apparently, a DotNetNuke cookie can be forged to log the attacker in as a superuser.

What happens after this is not related to the current ASP.NET vulnerability, but is related to a different vulnerability. Shell access is obtained to the machine through a known attack, and is carried out by installing a new module in DotNetNuke.

We'll return to the forged DotNetNuke cookie. Why is this possible? Well, yes, the encryption key and signing key for an authentication cookie are both compromised. Still, it's possible to tighten up session security in DotNetNuke. An authentication cookie should be tied to some server side state. When it's not, like in this demo, the entire authentication procedure can be skipped and rendered useless — unfortunately a very common setup in ASP.NET applications. In other words, losing your machine keys should not immediately lay open the road to log in to your application as a superuser!

I'll be blogging more about ASP.NET session management, and the whole "authorization based exclusively on client controlled state" idea. It's an important, though somewhat complicated matter.