Your critical infrastructure bug won't be fixed and this is why

Water, electricity, transportation—all of them are critical infrastructures. In Germany, everything classified as part of a critical infrastructure has to conform to security and safety guidelines. I had some nightmares^Wexperiences with these in the past. And I decided to only work on projects classified as critical infrastructure if I could do defensive research, despite being a mostly offensive security researcher. This blog post outlines why offensive critical infrastructure research is a bad idea, and is also a long rant about an article that will be released in a German magazine on December 19th. Sorry for ranting!!!!1!11

Critical infrastructure security

Critical infrastructure is regulated and has to follow various certifications. Disclaimer, I'm not an expert on this. However, certifications are both good and bad:

  • Everything classified as critical infrastructure has to pass various tests, ensuring it is safe and secure.
  • Such tests are limited in scope and prevent the ability to roll out fixes in a timely manner.
Components might be installed and never changed for decades. This shouldn't be a problem in theory, because why should something tested to be secure suddenly become insecure?

Cryptographic algorithms tend to break over time. They rely on computationally hard problems but computation power increases and there could be new approaches to solve them more efficiently. Attacker capabilities change over time. Software-defined radios are affordable these days and suddenly everything transmitted over-the-air can be sniffed, modified, and injected. Underlying software contains unknown bugs that are discovered later. Suddenly, components within the network infrastructure become insecure and require updates. Just to provide a few examples.

In practice, rolling out something that is classified as critical infrastructure might take so long that it is already outdated when it goes live. 👻🎉

Imagine a system that was installed during the last 30 years. Now, a security researcher finds out that it can be attacked. The vendor of this system might be able to create a new generation of devices, re-certify everything, and so on. This already takes a long time. And even worse, system components might now be incompatible. But replacing everything at once costs so much that neither the vendor nor the customer could pay this. The update process will probably take another 10 years, keeping fingers crossed that there is no new security flaw meanwhile.

So, when approaching critical infrastructure security research, ask yourself:
  • If this component has flaws, how could it be fixed?
  • Who is going to pay for the fix?
  • Is the flaw so severe that it is worth fixing?
This obviously applies to other security research as well. But the answers to these questions are security nightmares when it comes to critical infrastructure.

German electronic health card terminals

In Germany, every public health patient has an electronic health card (eGK), and every doctor has a special permission card (HBA). Both are put into a card terminal, and there is an additional authorization step with a PIN. Manipulation of these card terminals might allow tampering with health data, invoices, or prescriptions. Even though these card terminals are just an end point within a more complex ecosystem, they're classified as critical infrastructure. Their protection level requires that they should withstand physical manipulation attempts without special equipment for 10 minutes.

The roll-out of this system wasn't smooth. Doctors were forced to join this system by making them pay additional costs if they refused to join. Oh, and someone decided to install non-replaceable cryptographic certificates on some of the devices that will expire after 5 years... 🙈

I agree that these card terminals should be classified as critical infrastructure. Imagine something like a network-based attack that simultaneously disables all of them. This would require processing everything on paper, slow everything down, etc. and be a risk to the health of German citizens.

Research request

In September 2020, I got a special request concerning those card terminals by someone who had a lot of knowledge about the German electronic health system, and a news reporter. I was the perfect person to contact because I already ordered a VPN connector for this system in the past to prove that the supply chain wasn't secure. I knew the system pretty well and I was already publicly known in this context. 👩‍💻

Some "hackers" who wanted to stay anonymous published an attack that allows physical manipulation of health card terminals almost a year ago. BSI and gematik, who are responsible for the security of the terminals, were in doubt that this attack was possible. The news reporter wanted an additional opinion if the manipulation could be done.

In my point of view, the offensive part of this research was finished. The attack documentation appeared to be valid. Thus, any additional research would be to enforce a fix for this known bug. Moreover, the person who contacted me claimed that bypassing the security of a card terminal would be sufficient for illegal drug dealing, killing selected people, and more. Based on this description it was a severe flaw that hadn't been fixed because BSI and gematik doubted plausibility.

