Ran into Alex Halderman recently. He casually said "we found a weakness in
Diffie-Hellman." My jaw dropped. GO READ. https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/ …
The NSA does not have "an absolute right to gain access to every way in which two
people may choose to communicate." http://arstechnica.com/tech-policy/2015/04/nsa-dreams-of-smartphones-with-split-crypto-keys-protecting-user-data/ …
David Risney
@David_Risney :Level 7 of the Stripe CTF involved running a length extension attack on the level 7 server's custom crypto code.
"This is the kind of vulnerability that makes applied cryptographers cry tears of joy."
- 
Imagine a world where FBI director Comey talked about guns the way he talks about cryptography
@app.route('/logs/')
@require_authentication
def logs(id):
rows = get_logs(id)
return render_template('logs.html', logs=rows)
...
def verify_signature(user_id, sig, raw_params):
# get secret token for user_id
try:
row = g.db.select_one('users', {'id': user_id})
except db.NotFound:
raise BadSignature('no such user_id')
secret = str(row['secret'])
h = hashlib.sha1()
h.update(secret + raw_params)
print 'computed signature', h.hexdigest(), 'for body', repr(raw_params)
if h.hexdigest() != sig:
raise BadSignature('signature does not match')
return TrueThe level 7 web app is a web API in which clients submit signed RESTful requests and some actions are restricted to particular clients. The goal is to view the response to one of the restricted actions. The first issue is that there is a logs path to display the previous requests for a user and although the logs path requires the client to be authenticatd, it doesn't restrict the logs you view to be for the user for which you are authenticated. So you can manually change the number in the '/logs/[#]' to '/logs/1' to view the logs for the user ID 1 who can make restricted requests. The level 7 web app can be exploited with replay attacks but you won't find in the logs any of the restricted requests we need to run for our goal. And we can't just modify the requests because they are signed.
However they are signed using their own custom signing code which can be exploited by a length extension attack. All Merkle–Damgård hash algorithms (which includes MD5, and SHA) have the property that if you hash data of the form (secret + data) where data is known and the length but not content of secret is known you can construct the hash for a new message (secret + data + padding + newdata) where newdata is whatever you like and padding is determined using newdata, data, and the length of secret. You can find a sha-padding.py script on VNSecurity blog that will tell you the new hash and padding per the above. With that I produced my new restricted request based on another user's previous request. The original request was the following.
count=10&lat=37.351&user_id=1&long=%2D119.827&waffle=eggo|sig:8dbd9dfa60ef3964b1ee0785a68760af8658048ccount=10&lat=37.351&user_id=1&long=%2D119.827&waffle=eggo%80%02%28&waffle=liege|sig:8dbd9dfa60ef3964b1ee0785a68760af8658048cCode review red flags included custom crypto looking code. However I am not a crypto expert and it was difficult for me to find the solution to this level.
I was the 546th person to complete Stripe's web security CTF and again had a ton of fun applying my theoretical knowledge of web security issues to the (semi-)real world. As I went through the levels I thought about what red flags jumped out at me (or should have) that I could apply to future code reviews:
| Level | Issue | Code Review Red Flags |
|---|---|---|
| 0 | Simple SQL injection | No encoding when constructing SQL command strings. Constructing SQL command strings instead of SQL API |
| 1 | extract($_GET); | No input validation. |
| 2 | Arbitrary PHP execution | No input validation. Allow file uploads. File permissions modification. |
| 3 | Advanced SQL injection | Constructing SQL command strings instead of SQL API. |
| 4 | HTML injection, XSS and CSRF | No encoding when constructing HTML. No CSRF counter measures. Passwords stored in plain text. Password displayed on site. |
| 5 | Pingback server doesn't need to opt-in | n/a - By design protocol issue. |
| 6 | Script injection and XSS | No encoding while constructing script. Deny list (of dangerous characters). Passwords stored in plain text. Password displayed on site. |
| 7 | Length extension attack | Custom crypto code. Constructing SQL command string instead of SQL API. |
| 8 | Side channel attack | Password handling code. Timing attack mitigation too clever. |
More about each level in the future.
So this is another Stuxnet by Israel/US?
The analysis reinforces theories that researchers from Kaspersky Lab, CrySyS Lab, and Symantec published almost two weeks ago. Namely, Flame could only have been developed with the backing of a wealthy nation-state. … “It’s not a garden-variety collision attack, or just an implementation of previous MD5 collisions papers—which would be difficult enough,” Matthew Green, a professor specializing in cryptography in the computer science department at Johns Hopkins University, told Ars. “There were mathematicians doing new science to make Flame work.”
Some rights reserved