Bitcoin’s Double Spending Flaw Was Hush-Hush During Rollout

For a little while it was possible to spend Bitcoin twice. Think of it like a coin on a string, you put it into the vending machine to get a delicious snack, but if you pull the string quickly enough you could spend it again on some soda too. Except this coin is worth something like eighty-grand.

On September 20, the full details of the latest fix for the Bitcoin Core were published. This information came two days after the fix was actually released. Two vulnerabilities were involved; a Denial of Service vulnerability and a critical inflation vulnerability, both covered in CVE-2018-17144. These were originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited.

Let’s take a look at how this worked, and how the network was patched (while being kept quiet) to close up this vulnerability.

Continue reading “Bitcoin’s Double Spending Flaw Was Hush-Hush During Rollout”

Explaining Efail and Why It Isn’t the End of Email Privacy

Last week the PGPocalipse was all over the news… Except that, well, it wasn’t an apocalypse.

A team of researchers published a paper(PDF) where they describe how to decrypt a PGP encrypted email via a targeted attack. The research itself is pretty well documented and, from a security researcher perspective, it’s a good paper to read, especially the cryptography parts.

But we here at Hackaday were skeptical about media claims that Efail had broken PGP. Some media reports went as far as recommending everyone turn off PGP encryption on all email clients., but they weren’t able to back this recommendation up with firm reasoning. In fact, Efail isn’t an immediate threat for the vast majority of people simply because an attacker must already have access to an encrypted email to use the exploit. Advising everyone to disable encryption all together just makes no sense.

Aside from the massive false alarm, Efail is a very interesting exploit to wrap your head around. Join me after the break as I walk through how it works, and what you can do to avoid it.

Continue reading “Explaining Efail and Why It Isn’t the End of Email Privacy”

Seek and Exploit Security Vulnerabilities in an Infusion Pump

Infusion pumps and other medical devices are not your typical everyday, off-the-shelf embedded system. Best case scenario, you will rarely, if ever, come across one in your life. So for wide-spread exploitation, chances are that they simply seem too exotic for anyone to bother exploring their weaknesses. Yet their impact on a person’s well-being makes potential security holes tremendously more severe in case someone decides to bother one day after all.

[Scott Gayou] is one of those someones, and he didn’t shy away from spending hundreds of hours of his free time inspecting the Smiths Medical Medfusion 4000 infusion pump for any possible security vulnerabilities. Looking at different angles for his threat model, he started with the physical handling of the device’s user interface. This allowed him to enable the external communication protocols settings, which in turn opened to the device’s FTP and Telnet ports. Not to give too much away, but he manages to gain access to both the file system content and — as a result of that — to the system’s login credentials. This alone can be clearly considered a success, but for [Scott], it merely opened a door that eventually resulted in desoldering the memory chips to reverse engineer the bootloader and firmware, and ultimately executing his own code on the device.

Understanding the implications of his discoveries, [Scott] waited long enough to publish his research so the manufacturer could address and handle these security issues. So kudos to him for fighting the good fight. And just in case the thought of someone gaining control over a machine that is crucial to your vitality doesn’t scare you enough yet, go ahead and imagine that device was actually implanted in your body.

Let’s Talk Intel, Meltdown, and Spectre

This week we’ve seen a tsunami of news stories about a vulnerability in Intel processors. We’re certain that by now you’ve heard of (and are maybe tired of hearing about) Meltdown and Spectre. However, as a Hackaday reader, you are likely the person who others turn to when they need to get the gist of news like this. Since this has bubbled up in watered-down versions to the highest levels of mass media, let’s take a look at what Meltdown and Spectre are, and also see what’s happening in the other two rings of this three-ring circus.

Meltdown and Spectre in a Nutshell

These two attacks are similar. Meltdown is specific to Intel processors and kernel fixes (basically workarounds implemented by operating systems) will result in a 5%-30% speed penalty depending on how the CPU is being used. Spectre is not limited to Intel, but also affects AMD and ARM processors and kernel fixes are not expected to come with a speed penalty.

Friend of Hackaday and security researcher extraordinaire Joe Fitz has written a superb layman’s explanation of these types of attacks. His use of the term “layman” may be a little more high level than normal — this is something you need to read.

The attack exploits something called branch prediction. To boost speed, these processors keep a cache of past branch behavior in memory and use that to predict future branching operations. Branch predictors load data into memory before checking to see if you have permissions to access that data. Obviously you don’t, so that memory will not be made available for you to read. The exploit uses a clever guessing game to look at other files also returned by the predictor to which you do have access. If you’re clever enough, you can reconstruct the restricted data by iterating on this trick many many times.

For the most comprehensive info, you can read the PDF whitepapers on Meltdown and Spectre.

Update: Check Alan Hightower’s explanation of the Meltdown exploit left as a comment below. Quite good for helping deliver better understanding of how this works.

Frustration from Kernel Developers

These vulnerabilities are in silicon — they can’t be easily fixed with a microcode update which is how CPU manufacturers usually workaround silicon errata (although this appears to be an architectural flaw and not errata per se). An Intel “fix” would amount to a product recall. They’ve already said they won’t be doing a recall, but how would that work anyway? What’s the lead time on spinning up the fabs to replace all the Intel chips in use — yikes!

So the fixes fall on the operating systems at the kernel level. Intel should be (and probably is behind the scenes) bowing down to the kernel developers who are saving their bacon. It is understandably frustrating to have to spend time and resources patching these vulnerabilities, which displaces planned feature updates and improvements. Linus Torvalds has been throwing shade at Intel — anecdotal evidence of this frustration:

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.”

