IoT
Threats From a Compromised 4G/5G Campus Network
5G acts as a catalyst for change for industrial environments. One part of its deployment is the 4G/5G campus network for some organizations. In our research we delve into the security risks and implications of this technology.
Over the past two decades, industrial sectors and everyday users have reaped the benefits of advancements in telecom technologies. At present, the catalyst and basis for future changes is 5G. A sign of this continuing development and influence for some industries is their investment in non-public networks (NPN), also commonly referred to as campus networks.
The 4G/5G campus network helps fulfill the growing requirement among industries for higher availability, lower latency, better privacy, and network isolation. However, it can also open security gaps, wherein IT experts and operational technology (OT) personnel might find themselves lacking the knowledge to address telecom-related threats in an expanded attack surface.
In our research titled “Attacks From 4G/5G Core Networks: Risks of the Industrial IoT in Compromised Campus Networks,” we delve into the security risks involved in deploying a 4G/5G campus network. After creating our own 4G campus network, we tested different attack scenarios to show what kind of threats these entail and how to defend a campus network against them. In this entry, we give an overview of our research and some of the common attack scenarios that we tested.
The 4G/5G Campus Network
A campus network is limited within a geographic area, and it is also limited by Ethernet cables and a cellular network.
For our research, we used only the minimum number of devices for our campus network. Its core network represents either a campus network implemented on-premises or connectivity to an external cellular service provider. It also had a single base station (a small cell). Its other components included an industrial router, a control network, a field network, and multiple programmable logic controllers (PLCs).
Our research paper gives a more detailed account of both the campus network that we set up and the core network configuration that we used. We also go through the different types of campus networks and deployment options to provide a full guide and introduction to this topic.
Points of Compromise
The attack scenarios that we were able to demonstrate were rooted from a compromised core network. Therefore, we first had to show how an attacker can infiltrate a core network. In our research, we identified four entry points that can allow an attacker to compromise a core network:
- Server hosting core network services. An attacker could exploit well-known vulnerabilities since campus networks use standard servers (COTS x86 servers).
- Virtual machine (VM) or container. Regularly patched VMs and containers narrow the attack surface for this entry point. However, VMs and containers are not regularly patched. Common misconfigurations can also lead to unforeseen exposures and compromises.
- Network infrastructure. Unpatched infrastructural appliances can be used to infiltrate a company network. Attackers can, for example, use managed routers, switches, firewalls, or even cybersecurity appliances to intercept packets.
- Base stations. Possible vulnerabilities in base stations can allow attackers to infiltrate the core network.
Common Attack Scenarios From a Compromised Core Network
By taking over these four entry points, attackers would not need to be experts on telecom technologies to be able to launch attacks from an IP network. In the following, we discuss some of the common attack scenarios that we were able to test. It is important to note that these scenarios show how a compromised core network can be another opening for both threats that already affect industrial control systems (ICSs) and threats that could cause significant damages.
MQTT Hijacking
Modern ICSs support sending readings to the cloud via MQTT protocol. For maximum security, the MQTT can be protected by a password and TLS. However, this is typically absent in the field. If an attacker successfully changes the telemetry or messages sent to the cloud, then they would be able to affect analysis algorithms and statistics. The attacker can also intercept MQTT to temporarily conceal what they have done in remote sites.
This is illustrated in the fictional steel mill that we examine in our paper. In this steel mill, MQTT messages for temperature sensor readings were intercepted and modified. As a result of the internal temperature being modified, there was a rise in actual temperature. However, the rise was not reflected in the external audit logs.
Modbus/TCP Hijacking
A VPN is typically used between remote sites and the control network. However, for instances where the VPN is not used or when Modbus servers are directly connected to the campus network, an attacker can write a Modbus parser to change the Modbus function codes and data values in the packets.
This leads to a scenario that is similar to MQTT hijacking. In the steel mill, data sent to the control HMI was manipulated using this attack. The operators in the control room would not see anything amiss, even when in reality, the pressure, the airflow, and the temperature have gone above normal levels, thus leading to numerous impacts on the precise processing of alloys.
Remote Desktop Attack
Remote desktop is extensively used in remote sites. IT and field engineers use VNC or Microsoft Remote Desktop. While it is common for remote desktop sessions to be password-authenticated, this does not automatically mean that they are encrypted. Depending on the configured encryption options, an attacker sitting at the points of entry has the opportunity to sniff RDP port 3389 or VNC port 5900 in order to log keystrokes and passwords.
For example, an attacker would be able to sniff keystrokes by performing a downgrade attack on RDP in the core network. With regard to VNC, an unencrypted VNC with a connection password can be brute-forced and keystrokes can still be logged.
In the steel mill, the attacker in this scenario would be able to obtain access through the VNC. This opens many different options for them, with their next steps determined by their motivations. For example, they can choose to intercept the PLC directly or install ransomware.
These are just examples taken from several common attack scenarios that we were able to test on our campus network. Our research paper gives a more technical description of more attack scenarios, including the three described previously. The paper also discusses cellular-specific attack scenarios, which can only be delivered via a cellular network. The cellular-specific attack scenarios are a good starting point for narrowing the knowledge gap between the fields of IT, OT, and telecommunications technology.
Security Recommendations
In two or three years, 4G/5G campus networks will be deployed in more industrial systems. 4G campus network owners will also transition to 5G in the near future. In order to maintain a competitive edge, therefore, organizations must evolve — and that entails gearing up for 5G.
The changes have a huge impact on security and further implications on the roles that both IT and OT experts play in industrial systems. These experts need to expand their knowledge in line with the convergence of this new trio: IT, OT, and now communication technology (CT). The following are some general security recommendations for 4G/5G campus networks:
- Use application layer encryption, such as HTTPS, MQTTS, LDAPS, or any well-designed industrial protocols.
- Rely on proper network segregation, VLAN, and IPsec to defend industrial facilities that run campus networks.
- Apply the latest patches for operating systems, routers, and base stations as soon as the patches are available.
- Since LTE and 5G do not automatically address the need for encryption, use VPN or IPsec to help protect remote communication channels, including remote sites and base stations.
In our research titled “Attacks From 4G/5G Core Networks: Risks of the Industrial IoT in Compromised Campus Networks,” we also share specific mitigation tactics for the attack scenarios.