Back in January, welearned about a class of vulnerabilities against microprocessors that leverages various performance and efficiency shortcuts for attack. I wrote that the first two attacks would be just the start:
It shouldn't be surprising that microprocessor designers have been building insecure hardware for 20 years. What's surprising is that it took 20 years to discover it. In their rush to make computers faster, they weren't thinking about security. They didn't have the expertise to find these vulnerabilities. And those who did were too busy finding normal software vulnerabilities to examine microprocessors. Security researchers are starting to look more closely at these systems, so expect to hear about more vulnerabilities along these lines.
Spectre and Meltdown are pretty catastrophic vulnerabilities, but they only affect the confidentiality of data. Now that they -- and the research into the Intel ME vulnerability -- have shown researchers where to look, more is coming -- and what they'll find will be worse than either Spectre or Meltdown. There will be vulnerabilities that will allow attackers to manipulate or delete data across processes, potentially fatal in the computers controlling our cars or implanted medical devices. These will be similarly impossible to fix, and the only strategy will be to throw our devices away and buy new ones.
Researchers say they've discovered the seven new CPU attacks while performing "a sound and extensible systematization of transient execution attacks" -- a catch-all term the research team used to describe attacks on the various internal mechanisms that a CPU uses to process data, such as the speculative execution process, the CPU's internal caches, and other internal execution stages.
The research team says they've successfully demonstrated all seven attacks with proof-of-concept code. Experiments to confirm six other Meltdown-attacks did not succeed, according to a graph published by researchers.
Microprocessor designers have spent the year rethinking the security of their architectures. My guess is that they have a lot more rethinking to do.
I've been writing about "responsible disclosure" for over a decade; here's an essay from 2007. Basically, it's a tacit agreement between researchers and software vendors. Researchers agree to withhold their work until software companies fix the vulnerabilities, and software vendors agree not to harass researchers and fix the vulnerabilities quickly.
When that agreement breaks down, things go bad quickly. This story is about a researcher who published an Oracle zero-day because Oracle has a history of harassing researchers and ignoring vulnerabilities.
Software vendors might not like responsible disclosure, but it's the best solution we have. Making it illegal to publish vulnerabilities without the vendor's consent means that they won't get fixed quickly -- and everyone will be less secure. It also means less security research.
This will become even more critical with software that affects the world in a direct physical manner, like cars and airplanes. Responsible disclosure makes us safer, but it only works if software vendors take the vulnerabilities seriously and fix them quickly. Without any regulations that enforce that, the threat of disclosure is the only incentive we can impose on software vendors.
The Pentagon has suddenly started uploading malware samples from APTs and other nation-state sources to the website VirusTotal, which is essentially a malware zoo that's used by security pros and antivirus/malware detection engines to gain a better understanding of the threat landscape.
This feels like an example of the US's new strategy of actively harassing foreign government actors. By making their malware public, the US is forcing them to continually find and use new vulnerabilities.
EDITED TO ADD (11/13): This is another good article. And hereis some background on the malware.
This is really just to point out that computer security is really hard:
Almost as soon as Apple released iOS 12.1 on Tuesday, a Spanish security researcher discovered a bug that exploits group Facetime calls to give anyone access to an iPhone users' contact information with no need for a passcode.
A bad actor would need physical access to the phone that they are targeting and has a few options for viewing the victim's contact information. They would need to either call the phone from another iPhone or have the phone call itself. Once the call connects they would need to:
Select the Facetime icon
Select "Add Person"
Select the plus icon
Scroll through the contacts and use 3D touch on a name to view all contact information that's stored.
Making the phone call itself without entering a passcode can be accomplished by either telling Siri the phone number or, if they don't know the number, they can say "call my phone." We tested this with both the owners' voice and a strangers voice, in both cases, Siri initiated the call.
Consumer Reports is starting to evaluate the security of IoT devices. As part of that, it's reviewing wireless home-security cameras.
It found significant security vulnerabilities in D-Link cameras:
In contrast, D-Link doesn't store video from the DCS-2630L in the cloud. Instead, the camera has its own, onboard web server, which can deliver video to the user in different ways.
Users can view the video using an app, mydlink Lite. The video is encrypted, and it travels from the camera through D-Link's corporate servers, and ultimately to the user's phone. Users can also access the same encrypted video feed through a company web page, mydlink.com. Those are both secure methods of accessing the video.
But the D-Link camera also lets you bypass the D-Link corporate servers and access the video directly through a web browser on a laptop or other device. If you do this, the web server on the camera doesn't encrypt the video.
If you set up this kind of remote access, the camera and unencrypted video is open to the web. They could be discovered by anyone who finds or guesses the camera's IP address -- and if you haven't set a strong password, a hacker might find it easy to gain access.
The real news is that Consumer Reports is able to put pressure on device manufacturers:
In response to a Consumer Reports query, D-Link said that security would be tightened through updates this fall. Consumer Reports will evaluate those updates once they are available.
This is the sort of sustained pressure we need on IoT device manufacturers.
Abstract: We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocker, the encryption software built into Microsoft Windows will rely exclusively on hardware full-disk encryption if the SSD advertises supported for it. Thus, for these drives, data protected by BitLocker is also compromised. This challenges the view that hardware encryption is preferable over software encryption. We conclude that one should not rely solely on hardware encryption offered by SSDs.
The F25 software was found to contain a capture replay vulnerability -- basically an attacker would be able to eavesdrop on radio transmissions between the crane and the controller, and then send their own spoofed commands over the air to seize control of the crane.
"These devices use fixed codes that are reproducible by sniffing and re-transmission," US-CERT explained.
"This can lead to unauthorized replay of a command, spoofing of an arbitrary message, or keeping the controlled load in a permanent 'stop' state."
Automation and connectivity are fundamental enablers of DOD's modern military capabilities. However, they make weapon systems more vulnerable to cyber attacks. Although GAO and others have warned of cyber risks for decades, until recently, DOD did not prioritize weapon systems cybersecurity. Finally, DOD is still determining how best to address weapon systems cybersecurity.
In operational testing, DOD routinely found mission-critical cyber vulnerabilities in systems that were under development, yet program officials GAO met with believed their systems were secure and discounted some test results as unrealistic. Using relatively simple tools and techniques, testers were able to take control of systems and largely operate undetected, due in part to basic issues such as poor password management and unencrypted communications. In addition, vulnerabilities that DOD is aware of likely represent a fraction of total vulnerabilities due to testing limitations. For example, not all programs have been tested and tests do not reflect the full range of threats.
It is definitely easier, and cheaper, to ignore the problem or pretend it isn't a big deal. But that's probably a mistake in the long run.
Of course the ESS ExpressVote voting computer will have lots of security vulnerabilities. It's a computer, and computers have lots of vulnerabilities. This particular vulnerability is particularly interesting because it's the result of a security mistake in the design process. Someone didn't think the security through, and the result is a voter-verifiable paper audit trail that doesn't provide the security it promises.
Now there's an even worse option than "DRE with paper trail"; I call it "press this button if it's OK for the machine to cheat" option. The country's biggest vendor of voting machines, ES&S, has a line of voting machines called ExpressVote. Some of these are optical scanners (which are fine), and others are "combination" machines, basically a ballot-marking device and an optical scanner all rolled into one.
This video shows a demonstration of ExpressVote all-in-one touchscreens purchased by Johnson County, Kansas. The voter brings a blank ballot to the machine, inserts it into a slot, chooses candidates. Then the machine prints those choices onto the blank ballot and spits it out for the voter to inspect. If the voter is satisfied, she inserts it back into the slot, where it is counted (and dropped into a sealed ballot box for possible recount or audit).
So far this seems OK, except that the process is a bit cumbersome and not completely intuitive (watch the video for yourself). It still suffers from the problems I describe above: voter may not carefully review all the choices, especially in down-ballot races; counties need to buy a lot more voting machines, because voters occupy the machine for a long time (in contrast to op-scan ballots, where they occupy a cheap cardboard privacy screen).
But here's the amazingly bad feature: "The version that we have has an option for both ways," [Johnson County Election Commissioner Ronnie] Metsker said. "We instruct the voters to print their ballots so that they can review their paper ballots, but they're not required to do so. If they want to press the button 'cast ballot,' it will cast the ballot, but if they do so they are doing so with full knowledge that they will not see their ballot card, it will instead be cast, scanned, tabulated and dropped in the secure ballot container at the backside of the machine." [TYT Investigates, article by Jennifer Cohn, September 6, 2018]
Now it's easy for a hacked machine to cheat undetectably! All the fraudulent vote-counting program has to do is wait until the voter chooses between "cast ballot without inspecting" and "inspect ballot before casting." If the latter, then don't cheat on this ballot. If the former, then change votes how it likes, and print those fraudulent votes on the paper ballot, knowing that the voter has already given up the right to look at it.
A voter-verifiable paper audit trail does not require every voter to verify the paper ballot. But it does require that every voter be able to verify the paper ballot. I am continuously amazed by how bad electronic voting machines are. Yes, they're computers. But they also seem to be designed by people who don't understand computer (or any) security.
The bug underscores the primary risk posed by IoT devices and connected appliances. Because they are commonly built by bolting on network connectivity to existing appliances, many IoT devices have little in the way of built-in network security.
Even when security measures are added to the devices, the third-party hardware used to make the appliances "smart" can itself contain security flaws or bad configurations that leave the device vulnerable.
"IoT devices are frequently overlooked from a security perspective; this may be because many are used for seemingly innocuous purposes such as simple home automation," the McAfee researchers wrote.
"However, these devices run operating systems and require just as much protection as desktop computers."
I'll bet you anything that the plug cannot be patched, and that the vulnerability will remain until people throw them away.