5

I was reading this SO question when I was struck by @Slauma's link response (included here) to the chosen answer written by @reach4thelasers. It's a blog post of how to crack ASP.NET's forms authentication wide open and collect the remote machine key in about half an hour's time.

There were some responses to the blog post that mentioned this was only possible if you didn't do some specific things, but I was not clear on what those specific things were (something about a custom errors page, but the video didn't seem to hit any error page). It also mentioned MS had recommendations to avoid these sorts of attacks, but there was no link to the recommendation.

So, first up, can someone clearly explain what is necessary, when developing an ASP.NET forms authentication system, to prevent exploitations like the one mentioned above?

Secondly, are there any other well-known exploits in ASP.NET forms authentication that a certain best practice (that is not implemented by default) will mitigate or prevent? I am building a public site with financial data, so this is of serious concern to me.

Community
  • 1
  • 1
Jeremy Holovacs
  • 22,480
  • 33
  • 117
  • 254
  • I believe that you talk about that : http://stackoverflow.com/questions/3720720/how-serious-is-this-new-asp-net-security-vulnerability-and-how-can-i-workaround – Aristos Apr 13 '13 at 12:26
  • And a similar question from me is http://stackoverflow.com/questions/2498599/can-some-hacker-steal-the-cookie-from-a-user-and-login-with-that-name-on-a-web-s – Aristos Apr 13 '13 at 12:27

1 Answers1

4

This was already addressed a long time ago: http://technet.microsoft.com/en-us/security/bulletin/MS10-070

Scott Gu wrote about it at the time http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx

This SO question covers some the impact of the issue Is it vulnerable to ASP Padding oracle

I would say that the main take away is that patches and upgrades in frameworks are are less dangerous than leaving production apps at an old framework, old patch level, something that the change control boards of large organizations see in reverse. They generally fear the patches & updates more than the possibility of vulnerabilities in existing code.

Community
  • 1
  • 1
MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • Fantastic. I was a bit misled by the comments on the blog post, it seems... they seemed to be suggesting action had to be taken by the developer to prevent this. – Jeremy Holovacs Apr 13 '13 at 12:32
  • 1
    A few years ago I saw an installation of ASP.NET 1.0 around the time of the release of 3.5-- this could only have happened out of pathological fear of patches. That site could still have the issue, but even there, they'd have to have turned off windows updates, which delivers most of these sort of patches. When my server admins say they want to patch or update framework, I tell them "please!" even if it will mean some work checking that functionality still works the same. – MatthewMartin Apr 13 '13 at 12:39
  • I can't write a book here, but I want to more clearly explain the position of CCB's in very large organizations. I work for a very large organization (27K+) and they are slow to move forward and apply patches as well. However, that's primarily because there are more actors involved than you can count on two hands. Nothing in a large organization is, "just do it and it'll work - and if it doesn't we'll deal with it." I just doesn't work like that. So, you upgrade lower environments first, test them thoroughly, and then schedule off peak hours for updates. – Mike Perrenoud Apr 13 '13 at 12:41
  • @MichaelPerrenoud Ah, I don't oppose the idea of CCBs. It's just that the ones I've been involved in all actively alternate between active sabotage of all change & rubber stamping requests, in both cases independent of the technical merits of the proposed change. At best the CCB adds an extra layer of risk and effort without the benefit of oversight or a 2nd opinion at worst it halts all activity until the teams disband & the project gets canned driving development & support out of the organization into contract arragements beyond the reach of the CCB. Hopefully we didn't work at the same org. – MatthewMartin Apr 13 '13 at 15:24