GUEST BLOG | December 13, 2022

Interdependencies – Handshakes Between Critical Infrastructures | Ernie Hayden

As of this writing, the United States was recently threatened by a major railroad union strike. The railroads are a major element of the country’s critical infrastructure. Their shutdown could lead to multiple, cascading impacts on the delivery of goods and services, not only in the US but also in Canada and Mexico. Shipping lines could also be impacted by a railroad strike, since they will not be able to receive or offload containers and cargo to and from rail cars.

Per a CNN article, a rail strike would cost the US economy about $1 billion in the first week, according to the Association of American Railroads. The ripple effect of a shipping stoppage of that magnitude could lead to global food shortages and more: the American Chemistry Council said that around $2.8 billion in chemical shipments would be impacted each week. A separate article by the Association of American Railroads also outlines how other transportation and logistics partners are not positioned to take up the slack left by a railroad strike to keep goods moving efficiently across the nation, should a service interruption occur. Specifically, in the first half of 2022, more than 75,000 rail shipments began their journey each day; in the event of a shutdown, these shipments would sit idle.

This scenario demonstrates the fundamental concept of cascading issues following the failure of one element of the country’s critical infrastructure. This demonstrates the interdependencies in play between transportation, manufacturing, chemical production, and other vital systems.

What is Critical Infrastructure?

The concept of infrastructure in the United States began around 1983. The infrastructure under discussion included highways, public transit, wastewater treatment, water resources, air traffic control, airports, and municipal water supplies. However, these were not given the attribute of “critical.”

From 1983 until 2013, the US government formed policies and held discussions regarding infrastructure and “critical infrastructure” occurred. There were multiple iterations that are beyond the scope of this article; however, the US government perspective of “critical infrastructure” being used today in 2022 was laid out by the Obama Administration in Presidential Policy Directive 21 and Executive Order 13636.

These policy documents identified a list of US infrastructure that should be considered “…so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security; national economic security; national public health or safety; or any combination of those matters.”^[1]

The following are the 16 specifically identified sectors in the US Critical Infrastructure hierarchy:

Chemical Sector
Commercial Facilities Sector
Communications Sector
Critical Manufacturing Sector
Dams Sector
Defense Industrial Base Sector
Emergency Services Sector
Energy Sector
Financial Services Sector
Food and Agriculture Sector
Government Facilities Sector
Healthcare and Public Health Sector
Information Technology Sector
Nuclear Reactors, Materials, and Waste Sector
Transportation Systems Sector
Water and Wastewater Systems Sector

These appear in graphic format at the US Department of Homeland Security Cybersecurity & Infrastructure Security Agency (CISA) website.

Interdependencies Between Critical Infrastructure Sectors

As you may have observed in the discussion of the aforementioned railroad strike, the shutdown of the railroads is not a singular impact, instead impacting other aspects of commerce, manufacturing, and modes of transportation. These other impacts can be viewed as interdependencies.

Interdependencies and connections between infrastructure sectors or elements could mean that damage, disruption, or destruction to one infrastructure element may cause cascading effects negatively impacting the continued operation of another infrastructure element or sector.

These interdependencies are not always obvious, and can be subtle. Right now, the current trend towards greater and more accelerated infrastructure interdependency is due to the Internet. Some experts on critical infrastructure analysis have observed that the advent of the Internet has made critical infrastructure more complex and more interdependent, and thus more fragile.

In their research project Keeping America Safe: Toward More Secure Networks for Critical Sectors (2017), the MIT Center for International Studies observed that “…no one currently understands the extent to which electricity generation is coupled with other sectors, and therefore the risk of ‘catastrophic macroeconomic failure’ in the event of a cyber attack is not adequately known.”

A seminal report by Rinaldi, et al, Identifying, Understanding, and Analyzing Critical Infrastructure Interdependencies — written just before the catastrophic events of September 11, 2001 — reported:

“…what happens to one infrastructure can directly and indirectly affect:

Other infrastructures,
- Large geographic regions, and
- Send ripples throughout the national and global economy…”

This paragraph makes one realize that understanding and studying infrastructure interdependencies is extremely important for our country and the broader North American continent.

Another analysis of critical infrastructure interdependencies noted that “…critical infrastructure interdependencies constitute a risk multiplier: they can themselves be a threat or hazard, affect the resilience and protection performance of critical infrastructure, and lead to cascading and escalating failures.”

Interdependencies need to be understood as part of any risk assessment. If they are not considered, the risk assessment could offer the wrong conclusions.

Case Studies of Critical Infrastructure Interdependencies

In addition to our brief discussion about the railroads at the beginning of this article, here are three additional case studies that demonstrate where interdependencies were highlighted by the failure of a single element or piece of critical infrastructure.

Admittedly, the first two cases are dated; however, they are well documented and provide a sense of cascading failures in two industries.

Orbiting Satellites and Critical Infrastructure Interdependencies

In May of 1998, the five-year-old Galaxy IV Communications Satellite failed. The satellite’s computer and backup computer failed, causing the satellite to tilt away from Earth. The owner, PanAmSat, was unable to realign the satellite. PanAmSat was finally able to reroute traffic the next day to another satellite; however, the Galaxy IV was considered permanently out of service, seven years short of its intended 12-year operational life.

What were the impacts of this event? Here are some examples:

Pager service (remember that?) was disabled for 80-90% of U.S. customers (about 45 million). This impacted physicians, emergency departments, police, fire, and emergency medical technicians. This failure alone demonstrated how this one item of critical infrastructure can impact a major system used by emergency service providers.
Credit card authorization services at around 5,400 Chevron stations and most Wal-Mart stores were shut down.
Public television transmissions were impacted. These included:
- CBS
- Warner Brothers
- UPN
- Reuters TV
- Motor Racing Network
- CNN Airport Channel
- Chinese Television Network in Hong Kong
- US Armed Forces Entertainment Network
Radio stations, including National Public Radio’s national feed
Private business TV stations such as Aetna, Microsoft, and 3M

Overall, this one satellite failure caused a broad impact across multiple industries relying on the satellite’s communications capabilities.

Seattle Tacoma Airport and Olympic Oil Pipeline Interdependencies

The Olympic Pipeline is a 400-mile interstate pipeline system running from the US-Canada border near Blaine, Washington to Portland, Oregon. It delivers aviation jet fuel, diesel fuel, and gasoline to product terminals at Seattle (Harbor Island), Seattle-Tacoma International Airport (“Sea-Tac”), Renton, Tacoma, Vancouver (WA), and Portland.

