
Confusing Crypto Blobs - daeken
http://daeken.com/confusing-crypto-blobs
======
tptacek
It is absolutely not the case that people tend to get encrypted blobs right
nowadays. All-zeros IVs, ECB-mode encryption, failure to authenticate date,
repeated CTR nonces, wrappable/seekable CTR counters --- these are all things
that we've found just within the last several months.

Major components of popular high level web stacks have had bugs of this
severity lurking in them for years.

~~~
andrewcooke
what's seekable CTR counter mean (i know what CTR mode is)? would appreciate a
reference if you have one. thanks.

~~~
tptacek
CTR generates a keystream using a nonce and a counter as inputs; neither the
nonce nor any single value of the counter can be used for more than 1 item of
data.

~~~
rjones
If you find this kind of stuff interesting, take Dan Boneh's Cryptography
class on Coursera. It covers issues like this very well...

<https://www.coursera.org/course/crypto>

~~~
andrewcooke
as i said, i think i understand CTR mode. or thought i did. i was more curious
about how you could seek to a particular counter value. and then was even more
confused by the idea that _neither_ nonce nor counter can be repeated, as i
thought it was the _combination_ that had to be unique. so maybe i do need to
take that course. hmmm.

~~~
tptacek
There are systems that use CTR mode as a way to do "random access" bulk
encryption, because Schneier suggested that in both his major crypto books.

The specific exploitable condition is indeed the recurrence of a specific
nonce/counter tuple; the point is, there are systems in which attackers can
induce that condition, as opposed to simply having the system blunder into it
(for instance, by using the same nonce every time).

~~~
andrewcooke
ah, ok, thanks. "random access" makes everything much clearer.

~~~
tptacek
You end up with similar problems when you try to use CTR with 64 bit block
ciphers, like Blowfish and DES-EDE --- both of which are very common.

------
wooster
Can anyone offer any insight as to why you wouldn't generate a one-time random
string with a short lifetime for password reset emails? Sending a blob with
data in it (encrypted or otherwise) seems like a potential information leak
with no upside.

~~~
tptacek
That is exactly what you should do. The only upside to sending semantically
meaningful data in email tokens is that parsing the responses doesn't require
a central database lookup --- but that upside itself comes with the downside
of losing the control that a simple database table gives you over outstanding
tokens. And that's not really an "upside"; it's just a convenience.

Don't encrypt reset tokens. Send random strings.

~~~
ars
You have to be careful though. If someone managed an SQL injection and can
read tables, but you are using bcrypt hash properly, you might think you are
[somewhat] safe. (i.e. at least they can't write anything.)

But if they can read the password reset tokens from your database they can
login as any of the users. (This is especially bad if changing a password
doesn't invalidate "keep me logged in" cookies.)

The solution is to treat those tokens as passwords, and hash them as well.

(I know this because I had to clean up after this exact senario happened to
someone using Joomla. They got an admin login from a password reset token,
from there they were able to write files to disk and fully take control of the
server.)

~~~
tptacek
If you're writing injectable SQL queries, there is nothing I can tell you
about crypto and password resets that can help you.

Not all vulnerabilities are equally easy to blunder into. We can presume a
competent development team will avoid SQL injection, or at least, will
discover accidentally introduced SQLI quickly through testing. The same is not
the case with crypto flaws.

~~~
ars
In that case why bother using bcrypt? After all your queries are perfect and
no one can access the database.

I'm being sarcastic if it wasn't obvious.

~~~
tptacek
Another way to think about it is: if you're using an SQL database at all,
you've signed up for SQLI mitigation whether you use the database for reset
tokens or not. However, you still have the option of not having to deal with
crypto bugs.

------
forgotusername
> but if you can put in any data you want, you could poison the compression
> enough to put it into a bad state -- one where effectively nothing
> compresses properly, and you end up with your own data completely in the
> clear.

This sounds interesting, and completely counter to my understanding of how
compression works.. I thought CRIME's innovation was to exploit compression
ratios as a proxy for cleartext. Poking a compressor into emitting
probabilistically assigned bit-aligned symbols that happen to correspond to
its input seems unlikely.

~~~
DannyBee
A lot of compression algorithms use fixed size dictionaries over a window.
Let's take the canonical example of zlib/gzip, which does this.

With careful control over the data, you could make it so no dictionary lookup
would ever succeed. This would mean no strings would ever be eliminated
through backreferences.

Most also have a minimum match length, making your life a bit easier here.
Most also are outputting encoded streams that basically a little decompression
VM (IE literal, 0, backreference, 255 bytes ago, size 30). Because of this,
they will not eliminate duplicates where the match is too small (only 2
bytes).

This will get you past the duplicate elimination phase, but not the huffman
phase.

Getting past the huffman phase is harder. To get it to output a stored block,
you have to convince it the raw literal length of the block will end up less
than the length of the block as encoded.

For zlib, we have opt_len = (sizeof (compressed data in bits) + sizeof
(huffman tree in bits ) + 3 + 7) / 8

if (stored_len+4 <= opt_lenb) use stored block

So you do have some chance to beat it by messing with the probability
distributions, and do get a little leeway.

On the plus side, you only need to mess with the probability for a single zlib
block, not the whole shebang.

------
chime
Other than forgot-password, why use blobs at all? Only other rare use of blobs
that I can think of is proxying users from one domain to another (single sign-
on, session sharing etc.)

Why would a site use blobs for reporting?

~~~
DanBlake
I dont get why you would bother using a blob for forgot password.. Isnt
something like
reset.php?account=joeblow&auth=md5(accountname/secretkey/first10charsofcurrentpasshash/yymmdd)
enough?

You cant replay attack the reset link once its used, it expires in 24 hours
and so long as the 'secretkey' was sufficiently unique, you wouldnt be able to
bruteforce or crack it.

All the php script needs to do is attempt to build a 'good' md5 hash and see
if they match- if they do, let you input a new password to store.

~~~
tptacek
An attacker can do an offline brute-force attack on the "secret key" in this
scheme, since attackers can be presumed to know at least one valid password in
the system.

Just use a random string as a primary key for a token table in a database and
be done with it.

~~~
mikeash
The secret key could easily be huge without much of a penalty, though.

~~~
tisme
Why go for a second rate solution when a first rate solution has the same
operational costs?

~~~
mikeash
No idea. Just saying that the stated objection need not apply.

------
keeperofdakeys
Why do they even need to store arbitrary data in the blob at all? You can
simply use it as a token-id for the server. While it does dramatically
increase the amount of data that needs to be stored, and accessed, it nearly
prevents attacks like this.

------
njharman
TIL, you can make significant money bug hunting.

~~~
daeken
It can be good money, but it can also be a big time sink; really just depends
on the site. CCBill was super easy for me on the whole, but I've struggled
with others: I only found 3 or 4 bugs in PayPal, never found anything in
Facebook, etc.

~~~
bvdbijl
What was you experience with the PayPal bug bounty? It seems there's a lot of
negativity (like [http://l8security.com/post/33876600904/paypal-bug-bounty-
a-l...](http://l8security.com/post/33876600904/paypal-bug-bounty-a-lesson-in-
not-being-a-fuckup))

~~~
daeken
I submitted a couple bugs a while back, and they asked for some clarification
on one of them which I didn't ever take care of (just haven't had the time or
motivation). Given that, I really don't have any opinion on their bounty
program either way thus far; should I ever put some real effort into it, I'll
probably write about my experience.