I replied that the attack seemed to be plausible. Inside, the terminal didn't look that much different from all those IoT devices that I took apart before, lots of open contacts for debugging, some STM chip, and so on. Uuuh, maybe even some glitching attacks might be possible to extract keys??! However, the previously published attack required to bypass a protection against drilling, and claimed that plaintext data was sent over wires within the card terminal. Things that I couldn't confirm just from seeing a few pictures. 

Confirming the bug

The bug is as follows:
  • The older offline variant of the device has a serial port below a lid on the bottom. Everything else on the bottom is covered with foil to protect against drilling.
  • The newer online variant does no longer have the serial port. The manual claims the bottom lid is glued and cannot be opened but it can still be opened.
  • It's possible to bypass this foil by properly cutting it.
  • Then, the contacts of the doctor's card reader inside the terminal can be accessed, which transmit sensitive data in plaintext.
The news reporter ordered two terminals on eBay, the older offline variant and the online variant. Yeah, those devices with a "secure supply chain" can be purchased on eBay.

Each terminal has five seals. Yet, the case can be opened on the bottom without breaking any seal. Access to the mainboard is still protected. The protection against drilling is a foil with a very thin circuit structure. By inserting a 2.5mm high LED into the card slot, light shines through this foil and the structure becomes visible. I modified an animated rainbow LED for this experiment, and red light worked the best. 🌈 

I failed cutting the foil properly in the first attempt with the offline version. In the second attempt on the online version I took some more time, optimized the cut's position and length, and it worked well. This means that the foil can detect manipulation if the cut isn't precise but fails otherwise. Note that the model of the first attempt was an older generation that already had various debug outputs, and I used them to confirm my logic analyzer settings and observed a serial boot output. Moreover, the foils are made of different materials but both foils still have the same circuit structure and the mainboard has most components at the same positions, which helped me in optimizing the cut's position.

After succeeding with the second cut, I attached the logic analyzer to the card reader wires within the terminal that transmit plaintext data. However, even when rebooting the device multiple times, my logic analyzer didn't show anything interesting, including the analog output mode. Positioning the logic analyzer probes through the small cut isn't easy, this is why I repeated this step multiple times to exclude failures on my end. During the whole procedure I didn't insert any smartcard into the reader, which might've been required to extract signals out of it. I only saw a ground signal and maybe a clock but the clock could've also been due to the ground contact not being that stable. I didn't have any smartcards except my own banking and health insurance cards and I didn't want them on video—and I filmed every step to ensure reproducibility.

Facing reality

When discussing the last step, which was about intercepting and confirming the plaintext data with a smartcard, I rage quitted the project. Oooops 🤷‍♀️ I still provided my feedback for the article but didn't fully confirm the attack, even if the article states otherwise. And I opted out from submitting a CCC talk about this topic.

While confirming the terminal manipulation, I was talking to two people working in the German health system. Both confirmed that drug dealing based on terminal manipulation was almost impossible due to all the additional physical checks. Like, even if you have some digital prescription, you still need to get the drugs somewhere, everything is documented along the path, and can be traced back. Moreover, to intercept data in a doctor's office, it is much easier to install a web cam.

Luckily, humans are involved in all these processes, meaning that the attack wasn't as severe as in the initial description. Overall, the protection level that only considers manipulation attempts below ten minutes suddenly seemed to be legit. I started to understand why the issue didn't get fixed. I also informed the reporter very early in the process that manipulation of a single terminal wasn't as bad as described initially—but obviously this wouldn't make a great story.

As far as I know, there are two companies that sell these terminals in Germany. The manufacturer of the vulnerable terminal produces nothing else than this and sold 200k terminals in Germany and France. They're a GmbH (=LLC, Limited Liability Company), which means that if there is some failure for which they are accountable, the amount they have to pay is limited.

