As the devices with which we surround ourselves become ever more connected to the rest of the world, a lot more thought is being given to their security with respect to the internet. It’s important to remember though that this is not the only possible attack vector through which they could be compromised. All devices that incorporate sensors or indicators have the potential to be exploited in some way, whether that is as simple as sniffing the data stream expressed through a flashing LED, or a more complex attack.
Researchers at the University of Michigan and the University of South Carolina have demonstrated a successful attack against MEMS accelerometers such as you might find in a smartphone. They are using carefully crafted sound waves, and can replicate at will any output the device should be capable of returning.
MEMS accelerometers have a microscopic sprung weight with protruding plates that form part of a set of capacitors. The displacement of the weight due to acceleration is measured by looking at the difference between the capacitance on either side of the plates.
The team describe their work in the video we’ve put below the break, though frustratingly they don’t go into quite enough detail other than mentioning anti-aliasing. We suspect that they vibrate the weight such that it matches the sampling frequency of the sensor, and constantly registers a reading at a point on its travel they can dial in through the phase of their applied sound. They demonstrate interference with a model car controlled by a smartphone, and spurious steps added to a Fitbit. The whole thing is enough for the New York Times to worry about hacking a phone with sound waves, which is rather a predictable overreaction that is not shared by the researchers themselves.
We’ve covered an explanation of how MEMS accelerometers work before, as well as a look at air-gap exploits. There’s no need to worry too much about your devices with respect to this, but it’s a fascinating alternative method of input to keep in mind.
Thanks [Sterna] for the tip.
Wear a fitbit while you use a snowblower, it’ll say you walked alot of steps.
Ah, the potential of the creative human mind applied on how to avoid doing things continues to amaze me.. :D
Potentially put data in to the memory with this, possibly if a stack overflow or a jump could be produced, it could make for a basic virus or even a bridge else where.
Maybe not with a fitbit but possibly with a phone, gaming device or simular.
“We attack the hardware layer, bypassing the software” – “To help solve this problem, we wrote softwares” How cool is that?
Another vector would be the ripple in the power when you charge the device.
You can tell it’s software because of the way it is.
People don’t think it be like it is, but it do.
Interesting work, but I find the fake screens in the video extremely unsettling.
I thought it was hilarious when Xu was on the laptop screen talking and the person on the laptop was typing anyway.
[quote]frustratingly they don’t go into quite enough detail other than …[/quote]
@3 min into the video they confirm hackaday’s suspiscion of using (amplitude and) phase modulation relative to the sample frequency of the sensor.
That’s a typical American video. Not my cup of tea, really.
Even though this video is making it seem very complicated, by reading between the lines and summarising it, it isn’t really.
Basically they’re applying a vibration frequency much higher than the one sampled by the accelerometer. Because it exceeds the fourier frequency (the one referred to by the fourier theorem), the frequency then appears as a lower frequency to the accelerometer.
This is very basic stuff. You’ll have to apply a very strong high frequency signal, because usually accelerometers have an analog and/or digital low pass filter to counter this.
The guy says in the video: “for instance, by applying certain frequencies, I made my sensor spell WALNUT”. ….Nobody cares…
Yes, you’ve managed to make the sensor generate 0x57 0x31 0x4C 0x4E 0x55 0x54, which is the ASCII code for WALNUT, but it’s not like there is an interpreter looking at the ASCII code of accelerometer data. Why would there be?
Your fitbit doesn’t suddenly generate an alert when you’re running and that particular code comes along? “oh no, WALNUT! he must have tripped over a walnut when running!!”
It wasn’t ASCII, it was written in the raw accelerometer amplitude graph. Which was cute, but really weird.
http://i.imgur.com/GBXD40P.png
Nyquist frequency?
thanks.. one of my strong points is not remembering names. I have come to the point now that I shamelessly ask for peoples names again in stead of trying to pretend I do.
The paper is available here:
https://spqr.eecs.umich.edu/papers/trippel-IEEE-oaklawn-walnut-2017.pdf
Basically, this is a load of bulls***, where some “security researcher” who suddenly learned of “aliasing,” which they hadn’t known of before because they never took signals 101, called a perfectly well understood (and sometimes accepted) loss of accuracy called aliasing. You don’t know how badly I want to yell this to every general news organization publishing this bullc***.
Basically, in a lot of low power systems, in order to reduce power consumption, some accelerometers can only be sampled at very low sample rate. The onboard LPF might not have the appropriate characteristics for the required application sample rate, or would take too much power, so in many non-critical applications, the LPF may be omitted. Without it, it is a VERY BASIC SIGNALS PHENOMENON that any higher frequency signals than the sampling rate (like audio!) will induce substantial false measurements into the system.
Again, any well seasoned engineer is supposed to be aware of aliasing issues. The test in the paper is a complete joke, where they take an accelerometer with analog outputs, OMIT THE BANDWIDTH LIMITING CAPACITORS THAT ARE RECOMMENDED IN THE DATASHEET, and say, OH, SECURITY RISK IF YOU DON’T HAVE THE LOW PASS FILTERS ON BOARD! Based just on that, I’m fairly certain they did not configure the majority of their “tested” accelerometers correctly, many of which have extensive filter settings that need to be individually tuned for the application.
The random sampling techniques recommended are also a poor replacement for a proper filter. But in most applications, that simply isn’t done because it doesn’t matter. Additionally, what they suggest works on a very simple Arduino prototype, which is an exceptionally naive idea of the system requirements of most fitness trackers, for example. In those cases, undersampling is frequently required simply because of the fairly stringent power requirements.
Let’s cut the BS and get to the core thing they’re really trying to say – of course you can fool sensors in a device in all sorts of ways with interference. It’s just occasionally, people designing applications should accept that accelerometers (and most other inputs!) can be fooled in one way or another, so you have to be careful with how it’s applied
And in case anyone was worried about safety critical applications – automotive airbag accelerometers are a completely different grade and class, and have a whole slew of reliability and safety requirements. Having a proper anti-aliasing filter on the front end is expected, I’d imagine.
Also, notice the hearing protection. We’re talking about pretty extreme dBs here – the equivalent, if you were talking about a lock, is taking a sledgehammer to a door handle…
Anywho, there are interesting /systems/ where you can observe attacks, like the few they mentioned on the Tesla autopilot, or medical pumps. This group just took the easy way out, bought a bunch of accelerometers, and tested them all, and said, oh, there /probably/ is some safety critical application that is vulnerable to this. Show this working in a car airbag system (those accelerometers are specially rated to much higher safety standards, and probably have very, nice, sharp antialiasing filters and other filtering logic), and then you can publish a paper that gets this much publicity.
Most airbag sensors are basically a gold-plated bearing-ball supported by a spring. Very simple but unbelievably reliable. Not an attack vector IMHO unless the speaker is touching the module underneath the passenger’s seat.
I found myself wondering if I would notice a person pointing a deafening speaker at my wrist.
wow, it actually got published! I’m amazed.
Caveman version of attack…
Equipment, 1 root vegetable, 1 pressure flaked cutting utensil.
Method: install fitbit on caveman, instruct him to chop vegetable.
Result. OH EM GEE major HAX, false steps recorded by fitbit!!!!!!1111111oneone
Some laptops utilize accelerometers to set their W/R heads to a safe place in the HDD.
But now SSD is becoming more popular so….
I can think of one practical use for this sort of thing: is in combination with a GPS spoofer, it could be used for cheating at games like Pokemon Go.
I am hoping titles like this are not the future of HAD
Hmm. The paper seems just as bad as the video.
Can’t crash a computer with this? … Storm in a teacup ?
https://en.wikipedia.org/wiki/Active_hard-drive_protection
… What say I convince your server drive that it just fell 20m on to a concrete floor?… Not convinced yet?
Ah that would explain why that old guy with the testicular elephantiasis kept getting reading that were 150% of what they should have been.
Once I wore the watch part of a heartbeat monitor without the chest belt just as a watch while driving the car. Suddenly I heard it beeping and it displayed “heart rates”. It turned out that the speakers in the doors emitted enough magnetic fields in the 5kHz range to trigger the heart rate receiver.