Two pictures of the mobo side by side, both with kapton tape covering everything other than the flash chip. On the left, the flash chip is populated, whereas on the right it's not

Enabling Intel AMT For BIOS-over-WiFi

January 5, 2024 by Arya Voronova 28 Comments

Intel ME, AMT, SMT, V-Pro… All of these acronyms are kind of intimidating, all we know about them is that they are tied to remote control technologies rooted deep in Intel CPUs, way deeper than even operating systems go. Sometimes though, you want remote control for your own purposes, and that’s what [ABy] achieved. He’s got a HP ProDesk 600 G3 Mini, decided to put it into a hard to reach spot in his flat, somewhere you couldn’t easily fetch a monitor and a keyboard for any debugging needs. So, he started looking into some sort of remote access option in case he’d need to access the BIOS remotely, and went as far as it took to make it work. (Google Translate)

The features he needed are covered by Intel AMT — specifically, BIOS access over a WiFi connection. However, his mini PC only had SMT enabled from the factory, the cut-down version of AMT without features like wireless support. He figured out that BIOS dumping was the way, promptly did just that, found a suitable set of tools for his ME region version, and enabled AMT using Intel’s FIT (Flash Image Tool) software.

Now, dumping the image could be done from a running system fully through software, but apparently, flashing back requires an external programmer. He went with the classic CH341, did the 3.3 V voltmod that’s required to make it safe for flash chip use, and proceeded to spend a good amount of time making it work. Something about the process was screwy, likely the proprietary CH341 software. Comments under the article highlight that you should use flashrom for these tasks, and indeed, you should.

This article goes into a ton of detail when it comes to working with Intel BIOS images — whichever kind of setting you want to change, be it AMT support or some entirely different but just as tasty setting, you will be well served by this write-up. Comments do point out that you might want to upgrade the Intel ME version while at it, and for what it’s worth, you can look into disabling it too; we’ve shown you a multitude of reasons why you should, and a good few ways you could.

This Week In Security: Triangulation, ProxyCommand, And Barracuda

December 29, 2023 by Jonathan Bennett 6 Comments

It’s not every day we get to take a good look inside a high-level exploit chain developed by an unnamed APT from the western world. But thanks to some particularly dedicated researchers at Kaspersky, which just happens to be headquartered in Moscow, that’s exactly what we have today. The name Operation Triangulation was picked, based off part of the device fingerprinting code that rendered a yellow triangle on an HTML canvas.

The entire talk is available, given this week at the 37th Chaos Communication Congress, 37c3. The exploit starts with an iMessage attachment, delivered silently, that exploits an undocumented TrueType font instruction. Looking at the source code implies that it was a copy-paste error where a programmer didn’t quite get the logic right for a pointer calculation. That vulnerability gives a memory write primitive that pivots into code execution. What’s particularly interesting is that Apple silently fixed this bug January 2023, and didn’t make any public statements. Presumably there were an uptick of crash logs that pointed to this problem, but didn’t conclusively show attempted exploitation.

The exploits then moves to using NSExpression as a next stage. NSExpression is an ugly way to write code, but it does allow the exploit chain to get to the next stage, running JavaScript as an application, without Just In Time compilation. The JS payload is quite a beast, weighing in at 11,000 lines of obfuscated code. It manages to call native APIs directly from JS, which then sets up a kernel exploit. This is multiple integer overflow flaws that result in essentially arbitrary system memory reads and writes. Continue reading “This Week In Security: Triangulation, ProxyCommand, And Barracuda” →

A RISC-V Security Key

December 26, 2023 by Al Williams 6 Comments

The TKey is a RISC-V-based security key that plugs into a USB port. The device has a number of features, including a device-specific serial number, RAM scrambling, and a monitor that kills the CPU in the event of access to protected memory. There is also an FPGA that, on the end-user version, is locked down. This prevents you from changing the core features and the unique ID number for the device.

As part of the start-up code, the device calculates a hash of the application and merges it with the device ID and, potentially, a user-defined secret. If this number matches a previous calculation, it is reasonably certain that nothing has changed between the times of the calculations.

Continue reading “A RISC-V Security Key” →

This Week In Security: Terrapin, Seized Unseized, And Autospill

December 22, 2023 by Jonathan Bennett 5 Comments

There’s a new SSH vulnerability, Terrapin (pdf paper), and it’s got the potential to be nasty — but only in an extremely limited circumstance. To understand the problem, we have to understand what SSH is designed to do. It replaces telnet as a tool to get a command line shell on a remote computer. Telnet send all that text in the clear, but SSH wraps it all inside a public-key encrypted tunnel. It was designed to safely negotiate an unfriendly network, which is why SSH clients are so explicit about accepting new keys, and alerting when a key has changed.

