Security Hacks

1532 Articles

This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg

December 6, 2019 by 9 Comments

CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.

On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code. Continue reading “This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg” →

John McMaster Explains Crypto Ignition Phone Keys And How To Reproduce Them

December 2, 2019 by 17 Comments

When you’re a nation state, secure communications are key to protecting your sovereignty and keeping your best laid plans under wraps. For the USA, this requirement led to the development of a series of secure telephony networks over the years. John McMaster found himself interested in investigating the workings of the STU-III secure telephone, and set out to replicate the secure keys used with this system.

An encryption key in a very physical, real sense, the Crypto Igntion Key was used with the STU-III to secure phone calls across many US government operations. The key contains a 64KB EEPROM that holds the cryptographic data.

[John] had a particular affinity for the STU-III for its method of encrypting phone calls. A physical device known as a Crypto Ignition Key had to be inserted into the telephone, and turned with a satisfying clunk to enable encryption. This physical key contains digital encryption keys that, in combination with those in the telephone, are used to encrypt the call. The tactile interface gives very clear feedback to the user about securing the communication channel. Wishing to learn more, John began to research the system further and attempted to source some hardware to tinker with.

As John explains in his Hackaday Superconference talk embeded below, he was able to source a civilian-model STU-III handset but the keys proved difficult to find. As carriers of encryption keys, it’s likely that most were destroyed as per security protocol when reaching their expiry date. However, after laying his hands on a broken key, he was able to create a CAD model and produce a mechanically compatible prototype that would fit in the slot and turn correctly.

Continue reading “John McMaster Explains Crypto Ignition Phone Keys And How To Reproduce Them” →

This Week In Security:Malicious Previews, VNC Vulnerabilities, Powerwall, And The 5th Amendment

November 30, 2019 by 29 Comments

Malware embedded in office documents has been a popular attack for years. Many of those attacks have been fixed, and essentially all the current attacks are unworkable when a document is opened in protected view. There are ways around this, like putting a notice at the top of a document, requesting that the user turn off protected view. [Curtis Brazzell] has been researching phishing, and how attacks can work around mitigations like protected view. He noticed that one of his booby-trapped documents phoned home before it was opened. How exactly? The preview pane.

The Windows Explorer interface has a built-in preview pane, and it helpfully supports Microsoft Office formats. The problem is that the preview isn’t generated using protected view, at least when previewing Word documents. Generating the preview is enough to trigger loading of remote content, and could feasibly be used to trigger other vulnerabilities. [Curtis] notified Microsoft about the issue, and the response was slightly disappointing. His discovery is officially considered a bug, but not a vulnerability.

VNC Vulnerabilities

Researchers at Kaspersky took a hard look at several VNC implementations, and uncovered a total of 37 CVEs so far. It seems that several VNC projects share a rather old code-base, and it contains a plethora of potential bugs. VNC should be treated similarly to RDP — don’t expose it to the internet, and don’t connect to unknown servers. The protocol wasn’t written with security in mind, and none of the implementations have been sufficiently security hardened.

Examples of flaws include: Checking that a message doesn’t overflow the buffer after having copied it into said buffer. Another code snippet reads a variable length message into a fixed length buffer without any length checks. That particular function was originally written at AT&T labs back in the late 90s, and has been copied into multiple projects since then.

There is a potential downside to open source that is highlighted here. Open source allows poorly written code to spread. This isn’t a knock against open source, but rather a warning to the reader. Just because code or a project uses an OSS license doesn’t mean it’s secure or high quality code. There are more vulnerabilities still in the process of being fixed, so watch out for the rest of this story. Continue reading “This Week In Security:Malicious Previews, VNC Vulnerabilities, Powerwall, And The 5th Amendment” →

This Week In Security: More WhatsApp, Nextcry, Hover To Crash, And Android Permissions Bypass

November 22, 2019 by 7 Comments

There is another WhatsApp flaw, but instead of malicious GIFs, this time it’s malicious mp4 files. Facebook announced the vulnerability late last week. An update has been released, so first go make sure WhatsApp is updated. Facebook’s advisory is a bit light on the details, simply saying that a “stack-based buffer overflow” was possible as a result of “parsing the elementary stream metadata of an mp4 file”.

Shortly after the bug was announced, a GitHub repository popped up, with a claimed proof-of-concept mp4 file for CVE-2019-11931. (Thanks to [justtransit] on Reddit for the link.) I can’t easily test the PoC file, but we can take a look at it to see what the vulnerability is. What tools do we need to take a look? A hex editor is a good start. I’m using GHex, simply because it was available and easily installed on Fedora. Continue reading “This Week In Security: More WhatsApp, Nextcry, Hover To Crash, And Android Permissions Bypass” →

The ESP32, Laid Bare

November 17, 2019 by 31 Comments

Most readers will be familiar with the ESP32, Espressif’s dual-core processor with integrated WiFi and Bluetooth. Few of us though will have explored all of its features, including its built-in encryption facilities and secure booting capability. With these, a developer can protect and secure their code, and keep their devices secure.