Sea-Tac Airport receives jet fuel via a special pipeline from Renton, Washington, using a 16-inch pipe, since Sea-Tac airport cannot accommodate offloading fuel trucks to its jet fuel tank farm.

On Sunday, May 23^rd, 2004, a pinhole-sized leak opened in a ¾-inch sample line due to electric conduit rubbing against the tube. The leak immediately caused between 3,300 and 10,000 gallons of fuel to leak and catch fire (most of it was burned). The pipeline was immediately shut down, impacting delivery of 11 million gallons of fuel per day system-wide. The Olympic Pipeline lost $10,000 in business each hour.

On Tuesday, May 25^th, two days after the leak and subsequent pipeline isolation, Sea-Tac refueling operations were in trouble. The airport had 2.9 million gallons of fuel on hand, and typically uses 1.2 million gallons per day to fuel the airline jets. As such, Sea-Tac operations requested airlines to not refuel their planes at the airport. Alaska Airlines – the primary tenant airline at Sea-Tac – decided to refuel its planes in cities like San Francisco and San Jose to reduce reliance on Sea-Tac’s fuel.

Alaska even considered canceling some flights beginning on Wednesday, May 26^th, if the pipeline was not returned to service.

On Wednesday, May 26^th, the pipeline flow was restored, and Sea-Tac returned to normal refueling services soon afterwards.

This story affecting Sea-Tac is another example wherein the failure of one component led to the failure of one system, thus leading to the failure and negative impact of multiple elements of critical infrastructure.

Ukraine War and Critical Infrastructure Interdependencies

Between the start of the Russian invasion on February 24^th, 2022 and March 24^th, 2022, multiple critical infrastructures were seriously damaged or destroyed, including:

92 factories and warehouses
378 schools
138 healthcare institutions
12 airports
7 thermal power and hydroelectric power plants

The only functioning oil refinery was also destroyed.

That was the first month of the war. Up to the time of this writing, the number of destroyed critical infrastructure facilities is much larger still.

The following table lists the categories of critical infrastructure damaged by the end of the first month of the war.

Infrastructure	Number of Items	Cost in $US Millions
Roads (kilometers)	8,265	$27,546
Housing	4,431	$13,542
Civilian Airports	8	$6,816
Industrial Enterprises, Factories	92	$2,921
Healthcare Institutions	138	$2,466
Nuclear Power Plants	1	$2,416
Railway Stations and Rolling Stock	n/a	$2,205
Bridges	260	$1,452
Ports and Port Infrastructure	2	$622
Secondary and Higher Education Institutions	378	$601

Other impacts to critical infrastructure from the war in Ukraine include the following^[2]:

The European construction industry has had difficulty sourcing building supplies from Russia and Ukraine. For instance, Ukraine produces steel, timber, pallets, and clay for ceramic tiles. Also, the sanctions against Russia are restricting availability of copper, iron ore, and steel.
Ukrainian and Russian nationals provide more than 15% of the global shipping workforce, meaning that the war is leading to a shortage of able-bodied seamen.
Russia and Ukraine produce approximately one-third of the world’s ammonia and potassium exports, ingredients necessary for agricultural fertilizer. This alone has caused fertilizer prices to increase by 20 to 50%.
Food security has been impacted across the Middle East, North Africa, and Western and Central Asia — Ukraine is often called a “global breadbasket.”

The conclusion here is that a war between two countries has a major impact on critical infrastructures around the globe. It is important that the risk analysis includes a review of potential infrastructure interdependencies.

Rogers Telecom Outage, Ontario, Canada

At around 3:45 AM Eastern Time on Friday, July 8, 2022, Rogers Communications — one of the largest Internet service providers in Canada — experienced a significant disruption that rendered its network unavailable for long periods of time over the course of approximately 24 hours.

This failure impacted over 10 million wireless subscribers and 2.25 million retail internet subscribers. The outage caused problems for payment systems, Automated Teller Machines (ATMs), and phone connections, primarily in eastern Canada.

For instance, the outage affected all financial institutions across Canada, including the Royal Bank of Canada. It caused a shutdown or interruption of the INTERAC payment system used by all Canadian banks, thus affecting debit card and funds transfer services. Even Toronto Dominion Bank and Bank of Montreal suffered some service and capability interruptions.

Air Canada, which is headquartered in Toronto, suffered a major impact to its call centers. Even Vancouver International Airport – thousands of miles west of Toronto – was affected. There, travelers could not pay for parking, use terminal ATMs, or purchase items at airport retailers. Cash was king!

Even Canadian government offices, such as the Canadian Radio-television and Telecommunications Commission, lost telephone connections.

Although this is not a deep dive into the cause of this outage, the point of focus for the reader is that the failure of a telephone system resulted in nationwide impacts to commerce, retail sales, and provision of services such as automobile parking. Hence, critical infrastructure interdependencies were demonstrated on that fateful day.

Recent News: Substations Shot in North Carolina

In in early December 2022, two substations were shot at by unknown assailants. Approximately 45,000 homes lost power and some water systems were shut down due to lack of electricity. Again, this is an example of ways critical infrastructure is interrelated.

Thoughts to Ponder

In his paper on critical infrastructure interdependencies, Dr. Steven Rinaldi observed: “Interdependencies, however, are a complex and difficult problem to analyze.” This author agrees. If you look at the cases summarized above, and even consider those examples you have witnessed where the failure of one piece of critical infrastructure has affected one or more other sectors, you will realize that some extraordinary critical thinking is necessary to best understand the interdependencies.

Would your analysis have predicted the downstream failures observed with the failure of a single satellite? A tiny pipeline leak? A small regional war in Eastern Europe? Or the failure of one phone system?

It makes one wonder.

Overall, this perspective is intended to get you thinking, especially if you’re performing risk analysis of critical infrastructures and associated systems. Thinking “out of the box” is appropriate when trying to best understand the broader impacts that can surface with the failure of a single critical infrastructure.

Ernie Hayden
MIPM, CISSP, GICSP (Gold), PSP

About the Author

Ernie Hayden is a highly experienced technical consultant and thought leader in the areas of cyber/physical security. He has authored a book, Critical Infrastructure Risk Assessment – The Definitive Threat Identification and Reduction Handbook (published by Rothstein), which was awarded the ASIS International 2021 Security Book of the Year. Ernie is the Founder/Principal of 443 Consulting, LLC, and can be reached at enhayden1321(_at_)gmail.com.

