

Security researchers 'destroy' Microsoft ASP.NET security - dfj225
http://www.theinquirer.net/inquirer/news/1732956/security-researchers-destroy-microsoft-aspnet-security

======
pragmatic
Can anyone provide any more solid details? This article seems to be a lot of
hyperbole ("totally destroys") with little fact.

 _The error message provides a small tidbit of information about how ASP.NET
decrypts messages. With enough of these error messages it is possible to
decrypt the message in its entirety._

What message? The cookie itself?

~~~
daeken
As far as I can tell, this seems to allow you to decrypt the data within
cookies. However, what would be stored within these cookies aside from a
session ID? Some insight into what's actually stored in the cookie would be
good, as this seems very overblown.

~~~
pixelbath
Honestly, if you're storing sensitive user information, or site access
information in your cookies, then you deserve the resulting exploits.

I agree, unless this attack completely crashes the .Net stack to allow
privilege escalation or similar, it's complete hyperbole.

~~~
nopal
I'm inclined to disagree. Encrypted cookies should be secure, provided the
underlying encryption techniques are solid.

There are cases where having sensitive information in a cookie makes sense. In
a web farm, for example. A session store that serves a farm of web servers is
harder to set up and maintain than having clients send information back in a
cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed
cookies are also good for this scenario, if it's okay for the data to be seen
by others)

Am I wrong?

EDIT: Here's a good thread on how to ensure data on client cookies hasn't been
tampered with: <http://news.ycombinator.com/item?id=1687826>

~~~
dionysiac
Storing something like a username in client-side data and then trusting its
accuracy is effectively delegating your authentication outside you circle of
control. Saying that encryption will make this magically secure is like saying
encryption makes for effective DRM - eventually it will be compromised and you
will have a systemic problem.

Storing, say, a username and a password hash in your encrypted cookie is at
least as secure as direct authentication at each page load; even if they break
your encryption they still have to know the admin's password.

Start with the assumption that the locks you use for security will fail, and
ask "how will this break?" If we take the encryption out of the picture, do we
trust the client to log in as root (or similar) with just a username and no
password? The lock in question (as I understand it) is failing for an
unrelated (information disclosure) reason. The design decision to lean so hard
on the lock is what makes this such an issue.

~~~
DennisP
It's not like DRM. Effective DRM is impossible because the client has to have
the decryption key. All you can do is try to obscure it.

