Lowering JavaScript Timer Resolution Thwarts Meltdown And Spectre

January 6, 2018 by Roger Cheng 35 Comments

The computer security vulnerabilities Meltdown and Spectre can infer protected information based on subtle differences in hardware behavior. It takes less time to access data that has been cached versus data that needs to be retrieved from memory, and precisely measuring time difference is a critical part of these attacks.

Our web browsers present a huge potential surface for attack as JavaScript is ubiquitous on the modern web. Executing JavaScript code will definitely involve the processor cache and a high-resolution timer is accessible via browser performance API.

Web browsers can’t change processor cache behavior, but they could take away malicious code’s ability to exploit them. Browser makers are intentionally degrading time measurement capability in the API to make attacks more difficult. These changes are being rolled out for Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer. Apple has announced Safari updates in the near future that is likely to follow suit.

After these changes, the time stamp returned by performance.now will be less precise due to lower resolution. Some browsers are going a step further and degrade the accuracy by adding a random jitter. There will also be degradation or outright disabling of other features that can be used to infer data, such as SharedArrayBuffer.

These changes will have no impact for vast majority of users. The performance API are used by developers to debug sluggish code, the actual run speed is unaffected. Other features like SharedArrayBuffer are relatively new and their absence would go largely unnoticed. Unfortunately, web developers will have a harder time tracking down slow code under these changes.

Browser makers are calling this a temporary measure for now, but we won’t be surprised if they become permanent. It is a relatively simple change that blunts the immediate impact of Meltdown/Spectre and it would also mitigate yet-to-be-discovered timing attacks of the future. If browser makers offer a “debug mode” to restore high precision timers, developers could activate it just for their performance tuning work and everyone should be happy.

This is just one part of the shock wave Meltdown/Spectre has sent through the computer industry. We have broader coverage of the issue here.

Learn To Reverse Engineer X86_64 Binaries

January 6, 2018 by Sven Gregori 16 Comments

Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.

While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leonora Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, she ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.

All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.

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” →