Category: EDITORIAL

EDITORIAL, INSIGHTS | May 22, 2024

Transportation Electrification Cybersecurity Threatscape

By Kevin Harnett

World-Wide Electric Vehicle (EV) Charging Infrastructure Trends

The global push to meet rising EV adoption with sufficient EV smart charger infrastructure is astoundingly challenging. Bloomberg estimates the global charging infrastructure market opportunity to be $1.9T between 2022 and 2050. That opportunity will be seized upon by a host of organizations large and small, public and private. From EV fleet depots to fast charging stations along highways, parking garages, smart chargers for employees, and home chargers, EV supply equipment (EVSE) are already becoming a common sight.  The graph below depicts the world-wide cumulative global public charging connections:


Source: https://about.bnef.com/electric-vehicle-outlook/

World-wide trends of transition and adoption of EVs is due to climate control and carbon pollution-free electricity sector goals and policies that are being mandated over the coming years around the world, such as:

  • In the USA, Executive Order 14057[1] restricts all government agencies’ new acquisitions of light-duty vehicles to only EVs by 2027 and mid- and heavy-duty vehicle acquisitions to only EVs by 2035.
  • In California, Executive Order N-79-20[2], ends sales of ICE passenger vehicles and trucks by 2035[3].
  • The EU and UK have banned sales[4] of new combustion engine cars from 2035.

The Battery Electric Vehicle (BEV) and charging infrastructure landscape is rapidly evolving technologically and operationally in a market where cost and time-to-market are prioritized higher than security[5]. Technologies used to build the BEV ecosystem suffer from well-known cybersecurity issues, which expose vulnerabilities and risk. Current charging stations are operated as build-and-forget devices that are highly exposed and network connected, with cyber and physical vulnerabilities which pose a great challenge to the ecosystem, including bulk electric and distribution system stability, with limited current threat mitigation.

Securing such an advanced, fully connected, and heterogeneous supply grid will take a similar effort to the Information and Communication Technology (ICT) sectors that secure webservers and cloud infrastructure, and this would also include mitigations around the cyberphysical vulnerabilities unique to the BEV ecosystem.

HPC standards for the Megawatt Charging System (MCS) are being developed by the CharIN (Charging Interface Initiative eV.) international standards organization[6].

Modern electrified transportation vehicles will require a HPC infrastructure. Cybersecurity vulnerabilities in HPC systems operating at very high levels of power pose a serious cyberphysical threat to the new electric vehicles and supporting infrastructure, but also to the electrical grid (bulk and distribution) that supplies power to the HPC systems. These cyberphysical vulnerabilities will require focused, skillful mitigation.  

The potential consequences of a successful skillful attack on a BEV or ESVE system could produce remote code execution on BEVs or EVSEs, physically damaged vehicles or chargers, local or regional power outages, and larger coupling effects across countries from induced cascading failures.

IOActive’s Vehicle Cybersecurity Vulnerability Findings

In-vehicle technology is a top selling point for today’s car buyers[7]. What was once simply a “connected vehicle” is now increasingly more feature-rich, with software systems like self-driving and driver assist, complex infotainment systems, vehicle-to-other communication and integration with external AI. More than ever, all of this exciting technology turns modern vehicles into targets for malicious cyberattacks such as ransomware. It is imperative that automotive manufacturers take additional action now to infuse cybersecurity into their vehicles and mitigate potential threats. Moreover, EVSE manufacturers and utilities need to increase efforts to manage their highly impactful risks.

IOActive’s pioneering vehicle cybersecurity research began with the ground-breaking 2015 Jeep hack[8] that evolved into our ongoing vehicle research that has included commercial trucks, EVSE, and autonomous vehicles.

For over a decade, IOActive has been publishing original research blogs and papers:

EVSE Cybersecurity Incidents Are Increasing

The growing popularity of Electric Vehicles (EVs) attracts not only gas-conscious consumers but also cybercriminals interested in using EV charging stations to conduct large-scale cyberattacks for monetization purposes, espionage attacks, politically motivated attacks, theft of private/sensitive data (e.g., drivers’ data), falsifying EV ranges, and more. EVSEs, whether in a private garage or on a public parking lot, are connected IoT devices, running software that interacts with payment systems, maintenance systems, OEM back-end systems, telecommunications, and the smart grid. Therefore, charging stations pose significant cybersecurity risks.

Early incidents of cyberattacks on charging stations include the following:

EVSE cybersecurity incidents are on the increase. Links to information on several other cybersecurity hacks, as well as further reading regarding EVSE cybersecurity, are listed at the end of this blog post.

EVSE cybersecurity risk and threat scenarios include a wide variety of potential issues:

  • EVSE malware attacks threatening the integrity the electric grid/transportation network, leading to widespread disruptions in power supply and electric grid load balancing concerns
  • Ransomware attacks
  • Leakage/manipulation of sensitive data (e.g., PII, credentials, and payment card data)
  • Physical attacks to disable EVSEs, steal power, or and infect EVSEs with malware via accessible USB ports
  • Authentication RFID, NFC, or credit card chip attacks that could deny EVSE charging sessions or perform false billing
  • EVSE or grid Denial of Service attacks, impacting drivers’ ability to recharge during a hurricane or wildfire evacuation
  • Firmware/software update attacks, causing access disruption to the necessary cloud services for payment processing
  • Bypassing bootloader protections, which can allow attackers with physical access to gain root access into EVSEs to launch attacks on the backend infrastructure while appearing as a trusted device
  • An EVSE attack through the charging cable could compromise an EV, causing fire or other damage

IOActive’s Electric Vehicle Charging Infrastructure Vulnerability Findings

Over the past five years, IOActive has conducted several EVSE cybersecurity penetration testing engagements for automotive and commercial truck OEMs/suppliers and EVSE vendors. Examples of IOActive’s electrification penetration testing include assessments of Level 2 EVSEs, DC Fast Chargers (DCFCs), Open Charge Point Protocol (OCPP)/cloud services, front-end/back-end web applications, onsite network configuration reviews, and EV vans.

For the past year, IOActive has led an international EVSE standards working group which has developed a public EVSE Threat Model White Paper that identifies EVSE risks, vulnerabilities, and design flaws.  The paper also includes threat scenarios ranked based on magnitude, duration, recovery effort, safety costs, effect and confidence/reputation damage. This White Paper can be shared with industry members upon request.

IOActive Welcomes Future EVSE Cybersecurity Discussions with Industry

We would like to continue to support the key industries impacted by the transition to electrified vehicles. Much of the most detailed work that we have done cannot be shared publicly. We welcome those with a need to know about the risks of and mitigations for BEVs and EVSEs to engage with us for a briefing on example extant vulnerabilities, technical threat models, threat actors, consequences of operationalized attacks, and other threat intelligence topics, as well as potential mitigations and best practices.

If you are interested in hosting IOActive for a briefing, and/or would like copies of the aforementioned presentations or white paper please contact us.

Get The White Paper

EVSE Cybersecurity Incident References:

Suggested Reading:

[1]https://www.whitehouse.gov/briefing-room/presidential-actions/2021/12/08/executive-order-on-catalyzing-clean-energy-industries-and-jobs-through-federal-sustainability/
[2]https://ww2.arb.ca.gov/resources/fact-sheets/governor-newsoms-zero-emission-2035-executive-order-n-79-20
[3]https://www.gov.ca.gov/wp-content/uploads/2020/09/9.23.20-EO-N-79-20-Climate.pdf
[4]https://www.europarl.europa.eu/topics/en/article/20221019STO44572/eu-ban-on-sale-of-new-petrol-and-diesel-cars-from-2035-explained
[5]https://www.iea.org/reports/global-ev-outlook-2023/trends-in-charging-infrastructure
[6]https://www.charin.global/
[7]https://finance.yahoo.com/news/connected-vehicle-technology-becoming-key-140000573.html
[8]https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