^[1]2001 USA Patriot Act, Page 401, Definition of Critical Infrastructure https://www.congress.gov/107/plaws/publ56/PLAW-107publ56.pdf<

^[2]Many facts from McKinsey & Company analysis dated May 9, 2022

INSIGHTS, RESEARCH | November 2, 2022

Exploring the security configuration of AMD platforms

By Enrique Nissim Krzysztof Okupski & Joseph Tartaro

TLDR: We present a new tool for evaluating the security of AMD-based platforms and rediscover a long-forgotten vulnerability class that allowed us to fully compromise SMM in the Acer Swift 3 laptop (see Acer’s advisory).

Introduction

In the last decade, a lot of interesting research has been published around UEFI and System Management Mode (SMM) security. To provide a bit of background, SMM is the most privileged CPU mode on x86-based systems; it is sometimes referred to as ring -2 as it is more privileged than the kernel and even the hypervisor. Therefore, keeping SMM secure must be one of the main goals of the UEFI firmware.

One thing that caught our attention is that most, if not all, of the publicly available material is focused on Intel-based platforms. Since the release of CHIPSEC [1], the world has had a tool to quickly determine if the firmware does a good job protecting the system after the DXE phase and, as a result, it is hard to find misconfigured firmware in laptops from any of the major OEMs in 2022.

Make no mistake, it is not that AMD-based platforms are free from bugs [2]. Nevertheless, judging by their description, these seem to be associated with SMI handlers rather than platform security configurations. In contrast, the only presentation we found mentioning AMD platform security was done by Pete Markowsky in 2015 [3].

This blog walks through the discovery and exploitation of a security issue that was automatically identified by an in-house developed tool.

The Tool

Platbox is a firmware assessment tool that allows you to retrieve chipset configuration values and interact with PCIe devices, physical memory, MSRs, and so on. The project was born back in 2018 as part of a security evaluation for an OEM’s Intel-based platform; however, we recently extended it to support AMD systems.

Source code, compiled binaries, and examples can be found here: https://github.com/IOActive/Platbox

Next, we evaluate the security of one of our targets AMD systems and demonstrate how it can be used to find chipset configuration issues.

The Test-Run

In order to put our tool to the test, we ran it against the Acer Swift 3 (model no. SF314-42; BIOS v1.10), the output of which is shown below:

PS C:\Users\IOActive\Desktop\Platbox\PlatboxClient> .\build\build64\Release\platbox_cli.exe cli
>>> chipset

MemoryRange: fe000000

RomProtect_0 
- Base: ff73a000
- RangeUnit: 1
- Range: 00000039
- Protected size: 00390000
- WriteProtected: 1
- ReadProtected: 0
- Total range [ff73a000, ffad9fff)
RomProtect_1
- Base: fff20000
- RangeUnit: 0
- Range: 000000df
- Protected size: 000df000
- WriteProtected: 1
- ReadProtected: 0
- Total range [fff20000, ffffffff)
RomProtect_2
- Base: 00000000
- RangeUnit: 0
- Range: 00000000
- Protected size: 00000000
- WriteProtected: 0
- ReadProtected: 0
- Total range [00000000, 00000fff)
RomProtect_3
- Base: 00000000
- RangeUnit: 0
- Range: 00000000
- Protected size: 00000000
- WriteProtected: 0
- ReadProtected: 0
- Total range [00000000, 00000fff)

SPI BASE: fec10000

SPIx1D - SpiProtectEn0: 1
SPIx1D - SpiProtectEn1: 1
SPIx1D - SpiProtectLock: 1

LPC ROM Address Range1 Start: 0
LPC ROM Address Range1   End: fffff
LPC ROM Address Range2 Start: ff000000
LPC ROM Address Range2   End: ffffffff

-> MSR:[c0010111]: 00000000AEF43000
MSR C001_0111 SMM Base Address (SMM_BASE)
 => Base: aef43000
   -> SMI-Handler Entry Point: aef4b000
   -> SMM Save-State Area    : aef52e00

-> MSR:[c0010112]: 00000000AE000000
MSR C001_0112 SMM TSeg Base Address (SMMAddr)
 => Value: ae000000

-> MSR:[c0010113]: 0000FFFFFF006603
MSR C001_0113 SMM TSeg Mask (SMMMask)
 => Value: ff006603
   -> TSegMask: ff000000
   -> TMTypeDram: 6
   -> AMTypeDram: 6
   -> TMTypeIoWc: 0
   -> AMTypeIoWc: 0
   -> TClose: 0
   -> AClose: 0
   -> TValid: 1
   -> AValid: 1

-> MSR:[c0010015]: 0000000109000010
MSR C001_0015 Hardware Configuration (HWCR)
 => Value: 9000010
   -> SMMLock: 0

[...]

As we can see, the tool has extracted a variety of information from the system, namely:

Flash protected ranges
Flash lock configuration
TSEG memory range
SMM base address
SMM lock configuration

The first part describes the protections applied to the flash that prevent any run-time access (including from SMM). Each protected range defines (i) a memory range in flash and (ii) read/write access permissions. These protections are applied at boot-time and should be locked to prevent tampering.

The second part describes protections applied to the SMM memory that prevent any run-time access from the OS. To this end, the so called TSEG region is used; the configurations include, among others, (i) the TSEG memory range and (ii) whether it is active or not. As before, these protections are applied at boot-time and should be locked to prevent modification.

Note that for the sake of brevity the remainder of the output has been truncated.

The Vulnerability

We see that the tool has found that the SMM lock configuration bit in the HWCR is set to 0. Let’s try to understand why this is an issue.

According to AMD specifications [4], the SMM lock configuration bit in the HWCR is used to indicate that (i) SMM code is running in either the so called ASEG or TSEG region and (ii) that certain SMM registers are read-only:

The reference to another section at the end of the definition provides further clarification: it states that specifically MSRC001_0112 and MSRC001_0113 registers are configured to be read-only when the SMM lock bit is set:

Digging deeper into the aforementioned registers, we see that the MSRC001_0112 register corresponds to the TSEG base address. This is the base address of a protected memory region that can only be accessed when the CPU is in SMM.

The MSRC001_0113 register, on the other hand, is the TSEG mask that configures, among others, the size of the protected TSEG region, the memory range type and whether the TSEG or ASEG region should be enabled.

