By Daniel Heinen
The year is 2018. The place is Defcon 26, Las Vegas. 20-year-old me was walking around looking for something fun to do. I eventually came across something interesting at IoT Village. One of the sponsors that year was Starbucks, and they had brought a Mastrena II to see if hackers could break into it.
For context, the Marstrena II is a commercial espresso machine used in most Starbucks stores. Before that year, Starbucks had been using an older version of that espresso maker. The updated version they brought had internet connectivity, allowing Starbucks to update the software, change recipes, and obtain metrics.
The machine was custom-built for them, the manufacturer had built the hardware and software and Starbucks had to trust that it was secure. The Starbucks team told us their concern with the machine being on the same network as the Point of Sales System, and they wanted to ensure it was secure before they deployed it globally. The Starbucks team seemed confident that no one would be able to break into the machine. One of the reps even went as far as to say that they had just loaded the latest security software and that “there is no way, kid”. By the time I had stumbled across the espresso machine, there was only a day or two left at Defcon. No one had been able to crack it so far.
To their credit, the machine was locked down tight. The only open port was port 22 for ssh, which was the latest and greatest version of Open SSH. We had physical access to the system such that we had the same access a Starbucks employee might have. That was all — no access to software, login credentials, etc. I spent probably 2 hours trying to break into that machine using conventional methods with no luck.
After trying every trick I knew at the time, I sat back, frustrated. To me, being a hacker means thinking outside of the box. Everyone else had been trying a different version of the same thing, and I still could not help but feel like everyone around me was a much better hacker than me. What was I even doing there? Should I bother? I thought if they weren’t having any luck, how was I supposed to get in? I then started pacing around the conference room racking my brain for a new approach. After a second, something the rep had said stuck out to me.
“We just put the latest software on.”
This means they had probably brought a copy of the firmware to the convention. Back then, I had spent a lot of time tearing apart firmware for embedded devices. I had learned that many different vendors used terrible practices, so if you could get your hands on firmware, you could usually find something interesting. To me, most vendors appeared to focus on preventing hackers from getting access to firmware instead of writing secure firmware. If I could get my hands on a copy of the firmware then I was sure I had a shot.
While I was pacing around the IoT village conference room, I noticed that one of the Starbucks techs had left a toolbox off to the side. No one seemed to be paying any attention to the pile of extension cords, tools, and wires in that corner. I casually walked over and inspected the toolbox. It was unlocked and unattended, so I decided to help myself. I opened it and to my surprise, the first thing I noticed was a USB thumb drive.
“There is no way,” I thought to myself.
One golden rule at Defcon is that you should never, under any circumstance, plug an unknown thumb drive into your computer. Doing so at Defcon is just asking for something bad to happen. So while my logical brain was telling me to put it back, my insatiable curiosity was screaming, “PLUG IT IN, PLUG IT IN”. And so I did.
Lo and behold, the first folder I saw when I plugged in the flash drive was “firmware.zip”. I was dumbfounded. I had never thought it would be that simple, but it was — no encryption, no tricks, all firmware with that day’s updates. Inside the zip file, there was a squashfs file containing the file system. There were lots of interesting config files like Products.json which contained machine settings for making different drinks.
I called over a few friends I had made that week at Defcon and we started ripping the firmware apart. For background, within the machine’s GUI the settings menu was locked by a pin code. If we wanted to access any information about the machine, change settings, or load new firmware, we needed those pin codes. Eventually, we came across three hardcoded passwords for the machine. There was a service pin code, a lab tech pin code, and a manufacturer’s pin code. We tried our hacked credentials and bingo, we were in. We were overwhelmed by the number of settings and information we had access to. We had the ability to load new firmware, change the hardware settings for coil temperature, add new products, and much more.
Now keep in mind this was the last day that Starbucks was going to be at the conference and they were getting ready to pack up the machine. Sadly, we didn’t have enough time to do a thorough analysis of the software and find software exploits, but we did gain privileged access using manufacturer default credentials. We called over the rep from Starbucks and showed him our findings. By then we had successfully changed all the names of the coffee drinks the machine could make to our respective Twitter handles.
What did I learn from this experience? Well, I learned a lot about the real-world applications of embedded security. I also learned that you should never be afraid to think outside the box when it comes to hacking. There is always more than one way to break into something, and if all conventional methods fail, don’t be afraid to look for alternate solutions. I admit that without finding the firmware flash drive, I probably would not have been able to get into the machine. However, this demonstrates an example of supply chain vulnerability. The tech that left the USB drive unattended was not from Starbucks but from the manufacturer of the espresso machine. If a technician could accidentally leave proprietary firmware laying around at one of the biggest hacker conferences, where else could it have been left? What if someone was able to slip malicious firmware into the Starbucks supply chain? It wouldn’t be completely out of the realm of possibility that technicians might use that same USB drive to set up other machines at different Starbucks locations. Imagine if a bad actor had found a way to manipulate that copy of the firmware. With over 33,000 Starbucks stores across the USA processing billions of dollars in transactions, that would be a desirable target for hackers.
An important takeaway is that relying on a hacker not to have access to your firmware is not a safe way to approach security. Assuming you can use bad practices and no one will notice is a dangerous assumption. Additionally, you should be very careful when it comes to your software and hardware vendors. You could do everything right and still be left exposed. Always make sure that you are protecting your code and data by using best practices and monitoring your supply chain weaknesses. With the right information and creativity, almost anything can be hacked! Lastly, I learned that persistence pays off. If I had given up after an hour or two earlier, I would have walked away with one less cool story and less valuable experience.
Fast forward five years, and I have started a cyber security company called Graylark. We use AI to try to automate the process of bug hunting in a black box environment. Our philosophy is to find what assumptions have been built into a system and try to break and abuse them to find exploits/footholds. Using AI and machine learning, we are building a system that understands technical documentation of how a system/technology is supposed to function and identifies when technology is implemented improperly and what that impact is. Most modern-day applications and systems are built on top of other systems. Few engineers have the breadth of knowledge or the time to fully understand how technology functions and its limitations. Oftentimes, this leads to mistakes in code, architecture, and implementation. Oftentimes, this is where hackers can abuse/break a system for their gain. Building a solution that allows a developer or team to have a “Red Team In Their Pocket” can help us build more secure technology and keep users safe.
P.S
If you are interested in a copy of the binary send me a message.
