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?”
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.
Security researchers from Armis Labs recently published a whitepaper unveiling eight critical 0-day Bluetooth-related vulnerabilities, affecting Linux, Windows, Android and iOS operating systems. These vulnerabilities alone or combined can lead to privileged code execution on a target device. The only requirement is: Bluetooth turned on. No user interaction is necessary to successfully exploit the flaws, the attacker does not need to pair with a target device nor the target device must be paired with some other device.
The research paper, dubbed BlueBorne (what’s a vulnerability, or a bunch, without a cool name nowadays?), details each vulnerability and how it was exploited. BlueBorne is estimated to affect over five billion devices. Some vendors, like Microsoft, have already issued a patch while others, like Samsung, remain silent. Despite the patches, some devices will never receive a BlueBorne patch since they are outside of their support window. Armis estimates this accounts for around 40% of all Bluetooth enabled devices.
A self-replicating worm that would spread and hop from a device to other nearby devices with Bluetooth turned on was mentioned by the researchers as something that could be done with some more work. That immediately reminds us of the BroadPwn vulnerability, in which the researchers implemented what is most likely the first WiFi only worm. Although it is definitely a fun security exercise to code such worm, it’s really a bad, bad idea… Right?…
So who’s affected?
Continue reading “Bluetooth Vulnerability Affects All Major OS”
Great news everyone, Windows is not the only operating system with remote code execution via SMB. Linux has also its own, seven-year-old version of the bug. /s
This Linux remote execution vulnerability (CVE-2017-7494) affects Samba, the Linux re-implementation of the SMB networking protocol, from versions 3.5.0 onwards (since 2010). The SambaCry moniker was almost unavoidable.
The bug, however, has nothing to do on how Eternalblue works, one of the exploits that the current version of WannaCry ransomware packs with. While Eternalblue is essentially a buffer overflow exploit, CVE-2017-7494 takes advantage of an arbitrary shared library load. To exploit it, a malicious client needs to be able to upload a shared library file to a writeable share, afterwards it’s possible for the attacker to cause the server to load and execute it. A Metasploit exploit module is already public, able to target Linux ARM, X86 and X86_64 architectures.
A patch addressing this defect has been posted to the official website and Samba 4.6.4, 4.5.10 and 4.4.14 have been issued as security releases to correct the defect. Patches against older Samba versions are also available. If you can’t apply the patch at the moment, the workaround is to add the parameter “nt pipe support = no” to the [global] section of your
smb.conf and restart
smbd. Note that this can disable some expected functionality for Windows clients.
Meanwhile, NAS vendors start to realise they have work on their hands. Different brands and models that use Samba for file sharing (a lot, if not all, of them provide this functionality) will have to issue firmware updates if they want to patch this flaw. If the firmware updates for these appliances take the same time they usually do, we will have this bug around for quite some time.
When one buys a computer, it should be expected that the owner can run any code on it that they want. Often this isn’t the case, though, as most modern devices are sold with locked bootloaders or worse. Older technology is a little bit easier to handle, however, but arbitrary code execution on something like an original Nintendo still involves quite a lot of legwork, as [Retro Game Mechanics Explained] shows with the inner workings of Super Mario Brothers 3.
While this hack doesn’t permanently modify the Nintendo itself, it does allow for arbitrary code execution within the game, which is used mostly by speedrunners to get to the end credits scene as fast as possible. To do this, values are written to memory by carefully manipulating on-screen objects. Once the correct values are entered, a glitch in the game involving a pipe is exploited to execute the manipulated memory as an instruction. The instruction planted is most often used to load the Princess’s chamber and complete the game, with the current record hovering around the three-minute mark.
If you feel like you’ve seen something like this before, you are likely thinking of the Super Mario World exploit for the SNES that allows for the same style of arbitrary code execution. The Mario 3 hack, however, is simpler to execute. It’s also worth checking out the video below, because [Retro Game Mechanics Explained] goes into great depth about which values are written to memory, how they are executed as an instruction, and all of the other inner workings of the game that allows for an exploit of this level.
Continue reading “Arbitrary Code Execution Is In Another Castle!”
After finding the infamous Heartbleed vulnerability along with a variety of other zero days, Google decided to form a full-time team dedicated to finding similar vulnerabilities. That team, dubbed Project Zero, just released a new vulnerability, and this one’s particularly graphic, consisting of a group of flaws in the Windows Nvidia Driver.
Most of the vulnerabilities found were due to poor programming techniques. From writing to user provided pointers blindly, to incorrect bounds checking, most vulnerabilities were due to simple mistakes that were quickly fixed by Nvidia. As the author put it, Nvidia’s “drivers contained a lot of code which probably shouldn’t be in the kernel, and most of the bugs discovered were very basic mistakes.”
When even our mice aren’t safe it may seem that a secure system is unattainable. However, there is light at the end of the tunnel. While the bugs found showed that Nvidia has a lot of work to do, their response to Google was “quick and positive.” Most bugs were fixed well under the deadline, and google reports that Nvidia has been finding some bugs on their own. It also appears that Nvidia is working on re-architecturing their kernel drivers for security. This isn’t the first time we’ve heard from Google’s Project Zero, and in all honesty, it probably won’t be last.
Address Space Layout Randomization or ASLR is an important defense mechanism that can mitigate known and, most importantly, unknown security flaws. ASLR makes it harder for a malicious program to compromise a system by, as the name implies, randomizing the process addresses when the main program is launched. This means that it is unlikely to reliably jump to a particular exploited function in memory or some piece of shellcode planted by an attacker.
ASLR have been broken before in some particular scenarios but this new attack highlights a more profound problem. Since it exploits the way that the memory management unit (MMU) of modern processors uses the cache hierarchy of the processor in order to improve the performance of page table walks, this means that the flaw is in the hardware itself, not the software that is running. There are some steps that the software vendors can take to try to mitigate this issue but a full and proper fix will mean replacing or upgrading hardware itself.
In their paper, researchers reached a dramatic conclusion:
Continue reading “ASLR^CACHE Attack Defeats Address Space Layout Randomization”