Last updated at Mon, 24 Jul 2017 20:30:43 GMT
On February 13th 2013, Cisco released a security notice related to CVE-2013-1131. According to Cisco, the vulnerability is due to improper validation of the Service Set Identifier (SSID) when performing a "site survey" to discover other wireless networks. On the face of it, this vulnerability seems to be low-risk. Indeed, site surveys are not often performed and an adversary would need to either be incredibly lucky or create their own luck through some type of social engineering attack. While the research and attack are interesting to security nerds, it seems to be an impractical attack in the broader sense.
Or is it?
Although the idea of a malicious SSID is both humorous and inventive, the issue isn't so much how the attack is delivered. Rather, the proliferation of web-based interfaces, used to manage everything from refrigerators to aircraft carriers, means that the people designing these interfaces must be acutely aware of common flaws in web-based applications. Additionally, they should be aware of the impact an exploit might have to their application or underlying technologies.
In many ways CVE-2013-1131 represents a deficiency in Cisco's testing and QA processes. The idea of a malicious SSID is interesting, but it is not new. Indeed, using SSIDs as an attack vector has been discussed over the years and Metasploit modules are available to exploit some of them. Given this, it's reasonable to ask: Why is this attack vector not being actively tested in products that take input from untrusted endpoints.
To be sure, this testing deficiency is not unique to Cisco. Any security professional involved in testing web-based applications has inevitably identified the same core vulnerability (input validation issues) across their targets. In most cases these targets are more easily accessed and the negative impact related to successful exploitation can be far greater. Likewise, sub-par input validation related to SSIDs is not unique to Cisco. As I look around my desk I see a number of devices that might be susceptible to this type of attack. Devices such as my Kindle, smartphone, WiFi Pineapple and more. Likewise, I wonder about the possibility that my assessment rig might be compromised while exploring wireless networks using Kismet or Aircrack-ng (I'm paranoid like that). Put another way, how can my friends on Rapid7's assessment team make my day go bad.
For organizations that develop web-based applications, the more important question becomes: How are we testing known attack vectors in our applications. Using Cisco as an example, it seems clear that internal testing does not always produce the best results and some level of scrutiny by a third-party is important if not crucial.
Cisco closes their security advisory with an intriguing statement:
"Additionally, there is the risk that the attacker could obtain the ability to override part of the memory of the affected device. However, the ability to override part of the memory is theoretical and could not be proven by Cisco."
I look forward to IOS heap overflows triggered through functions that process these malicious SSIDs.
-mb