However, the definition of this register also tells us an important fact, namely that the ASEG and TSEG region are used to securely store SMM code and data so that it cannot be accessed when the CPU is not in SMM. If we can disable these regions, we can directly access SMM memory from the kernel.

The bits controlling whether the ASEG and TSEG regions are enabled are bit 0 and bit 1 in the SMM mask register, respectively. By setting these bits to 0, the protections should be disabled.

Having found this issue in a relatively modern system came as quite a surprise, as it was first documented by Duflot et. al. in 2006 [5] and since then, at least for Intel platforms, OEMs have basically eradicated it.

Exploitation

To exploit this vulnerability, we run the Read&Write Utility and add the SMM TSEG mask register to the list of custom MSR registers:

Next, we set the last two bits, corresponding to the ASEG and TSEG valid bits, on all CPUs to 0:

Finally, we confirm that the beginning of the TSEG region is accessible by inspecting the memory:

The magic SMMS3_64 at the start of the TSEG is the first member of the SMM_S3_RESUME_STATE structure, which, based on the EDKII reference code, gets mapped here (https://github.com/tianocore/edk2/blob/7c0ad2c33810ead45b7919f8f8d0e282dae52e71/OvmfPkg/SmmAccess/SmramInternal.c#L187):

From here on exploitation is trivial as we have full read and write access to SMM memory.

Here is the SMRAM dump for those who want to perform additional analysis on it: https://github.com/IOActive/uefi_research/tree/main/acer_swift_3_sf314_42

Timeline

06 August 2022: Reported vulnerability
22 September 2022: Confirmed vulnerability and working on fix
14 October 2022: Discussing timelines
18 October 2022: Confirmed patch release date
20 October 2022: Patch released
24 October 2022: Acer published bulletin

References

[1] https://github.com/chipsec/chipsec
[2] https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1027
[3] Ring -1 vs Ring -2: Containerizing Malicious SMM Interrupt Handlers on AMD-V, Pete Markowsky
[4] BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 15h Models 70h-7Fh Processors, Revision 3.09, AMD
[5] Using CPU System Management Mode to Circumvent Operating System Security Functions, Duflot et al

GUEST BLOG | October 26, 2022

Remote Writing Trailer Air Brakes with RF | Ben Gardiner, NMFTA

Over the course of a few years and a pandemic, we (AIS and NMFTA) tested several tractor-trailers for the security properties of the trailer databus, J2497 aka PLC4TRUCKS. What we discovered was that 1) this traffic could be read remotely with SDRs and active antennas but, more importantly, 2) that valid J2497 traffic could be induced on the trailer databus using SDRs, power amplifiers and simple antennas. In this blog post we will introduce you to some concepts and the discoveries overall – for the full technical details please get the whitepaper.

J2497 aka PLC4TRUCKS is a Power Line Carrier (PLC) scheme designed and implemented by Intellon as a bridge between UARTs over powerlines in the Intellon SSC P485 transceiver IC. For years this patented chip was the only way to realize the J2497 standard. With the recent expiration of the patent, this has changed, but the as-implemented behavior of the Intellon chip is still the de facto standard, and the J2497 specification itself has SSC P485-specific components to it. It was developed and deployed as an alternative physical layer to J1708 for the J1587 protocol that sits on top of it; the SSC-P485 converts bi-directionally between J1708 and J2497.

Offering this as a ‘conversion chip’ allowed suppliers to provide PLC4TRUCKS trailer controllers based on previously fielded J1708/J1587 solutions. This was very beneficial for the rapid deployment of solutions for the impending tailer ABS fault lamp regulations of the time but also meant that the trailer equipment inherited legacy features from the J1708/J1587 code. We were very interested in what diagnostic features were implemented in the trailer controllers using J1708/J1587 mechanisms and eventually found during the ‘Powermaster’ project that all trailer controllers and even some tractor controller did respond to the J1708 ‘data link escape’ means of executing proprietary diagnostics.

The ‘Powermaster’ project really kicked off in 2019. Much like the work that Baker, et. al.,^[1] released earlier that same year (simultaneous to our own testing, during which we found remote read capability), in which these authors demonstrated that Intellon’s (then-Atheros’, which would become Qualcomm’s) HomePlug GreenPhy (HPGP) Power Line Communications (PLC) can be received at distances of several feet using Software Defined Radios (SDRs). We eventually published our remote read findings at the Car Hacking Village DEF CON 29 SAFE MODE^[2] in 2020. Our results were the same: the much earlier (perhaps original) Intellon PLC scheme in J2497 can be read remotely, just like the modern incarnation in HPGP.

The remote read issue was reported in 2020, but during this time we were also testing for remote write – that part didn’t go so smoothly, more on that later. What we eventually confirmed was that it is possible to write remotely to J2497 via induced RF, depending on the equipment configuration (again, just like Baker et. al. who reported a wireless disruption issue in HPGP in February 2022^[3]). We found that the most susceptible equipment is tanker trailers and 3x road train trailers. The equipment from all trailer and tractor brake suppliers is affected and the maximum distance can be up to 12 feet. Furthermore, the equipment needed to make it work is not expensive: as cheap as $300 USD for the most susceptible trailer equipment configurations. For details on the confirmed results and testing methods we followed, please consult the tables in NMFTA’s Disclosure of Confirmed Remote Write.^[4]

What we’ve confirmed is that all three of today’s trailer brake suppliers implement diagnostics over J1587 on J2497 using Data Link Escapes (DLEs). We have encountered no diagnostics features there that require any authentication or authorization, meaning it is susceptible to a replay attack. In the ‘Powermaster’ project we eventually gravitated to testing with transmission of solenoid test commands because we found we were unable to measure the induced waveform voltages even though the valid J2497 messages were clearly being received; and the solenoid test commands have an audible response from the brake controllers which makes the test tests easy to confirm. It also made it easy to film, which we did and presented a couple videos at our DEF CON 30 talk which is now available on the media server^[5].

We still aren’t sure of how the attack to induce valid messages is successful (we do have some theories^[6] presented in the whitepaper) but we do know where it works and doesn’t:

Tankers, which are large metal shells and whose wiring typically runs out along their side, are very susceptible
Dry vans with wooden decking and metal beams are not very susceptible, as compared to trailers with the same dimensions but with metal decking. In these, the wiring runs under the decking and through the beams. In the metal decking trailers we tested, the wiring ran inside an extruded channel.
Even the least susceptible dry-van trailers with wooden decking are susceptible when in a 3x road train configuration.

