Cybersecurity News & Commentary - October 2019

The Source Port is Georgia Tech's monthly cybersecurity newsletter, featuring commentary from its researchers about topics in the news over the past month, what wasn't written between the lines, the big (and sometimes nagging) questions driving our research, and new projects underway.

October, 2019


Research Explores Attack Patterns Against Insecure Drivers

At this year's DEF CON security convention, researchers from security company Eclypsium presented a survey of Windows device driver security that demonstrates that device drivers tend to suffer from security flaws that can likely allow an attacker to use the driver to take complete control of a system.  Even though the drivers that the researchers studied are certified and signed by Microsoft, the drivers expose capabilities that are not properly secured.  Since the drivers run with the privileges of the Windows kernel, user applications that can access the drivers could potentially break system security policies or enable, a malicious application to take control of the system.​​

IISP Analyst Joel Odom There is so much hardware available for PCs these days that it is impossible for an operating system like Windows to know how to interact with every hardware device on the market.  The point of a device driver is to provide a mechanism for applications and the operating system to use hardware without having to understand the nuances of how the hardware works at a low level.  Device drivers typically run in kernel mode because they need direct access to the computing hardware.  With the power to talk directly to hardware comes the power to completely control the computer and the operating system, which is why improperly-implemented device drivers can cause a computer to crash completely, or can allow a malicious application to bypass security controls via the driver.

Eclypsium's research is valuable because it has made the software community aware of poor coding practices (called "anti-patterns") in device drivers.  For example, some of the capabilities exposed by device drivers were the ability to copy arbitrary memory, to write to arbitrary memory, to translate from virtual to physical addresses, and to perform read/write operations on hardware registers.  These are all things that you would expect a device driver to have to do, but these are capabilities that should not be exposed to applications using the device driver.

The actual security impact of a poorly-written driver depends on the particulars of what capabilities the driver exposes and how these capabilities are exposed.  In the worst case, we could envision an application that takes input from a tainted source (a network connection, an email attachment, etc.) and somehow uses that input to talk to a device driver.  This scenario could offer an attacker remote code execution with kernel privileges.  In another scenario, malware could use a vulnerable device driver to escalate privileges.

There is security built into the device driver ecosystem, such as hardware-enforced protections against kernel-mode drivers executing code from user-mode memory.  Device driver signing is probably the most widely recognized form of driver security, but Microsoft can only do so much diligence in verifying that a certified driver doesn't have vulnerabilities (although one cool aspect of the research is that Eclypsium showed how symbolic execution can sometimes be used to automatically find inputs to a device driver that could trigger dangerous operations).  The best protection is for device driver developers is to minimize the exposed features of a driver to the minimum set of features necessary for programs to use the driver, and to carefully sanitize all input to the driver (several years ago Microsoft published security guidelines for driver implementers, so this research probably doesn't come as a surprise to them).

This problem is surely not unique to Windows.  The device driver paradigm is standard across operating systems, so we can expect to find similar problems on Linux, OS X, and other operating systems.



How Vulnerable Are IoT Devices? 

Security researchers reported a vulnerability in the Imperial Dabman family of IoT (Internet of Things) radios. The bug allows full unauthenticated access to the device and, according to the researchers, affects about 1,000,000 devices in the wild [1]. The issue is that the radio has a telnet service listening with a hardcoded password (‘password’). Any user can trivially login and access the system, and with a bit of pivoting on the device, any action can be performed by an attacker. The vendor, Telstar, has patched the affected devices and said that they are not going to have telnet running on devices in the future.

IISP Analyst Kennon BittickThe crux of the bug is a telnet service that is always running. Remote access services like telnet should only be run on production devices when necessary and should be carefully managed to ensure that they cannot be attacked. In particular, this means that the services should not rely on a single hardcoded password that is deployed to every device. The Imperial Dabman bug is particularly bad, since the hardcoded password was literally just ‘password’. This bug is not an arcane memory corruption error; it is an easily found and easily preventable issue caused by a design decision made without security in mind.

It is likely that the telnet service was originally put in place as a debugging feature for developers and left in production devices. Such development features are very useful, but they must be removed in a production environment. This stresses the importance of reproducible builds with proper configuration management, as in a continuous integration system, with security integrated in all aspects of a product’s life cycle. It is not enough to use a memory safe language or to have developers who are security-conscious: managers, designers, testers, and dev-ops team members must also be educated on computer security and bake it in from beginning to end of a product.

Although the issue was highly preventable, it is unfortunately not surprising in the IoT world. Many devices are made by developers who are not security-conscious (perhaps coming from the embedded world where they are reliant on air gaps for security), and basic security flaws seem to be the norm rather than an anomaly. In particular, the Threatpost author [1] points out the similarities between this bug and the bugs in IoT devices that became part of the Mirai botnet – many of the exploits are trivial configuration-related issues that could have been easily prevented.

IoT devices, like the Imperial Dabman radios or Mirai victims, are often exposed on the internet without any protection, allowing the devices to be easily infected. In addition, since they are often on high bandwidth network links, once infected, the devices can be used for high volume DDoS attacks (see the Mirai attacks for example) or as spam senders. The owners of the device may never notice the infected traffic leaving their network, so they remain part of a botnet indefinitely.

The developers of the vulnerable radio have released a patch to the impacted devices, which is fortunate. Many vulnerable IoT devices are never patched and remain vulnerable even after exploits are made public. As IoT devices continue to be deployed ubiquitously, it is important that they be designed with security from the outset and maintained and patched as though they will be continuously the target of attacks.