TL;DR
- Seven of us descended to DEF CON 34 to support the Aerospace Village and, for the first time, the ICS Village.
- Attendees could land an Airbus or hack our industrial cocktail machines. We also delivered three talks covering electronic conspicuity devices, ARINC 664 flight control networks and programmable automation controllers used in critical infrastructure.
- Most of the hardware survived air freight. The flight simulator had a wobble, but taking it apart and putting it back together fixed it for reasons we still do not understand. Oh, and add a 6am run most mornings!
A perfectly normal amount of luggage
On Tuesday 4th August, 5 brave souls set off to the faraway climes of Nevada, bound for DEF CON 34. We had 9 cases of tech with us, a motley assortment of flight simulators, industrial control CTFs and plenty more.
We supported the ICS Village for the first time, reflecting our increased presence and expertise in utilities, shipping and manufacturing. As ever, we continued to support the Aerospace Village, which holds a place close to our hearts after helping get it off the ground in 2019.
Wednesday
Wednesday came early, with a cheeky 6am run to the DEF CON sign for three of us.
Two trusty colleagues arrived to bolster our numbers.
Supplies for our industrial cocktail machines were a must. What’s a cocktail machine without alcohol?
Thursday
Thursday came, starting with another 6am run, but this one was the first of the un/official DEFCON.runs, organised by KPH and AgentX as always. We had new T-shirts printed this time, including some for the wonderful organisers. There are a few left over, so if you are a keen runner in cyber, let us know and we might be able to get one to you. It was lovely to see runners returning, some wearing the swag we provided in previous years.
Thursday was also set up day for the Villages. After about 3 hours of reassembly and tweaking, our flight simulator sprang back into life. It doesn’t like being shipped by air cargo very much, which is ironic.
Here it is, performing a perfect 3-channel Autoland into London Heathrow 27R:
On Thursday evening we hosted the Auto ISAC. Cocktail machines were working overtime. The view from our suite was pretty good too
Friday
Friday came, starting with yet another 6am DEFCON run.
Back to the Villages to teach people to land an Airbus and get them to complete our cocktail-making OT CTFs:
The flight sim had other ideas. Despite having worked perfectly the day before, it decided to throw a wobbly. After extensive troubleshooting from Cybergibbons and me, one of the USB hubs seemed to be struggling to provide sufficient power. Reducing load seemed to have an effect, so we were trying to work out which components we could manage without, whilst still setting up an approach. We concluded that doing without the ECAM was OK, but losing the MCDU and MCP was a no-no.
Anyway, we put it all back together, at which point everything sprang back into life. No, we don’t know why.
Panic over, so we fired up the cocktail machine and made a drink.
Friday also saw us do our first talk. Adam and I presented vulnerabilities that we and Joe Lovett had found in systems to help light aircraft avoid each other.
Hacking Electronic Conspicuity Devices -or- Making Light Aircraft Fly into Conflict
Commercial aircraft have Traffic Collision and Avoidance Systems, or TCAS, to ensure they don’t fly into each other, but these are very expensive systems. How do general aviation aircraft find a way to avoid each other?
Enter ‘Electronic Conspicuity’ devices: small, light and cost-effective sensors to detect other aircraft and alert general aviation pilots before they can be seen by the naked eye.
Unfortunately, in the rush to improve flight safety and situational awareness in general aviation, cybersecurity has taken something of a back seat. As a result, some of these EC devices have trivial and not-so-trivial security flaws. In some cases, it is possible to delete Traffic Advisories and/or give an incorrect Resolution Advisory, bringing planes into conflict with each other, rather than ensuring they stay safely apart.
We’ll get this blogged and written up soon. Unfortunately, we keep finding new vulnerabilities every time we look at these devices, which is slowing us down!
Friday night came, with us hosting the Aviation ISAC.
Saturday
Another 6am DEFCON run came and went.
Back to the villages to make more cocktails and land more planes:
Saturday also saw another talk. This time Andrew and Adam presented about a reverse engineering project they had carried out on a flight control testbed:
Hacking AFDX or Not; A Primer for Flight Control Systems Security
One of the challenges of independent aeroplane cyber research is the lack of availability of recent hardware; avionics, LRUs and anything from the aircraft control domain is insanely expensive, even when used. Access to retired airframes therefore represents the state of the art from 20+ years ago.
We have been stuck with researching older ACD protocols such as ARINC 429 and 629. However, through a fortuitous stroke of luck, we were given access to an ARINC 664 or ‘AFDX’ environment on a test bench recently.
The protocol was developed by Airbus for the A380, but is also found on the B787, A350 and is increasingly being implemented on new designs. Avionics Full-Duplex Switched Ethernet / ADFX will be much more familiar to IT folks than the earlier protocols, having much more in common with the OSI reference model. But, it has crucial differences which requires a steep learning curve. This talk was a primer for interfacing with AFDX and the various security and safety features that it offers.
Sunday
Sunday came, with yet another DEFCON run.
Landings and cocktails happened again.
The final talk of the event for us was about PACs – a mash-up of a PLC and an OT gateway. Adam and Sam did a great job showing how they recreated a Triton style implant in these popular ICS controllers:
Two NICs, Zero Trust: Pulling Apart a PAC Buried in Critical Infrastructure
Imagine you get called up by a large CNI operator – “We have these devices, they’re all over our outstations and they sit between our most critical OT trust zones”, would you want to take a look?
We did what any curious gremlins would do: we bought the hardware, built a bench, and started pulling at every thread. This talk tells the investigation as it actually happened, starting with architecture and documentation, moving through firmware analysis and protocol dissection, and ending with full pwnage at the firmware and application layers.
Along the way we found a security model that felt frozen in the 2010s: weak trust boundaries, unauthenticated reconfiguration paths, and cryptographic protections as strong as wet cardboard. The point of the talk is not “bench testing is cool.”; It’s how to take a standard CNI concern into a hardware-led investigation that uncovers flaws a network-only pen test will miss.
Attendees left with a practical workflow for assessing OT devices at scale, a mental model for deciding when to go from docs to firmware to hands-on testing, and a clear picture of how apparently boring PACs can become high-value footholds inside critical infrastructure. The talk included nation-state-level firmware backdoors and research artefacts along the way.
Wrap up
By the end of Sunday, the jet lag, long days, late evenings and early runs had caught up with us. It had been a tough few days, but we would not have missed it for the world.
It was great to support the villages, maybe next year we will be able to support the maritime village too.
Huge thanks to Adam, Sam, Andrew, Paul, JP and Mark for making it all happen.
More talks, more research, more unnecessarily large cases of hardware. Bring it on DEF CON!
