Research shows how MacBook Webcams can spy on their users without warning
washingtonpost.com
washingtonpost.com
http://www.wired.com/threatlevel/2010/10/webcam-spy-settleme...
http://www.pcmag.com/article2/0,2817,2386599,00.asp
> When the school district investigated the case, it found other incidents of webcam spying, and notified the students involved, including Levin. According to the lawsuit, filed in Eastern Pennsylvania District Court, Levin's younger brother commented on a light near the webcam that appeared to go on and off at odd times. His mother "dismissed the idea as absurd," but it appears he was right.
No longer plastering devices with semi-pointless LEDs would help. Harddrive activity? Wifi? Bluetooth? I don't think all these lights are really necessary. Throw one on the power cable maybe, and a few to backlight the keyboard, but otherwise only use them as indicator lights for things that are actually important to the standard user.
HDD light blinking? That means it's working correctly. Am I right?
If people can perform remote admin on machines 1000s of miles away without the need of green LEDs, I'm sure consumer tech will do just fine.
I'd agree that the LED is nonessential with HDDs -- you can just listen; and then you can even make out whether it's doing a lot of seeking or long continuous accesses, but you can't do that with SSDs.
In a lot of ways that is correct. Generally, when something is thrashing the hard drive it is making actual progress on its task, and its task is relativly short lived. This means that if your computer is going slowly, and the HDD LED is active, you can likely wait for the HDD LED to quiet down. In contrast, when your computer is going slowly (or not responding at all) and your HDD LED is off, it is much more likely that something is wrong and won't resolve itself.
One of my biggest gripes is how MS removed in Win7 the little connection icon in the system tray that shows when data is sent/received (it even split send/recv into two separate indicators, rather clever I think.) IMHO the trend of "simplification" is going too far. How about educating the users instead of making them more ignorant by hiding anything that they "wouldn't know about" (and making it harder for them to even start wondering about - and thus possibly learning)?
This to me seems more like an application of Occam’s razor. Hardware or Software malfunctioning seems much more likely than someone spying on you.
http://www.grafik.com/blog/2011/11/apple-sleep-function/
But yes, it's nice that they don't have a bunch of LEDs for everything.
There is already a common pop-culture shorthand for "now recording," the blinking red light. That's cheap and simple, and everyone already knows what it means, particularly when it's on a camera.
The real question, in my mind, is how the world-renowned user-experience and user-interface experts at Apple decided to use anything else.
Then again, Apple’s marketing for the iPhone 5s made many claims of “subdermal fields”, “RF micro fields produced by the human body”, and how, as a result, it couldn’t be faked.
Except it could. Fairly easily. And without any remote pretense around the ‘emulate a live finger’. Just the fingerprint.
Much as I like Apple, these are pretty bold-faced deceptions.
Except, you know, they never actually said that.
The hack is to override the camera to ignore that signal. It is a rather unique idea and probably not something anyone even considered at Apple.
-- A LED shall light up when the camera is activated.
But what they should have implemented is:
-- It shall not be possible to activate the camera without the LED being lit, taking malicious third-party software into account.
The first requirement is obviously, and demonstrably, implemented by every camera (ignoring hardware defects regarding the LED). The second is, as proven by the paper, not fulfilled by any.
{EDIT: added the malicious part to the 2nd requirement}
-- There shall be a way for the user to physically obstruct the camera lens.
Apple used to have this in their standalone camera back in the day.
OS X allows non-privileged users to do that for some reason though...
This is disappointing, and I expect Apple will redesign the cameras because of it.
The fact the camera controller could be reprogrammed from user space and then used to emulate a keyboard or mouse and bypass security / a virtual machine particularly devious, and shows how hard it is to trust even known hardware.
Still, it's a very, very cool hack: they reprogram a microprocessor to send commands to another microprocessor and configure it in such a way that it enters a state where the pin that the LED is connected to is irrelevant.
The article mentions that authorities have tools to bypass the LED. I would guess that the complexity is on purpose and wasn't supposed to be used by the general public. I bet the same is true for sound.
Another option is to enable the LED when power is turned onto the module.
This interlock failed because the Micron sensor Apple used had software straps that could be reconfigured to have the sensor ignore its enable pin.
This is usually done at runtime, typically a bit of code that happens after the reset vector that puts the various config values into the appropriate registers that set up this routing and other customisable options.
In the case here, it's those other options that are the issue.
From the paper, Part IV(A):
> The Micron image sensor has a 16 bit configuration register, RESET (which is distinct from the #RESET power on reset signal). RESET is addressable from the I2C interface at address 0x0D in register page 0
And the hack involves setting that configuration register to unexpected values to enable functionality that bypasses the LED display circuit:
> Bit 7. Prevent STANDBY from affecting entry to or exit from the low-power state if set.
> Bit 6. Prevent STANDBY from contributing to output enable control if set.
(where STANDBY is the signal/pin to which the LED is connected)
So the controller assumes that the physical STANDBY pin will always accurately reflect/control the state of the sensor, which is not necessarily the case if it's been disabled by re-configuration.
The earliest standalone webcams, for instance Logitech models and the IndyCam that came with the Silicon Graphics 'Indy' workstation, had a 'door' that you could slide over the lens when not in use. Lenovo had this on their all in one PC's a few years ago but I don't think they kept that feature.
What was wrong with the slide-across lens cover?
You would think it would be an essential feature for some.
The fact that you can forget it open, duh!
Overengineering usually refers to something that's not simple or elegant or a solution which represents more effort than the problem calls for. None of those factors seem to apply here.
The sliding cover is simpler and more secure.
It's not a software hackable thing because of the physical orientation of the LED. This is where the current designs get it wrong by making things too complicated (though they have their reasons).
edit: I'd note that these features we're talking about aren't mutually exclusive
I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Also, USB is a bus, you can't splice an LED into the power line of the USB going to a camera and conclude that when the LED is lit, the camera is recording. There's a lot of other traffic that could be happening beween the host and the device, that doesn't mean the camera is performing any recording. The reverse would of course be true, though (no light = no recording).
Looking at my current macbook lid, I don't how how that would physically fit. The camera would need to be recessed further into the lid to accomodate for the door.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
I'm inclined to believe that a mechanical sliding door would have a higher failure rate than an LED.
Absolutely not. The moving parts vs. no moving parts divide is pretty huge, and an LED is not a complicated thing.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Having the LED in parallel on the power line is impossible to subvert without a soldering iron. I don't know why people are having trouble understanding this bit.
Perhaps to do this properly with a USB camera you'd need to give the camera its own USB controller. My god, who cares? The USB thing was just an example. The point is that you can wire in an LED such that when the camera has power, the LED has power.
> that doesn't mean the camera is performing any recording
The light today doesn't signify "recording," it just signifies that the camera is on.
On the whole, I think this discussion focuses on the wrong 'problem'. If someone can gain access to your computer, taking control of the camera is just one of a whole host of nasty activities they could get up to - the real problem is securing against remote access in the first place.
I've heard that this was a serious flaw in Google's opinion, and they went through great efforts to ensure that the LED for the chromebook pixel was actually hard-wired into the camera's electronics. Which if true, shows that it's indeed possible.
Um. That would be exactly the point of doing it, in this case. The camera indicator (and the microphone indicator that every laptop should but currently does not have) should be completely inflexible.
What "flexibility" is added by having an indicator that only sort-of indicates, anyway?
Seems like, at worst, any sort of manufacturing inflexibility is solved the same way they usually deal with this stuff: A ribbon cable. Then you just have to worry about the physical security of the machine which is its own independent issue regardless.
Personally, I assumed they did it this way since it seems obvious (that's what I do in my own electronics projects) and much simpler than using a microcontroller to do it. I forwarded this idea to concerned friends. Looks like I'm eating my own words.
As a compromise, the indicator could be wired-OR: software can turn on the indicator if it wants to, and it gets turned on if the camera is on, but software cannot turn it OFF if the camera is on.
But in the research paper cited by the Wash Post[1], there's a whole section where the authors discuss their recommendations, see under "VIII. SECURE CAMERA DESIGNS". Including some specific suggestions of how you would implement this design in hardware.
[1] https://jscholarship.library.jhu.edu/bitstream/handle/1774.2...
So, upon (my incorrectly) presuming this was how it's already done in hardware and reading the headline of the article before I got to the text, I assumed they were turning it on and taking a single frame and turning it off fast enough that the LED was only on for a short enough time for the user not to be able to see it (or not notice).
Turns out the article claims they just reprogrammed the microcontroller to not turn it on in the first place. Of course that's a bad design, but you do need some more logic in there - the light needs to stay on for a minimum time when the camera is functioning so that the user can notice it.
This, too, is simple enough that it can be achieved without a microcontroller, but please don't presume that it's a simple fix. It's not just "put it in parallel".
Of course many people made fun of it and mentioned "blah blah you are paranoid the LED cannot be manipulated and will always turn on ...".
Well ... here you go. Where are you now?
I wouldn't be surprised if someone-cough-you-know-who-cough had influenced the design for this to become a possibility. We know they are actively looking for opportunities like this. Go ahead, call me a paranoid again ... and next month when the story about how they did just that hits hacker news, I'll have an even better story to tell.
Here's the research paper linked to in the story, if anyone wants to see what the researchers have to say. I haven't taken a look yet myself: https://jscholarship.library.jhu.edu/handle/1774.2/36569
Ah, there it is right in the abstract, yep:
> The same technique that allows us to disable the LED, namely reprogramming the firmware that runs on the iSight, enables a virtual machine escape whereby malware running inside a virtual machine reprograms the camera to act as a USB Human Interface Device (HID) keyboard which executes code in the host operating system.
Ooh, neat.
Especially since there is no LED to signal the microphone is active, it doesn't need to point anywhere. If it could be activated while the laptop is closed (force wake up a part of the OS for just a few minutes here and there for instance) it would be a really tough problem.
One does not simply unload/delete kernel module on an iPad...
EDIT: Yeah, 2nd layer of tape = 0 input level even if I shout really, really loudly. You can't imagine how much my coworkers are enjoying this experimentation!
I'd want something more certain for a higher security situation, but this might do me for some "casual" use cases.
osascript -e 'set volume input volume 0' doesn't really produce the expected result…
This is with a mid-2012 macbook model.
That was my first thought, but then I realized the absolutely ridiculous extent to which Apple goes to build secure devices, and how "slick" the mute switch is on iPhones and iPads.
I wouldn't bet against it.
Agree entirely though.
I'd rather like a physical off switch as well like the original IBM PC (the big red lever)
(And now I half expect to read a new Snowden paper tomorrow detailing how the NSA coerced Apple into fitting batteries and flash storage into webcams so they could be instructed to covertly record video while not plugged in and upload it automatically later…)
(My friend once had to record herself for a foreign language homework, but her microphone broke. I instructed her to plug her headphones into the microphone jack and ust them instead. It worked, but she had to talk loudly to make them work.)
In other words, HN readers might come up with defensive hacks, but 99% of the population is completely vulnerable to all kinds of spying, whether government or stalker, and the situation can only get worse as wireless electronics pervade every part of our lives. Books? Internet-enabled. Fridge? Internet-enabled. Car? Internet-enabled. Our own bodies? Carry wireless-connected smartphone 24x7.
Now that we've reached that tipping point there should be sufficient interest from an adequate number of skilled and educated people to begin to work on solving this problem.
I strongly suspect that the number of stolen laptops recovered thanks to the owner being able to use the camera to "invade the privacy and potentially take creep-shots" of the unauthorized current user, is way way smaller than the number of people who've had their privacy invaded and potentially had creepshots taken by their laptops unauthorized "p0wners".
A car magazine claimed they discovered a serious weakness in a particular brand of a steering wheel lock. The company made a series of improvements to the lock and challenged the magazine to demo their hack. The magazine guy approached the new lock, gave it a good hard yank and it came off the steering wheel.
Another one was the Flash fullscreen mode. Flash used to (probably still does) display a hard-coded warning after the app went full screen - obviously to prevent Flash apps from impersonating browsers, OSes and so on. I've seen a demo that took advantage of the fact that the text was an overlay over what the app displayed.
The demo app just went full screen and printed lots of messages in the same font as the Flash warning, all over the screen. The overlay was still visible (Flash made it impossible to hide or cover) but it was basically impossible to read. The demo then pretended it did a Windows restart - it was pretty scary :-)
Serious weakness indeed. Not what people (especially HN readers) usually mean by that phrase!
It's actually kind of amusing to see pictures of you and notice your hair growing over several weeks :)
What's aggregated about you? Are you against this monitoring that protects us from fear and terrorism? Did you state that in some online devious hacker forum?
INFORM and VOTE
Months ago I read about a company that rented laptops for people to make payments on and eventually own. They installed spy software so they could locate the laptops had the user not made a monthly payment. Employees were spying on users while they were having sex and other things. This wasnt on MBPs but they still managed to not notify the user.
http://www.wired.com/threatlevel/2012/09/laptop-rental-spywa...
A tiny piece of black electrical tape blends in nicely and won't leave gunk on your bezel.
It might be possible to drill out the webcam from the backside so long as you were very careful to not drill too far, but if that is how your computer is set up you should probably look for a safer method.
Jesus Christ, guys. Do you use Linux?
Just blacklist the webcam module to preventing it from loading whenever the system boots. Want to use the webcam? Load the module manually.
# modprobe uvcvideo
Want to unload the camera again? Easy.
# modprobe -r uvcvideo
Generally, it's the uvcvideo module, but it might change from system to system.
A malicious code would need root access to your system to load/unload the webcam module. If someone has root access to your computer/to execute code in your computer, you're in MUCH, much deeper shit than if you let someone film you. Seriously. Specially if you use your computer for money transactions or talk about important stuff to people.
I would say that it's still notable even if it relies on root access, since it's been previously believed that this was not possible with software at all.
I want the same for the built-in camera and mic. A little physical "red switch" that no amount of coding can defeat.
I agree with others, here. I'm worried at least as much about the microphone as I am about the camera. I can always physically block the camera -- and control what it is pointed at.
Further, I'm not comfortable with plugging in a microphone to "override" the built-in microphone. Physical design alone leaves me certain (although without proof) that this "override" is controlled by code. And a bit of experience with software that overrides such defaults to allow simultaneous input over multiple, "normally" orthogonal channels leaves me convinced that such can likely be done with the internal microphone of most devices.
sudo nvram SystemAudioVolume=0
If this works for you, please donate the $10 to Archive.org.Edit: the story refers to precisely these early Macbooks. Yikes.
Second, if the LED fails to a short your camera won't get any power. That means an expensive component appears to be broken when it's only a very cheap component, and you have no way to knowing that w/o opening up and inspecting or replacing parts. In contrast, if an isolated LED fails, one can still verify that the camera works via software, and choose not to send it in for repair.
Also, LEDs have a very small leakage current even in their off state. If somebody is hyperoptimizing power consumption they might choose to put the LED on a high impedence controller output rather than feeding off a power rail or similar.
Finally, the desired led might work off a configurable controller output, but that might not be the same as the output driving the chip enable pin. So you could require extra circuitry to convert to a compatible voltage/current level.
That's my guess.
One never puts an LED on the power line directly. That will certainly blow up most LEDs. Power rails are typically 5V or 3.3V. LED drop is about 1V (+/- 0.3, varies between part numbers). There is always a resistor in series with the LED, to drop the rest of the voltage, and limit the current. So, LED getting shorted is not a problem. This is the case even when we're driving LEDs from an o/p pin. Besides, Hobbyists often blow up LEDs because they're still learning. But how often have you seen these tiny LEDs fail in professionally designed products? I have never ever seen it happen. Degrade and lose brightness over the years? Sure. Fail? Never.
> LEDs have a very small leakage current even in their off state.
Are you talking about reverse bias? That makes no sense in this context. When you don't supply any power to it, there is nothing to leak.
> the desired led might work off a configurable controller output
That is what has led to this mess of surreptitious filming, in the first place. It's time they went back to the old ways.
> There is always a resistor in series with the LED
Sure, almost always. But there are many different voltage level, forward drop, forward current combinations for a given application. There's no guarantee, even with a ballast resistor, that the a shorted LED won't result in an effective short to the power rail (not a real short, but drawing close to the power supply's current sourcing limit). A resistor with a shorted LED results in a useless current sink, in any case.
> But how often have you seen these tiny LEDs fail...I have never ever seen it happen.
What you've seen or not seen has very little bearing on the reality that parts fail. Period. Things should be designed in a cost effective way that minimizes the possibility/effects of failures. FWIW, I had a laptop recently that had a dead LED on the front panel :-/
> There is always a resistor in series with the LED
I just meant that if your "power rail" is actually just a signal line (or whatever) for some other purpose, and the led is there to indicate activity, then even in "low" signal states where the LED isn't fully conducting yet there is a small leakage current.
The victim they talked to mentioned "she never saw the light on her laptop go on" — that doesn't mean it didn't, it just means she could have just not been looking for it.
Ideally, your webcam LED will be wired with your webcam itself. For your webcam sensor to be powered up, the LED will be powered up as a physical requirement of sending power to the webcam sensor. Many lesser-engineered webcams have software controlled LEDs (kinect bar, generic egg-shaped webcams) that don't even take "hacks" or "malware" to disable LEDs—you just run "turn led off."
I notice that the EFF have some nifty little 'ultra-removable adhesive' stickers[1] that might do better, but what would be better is some sort of low-profile adhesive backed sliding cover.
...
It appears I spoke too soon, there are already plenty out there, with mixed reviews. The 'iPatch'[2] looks interesting.
The kext is created by the same authors of the paper[2] this article is talking about. Search the paper for "iSightDefender".
[1] https://github.com/stevecheckoway/iSightDefender
[2] https://jscholarship.library.jhu.edu/bitstream/handle/1774.2...
I'd MUCH rather see an admin password prompt come up, instead of nothing all.
I own a Logitech C920 Pro and a software called webcam settings allows me to easily turn off the lights. If this software can do this, so can a malware.
Also, a malware can be designed to click quick snaps when there is no keyword or mouse activity for a specific period. This can help the malware go unnoticed without controlling the light. Want to take it to the next level? You can use the mic anytime to estimate the user's distance from the system and then enable webcam accordingly. I know this would not be very accurate, but possible.
It is about the Macbook iSight. There is definitely no (official, known) software that allows you to turn off the privacy light. The Apple engineers intended it to be impossible to disable, and believed it was.
A while ago I wrote a component for the iPad that emulates the proximity sensor of the iPhone by measuring the brightness of images the the front camera captured. There was no way for the user to detect that I was actually capturing images.
This is of course nothing new. They used Firefox zero day vulnerabilities before. It just highlights the priority that exist today. Their job is no longer to serve and protect, but to create news article where they can gain glory of taking down bad people.
"NSA recommends physically removing iSight webcam from Apple laptops for security reasons"
http://endthelie.com/2013/08/20/nsa-recommends-physically-re...
Embrace Big Brother, folks, 'cos he's here.
There's really only 1 solid solution to this:
Open software and open hardware.
Edited for bad boolean.
Also applies to crypto-accelerated CPU instructions.
With OSS and OSH, at least there's a chance of auditing what one has is what was released, and a chance to audit that there's no funny business going on.
You'd have to get the user to download and run a package installer that prompts for an admin password RIGHT?
In other words; this isn't just something that can happen without end user interaction.
In theory; but a motivated party with sufficient resources could simply ("simply") author a fake OS update and deliver it to you over a compromised ISP and you'd never know the difference.
> But researchers figured out how to reprogram the chip inside the camera, known as a micro-controller, to defeat this security feature.
Aren't Mac firmware updates always a big deal with special boot modes and audio tones?
Obv. its still a problem, even if the light turns on. Taking a quick picture doesnt requite the light to be on for long, so it could go by unnoticed.
We already knew this: http://security.stackexchange.com/q/6758/10863
First: peer review. If your design documents are readily available, researchers don't have to reverse engineer them. Also, by open sourcing hardware design you lower the bar for critique: you might get feedback from an experienced electrical engineer who might not know how to write and upload a custom firmware for a USB controller.
Second: you can easily change it because it's not a black box.
Not sure where that one is, but there is a wealth of data here: http://www.nsa.gov/ia/mitigation_guidance/index.shtml
It's safe to assume they left a few things out, but part of NSA's mission is to protect the communications of US interests (government and enterprise) so it actually is part of their mandate to give advice like this.
Since I read that, I've been keeping a piece of post-it note on my Macbook Air camera, although it does fall off occasionally (and I need to remove it, very rarely, to actually use the camera.)
I've just upgraded it to a proper piece of card with real tape. ugly, but effective.
There's no light that indicates an active audio input channel.
[1] http://arstechnica.com/security/2013/12/perv-utopia-light-on...
I can't find the link right now but I remember a couple of triumphant "nerd recovers macbook pro" stories where they show photos taken of the thief using their macbook - presumably using this very trick to take a photo without turning on the indicator light.
I know of one Logitech USB webcam that has this issue. Turning the indicator off is as simple as:
$ uvcdynctrl -s 'LED1 Mode' 0In other words, would this work while the machine is off or running Linux?
I thought this was old news.
Then so can malware.
WEAKNESS IS STRENGTH