Many ASUS wireless routers are affected by a vulnerability that can be exploited by an attacker with access to the target’s local area network (LAN) to execute arbitrary commands.
The security hole was uncovered by Joshua Drake, practice manager of Accuvant Labs’ research and development department. The flaw has been assigned the CVE identifier CVE-2014-9583.
According to Drake, the vulnerability exists in infosvr, a LAN discovery service that runs with root privileges. The service listens on UDP broadcast port 9999, which can be leveraged by an unauthenticated attacker to send packets containing malicious code and take control of the device.
Drake has successfully tested the attack on an ASUS RT-N66U router running firmware version 3.0.0.376.2524-g0013f52. However, David Longenecker, who has also recently discovered a vulnerability in Asus routers, has confirmed that the bug affects the newest router model, RT-AC87U, running the latest firmware release (3.0.0.4.378_3754).
Longenecker has pointed out in a blog post that the exploit for this attack is limited to 237 characters. If the limit is exceeded, the device likely crashes due to a buffer overflow.
ASUS is reportedly aware of the issue and is already working on a fix. However, an exploit for the vulnerability is publicly available so users who don’t trust the individuals connecting on their LAN should take some measures.
A new version of Asuswrt-Merlin, a custom firmware for ASUS routers developed by Eric Sauvageau, mitigates potential attacks by disabling the feature responsible for remote code execution. Sauvageau has pointed out that this is just a temporary solution until Asus releases a proper fix. Alternatively, the expert recommends using the router’s firewall to block potential attacks.
Longenecker recommends killing the infosvr process on boot by running a script from a USB drive.
Another option, suggested by Drake, is to disable the infosvr service after boot. This task, which can be carried out by leveraging the vulnerability itself, must be repeated after each boot.
“Remove the remote command execution functionality from this service. Even if it were guarded with strong authentication, broadcasting a password to the entire LAN isn’t really something to be desired. If command execution is truly desired it should be provided via SSH or similar secure mechanism,” Drake recommended.