That’s the tamest part of his message posted on the Linux Kernel Mailing List.

Stock Sales Kerfuffle is Just a Distraction

The first thing I did on hearing about these vulnerabilities on Tuesday was to check Intel’s stock price and I was surprised it hadn’t fallen much. In fact, peak to peak it’s only seen about an 8% drop this week and has recovered some from that low.

Of course, it came out that back in November Intel’s CEO Bryan Krzanich sold off his Intel stock to the tune of $24 Million, bringing him down to his contractual minimum of shares. He likely knew about Meltdown when arranging that sale. Resist the urge to flame on this decision. Whether it’s legal or not, hating on this guy is just a distraction.

What’s more interesting to me is this: Intel is too big to fail. What are we all going to do, stop using Intel and start using something else? You can’t just pull the chip and put a new one in, in the case of desktop computers you need a new motherboard plus all the supporting stuff like memory. For servers, laptops, and mobile devices you need to replace the entire piece of equipment. Intel has a huge market share, and silicon has a long production cycle. Branch prediction has been commonplace in consumer CPUs going back to 1995 when the Pentium Pro brought it to the x86 architecture. This is a piece of the foundation that will be yanked out and replaced with new designs that provide the same speed benefits without the same risks — but that will take time to make it into the real world.

CPUs are infrastructure and this is the loudest bell to date tolling to signal how important their design is to society. It’s time to take a hard look at what open silicon design would bring to the table. You can’t say this would have been prevented with Open design. You can say that the path to new processors without these issues would be a shorter one if there were more than two companies producing all of the world’s processors — both of which have been affected by these vulnerabilities.

Another Defeat of the Intel Management Engine

If you have a computer with an Intel processor that’s newer than about 2007, odds are high that it also contains a mystery software package known as the Intel Management Engine (ME). The ME has complete access to the computer below the operating system and can access a network, the computer’s memory, and many other parts of the computer even when the computer is powered down. If you’re thinking that this seems like an incredible security vulnerability then you’re not alone, and a team at Black Hat Europe 2017 has demonstrated yet another flaw in this black box (PDF), allowing arbitrary code execution and bypassing many of the known ME protections.

[Mark Ermolov] and [Maxim Goryachy] are the two-man team that discovered this exploit, only the second of its kind in the 12 years that the ME has been deployed. Luckily, this exploit can’t be taken advantage of (yet) unless an attacker has physical access to the device. Intel’s firmware upgrades also do not solve the problem because the patches still allow for use of older versions of the ME. [Mark] and [Maxim] speculate in their presentation that this might be fixed on the next version of the ME, but also note that these security vulnerabilities would disappear if Intel would stop shipping processors with the ME.

We won’t hold our breath on Intel doing the right thing by eliminating the ME, though. It’s only a matter of time before someone discovers a zero-day (if they haven’t already, there’s no way to know) which could cripple pretty much every computer built within the last ten years. If you’re OK with using legacy hardware, though, it is possible to eliminate the management engine and have a computer that doesn’t have crippling security vulnerabilities built into it. This post was even written from one. Good luck doing anything more resource-intensive with it, though.

Radio Controlled Pacemakers Are Easily Hacked

Doctors use RF signals to adjust pacemakers so that instead of slicing a patient open, they can change the pacemakers parameters which in turn avoids unnecessary surgery. A study on security weaknesses of pacemakers (highlights) or full Report (PDF) has found that pacemakers from the main manufacturers contain security vulnerabilities that make it possible for the devices to be adjusted by anyone with a programmer and proximity. Of course, it shouldn’t be possible for anyone other than medical professionals to acquire a pacemaker programmer. The authors bought their examples on eBay.

They discovered over 8,000 known vulnerabilities in third-party libraries across four different pacemaker programmers from four manufacturers.  This highlights an industry-wide problem when it comes to security. None of the pacemaker programmers required passwords, and none of the pacemakers authenticated with the programmers. Some home pacemaker monitoring systems even included USB connections in which opens up the possibilities of introducing malware through an infected pendrive.

The programmers’ firmware update procedures were also flawed, with hard-coded credentials being very common. This allows an attacker to setup their own authentication server and upload their own firmware to the home monitoring kit. Due to the nature of the hack, the researchers are not disclosing to the public which manufacturers or devices are at fault and have redacted some information until these medical device companies can get their house in order and fix these problems.

This article only scratches the surface for an in-depth look read the full report. Let’s just hope that these medical companies take action as soon as possible and resolve these issue’s as soon as possible. This is not the first time pacemakers have been shown to be flawed.

Yet Another IoT Botnet

[TrendMicro] are reporting that yet another IoT botnet is emerging. This new botnet had been dubbed Persirai and targets IP cameras. Most of the victims don’t even realize their camera has access to the Internet 24/7 in the first place.

Trend Micro, have found 1,000 IP cameras of different models that have been exploited by Persirai so far. There are at least another 120,000 IP cameras that the botnet could attack using the same method. The problem starts with the IP cameras exposing themselves by default on TCP Port 81 as a web server — never a great idea.

Most IP cameras use Universal Plug and Play, which allows them to open ports from inside the router and start a web server without much in the way of security checks. This paints a giant target in cyber space complete with signs asking to be exploited. After logging into a vulnerable device the attacker can perform a command injection attack which in turn points gets the camera to download further malware.

The exploit runs in memory only, so once it has been rebooted it should all be fine again until your next drive by malware download. Check your devices, because even big named companies make mistakes. IoT is turning into a battlefield. We just hope that with all these attacks, botnets, and hacks the promise of the IoT idea isn’t destroyed because of lazy coders.

Part of feature image from Wikipedia, Creative Commons license.