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.

Art, Craft, Make, Hack, Whatever

Anyone who has spent much time reading Hackaday, or in the real world in or around a few hackspaces, will know that ours is a community of diverse interests. In the same place you will find a breathtaking range of skills and interests, people working with software, electronics, textiles, and all conceivable materials and media. And oftentimes in the same person: a bare-metal kernel guru might spend their time in a hackspace making tables from freight pallets rather than coding.

Through it all run a variety of threads, identities if you will, through which the differing flavours of our wider community define themselves. Words like “Hacker” and “Maker” you may identify with, but when I mention words like “Crafter” or “Artist”, perhaps they might meet with some resistance. After all, artists paint things, don’t they, and crafters? They make wooly hats and corn dollies! Continue reading “Art, Craft, Make, Hack, Whatever”

The Dark Arts – Remote File Inclusion

In the waning hours of 2010, a hacking group known as Lulzsec ran rampant across the Internet, leaving a path of compromised servers, a trail of defaced home pages, leaked emails, and login information in their wake. They were eventually busted via human error, and the leader of the group becoming an FBI informant. This handful of relatively young hackers had made a huge mess of things. After the digital dust had settled – researches, journalists, and coders began to dissect just how these seemingly harmless group of kids were able to harness so much power and control over the World Wide Web. What they found was not only eye-opening to web masters and coders, but shined a light on just how vulnerable all of our data was for everyone to see. It ushered in an era of renewed focus on security and how to write secure code.

In this Dark Arts series, we have taken a close look at the primary techniques the Luzsec hackers used to gain illegal access to servers. We’ve covered two them – SQL injection (SQLi) and cross-site scripting (XSS). In this article, we’ll go over the final technique called remote file inclusion (RFI).

DISCLAIMER: Fortunately, the surge of security-minded coding practices after the fall of Lulzsec has (for the most part) removed these vulnerabilities from the Internet as a whole. These techniques are very dated and will not work on any server that is maintained and/or behind a decent firewall, and your IP will probably get flagged and logged for trying them out. But feel free to set up a server at home and play around. Continue reading “The Dark Arts – Remote File Inclusion”

Don’t be a Code Tyrant, Be A Mentor

Hardware hacking is a way of life here at Hackaday. We celebrate projects every day with hot glue, duct tape, upcycled parts, and everything in between. It’s open season to hack hardware. Out in the world, for some reason software doesn’t receive the same laissez-faire treatment. “Too many lines in that file” “bad habits” “bad variable names” the comments often rain down. Even the unsafest silliest of projects isn’t safe. Building a robot to shine lasers into a person’s eyes? Better make sure you have less than 500 lines of code per file!

Why is this? What makes readers and commenters hold software to a higher standard than the hardware it happens to be running on? The reasons are many and varied, and it’s a trend I’d like to see stopped.

Software engineering is a relatively young and fast evolving science. Every few months there is a new hot language on the block, with forums, user groups, and articles galore. Even the way software engineers work is constantly changing. Waterfall to agile, V-Model, Spiral model. Even software design methodologies change — from pseudo code to UML to test driven development, the list goes on and on.

Terms like “clean code” get thrown around. It’s not good enough to have software that works. Software must be well commented, maintainable, elegant, and of course, follow the best coding practices. Most of these are good ideas… in the work environment. Work is what a lot of this boils down to. Software engineers have to stay up to date with new trends to be employable.

There is a certain amount of “born again” mentality among professional software developers. Coders generally hate having change forced upon them. But when they find a tool or system they like, they embrace it both professionally, and in their personal projects. Then they’re out spreading the word of this new method or tool; on Reddit, in forums, to anyone who will listen. The classic example of this is, of course, editors like the vi vs emacs debate.

Continue reading “Don’t be a Code Tyrant, Be A Mentor”

Shut the Backdoor! More IoT Cybersecurity Problems

We all know that what we mean by hacker around here and what the world at large thinks of as a hacker are often two different things. But as our systems get more and more connected to each other and the public Internet, you can’t afford to ignore the other hackers — the black-hats and the criminals. Even if you think your data isn’t valuable, sometimes your computing resources are, as evidenced by the recent attack launched from unprotected cameras connected to the Internet.

As [Elliot Williams] reported earlier, Trustwave (a cybersecurity company) recently announced they had found a backdoor in some Chinese voice over IP gateways. Apparently, they left themselves an undocumented root password on the device and — to make things worse — they use a proprietary challenge/response system for passwords that is insufficiently secure. Our point isn’t really about this particular device, but if you are interested in the details of the algorithm, there is a tool on GitHub, created by [JacobMisirian] using the Trustwave data. Our interest is in the practice of leaving intentional backdoors in products. A backdoor like this — once discovered — could be used by anyone else, not just the company that put it there.

