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.
Wi-Fi Chip Vulnerability Poses Severe Risk to Devices
Security researcher Denis Selianin has published technical details of a vulnerability in a popular Wi-Fi microchip used on devices from laptops to gaming systems to routers. The vulnerability in the firmware of the Marvell Avastar 88W8897 allows attackers to gain complete control over this Wi-Fi chip, which runs the ThreadX real-time operating system (RTOS). Though the ultimate impact of the vulnerability depends on how affected devices use the Wi-Fi chip, control of the Wi-Fi subsystem alone presents a severe risk to devices using the chipset.
IISP Analyst Joel Odom: Depending on what researchers learn about this security flaw in coming months, this could possibly be the biggest security story of the year. Remote code execution means that attackers may be able to take complete control of the Wi-Fi subsystem of affected devices. The fact that no user interaction is required to exploit the vulnerability means that attackers can exploit a device only by being in range of the device's listening Wi-Fi. A device does not even have to be connected to a network for this vulnerability to be exploited, and, if a device in standby has its Wi-Fi listening, this vulnerability still applies. If the Wi-Fi chipset has direct access to system memory, it's conceivable that an attacker could gain complete control of a computer via this vulnerability. It remains to be seen how many devices are affected by this worst case scenario, but initial indications are that this bug is probably of serious concern.
This vulnerability is a great example of how increasing interconnections via radio increase attack surface. I recently consulted with a student at Georgia Tech who was working on a project for which he built a custom transmitter. One of my first suggestions was that he use a commercial Wi-Fi chip instead of his custom solution. The use of commercial solutions for radio links on all kinds of devices and the increasing capabilities of these devices means that engineers are increasingly using off-the-shelf radio chipsets. Of course, increasing capabilities means increasing complexity. Increasing complexity means that security becomes harder! After all, these vulnerable Wi-Fi chips have an entire embedded operating system running on them. As the world becomes more connected, and as small devices and their subsystems become smarter, we will see more instances of vulnerabilities like this.
There are still some emerging details that will decide just how big this security story is. Exactly how many devices are affected by this bug? Is the bug as reliably exploitable as the discoverer reports? Can an attacker pivot from the exploited Wi-Fi chipset to attack the rest of the computer? Does the bug affect other devices running the ThreadX RTOS or only this chipset? Is it possible to patch the firmware or otherwise mitigate the attack? One thing is sure. Devices affected by this bug will be in the field for years to come.
DHS Emergency Directive
The Department of Homeland Security issued an emergency directive to "Mitigate DNS Infrastructure Tampering." The directive cites ongoing campaigns identified by Cisco Talos Intelligence and FireEye. Both of these reports detail the operation of a DNS redirection campaign. Attackers use previously compromised credentials to alter DNS records and redirect user traffic to an attacker-controlled infrastructure. Additionally, the attackers obtain “legitimate” TLS certificates for these machines. From this man-in-the-middle (MITM) position, the attackers are able to selectively target victims, view the cleartext of their traffic, and harvest entered credentials. The DHS directive instructs personnel responsible for government domains to validate their DNS configuration, change their DNS configuration passwords, and enable multi-factor authentication.
IISP Analyst Adonis Bovell:
The directive, and the underlying campaigns that it addresses, highlights the level of trust placed in DNS. This type of attack may not necessarily be novel, but several of its attributes make it noteworthy.
The attack does not involve a breach of the target's network, but rather the (typically 3rd party) DNS infrastructure, which may cause it to go undetected for a longer period than others. This is heightened by the fact that systems continue to run as intended, maybe with slightly increased latency. This allows the attack to continue and affect a large number of users over time.
To a security conscious enduser, this type of attack is very concerning because of how difficult it is to detect from their vantage point. It is almost impossible for a user to confirm whether DNS resolution changes are malicious or not. Typically, users are conditioned to believe that the presentation of a valid TLS certificate signifies safety and security. This attack exploits that belief, and does so on a large scale.
The defenses from this type of attack center around continuous monitoring. Site owners should be aware of changes to where their domain resolves, and of any new TLS certificates being used for their domains. The certificate transparency log is an open system that allows essentially real-time auditing of certificate issuance and use. Automated tools exist for alerting when any of these types of changes occur. Responsible security teams would be able to limit the damage of DNS redirection and MITM attacks, and notify affected users quickly, allowing users to invalidate their harvested credentials where ever they are used.
At the end of the day, one has to trust the security processes of the web services we interact with. However, this attack serves as a good reminder about what a valid certificate really means, and the claims it makes about the security of our conversations.