SSH uses a sequence counter to detect Man-in-the-Middle (MitM) shenanigans like packet deletion, replay, or reordering. That sequence isn’t actually included in the packet, but is used as part of the Message Authentication Check (MAC) of several encryption modes. This means that if a packet is removed from the encrypted tunnel, the MAC fails on the rest of the packets, triggering a complete connection reset. This sequence actually starts at zero, with the first unencrypted packet sent after the version banners are exchanged. In theory, this means that an attacker fiddling with packets in the pre-encryption phase will invalidate the entire connection as well. There’s just one problem.

The innovation from the Terrapin researchers is that an attacker with MitM access to the connection can insert a number of benign messages in the pre-encryption phase, and then silently drop the first number of messages in the encrypted phase. Just a little TCP sequence rewriting for any messages between, and neither the server nor client can detect the deception. It’s a really interesting trick — but what can we do with it?

For most SSH implementations, not much. The 9.6 release of OpenSSH addresses the bug, calling it cryptographically novel, but noting that the actual impact is limited to disabling some of the timing obfuscation features added to release 9.5.

Continue reading “This Week In Security: Terrapin, Seized Unseized, And Autospill” →

This Week In Security: Traingate, DNS, And JMP Slides

December 15, 2023 by Jonathan Bennett 5 Comments

Remember Dieselgate, the scandal where certain diesel vehicles would detect an emissions test, and run cleaner for it, “cheating” the test? Traingate may just put that one into perspective. We’ll tell the story from the beginning, but buckle up for a wild and astonishing ride. It all starts with Polish trains getting a maintenance overhaul. These trains were built by Newag, who bid on the maintenance contract, but the contract was won by another company, SPS. This sort of overhaul involves breaking each train into its components, inspecting, lubricating, etc, and putting it all back together again. The first train went through this process, was fully reassembled, and then refused to move. After exhausting all of the conventional troubleshooting measures, SPS brought in the hackers.
Continue reading “This Week In Security: Traingate, DNS, And JMP Slides” →

5Ghoul: The 14 Shambling 5G Flaws Used For Disruptive Attacks On Smartphones

December 13, 2023 by Maya Posch 5 Comments

A team of researchers from the ASSET Research Group in Singapore have published the details of a collection of vulnerabilities in the fifth generation mobile communication system (5G) used with smartphones and many other devices. These fourteen vulnerabilities are detailed in this paper and a PoC detailing an attack using a software defined radio (SDR) is provided on GitHub. The core of the PoC attack involves creating a malicious 5G base station (gNB), which nearby 5G modems will seek to communicate with, only for these vulnerabilities to be exploited, to the point where a hard reset (e.g. removal of SIM card) of the affected device may be required.

Hardware Setup for 5Ghoul PoC testing and fuzzer evaluation. (Credit: Matheus E. Garbelini et al., 2023)

Another attack mode seeks to downgrade the target device’s wireless connection, effectively denying the connection to a 5G network and forcing them to connect to an alternative network (2G, 3G, 4G, etc.). Based on the affected 5G modems, the researchers estimate that about 714 smartphone models are at risk of these attacks. Naturally, not just smartphones use these 5G modem chipsets, but also various wireless routers, IoT devices, IP cameras and so on, all of which require the software these modems to be patched.

Most of the vulnerabilities concern the radio resource control (RCC) procedure, caused by flaws in the modem firmware. Android smartphones (where supported) should receive patches for 5Ghoul later this month, but when iPhone devices get patched is still unknown.

Hilarious Security Flaw In Counter Strike 2 Is Now Patched

December 12, 2023 by Lewin Day 17 Comments

Normally, when we talk about video games having bugs, it’s some kind of item duplication glitch or a hilarious failure in the jacket equip code of some tedious ~~first-person-shooter~~ online wardrobe simulator. Counter-Strike 2 has had a more embarrassing faux-pas, however, with a security hole allowing bad actors to theoretically capture the IPs of their fellow players in a server. You won’t believe how this came to happen.

The exploit has already been making its way around the forums, with one [Crouch9706] raising the alarm. It’s all down to the way Counter-Strike 2 renders the names that players have entered in their Steam gaming profiles. In certain menus and other parts of the UI, the game will actually parse HTML in a player’s name. Typically, the way to trigger it is to join a game and vote to kick yourself. This brings up a dialog for other players that shows them your player name and parses the HTML. The only limitation is you only get 32 characters for your HTML.

There’s a nifty little extra trick to this, though, in that you can use this technique to snag another player’s IP. By putting in HTML that links to your own server, you can log any player IPs that connect to the server seeking an image, for example.

Of course, it’s not the biggest risk, with many players being behind ISPs that use CGNAT, making the harvested IPs rather useless. However, this sort of unexpected code injection is really not acceptable from a security standpoint. At the very least, it has the potential to expose players to nasty imagery.

Word on the street (Nitter) is that the exploit has now been patched. Meanwhile, if you’re working on a game that for some mad reason, executes code based on player names or any other such data, consider patching your work ASAP. If you find similar exploits in the wild, don’t hesitate to hit up our tipsline—and notify the developers, too!