Continue reading “Shut the Backdoor! More IoT Cybersecurity Problems”

Is Your Child A Hacker?

Parents in Liverpool, UK, are being prepared to spot the signs that their children might be hackers. The Liverpool Echo reports on the launch of a “Hackers To Heroes” scheme targeting youngsters at risk of donning a black hat, and has an expert on hand, one [Vince Warrington], to come up with a handy cut-out-and-keep list. Because you never know when you’re going to need one, and he’s helped the Government so should know what he’s talking about.

Of course, they’re talking about “Hacker” (cybercriminal) while for us the word has much more positive connotations. And it’s yet another piece of ill-informed media scaremongering about technology that probably fits like so many others in the “People are having fun. Something Must Be Done About It!” category. But it’s still something that will probably result in hassle for a few youngsters with an interest in technology, and that’s not encouraging.

The full list is reproduced below, if you’re a parent it seems you will need to watch your children if:

  1. They spend most of their free time alone with their computer
  2. They have few real friends, but talk extensively to online friends about computers
  3. Teachers say the child has a keen interest in computers, almost to the exclusion of all other subjects
  4. They’re online so much it affects their sleeping habits
  5. They use the language of hacking, with terms such as ‘DdoS’ (pronounced D-dos), Dossing, pwnd, Doxing, Bots, Botnets, Cracking, Hash (refers to a type of encryption rather than cannabis), Keylogger, Lulz, Phishing, Spoof or Spoofing. Members of the Anonymous Hackivist group refer to their attacks as ‘Ops’
  6. They refer to themselves and their friends as hackers or script kiddies
  7. They have multiple social media profiles on one platform
  8. They have multiple email addresses
  9. They have an odd sounding nickname (famous ones include MafiaBoy and CyberZeist)
  10. Their computer has a web browser called ToR (The Onion Router) which is used to access hacking forums on the dark web
  11. Monitoring tools you’ve put on the computer might suddenly stop working
  12. They can connect to the wifi of nearby houses (especially concerning if they have no legitimate reason to have the password)
  13. They claim to be making money from online computer games (many hackers get started by trying to break computer games in order to exploit flaws in the game. They will then sell these ‘cheats’ online).
  14. They might know more than they should about parents and siblings, not being able to resist hacking your email or social media
  15. Your internet connection slows or goes off, as their hacker rivals try to take them down
  16. Some circumstantial evidence suggests children with Autism and Asperger’s could be more vulnerable to becoming hackers.

Reading the list, we can’t help wondering how many Hackaday readers would recognise as perfectly normal behaviours from their own formative years. And some of them look ripe for misinterpretation, for example your internet connection slowing down does not automatically mean that little [Jimmy] is selling a billion compromised social media accounts on the Dark Web.

Particularly concerning though is the final association of computer crime with children who are autistic or have Asperger’s Syndrome. Picking on a minority as a scapegoat for a public moral panic is reprehensible, and is not responsible journalism.

Still, you have to laugh. They remembered to include a stock photo of a hacker using a keyboard, but they’ve completely missed the telltale sign of a real hacker, which is of course wr1t1n9 11k3 r341 1337 h4xxx0rzzz.

Via The Register.

Liverpool skyline, G-Man (Public domain) via Wikimedia Commons.

Do you trust your hard drive indication light?

Researchers in the past have exfiltrated information through air gaps by blinking all sorts of lights from LEDs in keyboards to the main display itself. However, all of these methods all have one problem in common: they are extremely noticeable. If you worked in a high-security lab and your computer screen started to blink at a rapid pace, you might be a little concerned. But fret not, a group of researchers has found a new light to blink (PDF warning). Conveniently, this light blinks “randomly” even without the help of a virus: it’s the hard drive activity indication light.

All jokes aside, this is a massive improvement over previous methods in more ways than one. Since the hard drive light can be activated without kernel access, this exploit can be enacted without root access. Moreover, the group’s experiments show that “sensitive data can be successfully leaked from air-gapped computers via the HDD LED at a maximum bit rate of 4000 bit/s (bits per second), depending on the type of receiver and its distance from the transmitter.” Notably, this speed is “10 times faster than the existing optical covert channels for air-gapped computers.”

We weren’t born last night, and this is not the first time we’ve seen information transmission over air gaps. From cooling fans to practical uses, we’ve seen air gaps overcome. However, there are also plenty of “air gaps” that contain more copper than air, and require correspondingly less effort.

Continue reading “Do you trust your hard drive indication light?”