Amazon Ring: Neighbors Leaking Data On Neighbors

For a while now a series of stories have been circulating about Amazon’s Ring doorbell, an Internet-connected camera and entry system that lets users monitor and even interact with visitors and delivery people at their doors. The adverts feature improbable encounters with would-be crooks foiled by the IoT-equipped homeowner, but the stories reveal a much darker side. From reports of unhindered access by law enforcement to privately-held devices through mass releases of compromised Ring account details to attackers gaining access to children via compromised cameras, it’s fair to say that there’s much to be concerned about.

One cause for concern has been the location data exposed by the associated Amazon Neighbors crowd-sourced local crime paranoia app, and for those of us who don’t live and breathe information security there is an easy-to-understand Twitter breakdown of its vulnerabilities from [Elliot Alderson] that starts with the app itself and proceeds from there into compromising Ring accounts by finding their passwords. We find that supposedly anonymized information in the app sits atop an API response with full details, that there’s no defense against brute-forcing a Ring password, and that a tasty list of API and staging URLs is there for all to see embedded within the app. Given all that information, there’s little wonder that the system has proven to be so vulnerable.

As traditional appliance makers have struggled with bringing Internet connectivity into their products there have been a few stories of woeful security baked into millions of homes. A defense could be made that a company with roots outside the Internet can be forgiven for such a gaffe, but in the case of Amazon whose history has followed that of mass Web adoption and whose infrastructure lies behind so much of the services we trust, this level of lax security is unforgivable. Hackaday readers will be aware of the security issues behind so-called “smart” devices, but to the vast majority of customers they are simply technological wonders that are finally delivering a Jetsons-style future. If some good comes of these Ring stories it might be that those consumers finally begin to wake up to IoT security, and use their new-found knowledge to demand better.

Header image: Ring [CC BY-SA 4.0]

Kerry Scharfglass Secures Your IoT Things

We’ve all seen the IoT device security trainwrecks: those gadgets that fail so spectacularly that the comment section lights up with calls of “were they even thinking about the most basic security?” No, they probably weren’t. Are you?

Hackaday Contributor and all around good guy Kerry Scharfglass thinks about basic security for a living, and his talk is pitched at the newcomer to device security. (Embedded below.) Of course “security” isn’t a one-size-fits-all proposition; you need to think about what threats you’re worried about, which you can ignore, and defend against what matters. But if you’ve never worked through such an exercise, you’re in for a treat here. You need to think like a maker, think like a breaker, and surprisingly, think like an accountant in defining what constitutes acceptable risks. Continue reading “Kerry Scharfglass Secures Your IoT Things”

File Systems For Tiny Devices

Sometimes you build a computer and use it every day. Sometimes you build a different type of computer and it sits alone on a mountaintop for years. The design considerations for these two setups are remarkably different, right down to the type of file system used. For small computers like [Jo] is using, and for the amount of time they sit alone in remote locations, he decided to build his own file system for them.

Known as JesFs ([Jo]’s embedded serial File system), the file system is for SPI Flash and intended for use in scientific data logging. It can be used on the chip-scale processors found in many development boards, and is robust enough to use in applications where remoteness is a concern. It has a small RAM footprint, is completely open source, includes wear leveling, and has a number of security features built-in as well.

Some of the benefits of using a file system on such a tiny chip aren’t immediately obvious unless you’re doing a lot of data logging, but it does allow you to change virtually any aspect of the firmware much more easily if everything is accessible as a file, and not something you would have to change by reflashing the whole chip, for example. There are also a number of traps that you can easily fall into when working with file systems for tiny devices.

The ESP32, Laid Bare

Most readers will be familiar with the ESP32, Espressif’s dual-core processor with integrated WiFi and Bluetooth. Few of us though will have explored all of its features, including its built-in encryption facilities and secure booting capability. With these, a developer can protect and secure their code, and keep their devices secure.

That sense of security may now be illusory though, thanks to [LimitedResults] who has developed a series of attacks on the chip that compromise its crypto core, secure boot, and flash encryption. This enables both the chance of arbitrary code execution and firmware extraction on locked-down ESP32 devices.

To achieve all this he used a glitching technique on the device’s power supply, inserting a carefully timed glitch in the rail to coincide with a particular instruction being executed. For those of us who are not experts in this technique, he provides a basic primer with a description of his home-made glitcher made using a CMOS switch chip.

It appears that there is no solution to this attack short of new silicon, however, it should be borne in mind that it’s something that depends upon a specialist hacker with a well-equipped bench, and is thus only likely to be a significant headache to manufacturers. But it undermines a key feature of a major line of microcontrollers, and as such it remains a significant piece of work.

Laser-Based Audio Injection On Voice-Controllable Systems