EDITORIAL, RESEARCH | April 25, 2024

Bits to Binary to Bootloader to Glitch: Exploiting ROM for Non-invasive Attacks

By Tony Moor

In this paper, we explore how ROM can be leveraged to perform a non-invasive attack (i.e., voltage glitching) by a relatively unsophisticated actor without a six-figure budget. We begin by explaining what ROM is, why it is used, and how it can be extracted.

What exactly is ROM?

Put simply, Read-Only Memory (ROM) is a type of Non-Volatile Memory (NVM) that is constructed as physical structures within chips. The structures are patterned as ones and zeroes on one, and only one, of several layers of the chip. Why just one? Cost. ROM is real hardware, and making any hardware changes in the layout of a chip is very expensive.

The fact that ROM is physically encoded in a chip makes it uniquely reliable and thus appropriate for critical functions, such as boot code execution. ROM is infinitely more reliable than NVM that relies on an electrical charge, like Flash.

The following table provides a brief overview of memory classes.

Table 1. Summary of memory classes, type, and uses

How can you extract data from ROM?

If there is no protection on the device (i.e., it is embedded on a development board), then it is simple to access the data and dump it as a binary (.bin) file. By doing so, we have essentially extracted the final code, as opposed to the raw bits. This means that the code is in an understandable format (no need to decrypt or descramble) and can be analyzed using standard software reverse engineering tools, like IDA Pro or Binary Ninja, to isolate a weakness in the bootloader.

If the ROM is protected, then there is the option to physically deprocess sample chips (more on that later) and extract the raw bits as ones and zeroes. The process is very skill dependent; however, it is possible to carry out on a shoestring budget depending on the age of the chip technology. In some cases, only a polishing wheel, a handheld polishing jig, and an optical microscope are needed.

Reading out the raw bits is only the first step of the process, as these bits need to be further analyzed and manipulated to properly understand the code. The complexity of reverse engineering will vary depending on the following:

Is the ROM scrambled?

Scrambling is when the data is ‘mixed-up’ at the periphery of the memory block. In this case, it is enough to study the peripheral circuitry to make sense of the data.

Figure 1. Normal (unscrambled) output
Figure 2. Scrambled output

The ordering may also vary byte-to-byte, making reverse engineering more difficult.

Is the ROM encrypted?

Encryption is far more difficult to reverse engineer because the data is routed out of the memory and into the CPU logic, which is usually vast and, on its face, random. The data will be routed to the decryption circuitry, which may only be a few dozen logic cells.

Finding the decryption circuitry in a sea of one hundred thousand logic cells with no direction on where to start is an extremely difficult task. It may be necessary to reverse engineer the entire CPU logic; however, there are isolation techniques like thermal or photon emission that can help identify a specific area of interest on the chip. Using such techniques, the chip is instructed to repeatedly decrypt data while the entire chip is monitored for heat or light emissions, revealing the area of the chip that is performing the decryption. This smaller area of the chip then becomes the focus of reverse engineering.

Is the ROM both scrambled and encrypted?

If the ROM is both scrambled and encrypted, recovering the data will require analysis of the addressing logic and reverse engineering some if not all of the CPU logic. If the raw data is encrypted, the physical bit pattern will look the same, whether it is scrambled or not.

How do you deprocess a chip?

Deprocessing is the physical removal of layers from a finished chip using chemical and mechanical techniques. The process is necessarily destructive and can be used to remove one or more layers, depending on the target.

Consider the following example chip:

Figure 3. Example chip cross-section showing metal layers and transistors

We can see that the chip is constructed of many layers of copper circuitry, all embedded in an insulator (glass-type material). Transistors are literally the building blocks of digital components and are fabricated on the silicon substrate at the bottom of the chip. Therefore, the ROM transistors will be located on the bottom as well. The raw bits we are looking for (the ROM encoding layer) will likely be at the Contact, Metal 1, or Via 1 layer (between Metal 1 and Metal 2), but we won’t know for sure until we start destroying some chips.

If we have the time and sufficient samples, we can start by removing all of the layers from one chip in order to analyze the floorplan. Based on this analysis, we can map out where the memories are located and even identify what types of memories are present, such as Flash, SRAM, DRAM, or ROM. This will help identify the specific area of the chip to focus on when attempting to extract the raw bits. In addition, we could also cross-section a chip at the location of the ROM to help determine which layer contains the bit encoding to guide our work.

If we don’t have the time or the samples, we can just go ahead and carefully deprocess a single chip, and at some point, the ROM bits will appear. But if we deprocess too far, we will go past the bit encoding layer and lose the data.

For our work, we will use the most basic and fastest technique—mechanical polishing. While many argue that mechanical polishing is the most effective method for deprocessing chips, it is also the most skill dependent.

We can polish in several ways (in order of increasing sophistication and cost):

  1. Manual finger polishing: The decapsulated chip is placed on the fingertip and polished on a static plate or piece of glass.
  2. Turntable finger polishing: Similar to manual but uses a rotating platen to expedite the polishing process (and eliminate Repetitive Strain Injury!).
  3. Manual polishing with fixture (jig): Uses a rotating platen in conjunction with a polishing fixture that can be adjusted to compensate for non-planarity.
  4. Semi-automated polishing: Uses a purpose-built system with control over:
    1. Platen speed
    1. Sample planarity
    1. Force applied to sample
    1. Sample rotation (in addition to platen rotation)

In this example we used the third approach because a turntable accelerates progress, and a polishing jig offers fine angle control. Additionally, the manual polishing table and jig, as well as the abrasives involved, are relatively low-cost items, keeping the approach within reach of a skilled and motivated hobbyist.

Figure 4. A decapsulated chip mounted to the polishing stub
Figure 5. The stub attached to the polishing jig while being polished

Determining when to stop polishing (end pointing) is difficult; however, when we hit the ROM encoding layer, we should see some kind of pattern under an optical microscope, even at 5x magnification.

The image below was taken at 20x magnification, and we can categorically say that we have reached the right layer.

Figure 6. Corner of ROM exposed at bit encoding layer

The bits appear as white dots from above, because they are bullet-shaped Tungsten interconnects, a little like the contacts shown in the following cross-section images:

Figure 7. ROM cross-section fully processed (left) and deprocessed to the bit encoding layer (right)
Figure 8. Sample area for initial visual inspection

We can see from a very high-level visual inspection that the ROM cannot possibly be encrypted, due to the distribution of ones versus zeroes. If the data was properly encrypted, then the distribution would appear random; however, a visual assessment is sufficient to confirm a lack of entropy without the need to formally calculate[1] it with binwalk[2] or another tool. We can conclude that although the data may be scrambled, it is not encrypted. There is enough evidence to tell us that if we extract the raw bits, we can derive the addressing to then get us back to an understandable binary.

For now, we don’t need to carefully analyze the addressing circuit; all we need is to determine if there is any scrambling in the addressing logic. We can do this visually.

Figure 9. Sample area of decoding/addressing circuit (bottom)
Figure 10. Sample area of decoding/addressing circuit (left)
Figure 11 Sample area of decoding/addressing circuit (between blocks)

When we isolate a small area of the decoding/addressing circuitry at any point (bottom, left, or between the blocks), it is perfectly repeated. This proves that the ROM is not scrambled, and all we need to do is to work out how the bits are read to recreate the full binary. That, and extract the raw bits, of course.

No Scrambling 😊

No Encryption 😊

How do you extract the raw bits?

It is preferable that we automate the extraction process, as the ROM’s capacity is 16 KB (128,000 single bits), which is far too much to extract manually. First, we must determine if our optical images are good enough to reliably extract the raw bits. If not, we may need to use a Scanning Electron Microscope (SEM) to obtain higher resolution, higher contrast images.

