0

This question already has an answer here:

Consider the following scenario giving a hypothetical attack:

  • Crypto.com is selling cryptostocks and accepts payments using a payment processor PayEasy.com. The entire site pages (of crypto.com) are served using HTTPS.

  • While traveling in a foreign country, Bob visits crypto.com on his laptop from his hotel network and clicks on the “buy now” button for 10 cryptostocks. He is forwarded to PayEasy.com using a link <a href='https://PayEasy.com/pay?amt=100&id=bob'/>

  • An attacker (such as the ISP) manages to redirect all traffic intended for PayEasy.com from Bob’s computer to a fake site he has set up called PayEazy.com. When Bob makes a DNS query for PayEasy.com, the attacker returns the IP address of PayEazy.com.This site also has an HTTPS connection using a genuine SSL obtained from a CA using "domain-validation". The certificate confirms that the site is served by payeazy.com. An attacker must do this, since otherwise Bob’s browser will give a warning and may fail the attack. Thus, Bob effectively clicks a link equivalent to <a href='https://PayEazy.com/pay?amt=100&id=bob'/>
  • Bob never suspects anything because he sees the green bar and he has not even bothered to read on crypto.com’s site that it uses PayEasy.com. Even if Bob did know that PayEasy.com is crypto.com’s payment processor, he does not notice the slight difference in PayEazy.com. Bob makes the payment of $100 for 10 cryptostocks and waits but they never arrive.
  • Bob assumes Crypto.com is a scammer and sues them. As the case unfolds, Crypto.com’s lawyers ask Bob to prove that Crypto.com sent him to https://PayEazy.com instead of https://PayEasy.com. Bob cannot prove this and loses. The case could have gone either way since even Crypto.com could not have proved that they indeed sent Bob to https://PayEasy.com and not https://PayEazy.com

Firstly, is this attack realistic. Secondly, how to prevent it? (This is similar to the example given in the article Schneier's PalmPilot)

As an example of this attack: https://google.com is a secure link to google.com. Assuming that this site (security.stackexchange.com) is served over HTTPS. Now edit your 'hosts.file' so that the IP address of google.com points to yahoo.com and click the above link.

marked as duplicate by Neil Smithline, Xander, Ohnana, Deer Hunter, Matthew Jan 15 '16 at 22:17

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Unless both an ISP and a CA are coordinating on this attack (extremely unlikely, and we have much bigger problems.) then the ISP would not be able to redirect Bob's traffic to PayEazy.com without Bob's browser alerting him that the domain's certificate doesn't match the one he intended to visit. – sethmlarson Jan 15 '16 at 16:32
  • "An attacker (such as the ISP) manages to redirect all traffic intended for PayEasy.com from Bob’s computer to a fake site he has set up called PayEazy.com" - How would the attacker be able to change the link (from PayEasy.com to PayEazy.com) when the link is being served from Crypto.com by HTTPS, and the attacker (presumably) does not have a valid CA-signed certificate for Crypto.com in order to pull-off a MITM attack for this site? – mti2935 Jan 15 '16 at 16:36
  • @mti2935 I believe he means redirect by saying the ISP simply routes all traffic from PayEasy.com to PayEazy.com, not physically changing the content of the web page served to Bob. – sethmlarson Jan 15 '16 at 16:38
  • 1
    Oasiscircle: In that case, the user's browser would warn him of a certificate mismatch. He clicked a link for PayEasy.com, so browser requested PayEasy.com, but the site served a certificate for PayEazy.com. – mti2935 Jan 15 '16 at 16:40
  • @mti2935 That's exactly what I said in my above comment. – sethmlarson Jan 15 '16 at 16:40
1

No. This is exactly why we have PKI - to prevent this type of DNS poisoning attack that you are describing.

Here is what would happen in the case that you are describing (including the comments), after Bob clicks the link to https://PayEasy.com. First, Bob's browser would do a lookup DNS lookup for PayEasy.com.

Let's assume that the attacker (Bob's ISP or his WiFi provider) managed to return a false IP address for PayEasy.com, and returns an IP address to a web server that the attacker controls.

OK, so now Bob's browser connects to the attacker's web server. But - here lies the problem - the attacker's web server serves up a certificate for PayEazy.com. At this point, Bob's browser knows that something is up, because the browser requested PayEasy.com, not PayEazy.com! Bob's browser would show him a warning of the certificate mismatch, and Bob would be wise to cease connecting with the site.

  • Bob's browser will show a mismatch only if the domain the site claims (payeazy.com -- the attacker's) does not match with the one in the certificate. In this case it does. Because the attacker has the certificate for payeazy.com (the bad site). So the browser will not give a warning. – Jus12 Jan 15 '16 at 17:06
  • No. Bob's browser requested PayEasy.com (because Bob clicked the link PayEasy.com). If the site serves a certificate for a different site (PayEazy.com), Bob's browser will show a certificate mismatch warning. – mti2935 Jan 15 '16 at 17:38
  • 1
    Sure. See security.stackexchange.com/questions/94331/… – mti2935 Jan 15 '16 at 18:06
0

Actually in case you've described(payment processing) there's one thing you've missed : vendor(Crypto.com) <-> payment_processor(PayEasy.com) interaction. I have implemented such a ties, and that's how it works:

  1. vendor makes a callback to processor: "give me a transaction id for the full details of transaction". Their sig's are checked between them by the certificates they've exchanged by previously
  2. vendor receives id, and redirects Bob to https://PayEasy.com/pay?sid=12345xYz... No "id=bob", "amount=100" - all this info and many other info was passed ALREADY in step 1
  3. Bob sees ALL the data in his browser, and only after that it approoves the payment.

You can even register https://PayEazy.com as a vendor too, but on Bob's side it will be different merchant name in payment confirmation, and this confirmation page will be HTTPS-signed by PayEasy SSL cert. That's it

  • The payment was just an example of the DNS based attack. Assume that it is a list of "recommended sites" hosted by someone (a static page) and the attack is on one of the links in those site. – Jus12 Jan 15 '16 at 17:43
  • 1
    @Jus12 take a look at Perspectives Project – Alexey Vesnin Jan 15 '16 at 18:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.