Two Factor Authentication With The ESP8266

January 4, 2018 by Tom Nardi 23 Comments

Google Authenticator is a particularly popular smartphone application that can be used as a token for many two factor authentication (2FA) systems by generating a time-based one time password (referred to as TOTP). With Google Authenticator, the combination of your user name and password along with the single-use code generated by the application allows you to securely authenticate yourself in a way that would be difficult for an attacker to replicate.

That sounds great, but what if you don’t have a smartphone? That’s the situation that [Lady Ada] recently found herself in, and rather than going the easy route and buying a hardware 2FA token that’s compatible with Google Authenticator, she decided to build one herself based on the ESP8266. With the hardware and source documented on her site, the makings of an open source Google Authenticator hardware token are available for anyone who’s interested.

Generated codes can also be viewed via serial.

For the hardware, all you need is the ESP8266 and a display. Naturally [Lady Ada] uses her own particular spin on both devices which you can purchase if you want to create an identical device, but the concept will work the same on the generic hardware you’ve probably already got in the parts bin. Software wise, the code is written in CircuitPython, a derivative of MicroPython, which aims to make microcontroller development easier. If you haven’t tried MicroPython before, grab an ESP and give this a roll.

Conceptually, TOTP is relatively simple. You just need to know what time it is, and run an SHA1 hash. The time part is simple enough, as the ESP8266 can connect to the network and get the current time from NTP. The calculation of the TOTP is handled by the Python code once you’ve provided it with the “secret” pulled from the Google Authenticator application. It’s worth noting here that this means your 2FA secrets will be held in clear-text on the ESP8266’s flash, so try not to use this to secure any nuclear launch systems or anything, OK? Then again, if you ever lose it the beauty of 2-factor is you can invalidate the secret and generate a new one.

We’ve covered the ins and outs of 2FA applications before here at Hackaday if you’d like to know more about the concept, in addition to previous efforts to develop a hardware token for Google Authenticator.

Samy Kamkar: Reverse Engineering For A Secure Future

January 2, 2018 by Dan Maloney 15 Comments

Show of hands: how many of you have parked your car in the driveway, walked up to your house, and pressed your car’s key fob button thinking it would open the front door? We’ve probably all done it and felt a little dopey as a result, but when you think about it, it would be tremendously convenient, especially with grocery bags dangling off each arm and the mail clenched between your teeth. After all, we’re living in the future — shouldn’t your house be smart enough to know when you’re home?

Reverse engineer par excellence Samy Kamkar might think so, but given his recent experiences with cars smart enough to know when you’re standing outside them, he’d probably have some reservations. Samy dropped by the 2017 Hackaday Superconference in November to discuss the finer points of exploiting security flaws in passive car entry systems, and also sat down with our own Elliot Williams after his talk for a one-on-one interview. Samy has some interesting insights on vehicle cybersecurity, but the practical knowledge he’s gained while exploring the limits of these systems teach some powerful lessons about being a real-world reverse engineer.

Continue reading “Samy Kamkar: Reverse Engineering For A Secure Future” →

When A Skimmer Isn’t A Skimmer

January 2, 2018 by Tom Nardi 163 Comments

I have a confession to make: ever since the first time I read about them online, I’ve been desperate to find an ATM skimmer in the wild. It’s the same kind of morbid curiosity that keeps us from turning away from a car accident, you don’t want to be witness to anyone getting hurt, but there’s still that desire to see the potential for danger up close. While admittedly my interest is largely selfish (I already know on which shelf I would display it), there would still be tangible benefits to the community should an ATM skimmer cross my path. Obviously I would remove it from the machine and prevent others from falling prey to it, and the inevitable teardown would make interesting content for the good readers of Hackaday. It’s a win for everyone, surely fate should be on my side in this quest.

So when my fingers brushed against that unmistakable knobby feel of 3D printed plastic as I went to insert my card at a local ATM, my heart skipped a beat. After all these years, my dream had come true. Nobody should ever be so excited about potentially being a victim of fraud, but there I was, grinning like an idiot in the farmer’s market. Like any hunter I quickly snapped a picture of my quarry for posterity, and then attempted to free it from the host machine.

But things did not go as expected. I spend most of my free time writing blog posts for Hackaday, so it’s safe to say that physical strength is not an attribute I possess in great quantity, but even still it seemed odd I couldn’t get the skimmer detached. I yanked it in every direction, tried to spin it, did everything short of kicking it; but absolutely no movement. In fact, I noticed that when pulling on the skimmer the whole face plate of the ATM bulged out a bit. I realized this thing wasn’t just glued onto the machine, it must have actually been installed inside of it.