In addition to the Powermaster project with AIS we also developed mitigation techniques and technologies which we released into the public domain^[7]. We then worked with CISA VDP on a coordinated disclosure and was able to eventually share the attack and mitigation details with the ATA TMC task forces that are responsible for defining the next generation tract trailer interface and are actively doing so today. The industry is focused on newer communications methods because J2497 never delivered on even its modest bandwidth promises. However, there’s the problem of 20 years’ worth of tractors and trailers using J2497. More than half of them will continue to be used for another 15 years. In addition to requesting that diagnostics on J2497 be excluded from the NGTTI we have also requested that all new tractors include mitigations against the J2497 remote write attack so that new tractors can protect older trailers. And at the Sept 2022 ATA TMC meeting the Task Force accepted our recommendations with a vote of 14 in favor to 4 against.

We will keep working with the ATA TMC task forces to ensure that the next-generation tractor-trailer interface does not inherit the issues we’ve seen in J2497. We are also looking for more testing opportunities to confirm these results on other equipment, as well as opportunities test new concepts.

Don’t forget to access the whitepaper for the full details to the research.

If you would like to host us for some testing^[8], please contact ben.gardiner@nmfta.org.

Ben Gardiner

Ben Gardiner is a Senior Cybersecurity Research Engineer contractor presently working to secure commercial transportation at the National Motor Freight Traffic Association (NMFTA). With more than ten years of professional experience in embedded systems design and lifetime worth of hacking experience, he has deep knowledge of the low-level functions of operating systems and the hardware with which they interface. Prior to partnering with the NMFTA team in 2019, he held security assurance and reversing roles at a global corporation, as well as working in embedded software and systems engineering roles at several organizations. He holds a Masters of Science in Engineering in Applied Math & Stats from Queen’s University. He is a DEF CON Hardware Hacking Village (DC HHV) volunteer, is GIAC GPEN certified and a GIAC advisory board member, he is also chair of the SAE TEVEES18A1 Cybersecurity Assurance Testing TF (drafting J3061-2), and a voting member of the SAE Vehicle Electronic Systems Security Committee.

^[1] Baker, Richard, and Ivan Martinovic. “Losing the Car Keys: Wireless {PHY-Layer} Insecurity in {EV} Charging.” 28th USENIX Security Symposium (USENIX Security 19), 2019.
^[2] Poore, Chris, and Gardiner, Ben. “Power Line Truck Hacking: 2TOOLS4PLC4TRUCKS.” DEF CON 30 Car Hacking Village 2019. http://www.nmfta.org/documents/ctsrp/Power_Line_Truck_Hacking_2TOOLS4PLC4TRUCKS.pdf?v=1
^[3] Sebastian Köhler and Richard Baker and Martin Strohmeier and Ivan Martinovic, “Brokenwire : Wireless Disruption of CCS Electric Vehicle Charging” 2022 https://arxiv.org/pdf/2202.02104.pdf
^[4] Gardiner, Ben, NMFTA Inc. “2021 Disclosure of Confirmed Remote Write.” http://www.nmfta.org/documents/ctsrp/Disclosure_of_Confirmed_Remote_Write_v4_DIST.pdf?v=1
^[5]https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20video%20and%20slides/DEF%20CON%2030%20-%20Ben%20Gardiner%20-%20Trailer%20Shouting%20-%20Talking%20PLC4TRUCKS%20Remotely%20with%20an%20SDR.mp4
^[6] the theory that we induce more voltage on the chassis and hence the receiver picks up a single-ended voltage seems promising considering that CharIn has adopted differential PLC for all HPGP connections in their megawatt charging interface
^[7] Gardiner, Ben. “Mitigations Options to J2497 Attacks” March 3^rd 2022. http://www.nmfta.org/documents/ctsrp/Actionable_Mitigations_Options_v9_DIST.pdf?v=1
^[8] Gardiner, Ben. “NFMTA CTSRP Heavy Vehicle Testing Plan” March 1^st 2022. https://github.com/nmfta-repo/nmfta-vehicle_cybersecurity_requirements/blob/main/resources/heavy_vehicle_testing_plan.md

INSIGHTS, RESEARCH | September 29, 2022

NFC RELAY ATTACK ON TESLA MODEL Y

By IOActive

Josep Pi Rodriguez, Principal Security Consultant, walks you through the proof-of-concept and technical details of exploitation for IOActive’s recent NFC relay attack research on the newest Tesla vehicle, the Model Y. To successfully carry out the attack, IOActive reverse-engineered the NFC protocol Tesla uses between the NFC card and the vehicle, and we then created custom firmware modifications that allowed a Proxmark RDV4.0 device to relay NFC communications over Bluetooth/Wi -Fi using the Proxmark’s BlueShark module.

It’s well-known in the vehicle security industry that NFC relay attacks (as well as Radio Frequency relay attacks) are a serious issue, and that they’re currently being used to steal cars. This type of attack consists of relaying cryptographic material between the vehicle and the virtual key (NFC card or smartphone).

Here you can find the paper with full technical details:

Download Paper

Attack in testing environment with logs.

The Proxmark device is connected to a laptop with USB cable to show the Proxmark’s logs in realtime on the laptop’s screen. The Tesla NFC card is placed on an USB NFC reader that is connected to another laptop to show the logs of the python tool created during the initial phases of testing. This second laptop with the python tool will act as the smartphone that the mule will use in the real attack.

Attack using Proxmark and smartphone on the streets.

In the second video, we demonstrate the attack in a more real-world scenario using the Proxmark and the smartphone application. The first attacker waits for the victim to leave the car, then gets close to the vehicle’s reader with the Proxmark. In the meantime, the second attacker will get closer to the victim and use a smartphone to read the Tesla NFC card in the victim’s pocket.

About final thoughts:

Time limitation seems to be very permissive, and it was possible to perform this attack via Bluetooth from several meters away, as well as via Wi-Fi with much greater distances. We believe it may be possible to make it work via the Internet as well.

Only one challenge/response is required to open and drive the car when the “PIN to Drive” feature is not enabled in the vehicle.

One of the attackers does have to be very close to the victim’s card when the mule is using a smartphone. This distance might change depending on multiple factors, but a distance of 4 cm or less might be fairly precise when using a smartphone. Using a more specialised, high power device might make this distance much bigger. In the following links is possible to read an old paper demonstrating it and also a a link with one of those long range readers that can be hidden in a backpack/purse while performing the attack:

