Linksys WAP54Gv3: Remote blind attack demo
The IS-2010-002 vulnerability, regarding the undocumented debug interface on the Linksys WAP54gV3, has received CVE number (CVE-2010-1573) and Cisco has published a detailed security advisory on the issue (credits report misspelled name).
It seems also that a separate CVE number(CVE-2010-2261) has been assigned just for the command injection vulnerability, present in the data2 and data3 POST variables.
The vulnerability has been reported also on several other websites, but not always with the utmost accuracy, so I here try to clarify a few things.
Affected devices and firmware
In some cases it has been reported that only European devices are affected while devices sold in the US are safe.
Unfortunately that is not correct, in facts, firmware version v3.05.03 is installed on European devices, while, at the best of my knowledge, v3.04.03 is the current firmware version for US devices.
Both firmware versions v3.05.03 and v3.04.03 are vulnerable, so, if these are the only available firmware versions, this lead to the conclusion that all the WAP54Gv3 that are currently available suffer of the reported security issue, without any country based distinction.
Vulnerability attack “range”
Some websites reported that, in order to exploit the vulnerability, attacker should/may/must have access to the local network, either wired or wireless, and, be able to access the web interface.
I have the feeling that this kind of formulation, or similar, does not completely capture and describe all the possible attack scenarios related to this vulnerability.
It seems clear that the debug interface has to be accessed by a resource that is able to reach the the device (eg: is able to “ping” port TCP/80 of the device), but this does not necessarily imply that the resource is the attacker himself, or that the attacker has access to the local network.
At a logical level, by “decoupling” the attacker functions from the resource, a “Remote Blind” attack scenario is possible, where an attacker can exploit a device that is not even “IP-reachable”.
This concept is not new at all, it has been known for years and discussed in details in the security community:
the resource (eg: a Web browser) act as a “reflector”, sending commands on behalf of the attacker, that could be very well located outside of the local network and could not even be able to reach the device.
Look at the following video for a demonstration of the attack, where a vulnerable Linksys WAP54Gv3 uploads sensitive information on an attacker controlled website.
Conclusion
if there is, at least, an user that is able to access a vulnerable access point, all that is required to an attacker to exploit the “unreachable” vulnerable device is to entice the user in accessing a malicious web page.
One possible countermeasure would be to deny connections from the Access Point to the Internet, or apply some similar policy on the firewall at the network edge, this would prevent the AP to upload information in this scenario.
Anyway this should provide proper warning to readers that might underestimate the advisory, thinking that “access to local network” may be related only to plugging cables and inserting Wi-Fi passphrases.
Your own browser could be very well the key to unlock your “local network” doors.
*** Update *** (23/06/2010)
If an attacker exploits the XSS detailed in IS-2010-003, the browser itself may upload credentials to the attacker website.
In this case the countermeasure of denying connections to the Internet that are originated by the AP wil not be effective in preventing the attack detailed in this post.
I have a question, which commands were in the javascript payload?