Insecure by design
Forget obscure hacks exploiting zero-day vulnerabilities. Some of the most insidious security flaws are hidden in plain sight. These are the “by-design” security issues – vulnerabilities inherent in a system’s design and implementation. This concept is particularly relevant as we further digitise the infrastructure which underpins so much of modern society.
A prime example of insecure design, relevant to the industry I work in, was highlighted at the Dec 2024 Chaos Computer Club conference…
BlinkenCity: Radio-Controlling Street Lamps and Power Plants A video presentation by Fabian Bräunlein and Luca Melette of Positive Security where they discuss (and demonstrate) the practicalities of remotely destabilising an electricity distribution network.
It is a must-watch for those who may design, select, install, or extend systems for use on the electricity distribution network.
TLDR: In Germany, power stations are required to reduce or curtail their output when they receive specific messages from the distribution system operator. This feature is designed for load-balancing energy across the grid. Unfortunately, the messaging protocol is an adaption of those commands that were once sent via hardwired Ripple Control Plant, and is completely flawed security-wise. These flaws allow malicious actors to control those systems (i.e. streetlights and power stations) connected to this messaging system.
Whereas Ripple Control Plants send messages down powerlines – which are harder (i.e. more dangerous) to tap into – the system used in Germany sends their messages over a wireless radio network. The attack, which is explained in the presentation, would require only a handful of strategically placed radio transmitters to maliciously control an estimated 20 gigawatts of generation/load Germany-wide, causing havoc on the European energy grid (brown-out, cascading failures, etc.). Insecure by design AND insecure through implementation.
How did this situation come to be?
Likely not through a single decision, but as a series of seemingly logical, but ill-informed steps that had the best of intentions;
- Customer: We have this system to switch streetlights remotely, but requires expensive hardware and is cumbersome. Can’t we just send those same messages via wireless instead?
- Vendor: Possibly. We have experience with Ripple Control Plants and wireless technologies, I’d say that making this work should be fairly straightforward.
- Customer: Perfect! Let’s make it happen.
Some time later…
- Employee 1: We need a way to remotely switch off all of the solar generators and battery storage systems connected to our network.
- Employee 2: We already have a system for switching streetlights. It’s been reliable for years. Why don’t we just use that?
- Employee 1: Is it integrated with our operational systems already?
- Employee 2: Yeah, and has been for the past two years.
- Employee 1: Perfect! Let’s make it happen.
Overlooked Security Risks
Of course, encryption was never the vendor’s concern. In their eyes, they are taking a well-established technology, one that has never been hacked before, and extending it to use wireless technology. They’re oblivious to the intricacies of how the technology could be used, and hence, they’re blind to the vulnerabilities they’ve baked into their product.
Customers, who are not wireless security experts, will have no way of assessing the system at a deep, technical level. They trust that the vendor has considered all facets and is supplying a product that’s fit for purpose. From their perspective, extending a cost-effective street lighting control solution into the realm of distributed energy control seems perfectly reasonable given the context.
Don’t fall into a similar trap
The ‘BlinkenCity’ issue won’t be unique to Germany. There are – and will continue to be – other systems, implemented by other customers, with inherent vulnerabilities baked into their design.
In these cases, it’s a matter of “an ounce of prevention is worth a pound of cure”. To avoid falling into these same pitfalls, ensure that the right stakeholders are involved at the right time – in the case of ‘BlinkenCity’, those who would have expertise in radio systems, cybersecurity, and the practical applications of the system within the business.
Even systems that seem “safe and reliable” in one application can introduce intolerable risks when used in another. Always seek the support of professionals to help you explore all probable risk scenarios, and to mitigate those risks that fall outside of your (and/or your organisation’s) risk tolerance.
In the case of “BlinkenCity,” the cat has been let out of the bag. German network operators now face a significant risk, one that will be exceptionally difficult to manage. This serves as a reminder: take the time to thoroughly understand the potential risks – and mitigate them – before your system becomes too entrenched to change.