https://eprint.iacr.org/2006/054.pdf

https://lab401.com/products/long-range-rfid-reader-writer-dl533n-xl

We actually bought this long range antenna and perform some tests to show that more than 10cm can be used to read the victim’s card / smartphone. We will use it in future proof of concepts shortly. The following video shows it working while reading an NFC card with more than 10cm distance:

However, 4cm can be enough in some scenarios when the victim is distracted, like a crowded night club/disco. If the attacker at the vehicle is ready at the driver’s door, then contact with the victim’s NFC card needs to only be for one to two seconds to be effective.

It is also important to clarify that this attack also works against smartphones that have the NFC capability to open the vehicle. Instead of targeting the Tesla NFC card, the victim’s smartphone would be the target.

PRESENTATION | August 17, 2022

Vulnerability and Patch Management: Every Day is a Zero Day

By John Sheehy

SC Media on-demand presentation | John Sheehy, SVP of Research and Strategy, participated as a panelist on the CyberRisk Alliance’s eSummit live broadcast.
Patch management can be an especially precarious proposition when you’re operating in a work environment where machines and devices must constantly remain operational. Hospitals, factories and power plants are among the many examples of settings where security professionals need to “keep the lights on,” even as they strive to ensure that software and hardware are hardened against the latest vulnerabilities and exploits. The discussion focused on the challenges of patching in ICS/OT/IoT environments, and strategies for balancing security with operational continuity. access it here

GUEST BLOG | June 14, 2022

The Battle of Good versus Evil: Regulations and Cybersecurity | Urban Jonson

Okay, so the title might be a little over the top, but we are at a very critical stage in the balance between government regulations and cybersecurity. With fifteen years in the transportation industry, I am seeing an important trend in transportation regulations, especially pertaining to heavy vehicles and trucking. This trend is also observable across other industries but it is in trucking that we are seeing clear and immediate issues.

The purpose behind most government regulations is to try to improve safety, protect the environment, reduce pollution, and in general make the world a better place. We can argue that the intentions of these regulations are actually good. I mean, we really don’t want to pollute the environment or have massive safety issues. Right? Well, as has been pointed out to me repeatedly, the road to hell is paved with good intentions. Unfortunately, the technocrats who create regulations are usually not qualified in computer science or more specifically cybersecurity. In the case of cybersecurity, we have seen a lot of unintended consequences over the past few years.

When the original vehicle Controller Area Network (CAN bus) was designed, it was to be a closed and trusted system. Therefore, security concerns like authentication, authorization, secure software development lifecycles, etc. were not considered. Let’s be honest, in the 1980s when the CAN bus network was unveiled at Society of Automotive Engineers (SAE), cybersecurity was not much of a thing anywhere. (This is the time I was getting into computers and I can attest to the lack of computer security…. never you mind how.) We are now in a technology transition period where we are taking systems which were designed to be closed and trusted and adding internet connectivity with little forethought. This is true with many CAN-based systems found on, planes, trains, trucks, automobiles, water treatment plants, power stations, etc. This transitional period is fraught with risk as we bring these old system designs online and the pace is accelerating.

The first wave of connectivity came in the form of productivity and enhanced performance. For example, telematics was a thing in trucking long before any regulator thought to mandate direct connectivity to trucks. Some of these telematics systems connected directly to the vehicle and some did not. Some were read-only and some were not. Some were outright terrifying from a cybersecurity perspective. That being said there was a choice to what to connect to your truck and how to do it.

Most people who are familiar with my work at NMFTA with the Commercial Transportation Security Research Program are probably familiar with the work that I and IOActive have done bringing attention to the cybersecurity issues regarding the rollout of the US Department of Transportation (US DOT) Federal Motor Carrier Safety Administration (FMCSA) Electronic Logging Device (ELD) regulations. Yeah, that’s a lot of acronyms! Corey Thuen did some presentations on the topic including at DefCon, and I have written and talked about it a lot. What made the ELD regulations so novel and problematic was that they mandated an electronic logging device without any material cybersecurity controls be connected to the vehicle CAN bus with read and write capabilities (at the time no OEM broadcast engine hours, so it had to be requested by sending a message on the bus) and that it be connected to the internet. What that really meant was that a read-write internet bridge to a system, that was originally designed as a trusted and closed system, was now required under the force of law. Yeah, I know. What could possibly go wrong?

Since the original regulations came out, there have been addendums and follow-ups including references to cybersecurity which were missing from the original regulations. Many people in the industry worked tirelessly to implement the required functionality in existing ELD systems and make sure they were as secure as the provider could manage. A large number of smaller providers popped up as there was a relatively low-cost barrier to entry. Some of these new, low-cost providers had interesting solutions that included almost no security at all. Think hardware with debug enabled, registration links with passwords in clear text. A total mess. So as a result, some of the new ELD systems are great and some of them are nothing short of terrifying from a cybersecurity perspective. While I was at NMFTA, we developed a whole matrix to evaluate the cybersecurity posture of telematics systems. OEMs have started broadcasting engine hours so write capabilities to the CAN bus are not needed to have a compliant ELD device. Telematics providers have started migrating from being connected directly to the on-board diagnostics (OBD) port—many times as spliced-in connections—to being connected to a connector intended for permanent and semi-permanent aftermarket equipment installation (RP 1226) that is increasingly being firewalled in truck designs.

So, that’s it right? We learned our lesson and we won’t do this again. Yeah, that would be wishful thinking. The trend for regulations mandating real-time vehicle information is increasing at a rapid pace. In the EU, they are working on the next set of vehicle emissions regulations, Euro VII , which will reportedly include real-time connectivity and reporting requirements for heavy vehicles, including information such as emissions readings and so forth. China, who generally follows the Euro standards, expanded on Euro VII to include a China 7b which includes real time connectivity and monitoring of exhaust information for trucks. In the US, the California Air Resource Board (CARB) is finalizing a new set of Heavy-Duty Inspection and Maintenance (HD I/M) regulations. The full details regarding this regulation effort can be found at https://ww2.arb.ca.gov/rulemaking/2021/hdim2021. These regulations include the concept of a Continuously Connected Remote On-Board Diagnostic (CC-ROBD) device which is to be semi-permanently installed into heavy vehicles operating in California. The purpose is to get more frequent and accurate vehicle emissions information to encourage vehicle operators to fix malfunctioning trucks quicker and to improve maintenance programs to avoid faults. The idea is that fixing faulty trucks and improving their operating efficiency will reduce emissions overall. Most of the fleets and OEMs that I work with already have extensive predictive maintenance capabilities and are already incentivized by fuel costs to ensure their trucks are in good working order. The regulations do not expand on what is already expected from an OBD port, but regulators would like the data reported remotely with a much higher degree of frequency. So, at the surface, everything should be aligned. Well… due to what is, in my opinion, a lack of overall industry and regulatory coordination and facilitation, the CARB regulations specify that the CC-ROBD needs to be connected to the OBD port and have read/write access to obtain the necessary emissions information.