Figure 12. Sample area of raw bits imaged optically (top) and by SEM (bottom)

Clearly there is a huge difference in resolution and, more importantly, contrast between the two types of images. It’s obvious that using SEM images would expedite the extraction process, but let’s see if we can use the optical images and do this on a shoestring budget.

First, we need to optimize the optical test image with photo editing software to maximize our chances of success. A good start is always to use the filters in Photoshop such as ‘Noise – Despeckle’ and ‘Noise – Dust and Scratches.’ The final step would be to manipulate the levels to maximize the contrast.

Figure 13. Screenshots showing Adobe Photoshop noise filters being applied
Figure 14. Sample area of raw bits imaged optically and filtered/optimized

Perhaps quite surprisingly, simply by filtering and adjusting the levels of the optical image, we can almost end up with the same result as with the SEM.

Figure 15. Plot of unfiltered optical image
Figure 16. Plot of filtered optical image

From this simple test, we can conclude that any effective tool will be capable of reliably extracting the raw bits from our optical images.

Figure 17. Single block with bit extraction grid overlaid
Figure 18. Zoomed view of bits with extraction grid overlaid

Commercial software is available for semi-automated ROM bit extraction. The software measures the brightness of the area around the line intersections and compares that against a user-defined estimate for both a one and a zero. The software then assigns values to each area in which a bit exists, then exports the values to a text file. Below is the text extracted from this small piece of ROM. This is a fraction of one of 64 sections within the memory array, so some time is required for a full extraction. There is certainly an AI/ML opportunity here to expedite the process.

After repeating the process many times, we have the entire ROM in our hands, and we can move onto the next step: deriving how the bits are addressed. At this point, we will have a usable binary to work with in IDA Pro or Binary Ninja so we can understand the boot process and find some potential areas of weakness we can glitch.

Bits to Binary

As this is a chip with a known vulnerability, it was possible to dump the entire ROM via JTAG. We will use this dump to help us do two things:

  1. Deduce how the ROM is addressed
  2. Compare our physically extracted ROM with the JTAG dump to validate our process

To illustrate the analysis of our physically extracted dump, we will use the higher-resolution SEM images we acquired after the optical images were taken.

Let’s start by looking at the electrical dump of the ROM. The following output is the beginning and end of the ROM .bin, with the end looking very much like a checksum. We know this is commonly used by this manufacturer, so after many zero bytes, there are two bytes of data at the very end of the file.

Figure 19. Hex dump output of the start (top) and end (bottom) of the ROM .bin
Figure 20. Bottom section of ROM SEM stitch with checksum bits annotated
Figure 21. Close-up showing that the three bits are not in the same row. One on the first row, then two on the second row (the red line is perfectly parallel)

From the fact that we have the two-byte checksum (0105) in hex, and that the corresponding raw bits (0000 0001 0000 0101) are not in a linear pattern, then we must assume that there is some flipping/mirroring happening on the bit addressing. The fact that the bits are split over two rows also gives us a clue.

Now our checksum is beginning to make sense. With a checksum of 0105 (0000 0001 0000 0101), there must only be one way to read it. Essentially, we are looking for how the three ones are addressed.

First, we can see that the three bits are all on the same bit column, so we can ignore the rest. It makes things easier to visualize by annotating all of the bit columns, then highlighting the only column (column 0) we care about in yellow. The values are now much easier to read by eye, and we can see the direction in which they are read by the memory array.

Figure 22. Right side of checksum area annotated with columns, binary values, and hex
Figure 23. Entire width of checksum area annotated with columns, binary values, and hex

We now see that 0105, albeit not in a logical order for a human. There is one question mark remaining: Do we assume that we read the left side in reverse first (01) followed by the second (05)? There we have a simple 50% chance of being correct, and to find out, we can apply that to the more densely populated areas of ROM.

Figure 24. Opposite end of ROM annotated with read order, binary values, and corresponding hex

The portion of ROM above shows the hex value along with the raw binary for the two-word width of the ROM array. The colored arrows illustrate the direction in which the bits are read from the .bin and how they are read from the raw bit image. The following is a closer view of one byte, where blue bits are logical ones and yellows are logical zeros:

the end of the ROM, annotated with read order and binary values

Finally, a binary!!!

The following image contains some dumped bytes from the target. This can be later be opened in the reversing tool of our choice, and after some preparation work, we can begin reverse engineering and identifying the potential weaknesses. In this case, as some readers might know, the target sample has a known vulnerability that can be exploited via fault injection. This vulnerability can allow an attacker with physical access to the device to retrieve the entire contents, even if the chip has been locked down.

Figure 26. Some bytes dumped from the target chip
Figure 27. Part of the boot process where CRP values are read and are controlling access to the debugging interfaces

Overall Conclusions

  • While a chip with a known vulnerability was used in this case study for comparative purposes, the same techniques can be applied to a chip without this vulnerability
  • The electrical version of the ROM dump matched 100% with the physically extracted version
  • Physical ROM bit extraction is skill-dependent, but can be carried out using a relatively basic toolset such as:
    • Basic polishing turntable
    • Handheld polishing jig
    • Diamond abrasives
    • Optical microscope
  • ROM binary extraction is dependent on:
    • Existence of encryption
    • Complexity of scrambling
    • Patience!
  • ROM binary analysis and isolation of glitching/fault injection points is possible
  • Electrical and electromagnetic fault injection techniques are skill- and chip-dependent; however, the bar of entry is relatively low (hundreds to thousands of dollars)

[1] https://resources.infosecinstitute.com/topics/cryptography/entropy-calculations/
[2] https://github.com/ReFirmLabs/binwalk

EDITORIAL, RESEARCH | March 28, 2024

Hack the Sky: Adventures in Drone Security | Gabriel Gonzalez

By 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.

EDITORIAL | March 1, 2024

Opinion: AGI Influencing the Secure Code Review Profession

By Gunter Ollmann

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!

EDITORIAL | December 19, 2023

Navigating the Cybersecurity Threatscape of Today’s Airports

By Kevin Harnett

Everything is ‘Connected’ in Today’s Modern Airports

Cybersecurity in global aviation is increasingly dependent on vulnerabilities in Information Technology (IT) and Operational Technology (OT) systems. The definition of OT systems in this context is defined as hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves or pumps. OT systems are much less organized and are rarely monitored as closely as conventional IT networks. Airports use several critical OT systems, including baggage handling, airport refueling systems, runway lights, building management systems, and supervisory control and data acquisition systems (SCADA)/industrial control systems (ICS).

At most modern airports, there are many cyber-physical security (CPS) challenges to be met, and airport CPS systems fall into three broad categories, each managed by means of network-connected digital controllers:

  • OT Systems – baggage handling systems, building management systems (mechanical, HVAC, electrical systems, lighting, alarms, and sensors), SCADA/ICS, airport refueling/SCADA systems, Approach Lighting System (ALS), Instrument Landing Systems (ILS), electronic baggage tags, etc.
  • IT Systems – video security surveillance systems, access control/badging, contactless mobile payment systems, barcode systems, license readers/parking lots, etc.
  • Ground Vehicles – de-icing trucks, Aircraft Rescue and Firefighting (ARFF) trucks, heavy-duty electric trucks, Electric Vehicle Supply Equipment (EVSE) chargers, snowplow trucks, remote-control airport tugs, Automotive People Movers (APM), Automated Guideway Transit (AGT), Personal Rapid Transit (PRT), automated shuttles, autonomous vehicles, etc.

Today’s Cybersecurity Threats at Airports is Increasing Exponentially

Persistent cybersecurity threats against the aviation sector pose a danger to world airport travel and safety, including unidentified malicious cyber actors who have specifically targeted the U.S. aviation sector over the past few years. Aviation entities have frequently reported incidents such as increased interactions with known malicious foreign IP addresses, phishing emails impersonating legitimate companies, brute-force attacks, and attempts to install backdoors on victim networks.

