Apple Passwords: They All ‘Just Work’

January 12, 2018 by Brian Benchoff 40 Comments

When the Macintosh was released some thirty-odd years ago, to Steve Jobs’ triumphant return in the late 90s, there was one phrase to describe the simplicity of using a Mac. ‘It Just Works’. Whether this was a reference to the complete lack of games on the Mac (Marathon shoutout, tho) or a statement to the user-friendliness of the Mac, one thing is now apparent. Apple has improved the macOS to such a degree that all passwords just work. That is to say, security on the latest versions of macOS is abysmal, and every few weeks a new bug is reported.

The first such security vulnerability in macOS High Sierra was reported by [Lemi Ergin] on Twitter. Simply, anyone could login as root with an empty password after clicking the login button several times. The steps to reproduce were as simple as opening System Preferences, Clicking the lock to make changes, typing ‘root’ in the username field, and clicking the Unlock button. It should go without saying this is incredibly insecure, and although this is only a local exploit, it’s a mind-numbingly idiotic exploit. This issue was quickly fixed by Apple in the Security Update 2017-001

The most recent password flaw comes in the form of unlocking the App Store preferences that can be unlocked with any password. The steps to reproduce on macOS High Sierra are simply:

Click on System Preferences
Click on App Store
Click the padlock icon
Enter your username and any password
Click unlock

This issue has been fixed in the beta of macOS 10.13.3, which should be released within a month. The bug does not exist in macOS Sierra version 10.12.6 or earlier.

This is the second bug in macOS in as many months where passwords just work. Or don’t work, depending on how cheeky you want to be. While these bugs have been overshadowed with recent exploits of Intel’s ME and a million blog posts on Meltdown, these are very, very serious bugs that shouldn’t have happened in the first place. And, where there are two, there’s probably more.

We don’t know what’s up with the latest version of the macOS and the password problems, but we are eagerly awaiting the Medium post from a member of the macOS team going over these issues. We hope to see that in a decade or two.

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

34C3: Hacking Into A CPU’s Microcode

December 28, 2017 by Elliot Williams 67 Comments

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

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

DRM Workarounds Save Arcade Cabinet

December 19, 2017 by Bryan Cockfield 32 Comments

DRM has become a four-letter word of late, with even media companies themselves abandoning the practice because of how ineffective it was. DRM wasn’t invented in the early 2000s for music, though. It’s been a practice on virtually everything where software is involved, including arcade cabinets. This is a problem for people who restore arcade machines, and [mon] has taken a swing at unraveling the DRM for a specific type of Konami cabinet.

The game in question, Reflec Beat, is a rhythm-based game released in 2010, and the security is pretty modern. Since the game comes with a HDD, a replacement drive can be ordered with a security dongle which acts to decrypt some of the contents on the HDD, including the game file and some other information. It’s not over yet, though. [mon] still needs to fuss with Windows DLL files and a few levels of decryption and filename obfuscation before getting the cabinet functional again.

The writeup on this cabinet is very detailed, and if you’re used to restoring older games, it’s a bit of a different animal to deal with than the embedded hardware security that older cabinets typically have. If you’ve ever wanted to own one of these more modern games, or you’re interested in security, be sure to check out the documentation on the project page. If your tastes are more Capcom and less Konami, check out an article on their security system in general, or in de-suiciding boards with failing backup batteries.

Design A Microcontroller With Security In Mind

December 15, 2017 by Roger Cheng 22 Comments

There are many parts to building a secure networked device, and the entire industry is still learning how to do it right. Resources are especially constrained for low-cost microcontroller devices. Would it be easier to build more secure devices if microcontrollers had security hardware built-in? That is the investigation of Project Sopris by Microsoft Research.

The researchers customized the MediaTek MT7687, a chip roughly comparable to the hacker darling ESP32. The most significant addition was a security subsystem. It performs tasks notoriously difficult to do correctly in software, such as random number generation and security key storage. It forms the core of what they called the “hardware-based secure root of trust.”

Doing these tasks in a security-specific module solves many problems. If a key is not stored in memory, a memory dump can’t compromise what isn’t there. Performing encryption/decryption in task-specific hardware makes it more difficult to execute successful side-channel attacks against them. Keeping things small keeps the cost down and also eases verifying correctness of the code.

But the security module can also be viewed from a less-favorable perspective. Its description resembles a scaled-down version of the Trusted Platform Module. As a self-contained module running its own code, it resembles the Intel Management Engine, which is currently under close scrutiny.

Will we welcome Project Sopris as a time-saving toolkit for building secure networked devices? Or will we become suspicious of hidden vulnerabilities? The researchers could open-source their work to ease these concerns, but value of their work will ultimately depend on the fast-moving field of networked device security.

Do you know of other efforts to add hardware-assisted security to microcontrollers? Comment below or let us know via the tip line!

[via Wired]

Image of Mount Sopris, namesake of the project, by [Hogs555] (CC-BY 4.0)