Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-03 Thread Peter Gutmann
Jerry Leichter leich...@lrw.com writes:

By the way, the don't acknowledge whether it was the login ID or the
password that was wrong example is one of those things everyone knows -
along with change your password frequently - that have long passed their
use by date.  

You got there before I did - real-world studies of users have shown that a
common failure mode for this is that when users get their user name wrong they
then try every password they can think of under the assumption that they've
remembered the wrong password for the site.  So not only does not
distinguishing between incorrect username and incorrect password not help [0],
it actually makes things much, much worse by training users to enter every
password for every site they know.

Peter.

[0] Well, it helps the attackers I guess...

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-03 Thread Richard Outerbridge

On 2010-10-02 (275), at 19:10, Jerry Leichter wrote:


On Oct 1, 2010, at 11:34 PM, Richard Outerbridge wrote:


[]

By the way, the don't acknowledge whether it was the login ID or  
the password that was wrong example is one of those things  
everyone knows - along with change your password frequently -  
that have long passed their use by date.  Just what attack on a  
modern system does revealing that a guessed login ID is correct  
actually allow?  It can only be used in on-line attacks, and it's  
been years since any decent system didn't protect against high rates  
of failures in on-line authentication.  Besides, valid - or highly- 
probably-valid - login ID's are typically cheaply available for most  
systems anyway.


I said it was old :)  but it's still as true now as a use-case as it  
was way back then, in its time.


Richard


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-03 Thread Kevin W. Wall
Peter Gutmann wrote:
 Jerry Leichter leich...@lrw.com writes:
 
 By the way, the don't acknowledge whether it was the login ID or the
 password that was wrong example is one of those things everyone knows -
 along with change your password frequently - that have long passed their
 use by date.  
 
 You got there before I did - real-world studies of users have shown that a
 common failure mode for this is that when users get their user name wrong they
 then try every password they can think of under the assumption that they've
 remembered the wrong password for the site.  So not only does not
 distinguishing between incorrect username and incorrect password not help [0],
 it actually makes things much, much worse by training users to enter every
 password for every site they know.
 
 Peter.
 
 [0] Well, it helps the attackers I guess...

There's other reasons that this is still done that relate to regulatory issues.
E.g., if the user names are considered by the regulatory body as sensitive PII,
this sometimes happens that these regulatory bodies mandate that one should not
distinguish between invalid user name or invalid password. So you can argue that
those regulatory bodies are misguided and/or behind the times, but can't always
blame the application developers. At other times, it is just some ill-advised
corporate policy that developers are forced to adhere to. I'm sure that you all
know well that those who understand the risks best are not always those setting
policy.

-kevin
--
Kevin W. Wall
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.-- Nathaniel Borenstein, co-creator of MIME

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-02 Thread Richard Outerbridge

On 2010-10-01 (274), at 12:29, Brad Hill wrote:


Kevin W. Wall wrote:
isn't the pre-shared key version of W3C's XML Encrypt also going to  
be vulnerable

to a padding oracle attack.


Any implementation that returns distinguishable error conditions for  
invalid
padding is vulnerable, XML encryption no more or less so if used in  
such a
manner.  But XML encryption in particular seems much less likely to  
be used

in this manner than other encryption code.


Oh come on.  This is really just a sophisticated variant of the old  
never say
which was wrong - login ID or password - attack.  In this case it's  
padding or
MACing.  If either fails the result should be the same: something went  
wrong,
sorry for you.  The POET Oracle depends upon the server taking a  
shortcut and

signaling which went wrong first.

--
Perfect games of Draughts always end in draws.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-02 Thread Jerry Leichter

On Oct 1, 2010, at 11:34 PM, Richard Outerbridge wrote:
Any implementation that returns distinguishable error conditions  
for invalid padding is vulnerable...
Oh come on.  This is really just a sophisticated variant of the old  
never say which was wrong - login ID or password - attack.  In  
this case it's padding or MACing.  If either fails the result should  
be the same: something went wrong, sorry for you.  The POET Oracle  
depends upon the server taking a shortcut and signaling which went  
wrong first.
I wouldn't call that a shortcut - one has to actually define two  
failure returns and choose which one to send.  More code, more  
complexity.  But ... there's a reason for doing this, in virtually all  
situations:  Manageability, Without some detail as to exactly what  
went wrong, it's very hard to know what to correct or even where to  
look.