That sense of security may now be illusory though, thanks to [LimitedResults] who has developed a series of attacks on the chip that compromise its crypto core, secure boot, and flash encryption. This enables both the chance of arbitrary code execution and firmware extraction on locked-down ESP32 devices.

To achieve all this he used a glitching technique on the device’s power supply, inserting a carefully timed glitch in the rail to coincide with a particular instruction being executed. For those of us who are not experts in this technique, he provides a basic primer with a description of his home-made glitcher made using a CMOS switch chip.

It appears that there is no solution to this attack short of new silicon, however, it should be borne in mind that it’s something that depends upon a specialist hacker with a well-equipped bench, and is thus only likely to be a significant headache to manufacturers. But it undermines a key feature of a major line of microcontrollers, and as such it remains a significant piece of work.

This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!

November 15, 2019 by 11 Comments

An issue was discovered in libarchive through Google’s ClusterFuzz project. Libarchive is a compression and decompression library, widely used in utilities. The issue here is how the library recovers from a malformed archive. Hitting an invalid header causes the memory in use to be freed. The problem is that it’s possible for file processing to continue even after that working memory has been freed, leading to all kinds of problems. So far an actual exploit hasn’t been revealed, but it’s likely that one is possible. The problem was fixed back in May, but the issue was just announced to give time for that update to percolate down to users.

Of note is the fact that this issue was found through Google’s fuzzing efforts. Google runs the oss-fuzz project, which automatically ingests nightly builds from around 200 open source projects and runs ClusterFuzz against them. This process of throwing random data at programs and functions has revealed over 14,000 bugs.
Continue reading “This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!” →

This Week In Security: BGP Bogons, Chrome Zero Day, And Save Game Attacks

November 8, 2019 by 24 Comments

Our own [Pat Whetman] wrote about a clever technique published by the University of Michigan, where lasers can be used to trigger a home assistant device. It’s an interesting hack, and you should go read it.

Borrowing IP Addresses

We’ve lived through several IPv4 exhaustion milestones, and the lack of available addresses is really beginning to show, even for trolls and scammers. A new approach takes advantage of the weak security of the Border Gateway Protocol, and allows bad actors to temporarily take over reserved address blocks. These particular providers operate out of Russia, operating network services they advertise as “bulletproof”, or immune to takedown requests. What better way to sidestep takedowns than to use IP addresses that aren’t really yours to begin with?

BGP spoofing has been at the center of other types of attacks and incidents, like in 2018 when a misconfiguration in a Nigerian ISP’s BGP tables routed traffic intended for Google’s servers through Chinese and Russian infrastructure. In that case it appeared to be a genuine mistake, but little prevents malicious BGP table poisoning.

Chrome Zero-day

Google released an update to Chrome on the 31st that addresses two CVEs, one of which is being actively exploited. That vulnerability, CVE-2019-13720, is a race condition resulting in a potential use-after-free. Kaspersky Labs found this one being actively used on a Korean news site. The attack runs entirely from Javascript, and simply visiting a malicious site is enough for compromise, so update Chrome if it’s installed.

Anti-anti-doping

What do you do when you feel you’ve been unfairly targeted by an anti-doping investigation? Apparently hacking the investigating agency and releasing stolen information is an option. It seems like this approach is more effective when there are shenanigans revealed in the data dump. In this case, the data being released seems rather mundane.

Firefox Blocking Sideload Extensions

Mozilla made a controversial announcement on the 31st. They intend to block “sideload” browser extensions. Until this change, it was possible to install browser extensions by copying them to a particular folder on the computer. Some legitimate extensions used this installation method, but so did malware, adware, and other unwanted software. While this change will block some malicious add-ons, it does present a bit of a challenge to a user installing an extension that isn’t on the official Mozilla store or signed by Mozilla.

As you might imagine, the response has been… less than positive. While making malware harder to install is certainly welcome, this makes some use cases very difficult. An example that comes to mind is a Linux package that includes a browser extension. It remains to be seen exactly how this change will shake out.

Save Games as Attack Vector

An oddball vulnerability caught my eye, published by [Denis Andzakovic] over at Pulse Security. He discovered that a recent indy game, Untitled Goose Game, can be manipulated into running arbitrary code as a result of loading a maliciously modified save file. The vulnerability is rooted in a naive deserialization routine.

If you’re interested in a deeper dive into .net deserialization bugs, a great paper was submitted to Blackhat 2012 discussing the topic. The short version is that if a programmer isn’t careful, the deserialization routine can overwrite variables in unexpected ways, potentially leading to code execution.

At first glance, a vulnerability triggered by a malicious save file seems relatively harmless. The level of access needed to modify a save file on a hard drive is enough to compromise that computer in a multitude of better ways. Enter cloud save synchronization. Steam, for instance, will automatically sync save games across a user’s install locations. This is a very useful feature for those of us that might play the same game on a laptop and a desktop. Having the save game automatically synced to all your devices is quite useful, but if an attacker compromised your Steam account, your save games could be manipulated. This leads to the very real possibility that an attacker could use a save game vulnerability to turn a Steam account compromise into an attack on all your machines with Steam installs.