Hey, CARB invented and regulated the OBD port into existence. Why shouldn’t they be using it? My friends at Geotab have an excellent history of the OBD port. Ever since the OBD port was put in place it has been reused for a number of different use cases apart from just emissions. It’s how we diagnose vehicle trouble codes, upgrade firmware, and even add optional features. It has become an all-powerful connection which bridges many vehicle networks. Now, I am not saying that you can’t connect to the OBD port in a secure and responsible manner. All I’m saying is that it is very hard to do, and requires significant organizational commitment to cybersecurity and investment in technology and processes. I’ve seen telematics providers who do an excellent job. (Hint: the $50 ELD device at Walmart or the “free” dongle from your insurance company are probably not of that caliber.) The HD I/M regulations do reference some basic cybersecurity requirements for the CC-ROBD devices, including SAE 3005-1 and SAE 3005-2, but there is a lot of wiggle room in there for issues to develop. For example, SAE 3005-2 specifies that only diagnostic messages should be allowed but it is commonly known that diagnostic messages can be abused. Just look at the research done by Ben Gardiner, et. al. on J2497. At least CARB is not allowing self-certification, so maybe we are learning after all.

So, as the trucking industry is moving from OBD and spliced-in wiring harnesses to the RP 1226 connector, they are being pushed back onto the OBD port. Given that this new regulation is scheduled to become effective in 2024, this could cause some serious problems. It takes most large fleets about two years to find, select, test, and deploy a new telematics device to their fleets. The engine designs for 2024 are already pretty much set in stone, so there is not much time to affect any changes to new tractors, never mind the existing ones. Add to this a global supply chain which is completely out of whack and we have the potential for a rather interesting convergence of events. And by interesting, I mean a total disaster.

As we introduce regulations to improve air quality, we may be setting ourselves up for bare shelves if we can’t field compliant trucks in California, which receives most of the inbound freight from China, Taiwan, etc. Remember, trucks move most goods from ports to inland destinations. As we are fond of saying, “If you bought it, a truck brought it.” If we can’t field compliant trucks in California this is not just an issue for California, but for the nation as a whole. Remember, trucks are a critical part of the supply chain delivering food, fuel, parts, raw materials and practically everything we need to keep everything running.

Obviously, my hope is that by raising awareness, the industry and regulators can come up with a solution that works for everyone and keeps our nation’s freight moving. While I am frustrated at our inability to learn our lessons, I am also hopeful and confident that the ever creative and resilient transportation sector will find a way to manage. Organizations such as IOActive are helping telematics vendors and vehicle OEMs assess the cybersecurity of their products. I am working within the industry to help them understand their cybersecurity posture, upcoming regulations which may impact their operations, and to help them come up with plans to reconcile conflicting requirements and mitigate risk. More importantly we still have time…but not much to avoid this potential disaster.

Regards,
Urban Jonson

You can now find me at SERJON providing advisory services in cybersecurity and general information technology. Please feel free to reach out to me at ujonson@serjon.com. I want to thank IOActive for being gracious enough to host this blog entry, as well as John Sheehy of IOActive and Ben Gardiner at Yellow Flag Security for their contributions to this post.

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

WHITEPAPER | April 19, 2022

Reverse Engineering of DAL-A Certified Avionics: Collins’ Pro Line Fusion—AFD-3700

By Ruben Santamarta

Ruben Santamarta, IOActive Security Researcher, presents a highly technical and detailed look into reverse engineering the DAL-A Certified Avionics: Collins’ Pro Line Fusion—AFD-3700.

Modern avionic systems are designed according to the Integrated Modular Avionics concept. Under this paradigm, safety-certified avionic applications and non-critical airborne software share the same computing platform but are running at different partitions. In this context the underlying safety-critical certified RTOS provides the logical isolation, which should prevent unintended interactions between software with different criticalities.

This paper provides a comprehensive analysis of the architecture and vulnerabilities found on the Adaptive Flight Display component of the Collins Aerospace’s Pro Line Fusion solution. This integrated avionics system, deployed both in military and commercial aircraft, is certified as DO-178B/C Design Assurance Level A.

Get the Whitepaper

INSIGHTS, RESEARCH | April 5, 2022

Satellite (In)security: Vulnerability Analysis of Wideye SATCOM Terminals

By Ethan Shackelford

Introduction

This blog post introduces our most recent whitepaper detailing original research into two SATCOM terminals manufactured by Addvalue Technologies, Ltd.: the Wideye iSavi and Wideye SABRE Ranger 5000.

We identified numerous serious security vulnerabilities in both devices, including broken or backdoored authentication mechanisms, rudimentary data parsing errors allowing for complete device compromise over the network, completely inadequate firmware security, and sensitive information disclosure, including the leaking of terminal GPS coordinates. These issues were present in all reviewed firmware versions, including the currently available release.

Research Goals

The primary goal of this research was to determine the security posture of these two SATCOM terminals, whose application spans multiple industries. By taking the results of this research in isolation, IOActive hopes to gain insight into the current state of security in the SATCOM industry. Additionally, by comparing the research results with the conclusions drawn from the research we conducted in 2014 and 2018, it is possible to assess how much progress toward improved security has been made in that time.

Furthermore, given the bleak outlook of the findings of this research, IOActive hopes that the publication of this information will increase awareness of these issues and make the necessity of immediate corrective action very clear.

Research Targets

Wideye iSavi Portable SATCOM Terminal

The Wideye iSavi is a portable satellite terminal operating over the Inmarsat iSatHub and BGAN services, offering voice, text, and Internet connectivity to devices connecting to the iSavi via a built-in WiFi access point. It is designed for general consumer use as per the Wideye documentation, allowing maintained connectivity for those outside the range of coverage of traditional ground-based Internet infrastructure. It may or may not be configured to be accessible over the broader Internet and can be managed remotely via a web interface or other means.

