2 December 2024

Interfaces

I am Jelte Derksen, an ethical hacker working at Kiwa NL. I got into the field of ethical hacking after initially pursuing studies that were, frankly, a terrible fit. Consequently, I pivoted into IT as a SCADA administrator. Once I had a solid grasp of the basics, I transitioned into IoT development and Data Engineering before landing in the field of security. My current work mostly involves assessing the security of IoT devices and performing penetration tests. While our team handles a variety of activities, my specialization primarily focuses on hardware and firmware. For me, the constraints and 'cleverness' involved in embedded systems represent a unique beauty. With this first blog, I want to address interfaces—specifically, physical interfaces. But before we dive in, let’s first distinguish the different types of interfaces according to ETSI EN-303 645: network interfaces, air interfaces, logical interfaces, and physical interfaces.

Differentiating interfaces 

For air and physical interfaces, we need to think in terms of Layer 1 of the OSI model, also referred to as PHY, meaning "physical." The key difference is that one is wireless (air), while the other is wired (physical). (The latter should consider less caffeine!) An air interface can be either radio waves or optical. Communication is wireless and travels through the air. Personally, I don’t find this name particularly fitting since light and radio waves can also travel through a vacuum, which lacks air. Physical interfaces require a physical connection, often a metal conductor that can transfer electrons. Network and logical interfaces operate at higher levels of the OSI model. When we think of network interfaces, Wi-Fi and the RJ45 Ethernet jack typically come to mind. But what about Zigbee and Bluetooth? Both contain network stacks; Bluetooth even creates a "Piconet" network. Fortunately for us, despite needing this information, distinguishing these interfaces isn’t essential during testing.

Subject of the matter: Interfaces

Current standards for testing IoT and OT devices take interfaces into consideration. We will focus on provision 5.6-4 from ETSI EN-303 645. For assessments, we use the accompanying Technical Specification, TS-103 701, which provides more detailed guidance on applying the standard. From ETSI EN-303 645: "Where a debug interface is physically accessible, it shall be disabled in software." This means that if a DEBUG interface exists, such as UART, JTAG, SWD, etc., it should be disabled in software. If the DEBUG function is intermittently required, it should be disabled by default. If not, it should be permanently disabled. However, TS-103 701 provides additional guidance, advising that only readily accessible DEBUG interfaces be accessible.

Accessibility: Plug and pray?

From ETSI TS-103 701: "Considering the level of security intended by ETSI TS 103 645 / ETSI EN 303 645, 'physically accessible' is defined as being readily usable with a standard interface cable. Using specific tools to physically access the interface (such as test probes) is not within the scope of the assessment." At Kiwa, this means that an interface is considered physically accessible if Dupont cables can be used for GPIO connections, as well as for many other standard interfacing cables and tools. For instance, JTAG cables are often used with tools like the Segger JLINK.

Battle story: Probing should be in scope

Even though ETSI considers testing probes out of scope, don’t assume that "hidden" interfaces on test pads provide security. Testing probes are inexpensive, and if you have a colleague with steady hands, even stiff wires will work. We once tested a device with a beautiful PCB, but without any markings on the silkscreen, featuring an NRF52832 chip. Using the readily available datasheet, pinout diagrams, and tracing the board, we found two tiny golden pads that seemed "interesting." With the JTAGulator, we identified the SWDIO and SWCLK from the chip and gained access. Security through obscurity is like hiding the cookie jar from kids—with enough time and dedication, they will find it, with all the accompanying consequences. My bet is on the dedicated kid who loves his "Lunettes."

Documentation: A benevolent evil

A common issue with cybersecurity standards is filling in the documentation correctly. Missing information or misinterpreting questions is very common. For provisions in section 5.6 on minimizing attack surfaces, only IXIT 15-Intf is needed. The IXIT is the "Implementation eXtra Information for Testing."

The assessment procedure involves three steps:

  1. Ensure all documentation is complete, and have two samples ready.
  2. Check if the documentation complies with the standard.
  3.  Confirm that the documentation aligns with the "real" situation.

The better the quality of the provided information, the smoother the testing process. The purpose of documentation is to allow assessment of the Device Under Testing (DUT). Testers need to understand the DUT fully. For this provision, interfaces are often forgotten or overlooked.

Some "fictional" excuses given:

  • "It’s not a DEBUG interface because it’s password-protected."
  • "It’s not a DEBUG interface because it only sends data."
  • "It has a proprietary connector."
  • "You need to jumper some pins."
  • "We forgot."

The last one is my favorite because small mistakes are just human nature. Additionally, most of the DEBUG information that may be emitted is intrinsically "security relevant." It’s better to provide more information and be slightly verbose than to risk the dreaded FAIL/INCONCLUSIVE result in the report.

Application: What can I take from this wall of text?
Alright, we’ve defined the interfaces and read through the provision. But what should you take from this information?

When working with a device, consider the following points from this provision:

  1. When the device is in production, does it need a DEBUG interface?
  2. If so, can you make it intermittently available and disabled by default?
  3. If it only outputs data, is it security-sensitive data?
  4. Have you filled in the complete documentation?

Conclusion: Connecting the dots

All interfaces that provide DEBUG functionality can—and likely will—be exploited by those looking for them, not all of whom have ethical intentions. This is why ETSI EN-303 645 takes interfaces seriously. DEBUG interfaces should be disabled in software either permanently or, if they’re intermittently required, by default. Designing secure devices is an art, and I hope you’ll embrace this form of artistry.