There are a staggering number of M2M gateways on the market. In some cases, gateways are designed and marketed for specific use-cases, such as in-vehicle connectivity and fleet management, sensor data aggregation and telematics, and home automation and management. Others are meant to provide failover cellular connectivity for a satellite office or kiosk. Over the last several years, we have researched gateway security, analyzing dozens of devices from various manufacturers. Throughout the process, we’ve disclosed numerous vulnerabilities and worked with the vendors to fix or control the issues we raise. As it becomes public, our research is available on our Disclosures page.

As a result of this work, we’ve assembled the following high-level list of risks and recommendations for organizations needing to deploy gateways.

It is important to point out that while Industrial Control and other “IoT” deployments get the spotlight, this information is also useful for organizations deploying cellular enabled gateways to provide primary or backup connectivity for branch or temporary work locations, such as retail stores or construction job sites.

1. Exposure on public carrier networks

Gateways are usually purchased standalone or as part of a larger solution offering from value added resellers (VARs). These VARs are typically responsible for providing SIM cards and other aspects of cellular provisioning. While not necessarily visible to the end-customer, the VAR should have options regarding how the devices are provisioned on carrier networks. Options should include, at a minimum: Public IP or Private Pool.

Most carriers offer several options that the VAR must select from to determine if the device is exposed to the Internet directly, or is NAT’d behind a firewall. The details of this configuration are critical, as we’ve found that many gateways have insecure services enabled by default on their WAN interface out of the box. If your VAR or your carrier decide to give your gateways non-NAT’d IP addresses, then these services are directly accessible from the Internet and may be susceptible to attack if they are not configured properly.

2. Insecure Default Settings, including predictable passwords

This is a major risk. First of all, most gateways are designed to be “plug and play” and operate right out of the box. Many gateways operate out-of-the-box with default passwords that are easy to guess, and sometimes cannot be changed. Many also operate with insecure remote administration services (Telnet or HTTP) exposed on their WAN interfaces.

The devices can be difficult to configure individually, and doing so at scale can be even more of challenge. As a result, there is a strong likelihood that devices will end up in production with these default settings, making them easy to fingerprint and access remotely using default credentials.

3. Poor Cryptography

M2M devices used to be extremely limited with regards to computing power. We find that some still are. However, the majority of gateways we’ve looked at have resources to take advantage of standard encryption libraries such as openssl, NaCl, PyCrypto, etc. Still, we frequently find “homegrown crypto” on devices leaving any secrets on the device accessible with minimal reverse engineer effort.

Remember, just because you can write code doesn’t mean you can write crypto code.

4. Insecure Applications

This relates directly with the insecure default settings issue (#2). Most gateways bundle their own multi-user web applications for configuration, monitoring, and management. We’ve found that these web applications typically contain serious bugs that allow us to remotely compromise the device, by exploiting command injection flaws and/or insecure update mechanisms.

Additionally, some devices include remote management capabilities where users can administer the devices remotely via cloud applications managed by the device OEM. In these cases, the security of the cloud environment directly impacts your ability to secure your device, and any other networks your devices are connected to.

5. Insecure Network Design

Because of their use cases, M2M gateways are typically installed in potentially insecure physical locations. If in-vehicle gateways in your fleet of trucks are VPN’d into the corporate network, and a truck is stolen, the thief can now potentially tunnel into your corporate network via your gateway. The impact of a stolen truck is now more severe from a network security perspective than a stolen laptop (assuming you have a sound remote access strategy for laptops).