Society relies so heavily on technology that the number of internet connected devices used globally is predicted to grow to 55.9 billion by 2025. Many of these devices span parts of Industrial Control Systems (ICS) that impact the physical world, assist us in our daily lives at home and monitor and automate everything from energy usage to machine maintenance at work. The potential to abuse these systems has already caught the eye of cybercriminals; according to the 2020 IBM X-Force Threat Intelligence Index, attacks against these systems increased over 2000% since 2018.
As part of their ongoing research, IBM’s team of hackers, X-Force Red, have discovered a new IoT vulnerability that can be exploited remotely. The manufacturer, Thales, has made a patch available for CVE-2020-15858 to customers since February 2020 and X-Force Red has been working together to ensure users are aware of the patch and taking steps to secure their systems.
Of the billions of smart devices in use today, Thales is one of leading makers of components that enable them to connect to the internet, securely store information and verify identities. Thales’ entire portfolio connects more than 3 billion things every year and more than 30,000 organizations rely on its solutions for everything from smart energy meters to medical monitoring devices and cars.
However, in September 2019, X-Force Red discovered a vulnerability in Thales’ (formerly Gemalto) Cinterion EHS8 M2M module used in millions of internet-connected devices over the last decade. After further testing, Thales confirmed that this vulnerability affects other modules within the same product line of the EHS8 (BGS5, EHS5/6/8, PDS5/6/8, ELS61, ELS81, PLS62), further expanding the potential impact of this vulnerability. These modules are mini circuit boards that enable mobile communication in IoT devices.
More importantly, they store and run Java code often containing confidential information like passwords, encryption keys and certificates. Using information stolen from the modules, malicious actors can potentially control a device or gain access to the central control network to conduct widespread attacks – even remotely via 3G in some cases. Using this flaw, attackers could potentially instruct smart meters to knock out a city’s electricity or even overdose a medical patient, as long as the devices responsible for these critical functions are using an unpatched module exposed to an attacker, for example, over the 3G/4G connection this module enables.
About the Vulnerability
The EHS8 module, and the others in its line, is designed to allow secure communications between connected devices via 3G/4G networks. Think of this module as the equivalent of a trustworthy digital lockbox, where companies can securely store a range of secrets such as passwords, credentials and operational code. This vulnerability undermines that function by allowing attackers to steal organizational secrets.
X-Force Red uncovered a way to bypass the security checks that keep files or operational code hidden from unauthorized users. This vulnerability could enable attackers to compromise millions of devices and access the networks or VPNs supporting those devices by pivoting onto the provider’s backend network. In turn, intellectual property (IP), credentials, passwords, encryption keys could all be readily available to an attacker. Put another way, confidential information stored by the module may no longer be confidential. Attackers may even grab the application code to completely change the logic and manipulate devices.
What is the Potential Impact?
The potential impact of this vulnerability varies based on which of the devices using this line of modules attackers may compromise. It’s understood that there are millions of devices around the world using this module, across the automotive, medical, energy and telecom industries.
Given the critical nature of many of these devices, a targeted cyberattack could be significant. Here are some examples of what an attacker might be able to do if an unpatched module is exposed in various types of devices:
- Medical Devices: Manipulate readings from monitoring devices to cover up concerning vital signs or create false panic. In a device that delivers treatment based on its inputs, such as an insulin pump, cybercriminals could over or underdose patients.
- Energy and Utilities: Compromise smart meters to deliver falsified readings that increase or reduce a monthly bill. With access to a large group of these devices through a control network, a malicious actor could also shut down meters for an entire city, causing wide-reaching blackouts that require individual repair visits, or, even worse, damage to the grid itself.
Technical Details
The EHS8 module, like the other modules in the line, is comprised of a microprocessor with embedded Java ME ™ interpreter and flash storage – as well as GSM, GPIO, ADC, Digital and Analogue Audio, GPS, I2C, SPI and USB interfaces. It also provides higher level communications stacks such as PPP and IP. The embedded Java environment allows installation of Java ‘midlets’ to provide customizable functionality and interaction with the host device, and/or to act as the main logic. The module behaves much like a traditional ‘Hayes’ modem when operating at the fundamental OEM integrator level. This means, that aside from the Java application loaded onto the system, it can be controlled using ‘AT’ serial commands via a physical UART connection built into the circuit.
In practice, this means that the Java application could be bypassed and the control handed back to the low level, allowing an attacker to control the module directly. Once in control of the AT command interface, it is possible to issue a large number of standard commands such as ‘ATD’ – dial a number, or ‘ATI’ – show manufacturer information. There are also a number of configuration commands and a specific subset of commands for accessing a rudimentary filesystem overlaid on the flash memory – ‘AT^SFA’. This provides for reading, writing, deleting and renaming of files and subdirectories.
To facilitate the Java environment, there are also a number of Java related commands, one of which ‘installs’ a Java midlet previously uploaded to the flash filesystem. This effectively copies the Java code to a ‘secure store’ within the flash filesystem, which is theoretically ‘write only’ – i.e., data can be copied to it but never read back. This way, an OEM’s private Java code containing their IP, as well as any security related files such as PKI keys or certificates and application related databases are secured against theft by third parties.
However, the vulnerability discovered by X-Force Red allows full read, write, delete access to the hidden area (though Thales has put additional checks in place for specific file types). This would allow an attacker to read out the full java code running on the system (both the OEM midlets and Thales’ main ‘master’ code) as well as any other ‘hidden’ support files they may have.
Since Java is easily reversed back to human readable code, this could expose the full logic of any application as well as any embedded ‘secrets’ such as passwords, crypto keys etc. and makes IP theft a very simple operation. Armed with this data, attackers could easily create ‘clone’ devices, or more alarmingly, modify the functionality to enable fraudulent or malicious activities.
Figure 1. Code listing with vulnerability
The figure above shows where the vulnerability exists in the code that counts the number of characters in the path substring and checks if the fourth character is a dot (third indexed in characters array). In normal circumstances, any attempt to access hidden files with a dot prefix will be denied (example: a:/.hidden_file). However, replacing the slash with double slash (example: a://.hidden_file) will cause the condition to fail and code execution will jump to a character checking loop which will match any printable character. After the second slash, which will be ignored by the system, nothing prevents an attacker from using the dot prefixed filename, bypassing the security test condition.
Responsible Disclosure and Remediation
Once this vulnerability was discovered, it was immediately reported to Thales who worked with the X-Force Red team to test, create and distribute a patch to its clients in February 2020.
The patch can be administered two ways – either by plugging in a USB to run an update via software, or by administering an over the air (OTA) update. The patching process for this vulnerability is completely dependent on the manufacturer of the device and its capabilities – for example, whether the device has access to the internet could make it complicated to work with. Another item to note is that the more regulated a device is (medical devices, industrial controls, etc.), the more difficult it is to apply the patch since doing so may require recertification, an often time-intensive process.
We want to commend Thales for their handling of this flaw and for spending significant time working with customers to ensure they were aware of the patches and taking the steps to secure their users. More information on CVE-2020-15858 can be found at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15858.
What X-Force Red Suggests
Considering the significant potential implications of this vulnerability, X-Force Red offers the following steps to mitigate risks and address the issue immediately:
- Apply the patch: Device manufacturers that used the impacted modules need to follow guidance provided by Thales and offer firmware updates as quickly as possible. And device users need to install these updates immediately while also ensuring they’re using the latest version of the module.
- Rethink what you store: Use this moment to think about what information is being stored on these devices and whether it can be stored elsewhere more securely.
- Apply Behavioral Analysis practices: Consider login credentials as only one layer of security and analyze users and devices to identify unusual behaviors. That way, even if a cybercriminal steals those credentials, there will be mechanisms in place to help identify and stop them.
- Ensure IoT is on your security team’s radar: Use a threat management service, like IBM Security’s X-Force Threat Management for IoT, that allows security teams to better understand their environments and respond to threats against unmanaged devices.
- Hire a hacker: Conduct regular penetration tests on your company and devices that identify and help you remediate vulnerabilities in your operations. Look for teams that offer a broad range of testing services including hardware and software testing to make sure you are thoroughly covered. X-Force Red offers hardware and IoT testing that can help reduce your risk from this specific vulnerability and others.
Information on this vulnerability and other research will be presented during X-Force Red’s virtual Red Con 2020 event, taking place August 19. For more information and to register, visit the Red Con event page.
Learn more about X-Force Red and X-Force Red’s penetration testing services.
The post New Vulnerability Could Put IoT Devices at Risk appeared first on Security Intelligence.