The cheapest fix against manipulation would be to add two more seals (resulting in seven seals, lol... 🦭🦭🦭🦭🦭🦭🦭). Then, the device could no longer be opened without voiding the seals. The overall costs of this? Let's assume some technician drives from terminal to terminal, documents the device was not manipulated, and then applies the seals. Maybe 50€ per terminal? That's like... oh... 10 million €. Just to confirm that no manipulation took place in the past and hoping that the seals are secure against manipulation as well. Oh, remember this detail with the pre-installed cryptographic certificates that expire in five years? The terminals will have to be replaced in two years anyway, as far as I know.

Yes, this is a valid attack. But there are much more critical components within this ecosystem, for example all the networked parts, encryption, and servers that store data.

So I wrote a mail that was along the lines of: "Okay, great, the attack probably works. I need some smartcards. And we have to inform BSI and gematik and tell them if and how to fix this, because I estimate the fix to cost 10 million €, paid by the German healthcare system or taxes."

And I got the following reply (by Thomas Maus, not the c't reporter Hartmut Gieselmann (CC), who asked me to clarify this... but he also didn't take any action afterwards): "Yeah, the fix will cost more like 50 million €. It doesn't matter since gematik is responsible for fixing this, they failed properly testing this terminal. The overall costs of this system were >4 billion € wasted so far, so this fix is rather cheap. Oh, and once they're finished checking the foil for cuts, we can tell them that there might be an additional foil on top to hide the cuts, and they need to check again."

This response crossed multiple ethical lines, like:
  • Wasting money for minimal security improvement.
  • Partial disclosure and hiding information about possible attacks.
In response, I quit the project, never signed the contract with the news magazine, didn't confirm the plaintext part of the attack, and sent back all the hardware. I'm still in the news with some article that confirms the attack excluding most of my criticism about the attack. "There is an attack but it really doesn't matter and the bug won't be fixed" isn't a fancy headline. Whatever. 🔥

Disclosure Timeline

  • September 27: Initial contact with c't.
  • October 26: c't reporter sent me the terminals.
  • November 13: I quit the project.
  • December 1: c't article draft.
  • December 17: c't reporter informed gematik about the findings.
  • December 18: c't reporter published heise article without informing me or gematik.
  • December 19: c't news magazine with article released.
Update: heise updated their article and states that they informed BSI&gematik about the anonymous hack on September 14. Back then the hack had been public for almost a year. The new relevant information, that I succeeded in confirming the hack, was not communicated to BSI&gematik until December 17. With regards to certifications of the terminals this makes a difference, since the existing attack was an anonymous hack while I confirmed all steps on video and added my credibility.

Responsible disclosure means that everyone needs to stay in the loop and that all vulnerabilities (not just a few selected ones) need to be disclosed to the vendor. The vendor should be allowed a decent amount of time to react to the findings. During my initial contact with gematik on December 2, I was quite surprised that they didn't know if and when the article would be published and if the reporter found someone who confirmed the anonymous hack or not.


  1. Hello Jiska,
    I'm the editor from c't. I don't want to wash dirty laundry in public, but I have to clarify some wrong statements in your post.

    1. We firstly informed Gematik, BSI and Ingenico about the hack mid September and had a very lively mail conversation since.
    2. The dispute you had was not with me or any other member of c't. It was with the other external security expert we involved in the project. He is not a member of c't or heise. You mainly disagreed with him about the interpretation of the consequences of the breach, not the breach itself.
    3. The quote in you blog post is not from me or any other member of ct. It might be from a conversation of you and the other external expert, which I was not involved in.
    4. We send you our whole article before release and discussed all the aspects and quotes you were involved in. We got your ok for the release. You were informed about the date and published your blog post one day earlier.

    Very astonished,
    Hartmut Gieselmann


Post a Comment

Popular posts from this blog

Always-on Processor magic: How Find My works while iPhone is powered off

Bluetooth → Wi-Fi Code Execution & Wi-Fi Debugging

Hunting Ghosts in Bluetooth Firmware: BrakTooth Meets Frankenstein