While there’s broad agreement that Meltdown and Spectre attacks are really bad news at a fundamental level, there is disagreement on its immediate practical impact in the real world. Despite reassurance that no attacks have been detected in the wild and there’s time to roll out the full spectrum of mitigation, some want to find protection right now. If you’re interested in an usable and easy to set up modern desktop that’s free of Meltdown or Spectre threats, a Raspberry Pi can provide the immunity you seek.
[Eben Upton] explained the side channel attacks using fragments of Python for illustration, which was an enlightening read independent of the Raspberry Pi pitch. While these ARM cores perform speculative instruction fetches, they don’t speculatively execute them or modify the cache. Under the current circumstances, that makes all the difference in the world.
A clever security researcher may yet find a way to exploit speculative fetches in the future, and claiming that Raspberry Pi has superior security would be a stretch. The platform has its own set of security problems, but today Meltdown/Spectre is not among them. And that just might be enough to sway some decisions.
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.
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.
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.
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.
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.
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.
