Posted: August 20, 2017 by James Pavur
This is the second in a series of posts outlining my efforts to reverse engineer the new Amazon Dash Wand to understand how it works and how secure it is. Rather than just do the typical security blog writeup of exploits, I wanted to share the entire process including the numerous dead ends and false leads involved in an embedded reverse engineering effort.
You can find other posts in the series here.
Although Matthew Petroff had already done an excellent teardown of the wand, I wanted to be 100% sure that my device was identical and see if there might be any easy debug pins that had made their way on to more recent iterations of the device.
The wand turned out to be far harder to get into than I expected due to some very strong plastic welds keeping the two halves of the case affixed to each other. This resulted in me more or less hopelessly scratching up my dash wand in an effort to slice through the welds and pop the device open.
Eventually, by focusing on one of the two corners down by the battery side I was able to get enough leverage to pry open the case and I didn’t end up breaking the device in the process.
If you want to try and pop open one of these wands yourself, I strongly recommend focusing on the lower corners and then prying up to the main body of the device. It’s also worth noting that the LED barcode reader on the front of the device is affixed with some sort of adhesive and can just be peeled off like a sticker once you have enough of the main body pried open.
Unsurprisingly, I didn’t notice much more than what Matthew had already found on his version of the wand. Rather than poke around for UART pins (which likely are lying somewhere on the board, but, judging by past efforts with the Dash Button v2, don’t offer much), I decided to close everything back up and return to the software side of things.
On the original dash buttons, during setup you could access a simple wireless access point called “Amazon ConfigureMe” and set network parameters there.
In more recent versions, this server has hosted a JSON-based REST API which an android phone can connect to and configure the device via POST requests containing information like the target network’s wifi credentials.
By holding down the Dash Wand’s button for a few seconds I was able to bring up the “Amazon ConfigureMe” hotspot. Connecting to the hostpot and then navigating to the default gateway (192.168.0.1) brought up a simple web interface that showed some information about my device.
Unfortunately, none of the previously discovered API endpoints from the Dash v2 appeared active and instead just returned 404 errors.
To confirm, I put a kali laptop into monitor mode and sniffed traffic to the end point while running through the setup flow in the Amazon App. No traffic was actually exchanged between the ConfigureMe hotspot and my Android phone. If I disabled Bluetooth on my device, the phone refused to event attempt to connect to the Dash Wand (unlike in previous versions where it would fall back to wifi).
Although the web application and hardware teardown turned out to be duds in terms of accessing the device, I did learn a few important things about the wand that will guide my next steps.
First, I confirmed that my device was the same physical device as the early 2016 teardown performed by Matthew Petroff. This tells me that it’s unlikely that there will be multiple versions of the dash wand on the market which means anything I can find online from other researchers is likely equally applicable to my own device.
Second, I learned that the device behaves differently in setup mode than simply when it is being used. While the only manifestation of this change I’ve encountered so far is the simple wifi hotspot it spins up, the discovery leads me to suspect that there might be other vulnerable behaviors that occur when the device is in this “configuration mode” that might not be detectable if I only audited a fully configured device.
Since it appears that the Amazon App is able to communicate with the device in some way (likely bluetooth), perhaps I’ll be able to find ways to pass vulnerable input information to the device over bluetooth communications channels. The first step to figuring out how to do that will be understanding how the official Amazon App communicates with the Wand.
Stay tuned for the next post in this series where I take a look at the inner workings of the Amazon Android App.