I was heartbroken to leave my prize behind, but at the very least I would be able to alert the responsible party. The contact info for the ATM’s owner was written on the machine, so I emailed them the picture as well as all the relevant information in hopes that they could come check the machine out before anyone got ripped off.

Continue reading “When A Skimmer Isn’t A Skimmer” →

34C3: Hacking The Nintendo Switch

December 29, 2017 by Tom Nardi 37 Comments

There’s a natural order to the world of game console hacking: every time a manufacturer releases a new game console they work in security measures that prevent the end user from running anything but commercially released games, and in turn every hacker worth his or her salt tries to break through. The end goal, despite what the manufacturers may have you believe, is not to run “bootleg” games, but rather to enable what is colloquially referred to as “homebrew”. That is to say, enabling the novel concept of actually running software of your choice on the hardware you paid for.

At 34C3, noted console hackers [Plutoo], [Derrek], and [Naehrwert] have demonstrated unsigned code running on Nintendo’s latest and greatest and while they are keeping the actual exploit to themselves for now, they’ve promised that a platform for launching homebrew is coming shortly for those who are on firmware version 3.0.0. From the sound of it, after 9 months on the market, Switch owners will finally have complete access to the hardware they purchased.

The key to running the team’s own code was through a WebKit exploit that was already months old by the time the Switch was released. Loading up an arbitrary webpage was the tricky part, as the Switch generally uses its web browser for accessing official sources (like the online game store). But hidden away in the help menus of Tetris, the developers helpfully put a link to their website which the Switch will dutifully open if you select it. From there it’s just a matter of network redirection to get the Switch loading a webpage from your computer rather than the Internet.

It’s easier to ask for forgiveness than permission.

But as the more security-minded of our readers may have guessed already, that just gets you into the browser’s sandbox. The team now had to figure out a way to break out and get full control of the hardware. Through a series of clever hacks the team was able to learn more about the Switch’s internal layout and operating system, slowly working their way up the ladder.

A particularly interesting hack was used to get around a part of the Switch’s OS that is designed to check which services code is allowed to access. It turns out that if code doesn’t provide this function with its own process ID (PID), the system defaults to PID 0 because the variable is not initialized. In other words, if you don’t ask the operating system which functions you have access to, you will get access to them all. This is a classic programming mistake, and a developer at Nintendo HQ is likely getting a very stern talking to right about now.

But not everything was so easy. When trying to get access to the boot loader, the team sniffed the eMMC bus and timed the commands to determine when it was checking the encryption keys. They were then able to assemble a “glitcher” which fiddled with the CPU’s power using FPGA controlled MOFSETs during this critical time in an attempt to confuse the system.

The rabbit hole is pretty deep on this one, so we’d recommend you set aside an hour to watch the entire presentation to see the long road it took to go from a browser bug to running their first complete demo. It’s as much a testament to the skill of [Plutoo], [Derrek], and [Naehrwert] as it is the lengths at which Nintendo went to keep people out.

We’ve seen other attempts at reverse engineering Nintendo’s hardware, but by the looks of it, the Switch has put up a much harder fight than previous console generations. Makes you wonder what tricks Nintendo will have up their sleeves for the next generation.

Continue reading “34C3: Hacking The Nintendo Switch” →

34C3: Fitbit Sniffing And Firmware Hacking

December 29, 2017 by Brian McEvoy 19 Comments

If you walked into a gym and asked to sniff exercise equipment you would get some mighty strange looks. If you tell hackers you’ve sniffed a Fitbit, you might be asked to give a presentation. [Jiska] and [DanielAW] were not only able to sniff Bluetooth data from a run-of-the-mill Fitbit fitness tracker, they were also able to connect to the hardware with data lines using test points etched right on the board. Their Fitbit sniffing talk at 34C3 can be seen after the break. We appreciate their warning that opening a Fitbit will undoubtedly void your warranty since Fitbits don’t fare so well after the sealed case is cracked. It’s all in the name of science.

There’s some interesting background on how Fitbit generally work. For instance, the Fitbit pairs with your phone which needs to be validated with the cloud server. But once the cloud server sends back authentication credentials they will never change because they’re bound to to the device ID of the Fitbit. This process is vulnerable to replay attacks.

Data begin sent between the Fitbit and the phone can be encrypted, but there is a live mode that sends the data as plain text. The implementation seemed to be security by obscurity as a new Bluetooth handle is used for this mode. This technique prevents the need to send every encrypted packet to the server for decryption (which would be for every heartbeat packet). So far the fix for this has been the ability to disable live mode. If you have your own Fitbit to play with, sniffing live mode would be a fun place to start.