This accumulation of incidents, which include the following recent examples, underscores the ongoing threat to the aviation sector and the unacceptable risks associated with delay or inaction:

Date(s) Incident
May 2021 Society International Telecommunication for Aeronautics (SITA), a telecommunications and IT provider used by approximately 90% of airlines, was the target of a cyberattack, in which threat actors stole over two million records. Affected entities included Air India, Singapore Airlines, Thai Airways, Finnair, Cathay Pacific, United, Air New Zealand, and others.
September 2022 An unidentified cyber actor conducted a brute force cyberattack targeting an identified US airline. This cyberattack originated from Russian IP space and caused airline employees to be locked out of their accounts.
October 2022 US airport websites suffered a cyberattack, and pro-Russian hacking groups listed multiple U.S. airports as targets.
October 2022 A pro-Russian criminal group named KillNet claimed to be behind a significant distributed denial of service (DDoS) attack that impacted several major airports in the United States. DDoS attacks can cripple online services and affect their availability to consumers if the company running those services doesn’t take the appropriate precautions. The group that claimed responsibility for this latest attack carried out similar attacks in the past six months in Europe. The websites of numerous airports were affected, including Atlanta, Los Angeles, Chicago, Orlando, and Phoenix.
October 2022 FireEye has reportedly observed at least 24 different advanced threat actor groups targeting various aspects of the aviation and aerospace industries. These include aerospace and defense parts wholesalers, aerospace products and parts manufacturing, aircraft engine and parts manufacturing, guided missile and space vehicle manufacturing, and industrial and military computer system manufacturing. The majority of these groups were Chinese nexus state-sponsored threat actor groups.
May 2023 Personal information was compromised in a breach at third-party vendor pilotcredentials.com, including name and social security number, driver’s license number, passport number, date of birth, Airman Certificate number, and other government-issued identification numbers, according to breach notifications from the airlines.
September 2023 State-sponsored threat actors have exploited a US aeronautical organization, using known vulnerabilities in Zoho ManageEngine software and in Fortinet firewalls. The organization has not been named, but a statement by US Cyber Command said the attack illuminated “Iranian exploitation efforts. it also said the organization was under attack by “multiple nation-states.”

In a September 2022 article titled “Top Cyber Threats Faced by the Aviation Industry,” SOCRadar reported that the aviation industry faces a landscape of cyber threats that has constantly evolved and posed new challenges for airports and airlines. The article noted that airport websites across the country were the target of Distributed Denial-of-Service (DDoS) attacks last year that temporarily shut down access to several sites, while ransomware attacks and data breaches remained a majority of incidents impacting the industry since 2020.  

In recent years, cyber incidents in the aviation industry have been reviewed within the context of events monitored by Eurocontrol, a pan-European, civil-military organization dedicated to supporting European aviation, who publish the EATM-CERT (European Air Traffic Management Computer Emergency Response Team) Aviation Cyber Event Map. The data in this map has led to the following findings: 

  • 52 attacks were reported in 2020, and 48 attacks were reported in 2021. 50 attacks were reported through the end of August 2022, with cyber incidents reaching the previous years’ totals in just eight months.
  • The most seen attack types in the last three years (2020, 2021, and 2022) are ransomware (%22), data breaches (%18.6), phishing (%15.3), and DDoS (%7.3).
  • In addition to civil aviation attacks, eight military-related incidents were reported, with some focused on cyber espionage and data theft. Two of these attacks were carried out with ransomware, two with malware, and one with a backdoor.

Attack types targeting the aviation industry and their distribution are enumerated in the following diagrams.

Figure 1. Attack Types Targeting the Aviation Industry
Figure 2. Distribution of Attack Types Targeting the Aviation Industry

TSA’s New Cybersecurity Requirements Regulation for Airport and Aircraft Operators

The TSA has taken emergency action in response to the increased threats and vulnerabilities at airports and airlines, issuing a Joint Emergency Amendment (EA) 23-01 Cybersecurity – Performance-Based Measures on March 7, 2023 for all world-wide Category I and II airports.

In summary, the EA 23-01 requirements include:

  1. Designate Critical Systems (e.g., baggage handling systems, airport re-fueling systems) and submit certain identifying information to TSA
  2. Develop and implement a Cybersecurity Implementation Plan (CIP) for TSA approval that demonstrates how the regulated entity applies or will apply four performance-based cybersecurity measures to each designated Critical System:
    • Network Segmentation – Develop network segmentation policies and controls to ensure that operational technology systems can continue to safely operate in the event that an information technology system has been compromised, and vice versa
    • Access Control – Create access control measures to secure and prevent unauthorized access to critical cyber systems
    • Continuous Monitoring and Detection – Implement continuous monitoring and detection policies and procedures to defend against, detect, and respond to cybersecurity threats and anomalies that affect critical cyber system operations
    • Vulnerability Patching – Reduce the risk of exploitation of unpatched systems through the application of security patches and updates for operating systems, applications, driver and firmware on critical cyber systems in a timely manner using a risk-based methodology.
  3. Develop and implement an annual Cybersecurity Assessment Program (CAP) that proactively assesses Critical Systems to ascertain the effectiveness of cybersecurity.

For the purposes of this EA, TSA defines a Critical System as any IT or OT system used by the airport or aircraft operator that, if compromised or exploited, could result in operational disruption incurred by the airport or aircraft operator.

IOActive provides services for customers that would assist in meeting the EA 23-01 cybersecurity requirements, such as penetration testing (white-box, gray-box, or black-box), vulnerability assessments, red/purple teams, vulnerability scanning, asset inventory verification, reverse engineering, code reviews, and cybersecurity architecture reviews.

Conducting Cybersecurity Assessments at Airports

Normally when we think of Airport Security we’re thinking about the physical aspects. Everyone has gone through the body scanners, metal detectors, taken their shoes off, opened their bags for a search, accidentally packed 4oz. of toothpaste, etc. However, when examining the cybersecurity ecosystem of an airport there is also a lot to learn about that particular environment.

  • Vulnerability Assessments: Instead of just a traditional scan of a website, when doing a full vulnerability assessment of an airport, we can learn a lot about asset management and how the digital attack surface is shaping up and changing over time.
  • Red Teaming: Really thinking outside of the box of how a set of attackers can breach an airport in various ways is important to understand where they are weak. From SCADA systems to bag management applications, airports provide a very unique set of challenges for a modern red team.
  • Purple Teaming: A proper feedback loop between red team findings and a team responsible for defending the airport is critical to make sure it is not just another PDF report of findings that don’t get addressed. Enabling threat hunting with meaningful data purpose fit for airports is invaluable for teams with this unique set of challenges.

Over the past few years, IOActive has conducted extensive cybersecurity engagements at critical world-wide airports, such as:

  • European Airport: IOActive penetration-tested “representative” baggage handling and building management systems, as well as an Industrial Control System (ICS) security monitoring system and created a Test Specification to test the “Live”  equipment
  • US Airport:  IOActive conducted a Security Architecture review of a major SCADA system before it was installed and major vulnerabilities were found in the remote maintenance devices.
  • US Airport: IOActive using the Department of Homeland Security (DHS) Cybersecurity Evaluation Tool (CSET), conducted a risk assessment on baggage handling systems and vulnerabilities were found in the technician’s authentication to the equipment
  • US Airport: IOActive assisted the airport to develop a Cybersecurity Implementation Program (CIP) and Cybersecurity Assessment Program (CAP) to meet the new TSA-approved Security Program regulations for airports and aircraft operators . A credentialing system, secure remote access and auditing/logging capabilities were implemented to mitigate vulnerabilities found in the Industrial Control System (ICS)/OT Segmentation (e.g. Access Control, Fuel Distribution, Baggage Handling, HVAC, and CCTV systems)

