Protecting IoT Against Man-in-the-Middle Attacks

Categories

One of the most successful methods for gaining control of sensitive user information (with the added benefit of less likely getting caught) is through Man-in-the-Middle (MiTM) attacks. In a man-in-the-middle attack, a third party pretends to be the server that a client is trying to connect to, and when the client connects, sends its request to the actual server it wants to connect to. The attack then takes the response the actual server sent back to it and sends it back to the client.

For man-in-the-middle attacks, the attacker must be able to successfully direct the customer to their proxy server instead of the real server. From there, the attacker can observe and record all transactions and HTTP/HTTPS communications. As far as the victim is concerned, they cannot discern the difference because everything is behaving “normally” as if they were connected to the server itself. However, the man-in-the-middle is intercepting all data transmitted between the two parties on both sides, and can even manipulate the information as it’s being sent between the client and server such as sending fake messages or changing money transactions.

Man-in-the-middle attacks pose a serious threat because they give the attacker the ability to capture and manipulate sensitive information in real-time. This is essentially eavesdropping by intercepting communications between the client/server and listening in on traffic. Because IoT products are being released with security vulnerabilities and poorly configured Wi-Fi networks, devices will be more easily prone to man-in-the-middle attacks. This is especially true if the product did not validate the HTTPS certificates of servers it connected to.

Common MiTM Attack Software Tools

Just like exploits and DDoS services, there are a variety of tools available to create a man-in-the-middle attack. Here are several tools that have man-in-the-middle attacks included as a capability:

  • Ettercap – Use the modules and scripting capabilities to manipulate or inject traffic on the fly. Can infect, replace, delete data in a connection, discover passwords for protocols such as FTP, HTTP, POP, SSH1, etc. and provide fake SSL certificates in HTTPS sections to the victims. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis.

  • evilgrade – Takes advantage of poor upgrade implementations by injecting fake updates and make hostname redirections (manipulation of victim’s DNS traffic). Comes with pre-made binaries (agents), a working default configuration for fast pentests, and has it’s own WebServer and DNSServer modules. Easy to set up new settings, and has an autoconfiguration when new binary agents are set. Can exploit the upgrade functionality on around 63 pieces of software including Opera, Notepad++, VMware, Virtualbox, itunes, quicktime and winamp.
  • SSLStrip – Forces a victim’s browser into communicating with an adversary in plain-text over HTTP, and the adversary proxies the modified content from an HTTPS server. reducing the connection to an unencrypted HTTP session, whereby all the traffic is readable. Turns https:// URLs into http:// URLs.
  • Dsniff – sshmitm and webmitm implement active man-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI
  • Cain and Abel – Described as a Windows-based password recovery tool, but software can capture and monitor network traffic for passwords, crack encrypted passwords using various methods, record Voice over IP (VoIP) conversations, and recover wireless network keys.
Implications for Internet of Things (IoT)

The implications are for future man-in-the-middle attacks are huge if there is the large risk posed by flawed or vulnerable cryptographic implementations. Vast vulnerabilities can be seen in a SEC Consult report in November 2015 which shows that the manufacturers of the IoT devices and home routers have been reusing the same set of hard-coded cryptographic keys, leaving devices vulnerable to hijacking.

The researchers studied over 4,000 firmware images of embedded devices from 70 different hardware vendors that manufacture devices such as Internet gateways, routers, modems, IP enabled cameras, network attached storage (NAS) devices and Voice over IP (VoIP) phones. They discovered that over 580 unique private cryptographic keys for SSH and HTTPS are re-shared between multiple devices from the same vendor and even from the different vendors.

The common static keys used was SSH host keys which verifies the identity of a device that runs an SSH server using a public-private key pair, and X.509 HTTPS certificates used to encrypt traffic between users and its web-based management interface. Out of the 580 keys scanned, it was found that at least 230 crypto keys are actively being used by more than 4 million IoT devices. Furthermore, the researchers recovered around 150 HTTPS server certificates that are used by 3.2 million devices, along with 80 SSH host keys that are used by at least 900,000 devices.

Many of the device with recycled cryptographic keys can be accessed directly from the public network, often because of remote management features that have been enabled. Because of these vulnerabilities that have already affected so many IoT devices, man-in-the-middle attacks will be able to easily detect authentication credentials and hijack sessions.

The Importance of Public Key Encryption (PKI)

Protecting IoT-enabled systems largely depends on how the device is identified, the owner, and how data is protected between the two. IoT requires billions of certificates to identify devices, authenticate software updates and facilitate encrypted communications. On the other end, users are required to manually patch their device software as soon as an update is released. Because of this, IoT devices will be constantly insecure for users as soon as a vulnerability is discovered.

Having guaranteed identities for the IoT should include more public-key cryptography (PKC), which enables reliably secure communication between individuals. The PKC establishes trusted identities in the IoT built on a network of uniquely identifiable devices. PKC creates relationship between two distinct numbers that encrypt data using both a public key number and a private key number used to encrypt and decrypt a message so that it arrives securely.

A central issue with the use of public-key cryptography is validating proof whether that a particular public key is authentic, belongs to the person claimed, and has not been manipulated with or replaced by a malicious third party. A public key infrastructure (PKI) eliminates the man-in-middle threat by generating certificates and signed software to prove authenticity. Verification requires a certification authority (CA) that issues a digital certificate to certify ownership of the keys. This digital certificate contains several fields to validate the identity of a device or system and the corresponding public key. PKIs generate, issue, store and manage both keys and digital certificates and is correspondingly enormous.

However, PKI keys can still be compromised which impacts every device manufactured. Given access to the root key, an attacker can still sign malicious software and create fake certificates which would still leave all IoT devices vulnerable. The solution is to involve the “root of trust” (RoT). RoT is a set of functions in the trusted computing module that is always trusted by the computer’s operating system (OS). The RoT serves as separate compute engine controlling the trusted computing platform cryptographic processor on the PC or mobile device it is embedded in.

Since public keys must be freely available while private keys must be secret and secure to ensure a trusted identity, it is difficult to remain effective. An RoT creates a barrier between software on the server and cryptographic key material, the practice can go a long way toward preventing a hacker’s paths of attack and access to sensitive cryptographic keys. Since it has been proven repeatedly that IoT devices are poorly encrypted and requires extra layers of protection, having a RoT in addition to a PKI can avoid more chances of being compromised and vulnerable to attacks.

Scroll to Top