------
darwinGod
Alex Payne (One of Twitter's earlier employees..) had written a nice article
on why he does not work in Infomartion Security, quite a while ago.

<http://al3x.net/2008/12/31/why-not-infosec.html>

..the core point being,about how little attention genuine, path-breaking work
gets, if security researchers DO NOT make an attempt to publicise it,quite
radically.

These sure are not some random guys making a bold claim.. that work has been
published in Usenix!

------
cryptbe
The video is out <http://www.youtube.com/watch?v=yghiC_U2RaM>

------
markgamache
Totally irresponsible journalism. This is not all or .NET or even a tiny
fraction. It is one control that will be rapidly patched.

This allows the end user to decrypt their own "encrypted" cookie, not an
attacker. At best, if the web app writers were stupid and put truly
exploitable data in the cookie, they'd be effected.

It is horrible that MS missed this, but calling .NET broken is probably
actionable libel.

~~~
wccrawford
Plus, the researchers didn't destroy the security. It was never there in the
first place. And I doubt they were the first to exploit it, either.

~~~
tptacek
Exactly what evidence have you observed to make you believe that other
researchers have used CBC padding oracles to break the security of ASP.NET?

~~~
storm
Brian Holyfield claims to have been doing it for a bit
([http://www.gdssecurity.com/l/b/2010/09/14/automated-
padding-...](http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-
oracle-attacks-with-padbuster/#comment-416)), although his approach seems to
have relied upon default error emissions and is defeated by the common
customErrors=on configuration. It doesn't sound like today's attacks have such
limitations. And it isn't clear what actual effective workarounds exist, if
any.

Even in cases where app logic will trip this approach up early (making hard
assumptions about session vals having been initialized post-login and
consequently failing fast, etc), the secrets are still captured.

~~~
marcinw
Brian does not claim to have been doing it before Juliano or Thai. He wrote
the blog post to explain in layman's terms what the attack was and released
his own version of the original POET tool written in Perl.

------
brettbender
At least now the next time a client wants me to do something in .NET I have a
good excuse to gently persuade them to something else (until this gets
patched, at least).

~~~
ergo98
This exploit has remarkably little applicability to the vast majority of
ASP.NET applications. These guys are grossly overblowing this to try to get
attention.

~~~
tptacek
Exactly how do you know that? Juliano used his pre-existing tool (POET) to get
admin privileges on DotNetNuke, without ever having used DNN --- or,
presumably, modifying his tool. DNN is not an obscure .NET app.

What makes you make a comment like this? What evidence are you basing it on?

~~~
ergo98
>Exactly how do you know that?

I have never worked on an ASP.NET-based site that relied upon cookies,
encrypted or not, for anything. Even where the built-in forms authentication
was used the username always had correlating server-side state that was
triumphant.

So saying that you can modify cookies == a complete and utter non-issue for
any site that followed any reasonable security practices.

~~~
tptacek
The easy answer here is to say, "you mean besides DotNetNuke".

The deeper answer would be to point out that my day job is security evaluation
for apps, roughly 50% of which are Fortune-100 web applications, roughly 60%
of which are .NET applications, and you're flat-out wrong. There's a reason
why cookie/session security is #3 on the OWASP top 10.

You're also presuming that the issue being discussed is, specifically, a
cookie.

I understand why you're as defensive as you are; you're a professional .NET
developer and Hacker News is hostile to Microsoft and, especially, .NET.
Listen to me: I am not hostile to Microsoft _or_ .NET. Microsoft is a client
of ours. They do software security better than any company in the industry.
Take my word for it: it appears that they screwed this one up just like
everyone else that tries to encrypt with AES.

~~~
ergo98
>The easy answer here is to say, "you mean besides DotNetNuke".

Yes, I see you've already mentioned DNN. It's good that you have that example.
It would be interesting if I somehow claimed that every app is immune to it.

Countless apps have countless vulnerabilities.

>You're also presuming that the issue being discussed is, specifically, a
cookie.

I _know_ that the issue being discussed is specifically a cookie. It's
specifically an AES-encrypted cookie.

To your edit: Defensive? Hardly. I'm just bitter after an endless stream of
B.S. security claims by the security industry. It always follows the same
pattern of arm waving and press releases, with a promised demonstration, and
then the day of reckoning comes and...quiet. Maybe this will be the exception
but, we'll see.

This has nothing to do with any sort of loyalty to .NET, though I hardly find
HN to be anti-.NET, or anti-Microsoft for that matter. Whatever, in any case.
It isn't my fight to wage.

~~~
brl
"It always follows the same pattern of arm waving and press releases, with a
promised demonstration, and then the day of reckoning comes and...quiet."

A few minutes ago, live on stage at a security conference in Buenos Aires
(#ekoparty) they popped local SYSTEM privileges remotely on both DotNetNuke
and SharePoint installed in a typical production configuration.

In case you think they stacked the deck, those applications were chosen only a
couple of days ago after Juliano asked on Twitter for suggestions for the
presentation.

~~~
ergo98
What do you mean by "local SYSTEM"?

I eagerly look forward to details on it. Where might I find them?

~~~
brl
> What do you mean by "local SYSTEM"?

The highest system privilege level on Windows. They were able to interactively
run CMD.EXE as the LocalSystem account on the remote web server.

> I eagerly look forward to details on it. Where might I find them?

The details were not disclosed until today when the attack was presented at a
security conference. As far as I know there isn't anything available online
yet, but that should change very soon.

