3

Have been playing around with the whole DNS spoofing thing. How can a rogue/phishing URL be masked with a legitimate URL in the address bar (without using images)? I was under the impression that this was doable, but so far the only way to pull this off is with superimposed JavaScript images.

I managed to trick my own browser by modifying the hosts file on my Mac and pointing twitter.com to a localhost site. Is it therefore safe to assume that modifying a hosts file on a rogue access point would yield legitimate-looking pages that are actually rogue?

2 Answers2

3

Actually, this can't be done with images. Images in browsers are confined to the main frame of the browser, and can't just escape that. Java Applets can, however, though these will ask for permission first.

In general the only way to mask a phishing URL by a legitimate one is to spoof DNS (or just go ahead and ARP spoof the whole connection and add a filter).

Is it therefore safe to assume that modifying a hosts file on a rogue access point would yield legitimate-looking pages that are actually rogue?

Well, APs usually don't have hosts files, but this is possible. In fact, if someone is on the same subnetwork as you, they can use ettercap with some filters (ARP spoofing) to mask phishing URLs.


In general, the only thing you can trust are SSL URLs (https://). These will display a green something on the address bar if the are legitimate, and will raise an error if they aren't (though this error can be caused by non-malicious situations too)

Manishearth
  • 8,237
  • 5
  • 34
  • 56
  • I think it's fair to assume most end users are unable to distinguish between a legitimate ssl indicator and a spoofed one. Certain MITM attacks are extremely convincingly deceptive. – user1128948 Jun 22 '13 at 15:47
  • @user1128948 You mean that they'll miss the big red warning page with the obscured "proceed anyway" button? That's prepos--actually quite close to the truth, unfortunately. There's ample warning, and Firefox makes you jump through hoops, but people do miss it anyway. – Manishearth Jun 22 '13 at 15:50
  • Where could I find more information on the DNS/ARP spoof combo? I'm more interested in successfully initiating a rogue session in my lab that's convincing enough to fool some of the more clever people. Guarding against it is more of a secondary priority. Thanks for the input, though. – user1128948 Jun 22 '13 at 15:50
  • @user1128948 It's not a combo, not exactly. I can either pretend to be a DNS server (Google "DNS spoofing") by configuring the router or an upstream node that way, or I can just sit on the subnet and pretend to be the router (Google "ARP spoofing", "ettercap", "Wireshark", "ettercap filters"). I'm afraid I don't have any links I can point you to, sorry :/ – Manishearth Jun 22 '13 at 15:53
  • I agree images are confined to the page. However, the favicon ( e.g., SE uses the shield icon here: http://cdn.sstatic.net/security/img/favicon.ico ) can spoof a padlock image similar to what some browsers display and convince naive users they are secure (using HTTPS) while the protocol is ordinary HTTP. – dr jimbob Jun 22 '13 at 17:59
  • @drjimbob sure. However, they can't hide the big red warning that is shown before the page has a chance to load. – Manishearth Jun 22 '13 at 18:14
  • @Manishearth - Agree. Wasn't trying to correct you; just show one way images could be used to trick someone. Naive users will type `paypal.com` into the address bar, or follow a link from an HTTP site, so maybe there's never a request to `https://paypal.com`. Instead user just sees a lock image in the address bar (the favicon) and think yup this is secure, and a MitM attack on `http://paypal.com` is done. Modern browsers do more to make it easier to differentiate true HTTPS from a lock favicon, but naive users will still be easily fooled. – dr jimbob Jun 22 '13 at 22:07
  • @drjimbob yep, that can happen. Though HSTS can help prevent that (not prevent it entirely, unfortunately) :) – Manishearth Jun 22 '13 at 22:14
1

If the website has an XSS vulnerability, you can show your own code on that page and the URL remains. For example if there's an XSS vulnerability on Paypal, you could place a link bit.ly/abc in a spam mail resulting in an URL with paypal.com, but showing your phishing site instead.

That's why XSS vulnerabilities are so dangerous for you. And 90% of commercial sites have XSS vulnerabilities according to some study I just read a few days ago.

Regarding the images thing: There were some bugs in old browsers where you could place a floating image over the URL bar, but all these bugs have been patched. That's not possible in any current browser anymore. Of course you could still draw an URL bar within the page content and still trick some users.

http
  • 127
  • 1
  • 1
  • 5