IOActive has seen many systems during our other engagements that have threatscape overlaps with airports. From SCADA/ICS systems to Programmable Logic Controllers (PLCs), pipelines, and even gas turbines. We’ve assessed electricity generation/transmission/distribution systems and even power plants, which all have applicable similarities to airports from a cybersecurity risk point of view.

Kevin Harnett is a Senior Transportation Cybersecurity Technical Advisor for IOActive with deep expertise and experience in ground vehicle and aviation/airport cybersecurity. Kevin has over 40 years experience with the Department of Transportation’s (DOT) Volpe Center.

EDITORIAL | October 19, 2023

A SAFE Journey to Selling Devices to Cloud and Datacenter Providers

By Gunter Ollmann

Observations from the OCP Global Summit | San Jose, CA | October, 18, 2023

If you missed it, there was a significant launch of the Open Compute Project (OCP) Foundation’s new community-led security program for improving device security underpins a fundamental change in the way device vendors and manufacturers engage and sell their products to the worlds leading cloud and datacenter providers.

Beyond standing up a framework for driving continuous security conformance assurance, the Security Appraisal Framework and Enablement (S.A.F.E.) program redefines(and optimizes) the relationship between the device vendor, the device adopter, and the security review provider.

Back when I served as chief security officer for Microsoft’s Cloud and AI Security group, I encountered a scaling problem with the way Azure worked with device vendors (think in terms of CPU’s, GPU’s, SSD’s, network cards, etc.) in validating the integrity and security of their devices. The short story is that before any device or it’s firmware could be deployed within a datacenter a security assessment had to be undertaken – and only devices (and their firmware) that came back with “clean” security reports could be purchased and ultimately deployed. Through a combination of Microsoft’s in-house and trusted third-party penetration testing and code review teams, each key device would be tested and an iterative improvement cycle would continue until the security assurance report came back clean.

There were two obvious problems with that mode of security assurance and interaction. As a purchaser and adopter of devices, how do you scale an in-house security practices to assess and assure the thousands of devices from hundreds of vendors and their ever-changing firmware? And, as a device vendor, how do you meet and coordinate the overlapping yet distinct security requirements of every purchaser and adopter of your technology?

Which brings me back to S.A.F.E. While it has been a couple years since I moved on from Microsoft, it’s fantastic to see that those first meetings with the OCP team and like-minded cloud service providers to tackle those problems that culminated this week in the official launch of the solution – and doubly proud of IOActive’s key involvements in both the creation of the S.A.F.E. device security checklist and Security Review Provider (SRP) criteria, and for being one of the founding SRP providers.

For device vendors, I think S.A.F.E. is great news.

A few points to justify that statement:

  1. Just one set of device security requirements (complete with device checklists) that address all OCP member purchasers and adopters. Better yet, community-driven and publicly available security requirements (with input from purchasers, vendors, and SRP providers alike) that will evolve and adapt to the changing world
  2. Accredited and trusted OCP SRP providers that device vendors can engage with at anytime in their device and firmware’s development lifecycle – cost-effectively accelerating and simplifying a vendors journey to “clean” S.A.F.E.-Approved product status; ultimately ensuring a vendor’s devices can be purchased and deployed by cloud and datacenter providers quicker than ever before
  3. Devices with advanced and proprietary technologies can be security tested and assured to meet adopter security requirements without the vendor having to share proprietary source code with the adopter.

One last perspective to share – oriented specifically to device vendors: there’s fantastic innovation going on across the cloud and datacenter device ecosystem. As I navigate the OCP conference Expo hall, passing by liquid cooling-systems, quantum computing data connectors, petabyte storage arrays, and even specialized forklifts for moving data racks- I’m reminded that many vendors are only just now starting their security journey, and the prospect of having to meet the detailed requirements of S.A.F.E. may feel daunting.

In all my time at Microsoft (and IBM for that matter), I never encountered a device vendor that “nailed security” the first time, nor the third time. Reaching S.A.F.E. approval will be a journey that requires a trusted security partner. When you’re ready for that journey, you’ll not find a stronger and more accomplished or experienced partner than the team at IOActive.

EDITORIAL | May 13, 2022

Update on SATCOM Terminal Attacks During the War in Ukraine

By John Sheehy

In a prior post titled “Missed Calls for SATCOM Cybersecurity: SATCOM Terminal Cyberattacks Open the War in Ukraine,” I shared three hypotheses about the identity of the threat actor responsible for the SATCOM terminal attacks that opened the war.[1] On 31 March 2022, shortly after my post went live, other posts examining forensic evidence from the attack provided some of the additional information needed to support or reject these hypotheses.

Open-Source Forensic Analysis

Ruben Santamarta published a blog post titled “VIASAT Incident: From Speculation to Technical Details” with a forensic analysis of a compromised Surfbeam2 modem.[2] In it, he reviews the Viasat blog post covering the cyberattack[3] and analyses the flash memory from both a compromised and working Surfbeam2 modem. His results showed that the overwrite pattern used on the firmware was identical to that used the AcidRain wiper malware.

Later the same day, a couple of analysts at SentinelOne posted their findings on the AcidRain malware titled “AcidRain | A Modem Wiper Rains Down on Europe.”[4] They analyzed a malware sample uploaded to VirusTotal with the interesting name of ‘ukrop.’[5] They conclude, “While we cannot definitively tie AcidRain to VPNFilter (or the larger Sandworm threat cluster), we note a medium-confidence assessment of non-trivial developmental similarities between their components and hope the research community will continue to contribute their findings in the spirit of collaboration that has permeated the threat intelligence industry over the past month.”

The VPNFilter malware[6] has been attributed to a specific unit of the Russian General Staff Main Intelligence Directorate (GRU), the GTsST, also known as Unit 74455.[7] This unit has developed other derivatives of the VPNFilter malware, such as Cyclops Blink.[8] This group is also known by the name Sandworm among others.[9] The GTsST has on occasion operated jointly with GRU Unit 26165, which is also referred to as APT28.[10] Additional information about Russian-linked cyberoperations elements can be found in the detailed April 2022 Joint Cybersecurity Advisory Alert (AA22-110A) from CISA.[11]

This additional open-source forensic and analytical information supports two of the initial hypotheses about the identity of the threat actor responsible for the Viasat cyberattack: an element of Russian military intelligence (GRU unit) or a collaboration between elements of Russian special services. Without any secret intelligence, a favored hypothesis emerged, which is one or more elements of the GRU. The hypothesis of the Russian FSB-linked Turla group should be disfavored based on this additional evidence.

It would be interesting to see a comparative analysis of the AcidRain and Cyclops Blink malware variants. While they have different target devices and platforms, any similarities could provide additional insights.

Intelligence Agency Public Attributions

On 10 May 2022, numerous governments made public attributions on the identity of this threat actor.[12] Australia,[13] Canada,[14] Estonia,[15] the EU,[16],[17] the UK,[18] and the US[19] varyingly attributed the 24 Feb 2022 Viasat SATCOM cyberattack to Russia and specific Russian cyber operation elements. Concurrently, New Zealand[20] issued a more broadly worded communique referencing Russian cyberattacks in Ukraine without specifically mentioning the Viasat SATCOM attack.

Many of the statements mentioned spillover, however, I will share some thoughts in a future blog post on how this was much more likely a case of ‘pour-over’ (intentional, plausibly deniable spillover) rather than true spillover.

Conclusions

The weight of open-source forensics evidence and the public attributions made by numerous national intelligence services suggests that the threat actor responsible for the Viasat SATCOM terminal attack on 24 February 2022 was almost certainly the Russian General Staff Main Intelligence Directorate (GRU). Moreover, the open-source forensic analysis indicates it was likely the GTsST (Unit 74455) operating alone or jointly with another GRU element.