The hardware side of this hack begins by completely removing the PCB from the rubber case. The board is running an STM32 and the team wanted to get deep access by enabling GDB. Unfortunately, the debug pins were only enabled during reset and the stock firmware disables them at startup (as it should). The workaround was to rewrite the firmware so that the necessary GPIO remain active and there’s an interesting approach here. You may remember [Daniel Wegemer] from the Nexmon project that reverse engineered the Nexus 5 WiFi. He leveraged the binary patching he used on Nexmon to patch the Fitbit firmware to enable debugging support. Sneaky!

For more about 34C3 we have a cheatsheet of the first day and for more about Fitbit security, check out this WAV file.

Continue reading “34C3: Fitbit Sniffing And Firmware Hacking” →

The Bedside Light App That Phones Home

December 26, 2017 by Jenny List 31 Comments

Desiring a bedside lamp with a remote control, [Peadar]’s wife bought a Xiaomi Yeelight, an LED model with an accompanying Android app. And since he’s a security researcher by trade, he subjected the app to a close examination and found it to be demanding permissions phoning home to a far greater extent than you’d expect from a bedside light.

His write-up is worth a read for its fascinating run-through of the process for investigating any Android app, as it reveals the level to which the software crosses the line from simple light-controller into creepy data-slurper. The abilities to create accounts on your device, download without notification, take your WiFi details and location, and record audio are not what you’d expect to be necessary in this application. He also looks into the Xiaomi web services the app uses to phone home, revealing some interesting quirks along the way.

This story has received some interest across the Internet, quite rightly so since it represents a worrying over-reach of corporate electronic intrusion. It is interesting though to see commentary whose main concern is that the servers doing the data-slurping are in China, as though somehow in this context the location is the issue rather than the practice itself. We’ve written before about how some mildly sinister IoT technologies seem to bridge the suspicion gap while others don’t, it would be healthy to see all such services subjected to the same appraisal.

As a postscript, [Peadar] couldn’t get the app to find his wife’s Yeelight, let alone control it. That the spy part of the app works while the on-the-surface part doesn’t speaks volumes about the development priorities of its originator.

Image: Xiaomi Yeelight website.

Edward Snowden Introduces Baby Monitor For Spies

December 24, 2017 by Tom Nardi 25 Comments

Famed whistleblower [Edward Snowden] has recently taken to YouTube to announce Haven: an Open Source application designed to allow security-conscious users turn old unused Android smartphones and tablets into high-tech monitoring devices for free. While arguably Haven doesn’t do anything that wasn’t already possible with software on the market, the fact that it’s Open Source and designed from the ground up for security does make it a bit more compelling than what’s been available thus far.

Developed by the Freedom of the Press Foundation, Haven is advertised as something of a role-reversal for the surveillance state. Instead of a smartphone’s microphone and camera spying on its owner, Haven allows the user to use those sensors to perform their own monitoring. It’s not limited to the camera and microphone either, Haven can also pull data from the smartphone’s ambient light sensor and accelerometer to help determine when somebody has moved the device or entered the room. There’s even support for monitoring the device’s power status: so if somebody tries to unplug the device or cut power to the room, the switch over to the battery will trigger the monitoring to go active.

Thanks to the Open Source nature of Haven, it’s hoped that continued development (community and otherwise) will see an expansion of the application’s capabilities. To give an example of a potential enhancement, [Snowden] mentions the possibility of using the smartphone’s barometer to detect the opening of doors and windows.

With most commercially available motion activated monitor systems, such as Nest Cam, the device requires a constant Internet connection and a subscription. Haven, on the other hand, is designed to do everything on the local device without the need for a connection to the Internet, so an intruder can’t just knock out your Wi-Fi to kill all of your monitoring. Once Haven sees or hears something it wants you to know about it can send an alert over standard SMS, or if you’re really security minded, the end-to-end encrypted Signal.

The number of people who need the type of security Haven is advertised as providing is probably pretty low; unless you’re a journalist working on a corruption case or a revolutionary plotting a coup d’etat, you’ll probably be fine with existing solutions. That being said, we’ve covered on our own pages many individuals who’ve spent considerable time and effort rolling their own remote monitoring solutions which seem to overlap the goals of Haven.

So even if your daily life is more John Doe than James Bond, you may want to check out the GitHub page for Haven or even install it on one of the incredibly cheap Android phones that are out there and take it for a spin.

Continue reading “Edward Snowden Introduces Baby Monitor For Spies” →