Cryptographic protocols are outliers here, because here you really  
can't afford to make the system manageable if the cost is that it  
can then serve as an oracle.  This is one reason it's so hard for most  
developers to produce correct crypto implementations:  So much of what  
is good practice almost everywhere else ends up being hazardous when  
it comes to cryptography.


It's not that there are *no* other situations where better error  
messages are a potential liability.  The classic example is error  
messages that leak information about directory configurations or  
database tables, thus enabling other attacks.  The difference is that  
such information, in most cases, is only problematic if the actual  
system *has some other vulnerability*.  We may not be at all good at  
producing systems without such vulnerabilities, but at least we know  
in general principle how to do so.  (If there are no SQL injection  
attacks, knowing what tables exist probably isn't useful to an  
attacker.)  One might argue that a cryptosystem that is vulnerable to  
a what failed attack is also buggy - but we really have no general  
idea how to fix them.  So we have to avoid them by accepting hard-to- 
manage protocols.


By the way, the don't acknowledge whether it was the login ID or the  
password that was wrong example is one of those things everyone  
knows - along with change your password frequently - that have long  
passed their use by date.  Just what attack on a modern system does  
revealing that a guessed login ID is correct actually allow?  It can  
only be used in on-line attacks, and it's been years since any decent  
system didn't protect against high rates of failures in on-line  
authentication.  Besides, valid - or highly-probably-valid - login  
ID's are typically cheaply available for most systems anyway.


I'm really tired of using up my on-line password tries, only to  
discover that I accidentally erased the last character on the login  
name, or added a trailing \ when I went for the RETURN key!  Systems  
are *so* nice to keep re-prompting with the bogus username.


Really, most systems these days reveal valid usernames quite easily.   
Both Windows boxes and Macs typically give you a pull-down list of  
accounts to log into.  Web logins have ways to recover passwords for  
lost accounts that usually reveal if you get the account name wrong -  
and then give you a way to recover the account name.  Can you think of  
an example in, say, the last 20 years of an attack that would not have  
been possible if the system had made it difficult to determine valid  
usernames?

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-01 Thread Brad Hill
Kevin W. Wall wrote:
 isn't the pre-shared key version of W3C's XML Encrypt also going to be 
 vulnerable 
 to a padding oracle attack.

Any implementation that returns distinguishable error conditions for invalid 
padding is vulnerable, XML encryption no more or less so if used in such a 
manner.  But XML encryption in particular seems much less likely to be used 
in this manner than other encryption code.

The primary use case you cite for PSK, an asynchronous message bus, is 
significantly less likely to return oracular information to an attacker than a
synchronous service.  And due to the rather unfavorable performance of
XML encryption, in practice it is rarely used for synchronous messages.  
Confidentiality for web service calls is typically provided for at the transport
layer rather than the message layer.  SAML tokens used in redirect-based
sign-on protocols are the only common use of XML encryption I'm aware 
of where the recipient might provide a padding oracle, but these messages
are always signed as well.

Brad Hill

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-29 Thread James A. Donald

On 2010-09-28 1:58 PM, Thai Duong wrote:

On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz  wrote:

I'm one of the authors of the attack. Actually if you look closer, you'll see
that they do it wrong in many ways.


The FormsAuth as well, not just the view state? �Interesting, I thought they
had that one right, at least.


We promised Microsoft not to release anything before they have a
working patch. Now they have it, so we release the slide we presented
at EKOPARTY. Check it out.

http://netifera.com/research/poet//PaddingOraclesEverywhereEkoparty2010.pdf


Now I understand why one should, counterintuitively, encrypt then MAC.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-29 Thread Kevin W. Wall
Thai Duong wrote:
 On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann
 pgut...@cs.auckland.ac.nz wrote:
 
 Ye gods, how can you screw something that simple up that much?  They use the
 appropriate, and secure, HMAC-SHA1 and AES, but manage to apply it backwards!
 
 I guess they just follow SSL.
 
 BTW, they screw up more badly in other places. Download .NET
 Reflector, decompile .NET source, and do a grep 'DecryptString',
 you'll see at least three places where they don't even use a MAC at
 all.

