EDITORIAL, RESEARCH | March 28, 2024

Hack the Sky: Adventures in Drone Security | Gabriel Gonzalez

Taking aim at the attack surface of these buzzy devices uncovers real-world risks

In the grand theater of innovation, drones have their spot in the conversation near the top of a short list of real game changers, captivating multiple industries with their potential. From advanced military applications to futuristic automated delivery systems, from agricultural management to oil and gas exploration and beyond, drones appear to be here to stay. If so, it’s time we start thinking about the security of these complex pieces of airborne technology.

The Imperative Around Drone Security

Now, I know what you’re thinking. “Drone security? Really? Isn’t that a bit… extra?”

Picture this: A drone buzzing high above a bustling city, capturing breathtaking views, delivering packages, or perhaps something with more gravitas, like assisting in life-saving operations. Now, imagine that same drone spiraling out of control, crashing into buildings, menacing pedestrians — or worse, being used as a weapon.

Drone security isn’t just about keeping flybots from crashing into your living room. It’s about ensuring that these devices, which are increasingly a part of our everyday lives, are hardened against the actions of those with malicious intent. It’s about understanding that while drones can be used for good, they can also be used for nefarious purposes.

And BTW, hacking a drone remotely is just plain cool.

But let’s not get carried away. While the idea of hacking a drone might sound like something out of a spy movie, it’s a very real threat. And it’s a threat that we need to take seriously. Let’s dive a little deeper.

Drones: The Other Kind of Cloud Vulnerabilities

Before we delve into the nitty-gritty of drone hacking, let’s take a moment to understand them. Drones are either controlled remotely or they fly autonomously through software-controlled flight plans embedded in their systems working in conjunction with onboard sensors and the satellite-based Global Positioning System (GPS).

At the heart of a drone’s operation — and the bullseye for any security research — is its firmware and its associated microcontroller or CPU. This is the software/chip combination that controls the drone’s flight and functionality. It’s the drone’s brain. And just like any brain, we’re sorry to report, it has weaknesses.

Drones, like any other piece of technology, are not impervious to attack. They present us with a few attack surfaces – the backend, mobile apps, RF communication, and the physical device itself.

Drone attack surfaces: 1) backend, 2) mobile apps, 3) RF comm, 4) device hardware

Electromagnetic (EM) Signal: A Powerful Tool for Hacking

Now that we’ve covered the basics let’s move on to the star of the show – the Electromagnetic (EM) signal. EM signals are essentially waves of electric and magnetic energy moving through space. They’re all around us, invisible to the naked eye but controlling much of our daily life.

These pulses can be used to interfere with the way a drone “thinks”, creating unexpected bad behavior in the core processor, disrupting its operations, or pushing the onboard controller to reveal information about itself and its configurations. It’s like having a magic wand that can bypass all the security systems, influence critical systems behavior, and even potentially take control of the drone. Sounds exciting, doesn’t it?

The potential of EM signals to bypass drone security systems is a concern and a threat that needs to be addressed quickly.

Case Study: Hacking a Drone with EM Fault Injection

Let’s walk through our real-world example of a drone being hacked using EM signals.

In this particular IOActive research, we used EM signals to interfere with the drone’s functionality by disrupting the routine processing of the device’s “neural activity” in its core microprocessor “brain” and branching out to its various onboard peripheral systems.

Most people are familiar with Electroencephalography (EEG) and Deep Brain Stimulation (DBS) — using electrodes and electrical impulses to both monitor and influence activity in the human brain. Our approach here is analogous to that, but with fewer good intentions and at a much greater distance.

Our initial strategy involved attempting to retrieve the encryption key using EM emanations and decrypting the firmware. We began by locating an area on the drone’s PCB with a potent EM signal to place a probe and record sufficient traces to extract the key.

After identifying the location with the strongest signal, we worked on understanding how to bypass the signature verification that takes place before the firmware is decrypted.

After several days of testing and data analysis, we found that the probability of a successful signature bypass was less than 0.5%. This rendered key recovery unfeasible since it would have required us to collect tens of thousands of traces.