In one of the cooler hacks we’ve seen recently, a bunch of hacking academics at the University of Michigan researched the ability to flicker a laser at audible sound frequencies to see if they could remotely operate microphones simply by shining a light on them. The results are outstanding.

While most Hackers will have heard about ‘The Thing’ – a famous hack where Russian KGB agents would aim a radio transmitter at the great seal in the US embassy,  almost none of us will have thought of using lasers shined in from distant locations to hack modern audio devices such as Alexa or Google Assistant. In the name of due diligence, we checked it out on Wikipedia: ‘The Photoacoustic Effect’ , and indeed it is real – first discovered in 1880 by Alexander Bell! The pulsing light is heating the microphone element and causing it to vibrate along with the beam’s intensity. Getting long range out of such a system is a non-trivial product of telescopes, lasers, and careful alignment, but it can be made to work.

Digging deeper into the hack, we find that the actual microphone that is vulnerable is the MEMS type, such as the Knowles SPV0842LR5H. This attack is relatively easy to prevent; manufacturers would simply need to install screens to prevent light from hitting the microphones. For devices already installed in our homes, we recommend either putting a cardboard box over them or moving them away from windows where unscrupulous neighbors or KGB agents could gain access. This does make us wonder if MEMS mics are also vulnerable to radio waves.

As far as mobile phones are concerned, the researchers were able to talk into an iPhone XR at 10 metres, which means that, very possibly, anybody with a hand held ultra violet / infra red equipped flashlight could hack our phones at close range in a bar, for example. The counter-measures are simple – just stick some black electrical tape over the microphone port at the bottom of the phone. Or stay out of those dodgy bars. Continue reading “Laser-Based Audio Injection On Voice-Controllable Systems”

Mozilla WebThings: An Open Platform For Building IoT Devices

Mozilla recently officially released their IoT platform. This framework comes with “Gateway” software that can run on a Raspberry Pi and a framework that can run on any number of devices.

As we’ve seen, IoT is a dubious prospect for consumers. When you throw in all the privacy issues, support issues, and end-of-life issues; it gets even worse. Nobody wants their light bulbs to stop working because a server in faraway land shut down, but that’s an hilariously feasible scenario.

WebThings comes with a lot out of the box. It comes with a user interface, logging, rules, and an easy-to-understand API. Likewise the actual framework allows for building on many common devices and can be written in Node, Python, Java, Rust, Micropython, and used as an Arduino library. This opens it up for everything from a eBay ESP32 to a particle board.

We’ve started to notice some projects that use it trickling in on the tip line and on hackaday.io. We’re interested to see what kind of community grows around this, and are curious if it won’t be too long before easy-to-hack kits start showing up on your favorite online retailers.

There’s good documentation and of course, being open source, you can check out the source for yourself.

Revisiting The BlackHat Hack: How A Security Conference Was Pwned

Does anyone remember the Black Hat BCard hack in 2018? This hack has been documented extensively, most notoriously by [NinjaStyle] in his original blog post revealing the circumstances around discovering the vulnerability. The breach ended up revealing the names, email addresses, phone numbers, and personal details of every single conference attendee – an embarrassing leak from one of the world’s largest cybersecurity conferences.

To recap: The Black Hat conference badges included an embedded NFC tag storing the participant’s contact details presumably for vendors to scan for marketing purposes. After scanning the tag, [NinjaStyle] realized that his name was readily available, but not his email address and other information. Instead, the NFC reader pointed to the BCard app – an application created for reading business cards.

[NinjaStyle] decompiled the APK for the app to search for API endpoints and found that the participants each had a custom URL made using event identification values. After finding data that appeared to correspond to an eventID and badgeID, he sent a request over a web browser and found that his attendee data was returned completely unauthenticated. With this knowledge, it was possible to brute-force the contact details for every Black Hat attendee (the range of valid IDs was between 100000-999999, and there were about 18,000 attendees). Using Burp Suite, the task would take about six hours. 

He was able to get ahold of BCard to reveal the vulnerability, which was fixed in less than a day by disabling the leaky API from their legacy system. Even so, legacy APIs in conference apps aren’t an uncommon occurrence – the 2018 RSA Conference (another cybersecurity conference) also suffered from an unprotected app that allowed 114 attendee records to be accessed without permission.

With the widespread publicity of leaked attendee data, event organizers are hopefully getting smarter about the apps that they use, especially if they come from a third-party vendor. [Yashvier Kosaraju] gave a talk at TROOPERS19 about pen testing several large vendors and discovering that Kitapps (Attendify) and Eventmobi both built apps with unauthenticated access to attendee data. It’s hard to say how many apps from previous years are still around, or whether or not the next event app you use will come with authentication – just remember to stay vigilant and to not give too much of your personal data away.