This Week in Security: Facebook Hacked your Email, Cyber on the Power Grid, and a Nasty Zero-day

Ah, Facebook. Only you could mess up email verification this badly, and still get a million people to hand over their email address passwords. Yes, you read that right, Facebook’s email verification scheme was to ask users for their email address and email account password. During the verification, Facebook automatically downloaded the account’s contact list, with no warning and no way to opt out.

The amount of terrible here is mind-boggling, but perhaps we need a new security rule-of-thumb for these kind of situations. Don’t ever give an online service the password to a different service. In order to make use of a password in this case, it’s necessary to handle it in plain-text. It’s not certain how long Facebook stored these passwords, but they also recently disclosed that they have been storing millions of Facebook and Instagram passwords in plain-text internally.

This isn’t the first time Facebook has been called out for serious privacy shenanigans, either: In early 2018 it was revealed that the Facebook Android app had been uploading phone call records without informing users. Mark Zuckerberg has recently outlined his plan to give Facebook a new focus on privacy. Time will tell whether any real change will occur.

Cyber Can Mean Anything

Have you noticed that “cyber” has become a meaningless buzz-word, particularly when used by the usual suspects? The Department of Energy released a report that contained a vague but interesting sounding description of an event: “Cyber event that causes interruptions of electrical system operations.” This was noticed by news outlets, and people have been speculating ever since. What is frustrating about this is the wide range of meaning covered by the term “cyber event”. Was it an actual attack? Was Trinity shutting down the power stations, or did an intern trip over a power cord?
Continue reading “This Week in Security: Facebook Hacked your Email, Cyber on the Power Grid, and a Nasty Zero-day”

Car Alarm Hacks 3 Million Vehicles

Pen testing isn’t about evaluating inks. It is short for penetration testing — someone ensuring a system’s security by trying to break in or otherwise attack it. A company called Pen Test Partners made the news last week by announcing that high-end car alarm systems made by several vendors have a critical security flaw that could make the vehicles less secure. They claim about three million vehicles are affected.

The video below shows how alarms from Viper/Clifford and Pandora have a simple way to hijack the application. Once they have access, they can find the car in real time, control the door locks, and start or stop the car engine. They speculate a hacker could set off the alarm from a nearby chase car. You’d probably pull over if your alarm started going off. They can then lock you in your car, approach, and then force you out of the car.

Continue reading “Car Alarm Hacks 3 Million Vehicles”

Fail of the Week: EPROMs, Rats’ Nests, Tanning Lamps, and Cardboard on Fire

It all started when I bought a late-1990s synthesizer that needed a firmware upgrade. One could simply pull the ROM chip, ship it off to Yamaha for a free replacement, and swap in the new one — in 2003. Lacking a time machine, a sensible option is to buy a pre-programmed aftermarket EPROM on eBay for $10, and if you just want a single pre-flashed EPROM that’s probably the right way to go. But I wanted an adventure.

Spoiler alert: I did manage to flash a few EPROMs and the RM1X is happily running OS 1.13 and pumping out the jams. That’s not the adventure. The adventure is trying to erase UV-erasable EPROMS.

And that’s how I ended up with a small cardboard fire and a scorched tanning lamp, and why I bought a $5 LED, and why I left EPROMs out in the sun for four days. And why, in the end, I gave up and ordered a $15 EPROM eraser from China. Along the way, I learned a ton about old-school UV-erasable EPROMs, and now I have a stack of obsolete silicon that’s looking for a new project like a hammer looks for a nail — just as soon as that UV eraser arrives in the mail.

Continue reading “Fail of the Week: EPROMs, Rats’ Nests, Tanning Lamps, and Cardboard on Fire”

35C3: Finding Bugs in Bluetooth

[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.

In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.

As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the address handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.

All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.

Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.

You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.

Continue reading “35C3: Finding Bugs in Bluetooth”

Monotron Gets All the Mods

[Harry Axten] turned the diminutive Korg Monotron into a playable analog synthesizer, complete with a full-sized keyboard spanning two octaves and a MIDI interface.

Korg Introduced the Monotron analog mini-synthesizer back in 2010. They also dropped the schematics for the synth. Hackers wasted no time modifying and improving the Monotron. [Harry] incorporated several of these changes into his build. The Low-Frequency Oscillator (LFO) has been changed over to an envelope generator. The ribbon controller is gone, replaced with a CV/gate interface to sound notes.

The CV/gate interface, in turn, is connected to an ATMega328P which converts it to MIDI. MIDI data comes from one of two sources: A two-octave full-sized keyboard pulled from a scrapped MIDI controller or a MIDI connector at the back.

The user interface doesn’t stop with the keyboard. The low-cost pots on the original Monotron have been replaced with much higher quality parts on the front panel. The tuning pot is a 10-turn device, which allows for precision tuning. All the mods are mounted on a single board, which is connected to the original Monotron board.

The fruit of all hard work is an instrument that is a heck of a lot of fun to play. Check it out in the video below. Want more? You can read all about hacking about the Monotron’s bigger brother, the Monotribe.

Continue reading “Monotron Gets All the Mods”

Repairs You Can Print: Fixing Pegboard Clips That Break Too Easily

Right now, we’re running the Repairs You Can Print Contest, where one lucky student and one lucky organization will win the fancy-schmancy Prusa i3 MK3, with the neato multi-extrusion upgrade. [Budiul] is a student, so he figured he would repair something with a 3D printer. Lucky for him, the pegboard in his workshop was completely terrible, or at least the pegboard hooks were. These hooks were made out of PVC, and after time, more and more hooks broke. The solution? Print his own, and make them stronger in the process.

[Budiul] started his fix by taking the remaining, unbroken hooks on his pegboard wall organizer and measuring the relevant dimensions. These were modeled in Creo 4.0, printed out, and tested to fit. After many errors and failed models, he finally got a 3D printable version of his plastic pegboard hooks.

Of course, replacing PVC pegboard hooks with ABS hooks really isn’t that great of a solution. To fix this problem of plastic pegboard hooks for good, he printed the hooks in halves, with a channel running down the middle. This channel was filled with some steel wire and acetone welded together. The result is a fantastically strong pegboard hook that will hold up to the rigors of holding up some tools.

While printing out pegboard hooks might not seem like the greatest use of time, there are a few things going for this hack. Firstly, these aren’t the pegboard hooks made out of steel rod we all know and love; this is some sort of weird proprietary system that uses plastic molded hooks. If they’re made out of plastic anyway, you might as well print them. Secondly, being able to print your own pegboard hooks is a severely underrated capability. If you’ve ever tried to organize a workbench, you’ll know that you’ll never be able to find the right hook for the right spot. There is, apparently, a mystical superposition of pegboard hooks somewhere in the universe.

This is a great hack, and a great entry for the Repairs You Can Print contest. You can check out a video of the hack below.

Continue reading “Repairs You Can Print: Fixing Pegboard Clips That Break Too Easily”

34C3: Hacking into a CPU’s Microcode

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.