So, I think I brought this up once before with Thai, but isn't the
pre-shared key version of W3C's XML Encrypt also going to be vulnerable
to a padding oracle attack. IIRC, W3C doesn't specify MAC at all, so unless
you use XML Digital Signature after using XML Encrypt w/ a PSK, then
it seems to me you are screwed in that case as well. And there are
some cases where using a random session key that's encrypted with a
recipient's public key is just not scalable (e.g., when sending out
to over something like Java Message Service, or the Tibco Bus, or
almost anything that uses multicast). And even if a new XML Encrypt
spec for using with PSK was adopted tomorrow, the adoption would take
quite a long time.  Sure hope I'm wrong about that. Maybe one of
you real cryptographers can set me straight on this.

-kevin
--
Kevin W. Wall
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.-- Nathaniel Borenstein, co-creator of MIME

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-28 Thread Thai Duong
On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:

 Ye gods, how can you screw something that simple up that much?  They use the
 appropriate, and secure, HMAC-SHA1 and AES, but manage to apply it backwards!

I guess they just follow SSL.

BTW, they screw up more badly in other places. Download .NET
Reflector, decompile .NET source, and do a grep 'DecryptString',
you'll see at least three places where they don't even use a MAC at
all.

Thai.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-27 Thread Thai Duong
On Wed, Sep 15, 2010 at 11:07 AM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
 Tom Ritter t...@ritter.vg writes:

What's weird is I find confusing literature about what *is* the default for
protecting the viewstate.

 I still haven't seen the paper/slides from the talk so it's a bit hard to
 comment on the specifics, but if you're using .NET's FormsAuthenticationTicket
 (for cookie-based auth, not viewstate protection) then you get MAC protection
 built-in, along with other nice features like sliding cookie expiration (the
 cookie expires relative to the last active use of the site rather than an
 absolute time after it was set).  I've used it in the past as an example of
 how to do cookie-based auth right

 Peter.


I'm one of the authors of the attack. Actually if you look closer,
you'll see that they do it wrong in many ways.

Here is a video that we just release this morning at EKOPARTY:
http://www.youtube.com/watch?v=yghiC_U2RaM

Slide, paper, and tools will be released on http://www.netifera.com/research.

Thai.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-27 Thread Kevin W. Wall
Peter Gutmann wrote:
 Tom Ritter t...@ritter.vg writes:
 
 What's weird is I find confusing literature about what *is* the default for
 protecting the viewstate.
 
 I still haven't seen the paper/slides from the talk so it's a bit hard to
 comment on the specifics, but if you're using .NET's FormsAuthenticationTicket
 (for cookie-based auth, not viewstate protection) then you get MAC protection
 built-in, along with other nice features like sliding cookie expiration (the
 cookie expires relative to the last active use of the site rather than an
 absolute time after it was set).  I've used it in the past as an example of
 how to do cookie-based auth right

FYI...I just received confirmation from my company's on-site consultant from
Microsoft that .NET's FormsAuthenticationTicket is also vulnerable to
this padding oracle attack. So apparently Microsoft didn't apply the MAC
protection quite right in their implementation.

-kevin
-- 
Kevin W. Wall
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.-- Nathaniel Borenstein, co-creator of MIME

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-15 Thread Peter Gutmann
Tom Ritter t...@ritter.vg writes:

What's weird is I find confusing literature about what *is* the default for
protecting the viewstate.

I still haven't seen the paper/slides from the talk so it's a bit hard to
comment on the specifics, but if you're using .NET's FormsAuthenticationTicket
(for cookie-based auth, not viewstate protection) then you get MAC protection
built-in, along with other nice features like sliding cookie expiration (the
cookie expires relative to the last active use of the site rather than an
absolute time after it was set).  I've used it in the past as an example of
how to do cookie-based auth right

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-14 Thread Tom Ritter
When their talk first started getting hyped on twitter last Thursday,
the focus was on ASP.Net's viewstate [1,2] rather than the cookie
aspect. (Viewstate is a base64 blob of data in a hidden form field
about the current state of controls on the page.) I wonder if
threatpost focused on cookies because it's more accessible to
non-webforms programmers.  On Friday, a tweet mentioning using HMAC on
the viewstate was a valid mitigation [3].  This made sense to me
because...