Wideye SABRE Ranger 5000

The Wideye SABRE Ranger 5000, built on technology similar to the iSavi, is a BGAN Machine-to-Machine (M2M) satellite terminal. It is designed to operate and stay connected to the Internet without interruption and is commonly configured for accessibility over the wider Internet, to allow for remote management. It is intended for industrial use, with the Wideye brochure [1] suggesting its use in the following industries:

Firmware Images

Despite the varied uses, investigation into the two devices indicated that very similar firmware runs on each. As such, all vulnerabilities identified during this research effect both the iSavi and the Ranger, with the impact varying somewhat for each vulnerability based on the use-case of each device.

Firmware versions analyzed during this research include:

iSavi

R01.0.0: The version which was pre-installed on the iSavi originally purchased for the research in 2019
R01.0.1 and R02.0.0: Firmware versions available for download from the vendor website [2] over the course of research beginning in 2019
R02.0.2: Current firmware version available for download from the vendor website as of the publication of this blog post

SABRE Ranger 5000

R01.0.0: The version which was pre-installed on the iSavi originally purchased for the research in 2019
R01.0.3: Current firmware version available for download from the vendor website as of the publication of this blog post

Cyberattacks on SATCOM Infrastructure: Understanding the Threat

Before elaborating on the vulnerabilities discovered during this research, it is important to understand what kind of threat is posed by any given attack, and how to think about that attack’s impact.

Attack Vectors

Since we will be looking at SATCOM terminals, it is important to understand the paths available to an attacker for potential device access. Figure 2 comes from the SABRE Ranger M2M (an older SABRE Ranger model) marketing brochure [3] and lays out the architecture of SATCOM terminal communication nicely. The layout for the iSavi differs slightly, in that its internal network is established over WiFi, but the diagram is still accurate at a high level.

External Network

Both the Ranger and the iSavi have the capability to be made accessible over the Internet, with or without a static IP address. This feature is more likely to be enabled on the Ranger, as its stated purpose includes remote access of resources to which it is connected.

Internal Network

Both the Ranger and the iSavi support some means of connecting the devices to a local IP network, which will then allow for routing of data between those devices and the Internet. For the iSavi, this is a WiFi access point. The Ranger includes two Ethernet ports which serve the same purpose.

Other Interfaces

While the iSavi’s functionality is limited to network connectivity, the Ranger also includes various physical interfaces for industrial equipment, including GPIO, analog, serial, and ModBus. While these interfaces could potentially be subject to vulnerabilities, exploitation via these interfaces would require physical access to the equipment, and as such are of lower impact than those attacks which can be performed remotely/semi-remotely. However, it is important to consider the impact that the compromise of this device might have on connected equipment; Figure 3 is from the Ranger 5000 brochure12 and provides an example of the kinds of equipment that would be under attacker control in such a scenario.

Attack Scenarios

The whitepaper lays out several plausible attack scenarios for the SABRE Ranger 5000 and the iSavi, taking into account the intended applications of each device and leveraging one or more of the vulnerabilities identified during this research. These scenarios include potential disruption of Emergency Services operations for the iSavi, and an undetected attack on critical Oil and Gas infrastructure for the SABRE Ranger 5000. In both cases, a reasonable case for a risk to human safety can be made.

Findings Overview

Conclusion

The stated goal of this research was to assess the security posture of two SATCOM terminals, the iSavi and SABRE Ranger 5000 from Wideye. Our assessment found the security of both devices to be extremely poor and cause for serious concern to the various industries which may make use of these products, including Oil and Gas, Agriculture, Utilities, Mining, and any remote work which must rely on satellite connectivity due to location or circumstance.

Taking these results in isolation, our assessment gives clear indication that neither the Availability, Integrity, nor Confidentiality of either the iSavi or Ranger 5000 is protected from compromise. These devices are affected by numerous vulnerabilities which are well established in the industry, with proposed fixes and well-known best practices in some cases for several decades. In other cases, the devices have been made less secure by design, with the introduction of several sets of hardcoded “backdoor” credentials—a practice understood to be insecure in all industries.

The results indicate that those devices exposed to the wider Internet, a possible configuration for the Ranger 5000 (whose marketed purpose is remote management of industrial assets), are at especially high risk. However, even if the devices are not exposed directly to the Internet, many vulnerable services are unnecessarily exposed to the satellite network, which still provides ample opportunity for attack from within that network.

Users of these devices can take steps to mitigate some of these issues, such as enabling the device’s firewall and heavily restricting access to only those IPs explicitly known to be trusted. This is not a panacea and does not fully protect these devices. The final responsibility for securing the iSavi and Ranger 5000 lies with the vendor, who is the only entity in a position to meaningfully correct the issues identified in this paper.

Taken in the wider context of the SATCOM industry and IOActive’s previous research in this field, the results of this research are a uneasy indication that the SATCOM industry has not heeded the many warnings of researchers and security professionals over the last decade, maintaining an unacceptable attitude toward security inappropriate in the face of the threat landscape of the modern age. As SATCOM technology becomes more advanced and is relied on more heavily by a variety of sectors, the security of this industry will only become more vital. It is in the hands of SATCOM vendors to rapidly modernize their approach and attitude toward security.

References

[1]: https://www.addvaluetech.com/wp-content/uploads/2021/05/SABRERanger5000_WE190205032100_en.pdf
[2]: https://www.addvaluetech.com/pdf_categories/firmware/
[3]: https://www.wideye.com.sg/default/uploads/Brochures/SABRERangerM2M_WE074210051500_EN.pdf

WHITEPAPER |

Cyberattacks on SATCOM: Understanding the Threat

By Ethan Shackelford

In 2014, Ruben Santamarta, Principal Security Consultant with IOActive, published a whitepaper titled “A Wake-up Call for SATCOM Security.” It detailed the discovery of an exceptionally weak security posture across a number of SATCOM terminals from a range of manufacturers. Four years later in 2018, Ruben published a follow up titled “Last Call for SATCOM Security” which detailed a thorough investigation into the security of SATCOM equipment across the Aviation, Maritime, and Military industries. In light of the cyberattacks at the start of the war in Ukraine, once again, the security posture was found to be overwhelmingly poor and in need of immediate and thorough corrective action by manufacturers.

Get the Whitepaper