The modern interneter is very click-happy. We like buttons and links, as long as they don’t look to suspicious. But this has caused for a lot of security problems, such as Phishing, Clickjacking, and a variety of other really bad things. Today, I’ve discovered yet another one of these things. I call it, Mediajacking.

Background

To begin, I’ll step back a little. Our browsers have many features designed to keep us safe. One of these core features, something that is essential to your safety, is prompts around hardware access. Whenever a website wants to use your webcam, microphone, or even GPS location, it can’t simply do this. It must first request permission, which, in chrome, pops up this little window:


Any modern browser will have something along these lines, and it allows websites to become more versatile, and do bigger and better things if used properly. So what’s the problem? Well, let’s take a closer look at the prompt window. It’s fairly simple, and it runs separately from the page so it can’t be accessed. But there’s one problem with it. It doesn’t run in the page, but it does run over the page. As you can see by the image below, the prompt window rests comfortably above the webpage.

How it works

This is where things get interesting. If we can get the user to press “Allow”, we gain access to their webcam. All we need to do to achieve this is to get the user to attempt to click something on the page ‘under’ chrome’s prompt, just after it’s appeared.

For example, if there were button directly underneath where the “Allow” button will appear, an attacker would simply need to ask for webcam access just before the user presses the button. Their mouse will already be hovering over “Allow”, they’ll click “Allow”, and the website will be granted webcam access. In my testing, this works for Chrome and Firefox, but I’m sure it could be adapted to other browsers fairly easily.

Caveats

Unfortunately, mediajacking requires a rather odd set of circumstances to be relevant. First, the user must click more than once at a decent speed. This is relatively easy to emulate, by making a button “fail” a few times, so users might feel inclined to spam click it. However, the larger issue involves the location of “Allow”. Unfortunately, the browser determines where “Allow” is relative to the window.

Luckily, we can actually control the location of “Allow”, by opening the page requesting media in a popup, and moving the popup to wherever we need it. In my test, if the user had multiple screens, re-positioning most likely wouldn’t work properly, but this could easily be fixed with some screen location checks.

Conclusion

This method of gaining access to media control could be extremely dangerous. Not only camera access is handled this way, but several other types of hardware control, such as GPS positioning or Microphone access. It’s also worth noting that since my website is TLS enabled(https), consent to use these hardware devices is only required once. This was discovered a while ago by Tal Ater. You can read about it here. The worst thing about mediajacking is that like its older cousin clickjacking, it can’t really be fixed without disabling JavaScript entirely. As far as I can tell, Mediajacking isn’t really a bug, and any other form of prompting for hardware consent would have similar problems.

Afterthought: This won’t work on Macs as is. I’ve skimmed out on a lot of compatibility because I just wanted to prove this could be done.