speculation
If Viewstates are protected with a simple hash by default, you could
append data and still generate a valid hash (because of many hash
functions' design flaw that created the need for HMAC itself [4]).

So you run the padding oracle attack described (which I won't explain
for fear of explaining it wrong) but you can append encrypted blocks
and generate valid hashes of your appended data.

Using HMAC on the viewstate instead of a vanilla hash function
prevents targeting the viewstate because you can no longer append
blocks and generate new hash.
/speculation

What's weird is I find confusing literature about what *is* the
default for protecting the viewstate.  In this article[5] it says that
in .Net 1.1 viewstates are HMAC-ed to prevent tampering...

validationKey - This specifies the key that the HMAC algorithm uses
to make ViewState tamper proof.


But this article [6] implies only SHA1 uses an HMAC and MD5 does not,
in .Net 2.0.  (.Net 2 also added encrypted viewstate which is another
story)

SHA1 - SHA1 is used to tamper proof ViewState and, if configured, the
forms authentication ticket. When SHA1 is selected for the validation
attribute, the algorithm used is HMACSHA1.
MD5 - MD5 is used to tamper proof ViewState and, if configured, the
forms authentication ticket.


And in this article[7], maybe the most recent, which talks about .Net
4.0 it gets even more confusing, adding specific HMAC options:


If your application is built on the .NET Framework 3.5 or earlier,
you can choose SHA1 (the default value), AES, MD5 or 3DES as the MAC
algorithm. If you're running .NET Framework 4, you can also choose
MACs from the SHA-2 family: HMACSHA256, HMACSHA384 or HMACSHA512.

After you choose a MAC algorithm, you'll also need to manually
specify the validation key. Remember to use cryptographically strong
random numbers: if necessary, you can refer to the key generation code
specified earlier. You should use at least 128-byte validation keys
for either HMACSHA384 or HMACSHA512, and at least 64-byte keys for any
other algorithm.


I'm thoroughly confused about what the default is in each version, and
how each option actually behaves.  Based on some of the documentation
and how I understand POET (their tool for the padding oracle attack)
working, I think there may be a disconnect between the writers, and
the security team.  I tried hard to get my company to send one of our
(non-security) Argentinean devs I'm friends with to ekoparty to take
notes and fill me in, but to no avail.  I hope after the presentation
blogs and this list fill with details about it.

Unrelated, at one point a phrase was written and echoed precipitously:
SHA1 is preferable because it produces a larger hash
http://www.google.com/search?q=%22larger+hash+than+MD5%22+%22and+is+therefore+considered+more+secure%22filter=0

Anyway, Colin Percival and Thomas Ptacek got in a discussion[x] about
Encrypt-then-MAC, reproduced here because following twitter
discussions is a pain:

  Ptacek: CBC + HMAC decrypt+validate is an infamously tricky piece of
code to get right. I've never seen a generalist's implementation that
did.
  Percival: This is why (a) you should encrypt-then-MAC, not vice
versa, and (b) not use CBC mode.
  Ptacek: What does encrypt-then-MAC have to do with it? That's the
pattern that creates the timing variant of the attack.
  Percival: With encrypt-then-MAC, fake messages are discarded without
having their CBC padding inspected.
  Ptacek: Sorry, I misread. But then: you trust SHA256 as a first-line
defense more than AES?
  Percival: Do I trust HMAC-SHA256 more than AES? Hell yes.

Colin's right of course, if the HMAC option is used, then it should
throw out the attempts POET makes without indicating the padding is
good or bad... It's just that darned documentation that's confusing
me!

-tom


[1] http://twitter.com/dragosr/status/24070283257
[2] http://twitter.com/tqbf/status/24032786374
[3] http://twitter.com/dragosr/status/24073818333
[4] http://en.wikipedia.org/wiki/HMAC#Design_principles
[5] http://channel9.msdn.com/wiki/wiki/HowToConfigureTheMachineKeyInASPNET2/
[6] http://msdn.microsoft.com/en-us/library/ff649308.aspx
[7] http://msdn.microsoft.com/en-us/magazine/ff797918.aspx
[x] http://twitter.com/tqbf/status/24033073128
http://twitter.com/cperciva/status/24036001435
http://twitter.com/tqbf/status/24036476121