Our subsequent — and more fruitful — strategy involved using ElectroMagnetic Fault Injection (EMFI), inspired by ideas published by Riscure. With EMFI, a controlled fault can be used  to transform one instruction into another, thereby gaining control of, say, the PC register. We can generate an EM field strong enough to induce changes within the “live bytes” of the chip. It’s very much like sending DBS current to the human brain and getting the muscles to behave in an unconscious, uncontrolled way.

After identifying a small enough area on the PCB, we tweaked the glitch’s shape and timing until we observed a successful result. The targeted process crashed, as shown here:

Our payload appeared in several registers. After examining the code at the target address, we determined that we had hit a winning combination of timing, position, and glitch shape. This  capture shows the instruction where a segmentation error took place:

Having successfully caused memory corruption, the next step would be to design a proper payload that achieves code execution. An attacker could use such an exploit to fully control one device, leak all of its sensitive content, enable access to the Android Debug Bridge, and potentially leak the device’s encryption keys.

Drone Security: Beyond the Horizon

So, where does this leave us? What’s the future of drone security?

The current state of drone defenses is a mixed bag. On one hand, we have advanced security systems designed to protect drones from attacks. On the other hand, we have researchers — like us — constantly scheming new ways to bypass such systems.

The future of drone cyber-protections lies in ongoing research and development. We must stay one step ahead and identify weaknesses so manufacturers can address them. This post is just a summary of a much longer research paper on the topic; I encourage you to check out the full report.

Follow along with us at IOActive to keep up with the latest advancements in the field, understand the threats, and take action. The sky is not just the limit. It’s also a battlefield, and we need to be prepared.

ADVISORIES |

IOActive Security Advisory | KUNBUS Revolution Pi – Multiple Vulnerabilities

KUNBUS GmbH (KUNBUS) develops and offers products and solutions for industrial communication in automation, process, manufacturing and drive technology. This includes a comprehensive portfolio of real-time Ethernet and fieldbus-based protocol technology on state-of-the-art hardware platforms, as well as stacks suitable for the sensor level with IO-Link and IO-Link Wireless and the entry into wireless communication technology.

INSIGHTS | March 27, 2024

IOActive Presents at HARRIS 2024, a Unique Workshop for Chip Reverse Engineering | Tony Moor

The Hardware Reverse Engineering Workshop (HARRIS) is the first ever annual workshop devoted solely to chip reverse engineering, and 2024 was its second year. IOActive has been present both years, and this year I attended to see what all the fuss was about.

Background

The workshop is organized by the Embedded Security group of the Max Planck Institute for Security and Privacy (MPI-SP) together with Cyber Security in the Age of Large-Scale Adversaries (CASA) and Ruhr-University Bochum (RUB).

Christof Paar is a founding member of MPI-SP, and HARRIS is his latest brainchild, following the success of the annual Conference on Cryptographic Hardware and Embedded Systems (CHES) that first took place in 1999. Considering the strong links between HARRIS and MPI-SP, it’s no surprise that the 2023 and 2024 workshops were both held there.

Day One

Upon arrival at the venue, it became immediately apparent how well-organized the event is. Registration was simple, and there were already many casual conversations going on between the organizers and attendees. Privacy is respected by way of providing white lanyards to attendees who do not wish to be photographed, while the rest receive green. Affiliations are also optional on the name tags. I estimated the attendance to be around 125, compared to last year’s number of 90. I fully expect that trend to continue given the efforts of the fine organizing committee. From my discussions, I would estimate the split was roughly 50% academia, 25% industry, and 25% government. Geographically, Singapore, USA, Canada, and the vast majority of European countries were represented.

Front-row seats at the venue within RUB

The presentations on day one were divided into four sessions, the first being my personal favorite: Sample Preparation. 😊 The standout talk for me here was by REATISS, where they really brought home two things:

  1. What a difficult job chip deprocessing is
  2. How amazing REATISS are at chip deprocessing

One of several fascinating facts that the talk illustrated was how planarity is key during deprocessing, which of course I know only too well. What I didn’t know, however (or at least what I never got around to calculating), is that the planarity required across a 1mm2 area of interest within a <10nm technology node chip is 25nm. This is equivalent to the total area of a football (soccer) pitch being flat to within 2mm. Now that is flat!

