Important to note that the fake page is "frozen", so there is no direct phishing risk. The user can click around but nothing happens. Scrolling works. Resizing curiously turns it into a blank page. Reloading leaves the fake page up.
It's a race, so it might not work at the first try over the network.
It rendered the phishing HTML, but you can't interact with it. I guess it's because the script is stopping the render of facebook after the request has been made (hence the www.facebook.com site), providing another security layer, as you can't be phished with an unresponsive website.
And I don't think javascript would make a difference.
I feel it's a little disingenuous for the author not to mention up front that the fake page can't be interacted with, because it completely changes the severity of the vulnerability.
It doesn't change anything. As some people used to say, "security is binary; you either are secure or you are not".
While it's useful for phishing pages to be interactive, it's not strictly necessary:
----
"Your paypal account is locked, because we suspect it to be hacked. To unlock it, please call our tech support (phone number 1-234-56789) and tell them your paypal password to prove your identity (and CVV of all the credit cards pretty please)."
It absolutely changes things, there's a marked difference in severity between encouraging someone to call a number or respond in some other way to written instructions, and capturing their login details on a page they've been trained to trust (i.e., https with a green lock.)
I'm certainly not saying there's no issue here - your example perfectly demonstrates a realistic and dangerous use case - I'm merely pointing out that omitting such an important aspect of the vulnerability in the repo readme is disingenuous and materially changes the severity of the issue. To be honest, the omission actually smacks a little of clickbait.
it's a proof of concept. I don't see how it changes anything. once you've got the browser displaying https://site you control pretending to be something else.
> As some people used to say, "security is binary; you either are secure or you are not".
I think anyone that used to say that was just wrong. "We" (software community in general) have a much more sophisticated understanding of security than we used to, and realization that absolute security is virtually impossible. Security is always a continuum of risk management.
Bruce Schneier writes:
> Security is a trade-off. This is something I have written about extensively, and is a notion critical to understanding the psychology of security. There's no such thing as absolute security, and any gain in security always involves some sort of trade-off.
He's not writing specifically about digital security in that quote, but since he's foremost an expert on digital security, it's safe to say his opinions on security in general apply to digital security too.
Here's another Schneier quote about digital specifically:
> That is why security experts aren't surprised by the Sony story. We know people who do penetration testing for a living—real, no-holds-barred attacks that mimic a full-on assault by a dogged, expert attacker—and we know that the expert always gets in. Against a sufficiently skilled, funded and motivated attacker, all networks are vulnerable. But good security makes many kinds of attack harder, costlier and riskier. Against attackers who aren't sufficiently skilled, good security may protect you completely.
> As some people used to say, "security is binary; you either are secure or you are not".
Disregarding all other context: I disagree strongly with this statement. Practical security is about risk management, and is never binary unless you've proven the absence of bugs (and backdoors) through your whole stack down to the transistors (unlikely). The practical exploitability of any particular bug is certainly relevant.
If facebook allows you to put an arbitrarily large img tag onto any of the pages under its domain (so internal navigation could be hidden under it), then yes it is a valid attack vector.
> As some people used to say, "security is binary; you either are secure or you are not".
I'm sorry, which people used to say that? I'm not aware of any serious security professionals who hold that opinion. "Security" is and has always been a complicated spectrum of interactions and requirements.
I don't remember the exact quote, and might have used one out of place.
I am thinking about it in binary terms, because it helps to prevent security through obscurity trap many seem to fall in.
My point is: the fact that a particular bug has security impart seems pretty binary. And dismissing one because "hey nobody will think of/work hard enough/have enough money/etc. to make use of it" isn't a very bright idea.
See 3rd party content under a legitimate url? The system is insecure. Period.
This isn't exactly the same as what you said, but I think it's an argument in favor of your point of view.
Another analogous thing is that academic cryptographers will regard an algorithm or protocol as broken if an adversary can gain a significant advantage (probability of distinguishing things that are supposed to be indistinguishable, reduction in work factor, etc.), even if the resulting work factor to mount the attack is still enormous. For example, if there were an attack that could break AES in 2¹⁰⁰ operations, AES would be considered broken even though we believe there is no one who can perform 2¹⁰⁰ operations, because it no longer provides the designed or advertised security margin.
Interestingly, this one has been around and known for awhile. I reported it back in September of 2012 and got the same response. Basically it wasn't viewed as a bug because the user couldn't interact with the DOM. I explored this quite extensively and was never able to make it interactive.
Here's a screenshot of just some of my exploration of this bug back in 2012:
The URL shows https://www.facebook.com, and a green shield indicating a secure connection. What is displayed is not from facebook. Maybe you're missing it? Ad or social blocker installed?:
It's a race, so it might not work at the first try over the network.
Original report: http://seclists.org/fulldisclosure/2015/Jun/108