Amazon Web Services signature version 1 is insecure

http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html

by cperciva • 18 years ago

48 52 18 years ago

there• 18 years ago

i believe flickr's api uses the same method of creating signatures.

cperciva16• 18 years ago

I just looked at the flickr API documentation, and it looks like you're right -- maybe that's where Amazon got the idea from. I'm not sure if it's a problem in flickr's case, but I'll send them an email pointing out the possible problem.

cperciva16• 18 years ago

This is interesting: I submitted this article both here and to programming.reddit.com; but at the same time as becoming the top story on news.yc, it got voted down on reddit (well, 1 up vote, 2 down votes).

I wonder if this is just the random luck of who happened to see the post on reddit first, or if news.ycers are innately more interested in security-related stories than programming.redditers.

byrneseyeview• 18 years ago

You may have a better brand name on news.yc.

Freaky• 18 years ago

Seems to be doing better on the netsec subreddit. +8, no downvotes in an hour, vs +4-8 in 11 hours on progit

cperciva16• 18 years ago

Aha, that explains why I've been seeing traffic from reddit in my logs for the past two hours -- thanks for resubmitting it to the more appropriate subreddit.

jamess3• 18 years ago

Does it worry anyone else that there seems to be no protection provided against replaying any particular authenticated request? If I were using this service, I'd heavily recommend restricting non-https requests to read-only operations. Any updates or deletes should be done using a security protocol proofed against replay attacks, like HTTPS.

cperciva16• 18 years ago

At least in the case of SimpleDB, replaying requests is usually not a problem -- if you Put or Delete an attribute which has already been Put or Deleted, it has no effect.

jamess3• 18 years ago

Sorry, but you aren't thinking like a security professional here. Consider the case, e.g., where you create a domain, delete it and recreate it. An attacker monitoring the deletion can with impunity wipe out your data at a later date.

jgrahamc2• 18 years ago

This is a lovely reminder that designing cryptographic protocols is hard. Even something as simple as signing a bit of data can have nasty pitfalls.

cperciva16• 18 years ago

I wouldn't say that this shows that designing cryptographic protocols is hard. "Use hashing and signature methods which don't have collisions" is a simple rule, both to remember and to apply -- no harder than "drive on the right side of the road" (or "drive on the left side of the road", depending on your country).

Would you say that driving is hard because people have to remember which side of the road to drive on?

jgrahamc2• 18 years ago

My assumption is that the Amazon people felt that by using HMAC-SHA1 they were secure because that's a well known way of hashing and signing something. The pitfall was in their implementation. They have such a simple system, yet they managed to make a mistake.

This sort of problem is one of the reasons that I made the crypto in tumbler (http://tumbler.sf.net/) as simple as possible because I was sure that if I did anything but total simplicity I would screw it up.

tptacek19• 18 years ago

If there were 40 sides of the road to choose from, and the side you drove on depended on the time of day and the color of your car, then yes, Colin, I would say driving on the correct side of the road would be hard too.

Have you ever, in your whole career, worked with a team that wrote their own crypto and got it right in version 1? Because I haven't.

tlrobinson• 18 years ago

Perhaps it's just late and my mind is tired, but it took me a minute to understand what was going on. Maybe a simpler example would be helpful.

Since the delimiters are removed before computing the signature (so each is just "ABCDEFGHIJLM"), the signatures for the following two query strings are the same:

    ?A=B&C=D&E=FHIJKLM

    ?A=B&C=D&E=F&H=I&J=K&L=M

So if the value of of the E parameter is controlled by the user, they can construct a value ("HIJKLM") such that the resulting signatures is the same as the signature for a query with a bunch of additional parameters they choose ("H=I&J=K&L=M").

Clever.

tptacek19• 18 years ago

Example #489643876834 of why you, a very smart, very capable developer, should not be writing crypto code. Rule #1: if you have to type the letters A-E-S or S-H-A into your code, you're doing it wrong.

brl5• 18 years ago

There are pretty big mistakes to be made on the other side of this philosophy as well. If you need to solve some cryptographic problem which is not exactly the same as something which has already been designed, implemented, and reviewed by competent cryptographers, then you essentially need to create a new protocol and accept all the pitfalls which that entails.

PGP seems to be a popular 'primitive' to try to roll your own broken crypto protocol out of.

Exhibit A: http://enigform.mozdev.org/

Exhibit B: http://web.monkeysphere.info/

Even SSL/TLS is not easy to use correctly (while understanding all the risks) for purposes other than what it was originally designed for: Preventing credit card numbers from being sniffed between a browser and a web merchant.

tptacek19• 18 years ago

Design a transport security protocol that is different in some way from TLS, and a good chunk of those differences are going to be vulnerabilities that the TLS designers figured out that you missed.

SSLv1 may have been originally designed for securing credit cards, but I'm not sure that argument survives a close read of TLS; why waste time with mutual authentication, with forward secrecy, with a custom record layer, with arbitrary length certificate signing chains, etc etc etc. You might be surprised at the number of systems that leverage TLS successfully on ports other than 443.

We probably agree; no matter how you choose to implement crypto security in a system, you're probably worse off for trying.

kirse2• 18 years ago

You seem to be knowledgable on these topics, so I have a question... If I take the query string parameters and then a ridiculously long pre-determined salt (30 chars) to create a SHA-256 signature for POSTing, what's the chance that this will actually result in collisions / cracking?

Even if null data is submitted and someone sniffs the salt, it's still 30-chars long and last I checked rainbow tables don't work too well on SHA-256 hashes of that length.

I ask because I use a system similar to this to just do a basic check to ensure that a form POST is coming from a user clicking an action and not just some random spammers' form just posting the needed vars. It's nothing particularly secure (I think), just a nuisance to any spammer.

tptacek19• 18 years ago

First, you're talking about a nonce, not a salt. You'd be a happier person if you took the word "salt" out of your CS vocabulary.

Second, the vulnerability here isn't password cracking; it's that AMZN verifies the signature on canonicalized data, but operates on non-canonicalized data.

brlewis• 18 years ago

The developer who made this mistake probably didn't think s/he was writing crypto code. (Switching to "he" for brevity) He probably thought he was merely making use of someone else's crypto code. The mistake was in choosing what string to sign, not in the function applied to that string after it was chosen. I think the real lesson here is that if your app needs cryptography, then you need at least a black-box understanding of what crypto does and doesn't do.

tptacek19• 18 years ago

In my experience, the people who do the worst at building secure systems are the ones who know "just enough" about how crypto works. These are the people who implement Diffie-Hellman and don't check parameters, the people who implement AES in ECB mode, the people who store passwords hashed with ultra-fast digest schemes, the ones that leak timing information or cipher state in distinguishable error messages, and the people who implement mirrorable challenge-response protocols.

The "dumb" developers just use OpenSSL and PGP, and they usually come out ahead in the end.

Also: I doubt the Amazon implementers here were dumb. I bet they were pretty smart. They just forgot about canonicalization; this is a classic problem in signature systems. Building crypto features is a good way to get screwed.

(PS: I feel qualified to take a contract breaking systems like this, but probably not qualified enough to engineer my own crypto protocol.)

Amazon Web Services signature version 1 is insecure

Related Stories