REATISS also touched on the challenges of characterizing 3D NAND Flash as well as the novel materials being utilized in the latest IC technologies, such as cobalt metallization.

Allied High Tech Products followed this with an excellent presentation of how toolset selection and a well-thought-out workflow are vital in effective chip/package deprocessing. They also showcased the deprocessing of some extreme examples of modern multi-chip packages.

Between sessions, there were informal discussions divided into different challenges in hardware reverse engineering. This was a great idea and encouraged new and old connections to discuss their techniques without giving away too much of their secret sauce. 😉

Day One concluded with a dinner at a very nice restaurant in the Bochum city center, where attendees could sit with whomever they pleased and continue discussions over a pleasant meal and drinks.

Livingroom’ in Bochum; the dinner venue where we concluded Day One

While some continued to socialize into the small hours, I retired to my hotel for a good night of sleep to make sure I was prepared for another day of talks, making connections, and inevitably learning lots of new things.

Day Two

A slightly later start than yesterday, but it allowed folks like me to catch up a little on email and activity back at home base. Kicking off today was the keynote, which was superbly delivered by Paul Scheidt of Synopsys. Entitled “Perspectives from Four Decades of Chip Design,” Paul provided fascinating insight into his career in the semiconductor industry. He contrasted how much the industry has advanced, alongside several instances where ideas have been recycled from previous generations of chips and systems. Following that, there were three further sessions and some more opportunities for informal discussion (the full agendas are here). The focuses for the talks today included FPGA and netlist reverse engineering.

Of course, for the IOActive folks, the focus and highlight of Day Two was our very own Dr. Andrew Zonenberg, presenting during the afternoon case studies session. “Secure Element vs Cloners: A Case Study” explores an example wherein a platform may be protected for both revenues and user experience: the OEM wants to protect their accessory market as best they can, and for as long as they can, while competitors are racing to make a compatible version of the accessory in question. These are potentially billion-dollar markets, so the reward is high and invites third parties with serious budgets to perform full netlist extractions of chips in order to carry out Focused Ion Beam (FIB) attacks. A multi-million-dollar lab and the associated talent (the latter often being the most difficult part) does not seem too much of an investment when the return on that could be tens of millions of dollars per year!

Information on the range of IOActive’s Silicon Security Services can be found here.

Andrew presented flawlessly (no surprises there), and the talk was very well received indeed. Some interesting follow-up conversations ensued, which for me capped off a very worthwhile event.

Andrew in full flow – once he gets started, there is no stopping him!

Conclusions

HARRIS 2024 was an extremely well-run event, which is not surprising considering the success of CHES under Christof Paar. For anyone that is involved in semiconductor reverse engineering, this really is a must-go. The format works very well, provides plenty of opportunities for networking, and the quality of talks was exceptional. I was impressed and am very much looking forward to attending next year, and with something even more interesting for IOActive to present. Roll on HARRIS 2025!

ADVISORIES | March 21, 2024

IOActive Security Advisory | Movistar 4G Router – Multiple Vulnerabilities

IOActive found that the Android Debug Bridge (ADB) is listening on all interfaces and gives access to a shell with root privileges; a malicious actor with access to the same network that the router is providing access to will have full control of the device. A malicious actor can send a specific payload to the gui.cgi using the ping_traceroute_process functionality to execute arbitrary commands as the privileged root user. IOActive saw a general lack of protection against cross-site request forgery (CSRF) attacks. CVE-2024-2414, CVE-2024-2415, CVE-2024-2416

ADVISORIES |

IOActive Security Advisory | Hikvision Camera Denial of Service

CVE-2023-28811. The Hikvision DS-7732NI-14(B) is a 32-channel Network Video Recorder (NVR). IOActive had the opportunity to assess the DS-7732NI-I4 and identified one high-risk vulnerability. This issue could be exploited to cause a denial of service (DoS) to the device.

ADVISORIES | March 5, 2024

IOActive Security Advisory | Socomec NET VISION – Multiple Vulnerabilities

