An ultrasonic beacon is an inaudible sound with encoded data that can be used by a listening device to receive information on just about anything. Beacons can be used, for example, inside a shop to highlight a particular promotion or on a museum for guided tours where the ultrasonic beacons can encode the location. Or they can be used to track people consumers. Imagine if Google find outs… oh, wait… they already did, some years ago. As with almost any technology, it can be used to ‘do no harm’ or to serve other purposes.
Researchers from the Technische Universitat Braunschweig in Germany presented a paper about Ultrasonic Side Channels on Mobile Devices and how can they be abused in a variety of scenarios , ranging from simple consumer tracking to deanonymization. These types of ultrasonic beacons work in the 18 kHz – 20 kHz range, which the human being doesn’t have the ability to hear, unless you are under twenty years old, due to presbycusis. Yes, presbycusis. This frequency range can played via almost any speaker and can be picked up easily by most mobile device microphones, so no special hardware is needed. Speakers and mics are almost ubiquitous nowadays, so there is a real appeal to the technology.
Betteridge’s Law of Headlines states, “Any headline that ends in a question mark can be answered by the word no.” This law remains unassailable. However, recent claims have called into question a black box hidden deep inside every Intel chipset produced in the last decade.
Yesterday, on the Semiaccurate blog, [Charlie Demerjian] announced a remote exploit for the Intel Management Engine (ME). This exploit covers every Intel platform with Active Management Technology (AMT) shipped since 2008. This is a small percentage of all systems running Intel chipsets, and even then the remote exploit will only work if AMT is enabled. [Demerjian] also announced the existence of a local exploit.
Intel’s ME and AMT Explained
Beginning in 2005, Intel began including Active Management Technology in Ethernet controllers. This system is effectively a firewall and a tool used for provisioning laptops and desktops in a corporate environment. In 2008, a new coprocessor — the Management Engine — was added. This management engine is a processor connected to every peripheral in a system. The ME has complete access to all of a computer’s memory, network connections, and every peripheral connected to a computer. The ME runs when the computer is hibernating and can intercept TCP/IP traffic. Management Engine can be used to boot a computer over a network, install a new OS, and can disable a PC if it fails to check into a server at some predetermined interval. From a security standpoint, if you own the Management Engine, you own the computer and all data contained within.
The Management Engine and Active Management Technolgy has become a focus of security researchers. The researcher who finds an exploit allowing an attacker access to the ME will become the greatest researcher of the decade. When this exploit is discovered, a billion dollars in Intel stock will evaporate. Fortunately, or unfortunately, depending on how you look at it, the Managment Engine is a closely guarded secret, it’s based on a strange architecture, and the on-chip ROM for the ME is a black box. Nothing short of corporate espionage or looking at the pattern of bits in the silicon will tell you anything. Intel’s Management Engine and Active Management Technolgy is secure through obscurity, yes, but so far it’s been secure for a decade while being a target for the best researchers on the planet.
In yesterday’s blog post, [Demerjian] reported the existence of two exploits. The first is a remotely exploitable security hole in the ME firmware. This exploit affects every Intel chipset made in the last ten years with Active Management Technology on board and enabled. It is important to note this remote exploit only affects a small percentage of total systems.
The second exploit reported by the Semiaccurate blog is a local exploit that does not require AMT to be active but does require Intel’s Local Manageability Service (LMS) to be running. This is simply another way that physical access equals root access. From the few details [Demerjian] shared, the local exploit affects a decade’s worth of Intel chipsets, but not remotely. This is simply another evil maid scenario.
Should You Worry?
The biggest network security threat today is a remote code execution exploit for Intel’s Management Engine. Every computer with an Intel chipset produced in the last decade would be vulnerable to this exploit, and RCE would give an attacker full control over every aspect of a system. If you want a metaphor, we are dinosaurs and an Intel ME exploit is an asteroid hurtling towards the Yucatán peninsula.
However, [Demerjian] gives no details of the exploit (rightly so), and Intel has released an advisory stating, “This vulnerability does not exist on Intel-based consumer PCs.” According to Intel, this exploit will only affect Intel systems that ship with AMT, and have AMT enabled. The local exploit only works if a system is running Intel’s LMS.
This exploit — no matter what it may be, as there is no proof of concept yet — only works if you’re using Intel’s Management Engine and Active Management Technology as intended. That is, if an IT guru can reinstall Windows on your laptop remotely, this exploit applies to you. If you’ve never heard of this capability, you’re probably fine.
Still, with an exploit of such magnitude, it’s wise to check for patches for your system. If your system does not have Active Management Technology, you’re fine. If your system does have AMT, but you’ve never turned it on, you’re fine. If you’re not running LMT, you’re fine. Intel’s ME can be neutralized if you’re using a sufficiently old chipset. This isn’t the end of the world, but it does give security experts panning Intel’s technology for the last few years the opportunity to say, ‘told ‘ya so’.
[Yingtao Zeng], [Qing Yang], and [Jun Li], a.k.a. the [UnicornTeam], developed the cheapest way so far to hack a passive keyless entry system, as found on some cars: around $22 in parts, give or take a buck. But that’s not all, they manage to increase the previous known effective range of this type of attack from 100 m to around 320 m. They gave a talk at HITB Amsterdam, a couple of weeks ago, and shown their results.
The attack in its essence is not new, and it’s basically just creating a range extender for the keyfob. One radio stays near the car, the other near the car key, and the two radios relay the signals coming from the car to the keyfob and vice-versa. This version of the hack stands out in that the [UnicornTeam] reverse engineered and decoded the keyless entry system signals, produced by NXP, so they can send the decoded signals via any channel of their choice. The only constraint, from what we could tell, it’s the transmission timeout. It all has to happen within 27 ms. You could almost pull this off over Internet instead of radio.
A suggested fix from the researchers is to decrease this 27 ms timeout. If it is short enough, at least the distance for these types of attacks is reduced. Even if that could eventually mitigate or reduce the impact of an attack on new cars, old cars are still at risk. We suggest that the passive keyless system is broken from the get-go: allowing the keyfob to open and start your car without any user interaction is asking for it. Are car drivers really so lazy that they can’t press a button to unlock their car? Anyway, if you’re stuck with one of these systems, it looks like the only sure fallback is the tinfoil hat. For the keyfob, of course.
Well, think again. At least if you are using Chrome or Firefox. Don’t believe us? Well, check out Apple new website then, at https://www.apple.com . Notice anything? If you are not using an affected browser you are just seeing a strange URL after opening the webpage, otherwise it’s pretty legit. This is a page to demonstrate a type of Unicode vulnerability in how the browser interprets and show the URL to the user. Notice the valid HTTPS. Of course the domain is not from Apple, it is actually the domain: “https://www.xn--80ak6aa92e.com/“. If you open the page, you can see the actual URL by right-clicking and select view-source.
So what’s going on? This type of phishing attack, known as IDN homograph attacks, relies on the fact that the browser, in this case Chrome or Firefox, interprets the “xn--” prefix in a URL as an ASCII compatible encoding prefix. It is called Punycode and it’s a way to represent Unicode using only the ASCII characters used in Internet host names. Imagine a sort of Base64 for domains. This allows for domains with international characters to be registered, for example, the domain “xn--s7y.co” is equivalent to “短.co”, as [Xudong Zheng] explains in his blog.
Different alphabets have different glyphs that work in this kinds of attacks. Take the Cyrillic alphabet, it contains 11 lowercase glyphs that are identical or nearly identical to Latin counterparts. These class of attacks, where an attacker replaces one letter for its counterpart is widely known and are usually mitigated by the browser:
Researchers from the Argus Research Team found a way to hack into the Bosch Drivelog ODB-II dongle and inject any kind of malicious packets into the CAN bus. This allowed them to, among other things, stop the engine of a moving vehicle by connecting to the dongle via Bluetooth.
Drivelog is Bosch’s smart device for collecting and managing your vehicle’s operating data. It allows a user to connect via Bluetooth to track fuel consumption and to be alerted when service is necessary. It was compromised in a two stage attack. The first vulnerability, an information leak in the authentication process, between the dongle and the smart phone application allowed them to quickly brute-force the secret PIN offline and connect to the dongle via Bluetooth. After being connected, security holes in the message filter of the dongle allowed them to inject malicious messages into the CAN bus.
The Bluetooth pairing mechanism, called “Just Works”, has been fixed by Bosh by activating a two-step verification for additional users to be registered to a device. The second issue, the ability for a maliciously modified mobile application to possibly send unwanted CAN messages, will be mitigated with an update to the dongle firmware to further limit the allowed commands that the dongle is able to place on the CAN bus.
Bosch downplays the issue a bit in their statement:
It is important to note that scalability of a potential malicious attack is limited by the fact that such an attack requires physical proximity to the dongle. This means that the attacking device needs to be within Bluetooth range of the vehicle.
The problem is that physical proximity does not equal Bluetooth range. Standard Bluetooth range is about 10m, which is very arguable physical proximity, but it is pretty easy to buy or even modify a Bluetooth dongle with 10x and 100x more range. When adding a wireless connection to the CAN bus of an automobile, the manufacturer has an obligation to ensure the data system is not compromised. This near-proximity example is still technically a remote hack, and it’s an example of the worst kind of vulnerability.
There is a new class of virii in town, specifically targeting Internet of Things (IoT) devices. BrickerBot and its variants do exactly as their name says, turning your smart devices into bricks. Someone out there has gotten tired of all the IoT security flaws and has undertaken extreme (and illegal) measures to fix the problem. Some of the early reports have come in from a security company called Radware, who isolated two variants of the virii in their honeypots.
In a nutshell, BrickerBot gains access to insecure Linux-based systems by using brute force. It tries to telnet in using common default root username/password pairs. Once inside it uses shell commands (often provided by BusyBox) to write random data to any mounted drives. It’s as easy as
dd if=/dev/urandom of=/dev/sda1
With the secondary storage wiped, the device is effectively useless. There is already a name for this: a Permanent Denial-of-Service (PDoS) attack.
Now any card carrying Hackaday reader will know that a system taken down like this can be recovered by re-flashing through USB, JTAG, SD, other methods. However, we’re not BrickerBot’s intended audience. We’ve all changed our devices default passwords, right? RIGHT?
A couple of weeks back a report came out where [Tavis Ormandy], a widely known security researcher for Google Project-Zero, showed how it was possible to abuse Lastpass RPC commands and steal user passwords. Irony is… Lastpass is a software designed to keep all your passwords safe and it’s designed in a way that even they can’t access your passwords, the passwords are stored locally using strong cryptography, only you can access them via a master-key. Storing all your passwords in only place has its downfalls. By the way, there is no proof or suggestion that this bug was abused by anyone, so if you use Lastpass don’t worry just yet.
But it got me thinking, how worried and how paranoid should a regular Internet user should be about his password? How many of us have their account details exposed somewhere online? If you’ve been around long enough, odds are you have at least a couple of accounts on some major Internet-based companies. Don’t go rushing into the Dark Web and try to find if your account details are being sold. The easiest way to get your paranoia started is to visit Have I Been Pwned. For those who never heard about it, it’s a website created by [Troy Hunt], a well-known security professional. It keeps track of all known public security breaches he can get his hands on and provides an answer to a simple question: “Was my account in any major data leak?” Let’s take a look.