Our own [Brian Benchoff] asked this same question just six months ago in a similar headline. At that time, the answer was no. Or kind of no. Some exploits existed but with some preconditions that limited the impact of the bugs found in Intel Management Engine (IME). But 2017 is an unforgiving year for the blue teams, as lot of serious bugs have been found throughout the year in virtually every fields of computing. Researchers from Positive Technologies report that they found a flaw that allows them to execute unsigned code on computers running the IME. The cherry on top of the cake is that they are able to do it via a USB port acting as a JTAG port. Does this mean the zombie apocalypse is coming?
Before the Skylake CPU line, released in 2015, the JTAG interface was only accessible by connecting a special device to the ITP-XDP port found on the motherboard, inside a computer’s chassis. Starting with the Skylake CPU, Intel replaced the ITP-XDP interface and allowed developers and engineers to access the debugging utility via common USB 3.0 ports, accessible from the device’s exterior, through a new a new technology called Direct Connect Interface (DCI). Basically the DCI provides access to CPU/PCH JTAG via USB 3.0. So the researchers manage to debug the IME processor itself via USB DCI, which is pretty awesome, but USB DCI is turned off by default, like one of the researchers states, which is pretty good news for the ordinary user. So don’t worry too much just yet.
Continue reading “Is Intel’s Management Engine Broken yet?”
Information about this one is still tricking in, so take it with a grain of salt, but security company [Bkav] is claiming they have defeated the Face ID system featured in Apple’s iPhone X. By combining 2D images and 3D scans of the owner’s face, [Bkav] has come up with a rather nightmarish creation that apparently fools the iPhone into believing it’s the actual owner. Few details have been released so far, but a YouTube video recently uploaded by the company does look fairly convincing.
For those who may not be keeping up with this sort of thing, Face ID is advertised as an improvement over previous face-matching identification systems (like the one baked into Android) by using two cameras and a projected IR pattern to perform a fast 3D scan of the face looking at the screen. Incidentally, this is very similar to how Microsoft’s Kinect works. While a 2D system can be fooled by a high quality photograph, a 3D based system would reject it as the face would have no depth.
[Bkav] is certainly not the first group to try and con Apple’s latest fondle-slab into letting them in. Wired went through a Herculean amount of effort in their attempt earlier in the month, only to get no farther than if they had just put a printed out picture of the victim in front of the camera. Details on how [Bkav] managed to succeed are fairly light, essentially boiling down to their claim that they are simply more knowledgeable about the finer points of face recognition than their competitors. Until more details are released, skepticism is probably warranted.
Still, even if their method is shown to be real and effective in the wild, it does have the rather large downside of requiring a 3D scan of the victim’s face. We’re not sure how an attacker is going to get a clean scan of someone without their consent or knowledge, but with the amount of information being collected and stored about the average consumer anymore, it’s perhaps not outside the realm of possibility in the coming years.
Since the dystopian future of face-stealing technology seems to be upon us, you might as well bone up on the subject so you don’t get left behind.
Thanks to [Bubsey Ubsey] for the tip.
Continue reading “Face ID Defeated With 3D Printed Mask (Maybe)”
Are you reading this on a machine running a GNU/Linux distribution? A Windows machine? Or perhaps an Apple OS? It doesn’t really matter, because your computer is probably running MINIX anyway.
There once was a time when microprocessors were relatively straightforward devices, capable of being understood more or less in their entirety by a single engineer without especially God-like skills. They had buses upon which hung peripherals, and for code to run on them, one of those peripherals had better supply it.
A modern high-end processor is a complex multicore marvel of technological achievement, so labyrinthine in fact that unlike those simple devices of old it may need to contain a dedicated extra core whose only job is to manage the rest of the onboard functions. Intel processors have had one for years, it’s called the Management Engine, or ME, and it has its own firmware baked into the chip. It is this firmware, that according to a discovery by [Ronald Minnich], contains a copy of the MINIX operating system.
If you are not the oldest of readers, it’s possible that you may not have heard of MINIX. Or if you have, it might be in connection with the gestation of [Linus Torvalds]’ first Linux kernel. It’s a UNIX-like operating system created in the 1980s as a teaching aid, and for a time it held a significant attraction as the closest you could get to real UNIX on some of the affordable 16-bit desktop and home computers. Amiga owners paid for copies of it on floppy disks, it was even something of an object of desire. It’s still in active development, but it’s fair to say its attraction lies in its simplicity rather than its sophistication.
It’s thus a worry to find it on the Intel ME, because in that position it lies at the most privileged level of access to your computer’s hardware. Your desktop operating system, by contrast, sees the hardware through several layers of abstraction in the name of security, so a simple OS with full networking and full hardware access represents a significant opportunity to anyone with an eye to compromising it. Placing tinfoil hats firmly on your heads as the unmistakable thwop of black helicopters eases into the soundscape you might claim that this is exactly what they want anyway. We would hope that if they wanted to compromise our PCs with a backdoor they’d do it in such a way as to make it a little less easy for The Other Lot. We suspect it’s far more likely that this is a case of the firmware being considered to be an out-of-sight piece of the hardware that nobody would concern themselves with, rather than a potential attack vector that everyone should. It would be nice to think that we’ll see some abrupt updates, but we suspect that won’t happen.
Intel I7 processor underside: smial [FAL].
A team of college hackers was disappointed with the selection of secure purses available. Nearly every purse on the market is attractive, secure, or neither so they are designing their own security purse with some style. Instead of just brass or leather clasps keeping unwanted hands out, they are upgrading to automation and steel.
Everything starts with a fingerprint reader connected to an Arduino. Once an acceptable finger is recognized, a motor opens a coffin lock, also known as a butt-joint fastener, which can be completely hidden inside the purse and provides a lot of holding force. That is enough to keep quick fingers from reaching into an unattended purse.
In the case of a mugging, a sound grenade will trigger which should convince most thieves to quickly abandon it. Then, the internal GPS tells the owner where the purse can be found.
We can’t imagine a real-life purse thief prepared to tackle this kind of hardware. Hackaday loves knowing the ins and out of security from purses to cars and of course IoT.
In the old days, spies eavesdropped on each other using analog radio bugs. These days, everything’s in the cloud. [Sebastian] from [Hacking Beaver] wondered if he could make a WiFi bug that was small and cheap besides. Enter the ESP8266 and some programming wizardry.
[Sebastian] is using a NodeMCU but suggests that it could be pared down to any ESP8266 board — with similar cuts made to the rest of the electronics — but has this working as a proof of concept. A PIC 18 MCU samples the audio data from a microphone at 10 kHz with an 8-bit resolution, dumping it into a 512-byte buffer. Once that fills, a GPIO pin is pulled down and the ESP8266 sends the data to a waiting TCP server over the WiFi which either records or plays the audio in real-time.
[Sebastian] has calculated that he needs at least 51.2 ms to transfer the data which this setup easily handles, but there are occasional two to three second glitches that come out of the blue. To address this and other hangups, [Sebastian] has the ESP8266 control the PIC’s reset pin so that the two are always in sync.
Continue reading “Eavesdropping With An ESP8266”
The title reads like the name of a lecture in cryptography 101 or the first rule of Crypto Club. ‘DUHK‘ is in fact neither of those but the name of a recently disclosed vulnerability in a pseudorandom number generating algorithm (PNRG) that was until recently part of the federal standard X9.31.
Random numbers are essential to viable cryptography. They are also hard to obtain leading to solutions like using the physical properties of semiconductors or decaying matter, that are governed by quantum effects. The next best solution is to log events that are hard to predict like the timing of strokes on a keyboard. The weakest source of randomness is math, which makes sense, because one of maths most popular features is its predictability. Mathematical solutions have the one redeeming quality of being able to produce a lot of numbers that look random to a human in a short time.
PNRGs require a starting point from which they begin to produce their output. Once this seed is known the produced sequence becomes predictable.
The X9.31 PNRG is an algorithm that is used in various cryptographic algorithms and has been certified in the Federal Information Processing Standards for decades until it was dropped from the list of approved standards in 2016. The researchers behind DUHK found out that the standard allowed the seed to be stored in the source code of its implementation. The next step was to look for software that did this and they found X9.31 in an older version of FortiOS running on VPN gateways.
Should I be Worried?
Probably, maybe not. The analysis (PDF) published by the team behind DUHK notes that the vulnerability is limited to legacy implementations and doesn’t allow to takeover the device running them, only to eavesdrop on ‘secure’ connections. The scope of this is much more limited than exploits like remote code execution via bluetooth. It is on the other hand providing a strong case for handling standards and technical certifications with extreme scrutiny. The teams conduct also gives insight into the best practises for white-hat hacking which are frequently discussed around here. And they have a great theme song.
[tomwimmenhove] has found a vulnerability in the cryptographic algorithm that is used by certain Subaru key fobs and he has open-sourced the software that drives this exploit. All you need to open your Subaru is a RasPi and a DVB-T dongle, so you could complain that sharing this software equates to giving out master keys to potential car thieves. On the other hand, this only works for a limited number of older models from a single manufacturer — it’s lacking in compatibility and affordability when compared to the proverbial brick.
This hack is much more useful as a case study than a brick is, however, and [tomwimmenhove]’s work points out some bad design on the manufacturer’s side and as such can help you to avoid these kind of mistakes. The problem of predictable keys got great treatment in the comments of our post about an encryption scheme for devices low in power and memory, for instance.
Those of you interested in digital signal processing may also want to take a look at his code, where he implements filtering, demodulation and decoding of the key fob’s signal. The transmission side is handled by rpitx and attacks against unencrypted communications with this kind of setup have been shown here before. There’s a lot going on here that’s much more interesting than stealing cars.
[Via Bleeping Computer]
Continue reading “Exploiting Weak Crypto on Car Key Fobs”