IOActive Security Advisory/Disclosure document (CVE TBA) by Daniel Martinez, IOActive Senior Security Consultant, of the multiple vulnerabilities discovered in the Socomec NET VISION devices.

Socomec, Inc. (Socomec) is an electrical equipment design and manufacturing company, specializing in low-voltage energy performance in terms of safety, service continuity, quality and energy efficiency. NET VISION is a professional network adapter for monitoring and controlling UPS units from a remote location. It allows direct connection of a UPS to the IPv4 or IPv6 Ethernet network, thereby enabling remote management of the UPS using a web browser, a TELNET interface, or an NMS application via SNMP protocol.

Get the IOActive Security Advisory

ADVISORIES |

IOActive Security Advisory | Lamassu Douro Bitcoin ATM – Multiple Vulnerabilities

Supporting security advisory/disclosure document (CVE-2024-0175, CVE-2024-0176 and CVE-2024-0177) supporting the Lamassu Douro Bitcoin ATM research by Gabriel Gonzalez, IOActive Director of Hardware Security.

IOActive had access to few of these machines, specifically to Lamassu’s Douro ATM. This provided the team with the opportunity to assess the security of these devices – more specifically, to attempt to gain full control over them – assuming the role of an attacker with the same physical access to the device that a regular customer might have.

Read the IOActive Security Advisory

EDITORIAL | March 1, 2024

Opinion: AGI Influencing the Secure Code Review Profession

It’s tough to be a secure code reviewer. There are already over 700 programming languages according to Wikipedia, and seemingly more languages materializing every year. Expectations are high that rapid developments in Artificial Generative Intelligence (AGI) will bring a new suite of languages and security issues that’ll have an oversized impact on software development. Consequently, secure software development lifecycle (SDL) processes and security code review are having to evolve rapidly.

I’m both excited and nervous about AGI advancements in the world of software development and secure application design. It’s exciting to see how prompt engineering of Large Language Models (LLM) and adoption of AI augmentation in the form of copilots and chatbots are increasing the pace of ideation into new products. I’m nervous about the hallucinations and code quality being generated in response though.

English as a Programming Language

2023 was the breakthrough year for AI, with LLM and AGI permeating every industry, technology, and product. Today, the most in-demand languages currently are Python, C, and C++ but, controversially, the future star programming language may in fact be English; something that’ll take some time to adjust to.

For over a decade we’ve been told that the supply of experienced cybersecurity professionals has trailed the market’s requirements, with a deficit growing year-on-year, and a casual scan across office desks and cubicles will highlight a more significant gender gap across the cybersecurity (and software development) industry. I think AGI and emergence of English as a critical programming language are fundamental to correcting both industry problems.

AGI, particularly those based upon LLM advancements, are increasingly sophisticated language machines – and women may have an advantage over men in maximizing utility and productivity from them.

Multiple studies over the last 30 years have constantly highlighted that women are better communicators than men. “Better” is obviously an explosive and controversial term even amongst the academics who published the studies, but in general women have more expansive vocabularies and stronger interpretative communication skills. Modern neuroscience and studies in children and adolescents identify girls as more garrulous than boys, with greater complexity and sophistication of language, and tend to develop more in the realm of listening with greater focus and concentration as they age. This historically translates into women being better coders than men (once you remove the bias in the system).

As I look to AGI and the expanding world of prompt engineering, I anticipate that women will have an advantage over their male developer counterparts. Strong and well-developed communication skills (and the reasoning and understanding that underlays those polished skills) are prerequisites for maximizing efficiency of AGI-returned results and tuning responses – both now and for the immediate future.

Starter-job Experience

But what about experience? The “experience gap” is often called out as a chasm for newly minted degree-holding graduates and landing a starter-job in cybersecurity.

It’s rare to find an entry-level job in our industry that doesn’t require multiple years of hands-on security experience nowadays as many of those traditional starter roles – network scanning, alert triage, playbook maintenance, patch management – have been automated away, with many more projected to disappear as AI adoption increases.