[1] https://ioactive.com/missed-calls-for-satcom-cybersecurity/

[2] https://www.reversemode.com/2022/03/viasat-incident-from-speculation-to.html

[3] https://www.viasat.com/about/newsroom/blog/ka-sat-network-cyber-attack-overview/

[4] https://www.sentinelone.com/labs/acidrain-a-modem-wiper-rains-down-on-europe/

[5] https://www.virustotal.com/gui/file/9b4dfaca873961174ba935fddaf696145afe7bbf5734509f95feb54f3584fd9a/details

[6] https://www.cisa.gov/uscert/ncas/alerts/TA18-145A

[7] https://www.ncsc.gov.uk/news/uk-and-partners-condemn-gru-cyber-attacks-against-olympic-an-paralympic-games

[8] https://www.cisa.gov/uscert/ncas/alerts/aa22-054a

[9] https://attack.mitre.org/groups/G0034/

[10] https://www.justice.gov/opa/page/file/1098481/download

[11] https://www.cisa.gov/uscert/ncas/alerts/aa22-110a

[12] https://www.reuters.com/world/europe/russia-behind-cyberattack-against-satellite-internet-modems-ukraine-eu-2022-05-10/

[13] https://www.foreignminister.gov.au/minister/marise-payne/media-release/attribution-russia-malicious-cyber-activity-against-european-networks

[14] https://www.canada.ca/en/global-affairs/news/2022/05/statement-on-russias-malicious-cyber-activity-affecting-europe-and-ukraine.html

[15] https://vm.ee/en/news/estonia-joins-statement-attribution-cyberattacks-against-ukraine

[16] https://www.consilium.europa.eu/en/press/press-releases/2022/05/10/russian-cyber-operations-against-ukraine-declaration-by-the-high-representative-on-behalf-of-the-european-union/

[17] https://news.err.ee/1608593500/estonia-high-certainty-russia-behind-cyberattacks-on-ukraine-viasat

[18] https://www.gov.uk/government/news/russia-behind-cyber-attack-with-europe-wide-impact-an-hour-before-ukraine-invasion

[19] https://www.state.gov/attribution-of-russias-malicious-cyber-activity-against-ukraine/

[20] https://www.beehive.govt.nz/release/new-sanctions-target-disinformation-and-malicious-cyber-actors

EDITORIAL | March 30, 2022

Missed Calls for SATCOM Cybersecurity: SATCOM Terminal Cyberattacks Open the War in Ukraine

By John Sheehy

Unfortunately, IOActive was right. IOActive presciently foresaw the use of cyberattacks against commercial satellite communication (SATCOM) terminals and has worked tirelessly to warn the industry for the last nine years. There have been several credible reports of destructive exploitation of vulnerabilities in commercial SATCOM terminals during the opening hours of the War in Ukraine by Russian elements to prepare the battlefield.[1],[2],[3]

I’m disappointed that more industry members didn’t heed our warning, which provided ample time to act and mitigate the realization of these threats.

BACKGROUND

IOActive has sponsored several original cybersecurity research projects on commercial SATCOM over the last decade, and with the exception of our most recent work related to Wideye™ SATCOM terminals,[4] all of the research has been done by Ruben Santamarta.

IOActive has distinguished itself with a commanding body of work related to SATCOM. Our first SATCOM cybersecurity project was completed in 2013, and after several months of coordinated disclosure with the affected vendors, we presented[5] our findings in 2014 at Black Hat in a talk entitled “SATCOM Terminals Hacking by Air, Sea, and Land.”[6] In conjunction with this presentation, we published a comprehensive whitepaper entitled “A Wake-up Call for SATCOM Security”[7] exploring the vulnerabilities and issues in greater detail. As a testament to the ground-breaking nature of this work, Google Scholar shows this paper has been cited 37 times as of March 2022.[8]

For this research project we reviewed SATCOM terminals from five major vendors used on the INMARSAT[9] and Iridium[10] services and found that malicious actors could abuse all of the devices. The vulnerabilities included what would appear to be backdoors, hardcoded credentials, undocumented and/or insecure protocols, and weak encryption algorithms. In addition to design flaws, IOActive also uncovered a number of features in the devices that clearly pose security risks. We concluded that this research “should serve as an initial wake-up call for both the vendors and users of the current generation of SATCOM technology.” We did have one major user of these services engage with us to understand the risk it posed to their global operations. We wish we were able to help more organizations during this time period.

As the consequences of our findings were largely ignored within the industry and amongst those who rely upon such commercial SATCOM services, IOActive sponsored a follow-up research project called “Last Call for SATCOM Security,”[11] which we presented[12] at Black Hat in 2018.[13] We discovered vulnerabilities that affect the aviation, maritime, and military industries including backdoors, insecure protocols, and network misconfigurations. We identified hundreds of vulnerable systems on aircraft, maritime vessels, and units used by the military in active conflict zones disclosing detailed geolocation data. The paper and talk’s title clearly challenged the industry to do something about these pervasive cybersecurity issues before it was too late.

Stakeholders were more open to the second body of research, even though some sectors pushed back on the conclusions despite the irrefutable, concrete code examples IOActive provided. Some small groups listened very thoughtfully and carefully before they began to take action to manage the risks they and their users faced. Unfortunately, this type of proactive approach was not a common response to our research.

In January 2022, a little more than three years after the publication of our second body of research, the U.S. National Security Agency (NSA) issued a rare public Cybersecurity Advisory[14] urging operators to protect commercial Very Small Aperture Terminals (VSATs), since they are “increasingly used for remote communications in support of U.S. government missions.” In the Works Cited section of the advisory, the only vulnerability research cited was IOActive’s “Last Call for SATCOM Security” presentation. It is difficult to receive a higher accolade in the world of SATCOM for your cybersecurity research. Congratulations to the NSA for pushing this advisory out prior to the exploitation of SATCOM terminals in Ukraine.

Most recently, on 17 March 2022, the U.S. Federal Bureau of Investigation (FBI) and Cybersecurity and Infrastructure Security Agency (CISA) issued a joint advisory related to SATCOM security titled “Strengthening Cybersecurity of SATCOM Network Providers and Customers.”[15] This document provides guidance on how to improve the security posture of SATCOM systems. We urge everyone to take this guidance very seriously.

RECENT SATCOM TERMINAL ATTACKS IN EUROPE

The Reuters piece does a good job of covering what’s publicly known about the attacks.[16] Ruben has posted a great technical blog[17] analyzing the likely technical attack vectors based upon currently available open-source information.

Unfortunately, our second piece of research was more controversial, since it challenged the widespread, sacrosanct belief held by most members of the aviation industry that they have identified and appropriately mitigated all risks to safety. Unquestionably, they have done an exceptional job for passive and natural threats; however, within aviation and aerospace industries, there is significantly more work to be done to properly manage active threats to safety from highly motivated, competent, and sophisticated threat actors such as the one who bricked thousands of SATCOM terminals on 24 February 2022.

Hypotheses on Threat Actor Identity

While there is no clear public evidence as to the identity of the threat actor responsible for the SATCOM terminal attack, informed analysis of open sources can provide a working hypothesis for potential threat actors. To strongly confirm the hypothesis, one would need to gather secret intelligence via human intelligence (HUMINT) sources such as a penetration or through active or passive signals intelligence (SIGINT). Forensic analysis of the malware used in the attack could yield technical evidence to tie the cyberattack to the responsible group through their operational infrastructure. Alternately, some years in the future, we may see the unit and even team members publicly recognized for their contribution to the ground-breaking cyberattack that opened the War in Ukraine. It was a bright spot in a campaign that has otherwise highlighted the inadequacies of the Russian armed forces.[18]

