cj-sp-pb

This post was made public on 27.8.2015. It was previously disclosed privately to Google.

More info: Webcam spying with Chrome

———————————————————————————————————–

Clickjacking and Spoofing the Google Chrome Permission Bar is Too Damn Easy

The permission bar in Chrome suffers from a list of bugs that can be combined in multiple ways in order to trick the user into granting access to privacy related features without being aware of it.

In some situations the user might realize that something bad just happened, but until he’ll take action to reverse it – his privacy will already be compromised. I.e. his camera will photograph him, his location will be revealed, etc’.

*
The Demos:*

The demos are targeting for full access to the user’s camera and microphone, which are probably the most privacy related features.

1. Wearing With Bars.
   This demo abuses the fact that it’s possible to create a completely identical fake permission bar. And that the real bar can be altered to show merely “http://” instead of the full text.
   The user will be tired will multiple fake bars until the real bar will appear.

2. Clickjacking using popups
   Using 2 popups, and the way popups can be controlled, to clickjack the user to “Allow” the access to his camera. Even if the user will notice something phishy happened, and will take immediate action. It’s likely that his privacy was already compromised.
   Clickjacking using popup (Popjacking) is extremely overlooked by all browsers.

3. Ubuntu.
   Chrome renders the permission bars differently on every OS. This is an example of how to mess with it in Ubuntu. This demo is not fully functional, just shows an example of what can be done.
   This flaw was mitigated in Chrome 35 thanx to the move to the Aura UI. But still, the permission bars renders and behave slightly different in Ubuntu.

4. None Closable Popup.
   While this is more of a popup bug, it shows how this can be leverage to trick the user into allowing access to his camera.
   The permission bar should not be functional under extreme condition. In this case the popup is almost frozen but the “Allow” button is still functional.
5. Over And Switch.
   The most basic clickjacking attack on the permission bar.
   The time it takes for the real bar to appear is probably the best time for clickjacking. (~130 milliseconds)

These are just a few examples, these flaws can be combined in multiple other ways.

*
The List of Flaws:*

The list is not the most organised list; I basically threw-in most of the stuff I’ve stumbled into. The video is more explanatory.
Some of the items in the list are objectively bugs, and some may be considered as “by-design”. The by-design features or bugs should be mostly mitigated, though some of it is not harmful on its own.

1. It’s easy to create a fake identical permission bar.
2. Permission bars act and render differently between OSs each with it’s own flaws.
3. Different types of permission-bars act and render differently.
4. It’s possible to tell when the permission bar is opened and when it’s closed – using the content height (resize event is fired).
5. Permission bars are not accessible. When enlarging fonts/zooming – permission-bars stay the same.
6. Use window focus and blur events to tell when the window is clickable.
7. The permission bar doesn’t have “the arrow” when opened in a popup (Mac only)
8. The permission bar can be made to reopen constantly requesting it multiple times. Requesting the same permission multiple times will show the bar multiple times when clicking on “x” (infinitely)
9. It’s easy to control the existent of the permission bar. Showing is obvious, hiding it using refresh and/or sub-domains.
10. When using a very long subdomain the message will be turned into merely “http://“ (MAC only). Other OSs bar are truncated differently.
11. Use staggering permission (multiple tries) – ask for camera if decline ask for microphone if declined ask for speech etc’.
12. Infinite tries using infinite subdomains (if the user “Deny” simply redirect to another subdomain and try again)
13. Resize the popup to show only the “Allow” button (Windows only)
14. Resizing the popup smaller and than bigger – the Permission Bar UI will not revert itself. It’s possible to leave only the Camera Icons and the “Allow” button (Ubuntu)
15. Inconsistency between OSs (MAC, Windows 7, Ubuntu)
16. Information popover (when clicking on the camera icon in the address bar) can be messed-up. Especially on windows when the popup is small. On the mac it can be slightly messed using a long subdomain / domain.
17. The “Allow” button can be clicked in a window, which is out of focus. Optimally the buttons in the permission bar will be functional only a second or so after the window received focus. This will mitigate clickjacking using popups.
18. After the user approve, the camera icon in the address bar is not clear enough, will be missed by most users. It should be clear “Website attacker.com is accessing your webcam and microphone!”
19. On the MAC refresh remove the bar on win7 the bar stays after refresh. It can be removed using a redirect to a different subdomain.
20. The red circle in the tab that indicates that the camera is being access is not existant in popups and hidden on a normal window when multiple tabs are opened.
21. On HTTPS permission is sticky even if the SSL certificate is not valid.
22. POPUPS flaws ->
23. These are flaws on its own but are very helpful for jacking the permission bar.
24. Tell the mouse location also from the parent window.
25. Enforcing the size and position of the popup.
26. Popups can be made un-closable using a while loop, resizing or moving (works only after the Dev tools were opened at least once) (might be possible without opening the dev tools)(easy to trick the user to open the dev-tools by asking him to type the shortcut)
27. Clicking multiple times will open multiple popups- there is absolutely no delay. For example, tricking the user to click 10 times in a second during a game is pretty easy – it will result in 10 popups opening together (windows)
28. Popups opening can be delayed for second, it may look like the popup was not generated from the click. This goes well with the previous flaw – the user will click multiple times before noticing anything wrong and multiple popups are scatter all over the screen. (windows)
29. Using double-click its possible to calculate the different between 2 clicks and make the 2 popups open together. (windows)
30. You can still do popunders in Chrome, jquery-popunder is a good example. (the user will be able to notice it openeing though)
31. You can make a popup open on another screen, messing with moveTo. A small popup that is located on the far bottom of the other screen can go unnoticed.
32. A popup can be made to jump between screen, stucking (no close). This is very annoying and confusing to the user. The popup will become semi transparent and very difficult to interact with.

*
Mitigation*

The fastest mitigation might be to simply add 1 second where the buttons are disabled. It should happen every time the permission bar is opened or when the window is gaining focus. That will mitigate all the clickjacking attacks, but it won’t help other kinds of attacks (tricking the user to click allow using fake bars, for example)

The current permission bar is subtle and elegant, it looks great. But, it doesn’t serve it’s purpose. The Permission-bar should be bigger, clearer and completely separated from the content area.

An extreme mitigation will also eliminate popups completely. Popups are bad for the user experience even when used legitimately.
Obviously, popups can be abused for clickjacking of any web content and not only the permission-bars – this is extremely overlooked by all browsers.

The best solution for this problem is probably OS level permissions that will stay the same across browsers and OSs.