Most successful new entrants into the cybersecurity profession come from adjacent technical industries making a career jump rather than direct from a college or university. Armed with transferable skills and technical experience, they’re capable of crossing the chasm left in the wake of cyber automation. However, the security knowledge gap between a cybersecurity veteran and a recent transfer remains large and a growing concern for the industry.

I’m excited to think AI augmentation and copilot technologies will have one of the largest impacts on our industry – removing much of the security knowledge gap and reducing the overall impact of the experience gap – like what is happening in other industries, such as the medical field. For example, AI use in patient triage, predictive analytics, and virtual assistants are augmenting generalist regional nurses (two-year qualification) and Bachelor of Science in Nursing (four-year qualification) graduates, and allowing them to perform many of the roles and responsibilities traditionally associated with a completed medical doctor degree (10 to 12 years).

Secure Code Reviews

It’s tough to be a secure code reviewer. There aren’t enough of them. The job requires tremendous amounts of experience and advanced security knowledge, and it’s tiring and hard work.

AGI is going to have a huge impact on their job.

On the positive side, English as a programming language and AI augmentation and copilots is going to help increase both the breadth and depth of the cybersecurity talent pool available to perform this critical job. The tools available to code reviewers to automatically review and assess code security are advancing quickly and, while still in their first generation of AI adoption, are anticipated to mature rapidly and identify vulnerabilities and logic flaws with higher fidelity and trust. I’m sure there’ll be a gap between the best that a tool can achieve versus the best-of-the-best human expert though – especially when that expert is augmented and using similar tools themselves.

Meanwhile, AGI is spearheading prompt engineering of new software applications. A new generation of product developers may have little to no influence over the code that powers the application. Indeed, I’ve previously argued that the role of product manager will change greatly in the coming years as their skills in product design and requirement setting pivot from being directed to engineering teams and into AGI prompts instead.

What does an AGI-generated application look like under the covers? Time will tell. We anticipate it’ll increasingly become more secure – using best security practices and recycling pretested code behind the scenes – and that it’ll constantly learn, optimize, and apply best and better security practices – but we’ll still need those human secure code reviewers for some time to come, specially when it comes to high-impact applications and certification.

A concern though as AGI does more of the application development software developers will have less direct influence over the underlying code is that powering the application and business logic. It would be a nightmare if the AGI produced entirely different code throughout the application each time it received new design criteria and re-optimized – making vulnerability triage, reporting, reconciliation, and tracking near impossible, and code reviews and code certifications (human or tool led) largely nonsensical.

Watch this space!

I think we’re still some years away from having to worry about continuously reimagined code generated by AGI without human software developers tweaking and refining the underlaying application code, but it is tremendously exciting to see the rapid advances in prompt engineering and how LLM’s are being incorporated into both old and new products.

Our industry has consistently struggled to attract and retain women. AGI has the potential to not only level the field and make it easier to join the game, but to also leverage previously poorly-tapped communication skills for the betterment of both application development and security. There’s a lot of work ahead. There’s a lot of research to be done. There’s a lot of opportunities to make code more secure!

INSIGHTS, RESEARCH | February 6, 2024

Exploring AMD Platform Secure Boot

Introduction

In our previous post on platform security (see here) we provided a brief introduction into platform security protections on AMD-based platforms and touched upon the topic of AMD Platform Secure Boot (PSB).

As a quick reminder, the purpose of PSB is to provide a hardware root-of-trust that will verify the integrity of the initial UEFI firmware phases, thereby preventing persistent firmware implants.

In this part of the blog series, we will dig deeper into the nitty gritty details of PSB, including a first glimpse of how it works under the hood, how it should be configured and, naturally, how various major vendors fail to do so.

Architecture

To begin, it is important to understand that the UEFI boot process is divided into various phases, referred to as SEC, PEI, DXE, BDS, TSL, RT and AL. For the sake of brevity, we won’t go into detail on the purpose of each phase as it has already been widely covered already (e.g. here).

In short, the role of the PSB is to ensure that the initial UEFI phases, specifically the SEC and PEI phase, are properly verified and cannot be tampered with. In turn, the PEI phase will verify the DXE phase using a proprietary and vendor-specific method.   

The resulting scheme is summarized in the following image:

Upon reset, only the AMD Platform Security Processor (PSP), an ARM-based co-processor embedded within the AMD chip, is running. It functions as a hardware root-of-trust and verifies the SEC and PEI phase portions of the UEFI firmware. If verification succeeds, then it releases the main cores that then start executing the SEC and PEI phase.

Trust Hierarchy

In order to understand the trust hierarchy in more depth, we will first take a look at how the UEFI firmware, stored in the SPI flash, is structured. To do so, we will use the SPI flash dump we have obtained from an AMD-based Huawei Matebook 16 (BIOS v2.28).

When we open up a SPI flash dump with our trusty UEFI Tool, we will typically see, among others, the following structures:

  • Padding areas
  • Firmware volumes (containing DXE drivers and SMM modules)
  • NVRAM data (containing non-volatile configuration data, i.e. UEFI variables)

However, while UEFI Tool correctly identifies firmware volumes that contain code executed in the DXE phase of the UEFI boot process, the code running in the SEC and PEI phases seems to be missing altogether.

This is because it does not support parsing an AMD platform specific structure called the Embedded Firmware Structure (EFS). Once again, for the sake of brevity, as the structure is relatively complex, we will only focus on portions relevant to the chain-of-trust.

As described here, the EFS is located at one of the pre-defined locations in the SPI flash and contains pointers to:

  1. The PSP directory table that includes:
    • The BIOS signing key (entry type 0x05)
    • The BIOS PEI firmware volume (entry type 0x62)
    • The BIOS PEI firmware volume signature (entry type 0x07)
  2. The BIOS directory table that includes:
    • The AMD root signing key (entry type 0x00)

In visualized form, the resulting data structure looks as follows:

As a sidenote, we have also developed a simple parser (available here) that can be used to parse and extract the different portions of the PSP and BIOS directories.

Upon reset, the PSP will hold the main cores and verify the trust chain in the following order:

  • The AMD root signing key is verified against a SHA256 hash programmed into the PSP
  • The BIOS signing key is verified against the AMD root signing key
  • The BIOS PEI firmware volume is verified against the BIOS signing key

At this point the PSP releases the main cores and the SEC+PEI phase code, stored in the PEI firmware volume, will execute. Then, to complete the chain-of-trust, a vendor-specific PEI module will verify the DXE firmware volume(s).

PSB Configuration

The next step is to understand how we can interact with the PSP to determine whether the PSB is properly configured or not. This, in turn, could be used to implement a simple tool to detect potential misconfigurations. 

Here we found that the configuration can be checked by first determining the PSP MMIO base address and then, at a specific offset, reading out the value of two PSB-related registers.

PSP MMIO Base Address

First, the PSP MMIO base address is obtained by writing a specific value to a register of the AMD IOHUB Core (IOHC). More specifically:

  • 0x13E102E0 for families 17h, model 30h/70h or family 19h, model 20h or
  • 0x13B102E0 for all other models

is written to the register at offset 0xB8 of the IOHC device (on bus 00h, device 00h, function 00h) and the result is read from the register at offset 0xBC.

For example, on an Acer Swift 3 (fam 17h, model 60h) we write the value 0x13B102E0 at offset 0xB8 of the IOHC and read the base address 0xFDE00000 (after masking) at offset 0xBC.

PSB Configuration Registers

The PSB fuse register, located at offset 0x10994, reflects the actual fuse configuration and has the following structure:

It has various fields, such as:

  • the platform vendor ID and platform model ID to uniquely identify the platform
  • the BIOS key revision and anti-rollback to revoke BIOS signing keys
  • the AMD disable key to prevent booting a BIOS signed with the AMD root signing key
  • the PSB enable field to enable the feature
  • the customer key lock to permanently burn the fuses

We observed that on systems with the PSB enabled, typically the platform vendor ID, the platform model ID, the PSB enable bit and the customer key lock are configured accordingly. In fact, if the BIOS was compiled with the feature enabled, the fusing process occurs automatically when the system boots for the first time.