Prima facie, one would expect an element of Russian military intelligence to support the Russian armed forces through cyber operations. This is a very logical, reasonable starting position. This is the current theory floated by a source in the U.S. intelligence community to the Washington Post.[19] However, there is no desire to make a high-confidence, public attribution at this time. Looking for additional evidence as to whether they have the capability and capacity to do this in the absence of specific evidence from the attack helps support this hypothesis. GRU cyber elements have a history of successful attacks on critical infrastructure in Ukraine, which demonstrates they have the capability and capacity to successfully target operational technology with consequential effects.[20]

An alternate Russian-government-affiliated advanced persistent threat (APT) group, Turla[21] (affiliated with the FSB[22]), is another potential candidate. They have been linked to prior, sophisticated use of SATCOM in espionage activities.[23],[24] In addition, they have a track record of innovation, including adapting new TTPs, like living off the land, to improve their evasion capabilities and protect their operational security.[25] In addition, their targets generally align with Russian strategic interests, and supporting the creation of a neutral buffer space in Ukraine between their border and NATO member states is among the most important interests of the Russian nation.

Finally, there’s a third hypothesis involving some sort of collaboration between different Russian special services. While there have been indications of toolchain sharing or joint operations between cyber elements of Russian special services in the SolarWinds incident,[26] it is not clear from public information whether this was due to a formal joint operation or an admixture of personnel over time.

Interested parties should look for further confirmatory and contradictory evidence to prove or disprove these hypotheses.

Future Cyberattacks on SATCOM

Regrettably, we are in a new era with a significantly increased probability of additional SATCOM cyberattacks. Fortunately, we may not see another destructive cyberattack like we saw last month in Ukraine for some time, but clandestine exploitation in support of intelligence and espionage operations is more likely. Unfortunately, this very public example of a successful cyberattack on SATCOM will increase interest amongst those threat actors with the capability and capacity to develop weaponized SATCOM exploits and lower the inhibition for the use of those exploits amongst those threat actors who have them in inventory.

ACT NOW

While disappointing that it took real-world attacks for a wake-up call to be realized, it’s not too late for all members of the industry to take these threats to heart and finally address the underlying issues. We emphasize that if an organization offering or using SATCOM services hasn’t acted on these risks yet, they must do so quickly. We’ll share some general thoughts about on how to start.

SATCOM Providers

SATCOM providers can do the most to manage cybersecurity risk. The following is some general guidance:

  1. Avoid groupthink and the problems of checking one’s own work. Engage a competent third party to perform independent validation and verification of your cybersecurity posture.
  2. Ensure you are getting regular assessments of your cybersecurity posture, including:
    1. Daily or weekly vulnerability scans
    2. Quarterly penetration testing
    3. Regular full-spectrum, Red Team engagements
  3. Support your Security Operations Center (SOC) team members with additional training, including Purple Team engagements.
  4. Ensure any devices used on your network or service have been tested by a competent third-party assessor with deep experience in embedded device security.
  5. If you manufacture devices, ensure your developers have cybersecurity training to include threat modeling, secure coding, and embedded device security.
  6. Develop an operational resiliency plan to respond to cyberattacks and minimize the impacts of such incidents.
  7. Retain an incident response firm in preparation for any compromise.

SATCOM Users

Here’s a short action list for users:

  1. Understand the details of the SATCOM services your organization uses.
  2. Understand the business criticality and impact if these services are affected.
  3. Ask your provider(s) to supply proof they are taking prudent steps to protect their service and their clients. (Service and terminal providers will likely be different entities.)
    1. Ask for summary reports of their third-party network penetration testing.
    2. Ask for summary reports of their third-party terminal device penetration testing.
  4. Evaluate switching to a SATCOM provider who is able to demonstrate they are prudently addressing these concerns.
  5. Develop plans for containment and operational resiliency should you experience an attack.
  6. Retain an incident response firm in preparation for any compromise.

Finally, if you’re an organization offering or using SATCOM services, we are happy to have a confidential chat with you to help you develop a customized course of action appropriate to your specific circumstances.

THANKS

I would like to extend a thank you to those who took these issues seriously over the last nine years. I know some were unable to convince their senior leadership to act, but it was most certainly not due to a lack of effort.

 

[1] https://www.reuters.com/business/aerospace-defense/satellite-firm-viasat-probes-suspected-cyberattack-ukraine-elsewhere-2022-02-28/

[2] https://www.reuters.com/world/europe/exclusive-us-spy-agency-probes-sabotage-satellite-internet-during-russian-2022-03-11/

[3] https://techcrunch.com/2022/03/18/cisa-fbi-satellite-networks/

[4] https://ioactive.com/wideye-advisory-and-current-satcom-security-concerns/

[5] https://www.youtube.com/watch?v=YeKswEamOl4

[6] https://ioactive.com/pdfs/IOActive_SATCOM_Presentation_Black_Hat_2014.pdf

[7] https://ioactive.com/pdfs/IOActive_SATCOM_Security_WhitePaper.pdf

[8] https://scholar.google.com/scholar?cites=513025268424616717

[9] https://www.inmarsat.com/en/index.html

[10] https://www.iridium.com/

[11] https://ioactive.com/wp-content/uploads/2018/08/us-18-Santamarta-Last-Call-For-Satcom-Security-wp.pdf

[12] https://www.youtube.com/watch?v=8M8MurmuEtQ

[13] https://ioac.tv/3Nh0hM2

[14] https://media.defense.gov/2022/Jan/25/2002927101/-1/-1/0/CSA_PROTECTING_VSAT_COMMUNICATIONS_01252022.PDF

[15] https://www.cisa.gov/uscert/ncas/alerts/aa22-076a

[16] https://www.reuters.com/world/europe/exclusive-us-spy-agency-probes-sabotage-satellite-internet-during-russian-2022-03-11/

[17] https://www.reversemode.com/2022/03/satcom-terminals-under-attack-in-europe.html

[18] https://www.atlanticcouncil.org/blogs/new-atlanticist/russia-crisis-military-assessment-why-did-russias-invasion-stumble/

[19] https://www.washingtonpost.com/national-security/2022/03/24/russian-military-behind-hack-satellite-communication-devices-ukraine-wars-outset-us-officials-say/

[20] https://www.wired.com/story/russia-ukraine-cyberattack-power-grid-blackout-destruction/

[21] https://attack.mitre.org/groups/G0010/

[22] https://www.cyberscoop.com/turla-solarwinds-kaspersky/

[23] https://www.kaspersky.com/about/press-releases/2015_turla-hiding-in-the-sky-russian-speaking-cyberespionage-group-exploits-satellites-to-reach-the-ultimate-level-of-anonymity

[24] https://www.wired.com/2015/09/turla-russian-espionage-gang-hijacks-satellite-connections-to-steal-data/

[25] https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/waterbug-espionage-governments

[26] https://www.reuters.com/article/us-global-cyber-solarwinds-idCAKBN29G0XT

EDITORIAL | March 16, 2022

Responding to a Changing Threatscape: Sharing More

By John Sheehy

The War in Ukraine has caused a sea change in the threatscape, where a highly capable group of threat actors now has a much stronger incentive to use cyber actions to achieve their objectives and support their interests. At IOActive we are adjusting our course of action in response to this change in several areas: in addition to our groundbreaking cybersecurity research, another element to arrive in the upcoming months will see us sharing more and different types of content on our blogs.

Some of this new content will be items we normally share discreetly with our clients in small, verbal briefings or through Information Sharing and Analysis Centers (ISACs). However, we have decided to judiciously publicize more of this information due to the more intense risks the community is facing today.

Original Cybersecurity Research

