1108048 - Phishing evasion that changes location bar

Status: RESOLVED INVALID

(Firefox :: Security, defect)

Description

[Cedric Knight]

Attachment: Obfuscated phishing page

I'd like to report a phishing mechanism that may cause some user interface security problems.

The site http://halifaxonline.usa.cc/ is as a write a redirect to a subdomain verify.barclays.co.uk. [...] .golevleri.com, which is the attached script including
  window.location.href = "data:text/html;charset=utf-8;base64,PCFET ...
so that the base64-decoded data is the Halifax phishing page.

My concerns are:
a) I don't recall seeing this technique before and it may be doing something I don't yet understand.
b) The script appears to execute despite NoScript 2.6.9.6.  I can report this to NoScript maintainers.
c) It's common for a subdomain to be used that resembles the phished site.  However having "data:" in the location bar may be even less suspicious to users.
d) Clicking on the phishing link in email results in a page being shown where I cannot find a way to see either the genuine URL from which the content comes, nor the source.
e) The usual tools such as "Help > Report Web Forgery" or Netcraft toolbar are not able to use the relevant URL either.  
f) It may also be that this technique evades phishing databases because the URL is never checked.
g) with the combination of add-ons in the test browser, including TabMix Plus, the effective x-size of the FF window appears to increase so that some tabs disappear outside the window, and it is not possible to clear some warning messages on the tab because their closes button are also outside the window.

One expected action would be that the source URL is shown in the location bar.

Comment 1

[Daniel Veditz [:dveditz]]

The phishing technique is not new, but not that common because until more recent versions IE didn't support very long data: urls.

Thanks for attaching the page source to the bug. Phishing pages don't live long and this one is already taken down (not to mention blocked by SafeBrowsing).

Your concern b) is alarming, but what evidence do you have that a script has executed? I'll leave that up to Giorgio to investigate.

For concern d) what email program (or webpage) do you use? Given your link in comment 0 I definitely see the data: URL in the address bar so I'd like to know what steps I'm missing to see d)

I also don't see your concern g), but I am unlikely to have your specific combination of add-ons. I don't know why an addon would make a data: url content page a different size, though. It's just content.

I'm not convinced a data: url would be less suspicious than other kinds of phishing domains. Either the user is checking or not, and if they're checking then the fact that it's not a GREEN URL with the bank's full correct name (not a domain) should be all the clue they need to steer clear.

Giorgio: let me know if I can unhide this bug or if there's a NoScript problem you want to deal with first.

Comment 2

[Giorgio Maone [:ma1]]

The attacking page's script (which is just the window.location.href assignment) gets to run only if its domain is whitelisted, which is what we expect so no worries here.

Scripts in the data: content inherit the principal of the loading page, hence they don't get executed ulnless if the first-stage attack page is whitelisted, which again is expected and fine. 

Notice that, if the domain is not whitelisted, the fall-back META refresh leads to the legitimate Halifax page, rather than loading the data: URLs, which makes me think they do believe to depend on JavaScript even for their phishing attempt (which is over-pessimistic IMHO, since they could just wait for user to actually submit the login form).

So Dan, I cannot see any NoScript issue here which prevents the embargo from being lifted, thank you for asking.

Comment 3

[Daniel Veditz [:dveditz]]

unfortunately this is the way the web works and isn't a bug. People need to go beyond looking for "suspicious" things and verify they are exactly where they think they ought to be.