Interestingly, the PSB can also be permanently disabled by setting the PSB enable bit to 0 and the customer key lock to 1. This would enable an attacker to leave the system vulnerable indefinitely and is similar to what was discovered for Intel BootGuard by Alexander Ermolov (see Safeguarding Rootkits: Intel BootGuard at ZeroNights). 

The PSB status register, located at offset 0x10998, is used for obtaining PSB state information and has the following structure:

Here we only know that the PSB status field returns 0x00 if no errors occurred; otherwise returns a non-zero value likely corresponding to a specific error code.

Vulnerabilities

Now that we understand how the PSB should be configured, we would like to walk you through misconfiguration and implementation issues we discovered during our research.

For completeness, the list of systems we tested and whether they were found to be vulnerable or not can be found in a table at the end of this blog.

Configuration flaws

Based on our knowledge of the PSB fuse and status registers, we implemented the logic into our in-house developed platform testing tool Platbox (see here) and discovered that almost none of the tested systems had the feature enabled. 

As can be seen below, the Lenovo IdeaPad 1 Gen7 (BIOS JTCN44WW) did not have the PSB fuse register burned and the PSB status field returned a non-zero value. In fact, the same pattern was observed on all other vulnerable systems.

When trying to determine the root cause, we found that various data structures that are essential to the correct functioning of the PSB were missing, such as the BIOS signing key and the BIOS PEI firmware volume signature. This may indicate that already during the build process of the firmware image the feature was simply disabled.

Implementation flaws

Beyond configuration flaws, we also wanted to find out whether there were any potential implementation issues. While AMD implements the first portion of the chain-of-trust, verifying the SEC and PEI phase, we decided to focus on the vendor-specific portion that verifies the DXE phase.

To begin, we picked the Lenovo Thinkpad P16s Gen1 (BIOS v1.32) as our target, as it was one of the few systems that had the PSB enabled, and inspected the firmware with UEFI Tool. As it turns out, it uses a Phoenix-based BIOS and a well-known data structure, called the Phoenix hash file, to verify the DXE phase:

The Phoenix hash file format is straightforward – it is a list of protected ranges of the SPI flash encoded using triples that consist of base address, size and a hash. These protected ranges should, at least in theory, cover the DXE phase code, stored in DXE firmware volumes, that will be loaded.

However, we found that that multiple firmware volumes were used and that one of them (GUID 8FC151AE-C96F-4BC9-8C33-107992C7735B) was not covered by the protected ranges. Thereby, code contained within said volume could be tampered with and it would be automatically loaded during the boot process.

To make matters worse, we noticed that while the BIOS PEI firmware volume, verified by the PSP, was located in the beginning of the firmware in the padding section, whereas the Phoenix hash file was located at the end of it and thereby could be tampered with.

To confirm that the issue was indeed exploitable, we replaced the PersistenceConfigDxe DXE driver (GUID 27A95D13-15FB-4A2E-91E2-C784BF0D20D3) with a malicious DXE driver that configures the SMM_KEY MSR and allows us, at runtime, to disable the TSEG protections and thereby trivially escalate privileges to SMM (see previous blog post for more details).

Note that an advisory was published by Lenovo (see here) for this vulnerability (assigned CVE-2023-5078) that details which systems it affected and when different BIOS updates were released.

Vendor response

As part of our responsible disclosure process, we have reached out to various vendors in order to address the issues and get an understanding of the underlying problem. The responses were, to say the least, quite surprising:

Acer

“We appreciated your information about a possible vulnerability in Acer product. After thoroughly investigation, AMD PSB is an Optional Design during develop on consumption product, it’s not a mandatory requirement in Swift 3 SF314-42;

even though AMD PSB status is not enabled by default, platform with Secure Boot and Secure Flash are in position to protect system if malicious code injecting to flash ROM, so we don’t consider this as a vulnerability.”

Lenovo

“Platform Secure Boot was introduced as a standard feature on all consumer Lenovo laptops in 2022, and laptops manufactured prior to this date were not designed with this feature in mind. Enabling it on devices now in the field would be likely to frustrate consumers if any unexpected issues arise.”

Huawei

The PSB function was not enabled on our early AMD platform product, the PSB-like function(also known as “Intel Boot Guard”) was enabled on our later Intel platform product (such as MateBook 16s 2022).