In accordance with our Responsible Disclosure Policy1, we’ll be sharing previously unpublished, original cybersecurity research to which product manufacturers were non-responsive after our disclosure steps or where we’re seeing similar vulnerabilities exploited in the wild. For example, due to the exploitation of vulnerabilities in commercial satellite communications (SATCOM) terminals2 as presciently foreseen by Ruben Santamarta in two research projects from 20143 and 20184, as well as by the US National Security Agency (NSA) in a January 2022 Cybersecurity Advisory5, we’ll be sharing vulnerabilities in a two-phase approach that we originally reported to a terminal manufacturer more than 3 years ago. You can find that initial post here.6

Analytical Threat Intelligence

IOActive normally chooses not to publicly share the products of our threat intelligence analytics, wherein we explore the operational and cybersecurity consequences of our original research findings or assess which threat actors may have the capability and interest to perform or operationalize attacks similar to those found in our research. Given the changed threatscape, however, we feel it’s important to share a retrospective look at the revealed SATCOM vulnerabilities and their utilization in the War in Ukraine; likewise, we will be sharing more analytical perspectives on cybersecurity threats to transportation, as briefly covered in a recent FleetOwner article specific to trucking fleet operations.7 While these analytical products are often informal, they can be extremely valuable to organizations of all types.

Strategies and Potential Courses of Action

In addition to providing threat intelligence products from an attacker’s viewpoint, we also advise our clients and share with ISACs strategies to manage their cybersecurity and operational risks, as well as potential courses of action based on our detailed understanding of how attackers operate and succeed. Often these suggestions and advice are made in response to our original cybersecurity research and its corresponding analytical threat.

 

1https://ioactive.com/disclosure-policy/

2https://www.reuters.com/business/aerospace-defense/satellite-firm-viasat-probes-suspected-cyberattack-ukraine-elsewhere-2022-02-28/

3https://ioactive.com/pdfs/IOActive_SATCOM_Security_WhitePaper.pdf

4IOActive whitepaper | Last Call for SATCOM Security

5https://media.defense.gov/2022/Jan/25/2002927101/-1/-1/0/CSA_PROTECTING_VSAT_COMMUNICATIONS_01252022.PDF

6IOActive blog | Wideye Security Advisory and Current Concerns on SATCOM Security

7https://www.fleetowner.com/technology/article/21235462/are-cybercriminals-waiting-for-the-right-time-to-attack-us-trucks

EDITORIAL | August 3, 2021

Counterproliferation: Doing Our Part

By John Sheehy

IOActive has always done its part in preventing the misuse of our work.

IOActive’s mission is to make the world a safer and more secure place. In the past, we’ve worked to innovate in the responsible disclosure process, with the most visible and memorable example being Dan Kaminsky’s research into DNS.[1] This involved one of the first uses of widespread, multiparty coordinated responsible disclosure, which quickly became the gold standard as referenced in CERT’s Guide to Responsible Disclosure.[2]

We don’t always talk publicly about our non-technical innovations, since they frequently aren’t as interesting as the groundbreaking cybersecurity research our team delivers. However, a couple recent events have prompted us to speak a bit about some of these less glamorous, but nonetheless extremely important innovations. First, we were deeply saddened by the passing of Dan Kaminsky, and would like to share how we’re building upon his legacy of non-technical innovation in vulnerability research. Second, a significant disclosure covered by global media organizations regarding the misuse of weaponized mobile phone vulnerabilities, packaged with surveillance tools, to target journalists and others for political purposes, rather than for lawful purposes consistent with basic human rights.

What We’re Doing

There are three primary elements to our policies that prevent the misuse of the vulnerabilities we discover.

Responsible Disclosure

IOActive has always had a policy of responsible disclosure. We transparently publish our policy on our website for everyone to see.[3] Over time, we’ve taken additional innovative steps to enhance this disclosure process.

We’ve built upon Dan’s innovation in responsible disclosure by sharing our research with impacted industries through multinational Information Sharing and Analysis Centers (ISACs).[4] Likewise, we’ve worked to confidentially disclose more of our pre-release research to our clients when it may impact them. As our consultants and researchers find new and innovative ways to break things, we’ll find new and innovative ways to disclose their work and associated consequences, with the goal of facilitating the best outcomes for all stakeholders.

Policy on the Sale of Vulnerabilities

IOActive is very clear on this simple policy, both publicly and with our clients: we do not sell vulnerabilities.

A well-developed market for vulnerabilities has existed for some time.[5] Unfortunately, other cybersecurity firms do sell vulnerabilities, and may not have the necessary ethical compartmentalization and required policies in place to safeguard the security and other interests of their clients and the public at large.

While we support the bug bounty concept, which can help reduce the likelihood of vulnerability sales and support the independent research community, as a commercial service bug bounties do not adequately address concerns such as personnel vetting or testing of resources only available when onsite at a client.

Contractual Responsible Disclosure Requirement

As a standard practice in our commercial work, we require the ability to report vulnerabilities we discover in third-party products externally only to the affected manufacturers, in addition to the client, to ensure that an identified defect can be properly corrected. IOActive offers to coordinate this disclosure process to the manufacturers on behalf of our clients.

This normally leads to a virtuous cycle of improved security for everyone through our commercial work. Any vulnerability discovery benefits not only the client, but the entire ecosystem, both of whom in turn benefit from the vulnerability discovery work we do for other clients.

Every person reading this post has benefited from better security in the products and services they and their organizations use every day, due to the combination of our fantastic consultants and clients who support doing the right thing for the ecosystem.

Fundamentally, when a vulnerability is corrected, that risk is retired for everyone who updates to the secure version and prevents the weaponization of the vulnerability. When those fixes are pushed out through an automated update process, the benefits accrue without any active effort on the part of end users or system maintainers.

How to Help

Make it Easy to Receive Disclosures

As a prolific vulnerability discloser, we see a wide spectrum of maturity in receiving and handling vulnerability disclosures. We must often resort to creative and time-intensive efforts to locate a contact who will respond to our attempts to disclose a vulnerability. Occasionally, we run into a dead end and are unable to make productive contact with organizations.

Here’s a short list of actions that will help make it easy to collect vulnerability information your organization really needs:

  1. Run a Vulnerability Disclosure Program. A vulnerability disclosure management program provides bidirectional, secure communication between the discloser and the impacted organization in a formal, operationalized manner. You can run such a program with internal resources or outsource it to a commercial firm providing managed vulnerability disclosure program services.
  2. Be Easy to Find. It should be simple and effortless for a researcher to find details on the disclosure process for any organization. A good test is to search for “<Your Organization Name> Vulnerability Disclosure” or “<Your Organization Name> Vulnerability Report” in a search engine. Ideally, your public disclosure page should appear in the first page or two of results.

Cesar Cerrudo, CTO of IOActive Labs, has a more in-depth post discussing how to get the best outcomes from working with researchers during the vulnerability disclosure process in his post, 10 Laws of Disclosure.[6]

Working with Security Firms

When you’re selecting a security firm for vulnerability discovery work, you should know what they will do with any vulnerabilities they find. Here are a few core questions for which any firm should have detailed, clear answers:

  • Does the company have a responsible disclosure policy?
  • What is the company’s policy regarding the sale of vulnerabilities?
  • Does the company require responsible disclosure of the vulnerabilities it discovers during client work?
  • How does the company handle third-party responsible disclosure for its clients?

Participate in the Discussion

The global norms around the sale and weaponization of cybersecurity vulnerabilities, as well as their integration into surveillance tools, are being established today. More constructive, thoughtful public debate today can prevent the current deleterious conduct from becoming a standard of global behavior with its associated dystopic outcomes through inattention and inaction.

References

[1] https://www.cnet.com/tech/services-and-software/security-bites-107-dan-kaminsky-talks-about-responsible-vulnerability-disclosure/
[2] https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
[3] https://ioactive.com/disclosure-policy/
[4] https://www.nationalisacs.org/
[5] https://www.rand.org/content/dam/rand/pubs/research_reports/RR600/RR610/RAND_RR610.pdf
[6] https://ioactive.com/10-laws-of-disclosure/