We confirmed with the BIOS supplier (Wingtech Technology) of the AMD platform product, there is no modification plan for this issue. To avoid confusing users, we kindly ask you not to disclose this issue. […]”

Conclusions

The results of our research demonstrate how vendors systematically failed to either properly configure the platform or correctly implement the chain-of-trust. Although it is clear how this issue needs to be addressed, based on vendor responses, it appears that they are reluctant to do so.

These issues would allow an attacker that has obtained a foothold on the OS, in combination with a SPI flash write primitive (e.g. CVE-2023-28468), to install firmware implants on the system. These, by design, bypass any OS- and Hypervisor-level protections that may be implemented and, if done properly, can also be made resistant to traditional firmware updates.

To determine whether you are vulnerable, we recommend running our in-house developed tool Platbox (see here) and, if that is the case, to reach out to the vendor in the hope that they will address these issues.

Appendix

The following table lists the systems we tested and what we discovered.

INSIGHTS, RESEARCH | January 18, 2024

Owning a Bitcoin ATM

Nowadays, Bitcoin and cryptocurrencies might look lees popular than they did just a few years ago. However, it is still quite common to find Bitcoin ATMs in numerous locations. 

IOActive had access to few of these machines, specifically to Lamassu’s Douro ATM (https://lamassu.is). This provided us with the opportunity to assess the security of these devices – more specifically, to attempt to achieve full control over them.

Figure 1. Lamassu Douro Bitcoin ATM

In this post, we’ll explain all the steps we followed to identify a series of vulnerabilities (CVE-2024-0175, CVE-2024-0176 and CVE-2024-0177) that allows full control over these ATMs. For this exercise, we are assuming the role of an attacker with the same physical access to the device that a regular customer might have. 

Don’t Touch Me

After booting up, the screen displays the the UI for the kiosk’s primary application. However, during boot, for a few seconds the user can interact with the Linux operative system’s window manager, as illustrated in Figure 2.

Figure 2. Accessing Applications during boot

During this time, it was possible to pop up a terminal window or run any other installed application as a low-privilege user.

Look at the Camera!

In order to obtain full control over the device, the next step was to perform a privilege escalation. To achieve this, we exploited the software update mechanism by creating a file named ‘/tmp/extract/package/updatescript.js’ with the following payload:

cp = require(“child_process”)
cp.exec(“cp /bin/sh /tmp/shuid; chmod +sx /tmp/shuid”)

Next, we created a file named ‘done.txt’ in the ‘/tmp/extract folder.’ This would trigger the watchdog process, which runs as root in the reviewed machines, to execute the JavaScript payload.

How did we create these files? Well, that’s an interesting question, as although we gained access to the graphical interface and the terminal, there was no keyboard plugged in. While we did have physical access to the devices, so that opening them and plugging in a keyboard would be too easy, the goal was to gain control without invasive physical access, therefore we explored a different approach.

The ATM supports a feature that enables it to read QR codes, and the binary located at ‘/usr/bin/zbarcam’ could be executed using the touch controls, so we only had to use a custom QR code containing our payload. Once the payload was read, a root shell was popped.

The following video illustrates the paths we followed to exploit the vulnerability.

Once we gained root access, we could reasonably think that the job was done. However, we looked to the ‘/etc/shadow’ file, where we were able to crack the root password in less than one minute – and the same password was valid for all of the devices.

Disclosure Timeline

 IOActive followed responsible disclosure procedures which included the following:

  • 11th July 2023 – Initial contact to report the vulnerabilities.
  • 9th October 2023 – The vendor confirmed the issues were fixed.
  • 25th October 2023 – The vendor asked us to delay publishing details about the vulnerabilities.
  • 22nd November 2023 – The vendor contacted us and published an advisory mentioning the issues were fixed.
  • 18th January 2024 – CVEs have been published by the corresponding CNA.

The following security bulletin was released by Lamassu regarding their remediation of the security issues found by IOActive:

https://support.lamassu.is/hc/en-us/articles/20747552619149-Security-update-for-Douros-2023-10-26