Last updated at Thu, 31 Aug 2017 14:02:27 GMT
Like the proverbial cat, curiosity can often get me in trouble, but often enough, curiosity helps us create better security. It seems like every time I encounter a product with a web management console, I end up feeding it data that it wasn't expecting.
As an example, while configuring a wireless bridge that had a discovery function that would identify and list all Wi-Fi devices in the radio range, I thought: "I wonder what would happen if I broadcast a service set identifier (SSID) containing format string specifiers?"
I set up a soft AP on my Linux host using airobase-ng and configured the SSID to broadcast %x%x%x. I was shocked when the discovered AP's SSID displayed data from the wireless bridge's process stack as shown in Figure 1:
This data confirmed that this wireless bridge appliance was vulnerable to a format string exploit. This lead to the discovery of multiple devices vulnerable to injection attacks within the web management consoles via SSID, including format strings, persistent cross-site scripting (XSS) and cross-site request forgery (CSRF) (more details of these are discussed in a whitepaper I released at Blackhat).
Unfortunately, attacks against web management interfaces don't stop with SSIDs. So many products inevitably consume data from various resources and then display that data within the web management console without conducting any validation checks of that data first. This often leads to vulnerabilities being exploited via the web management interfaces, and it appears to not be going away any time soon. Recently Matthew Kienow and myself released a number of advisories where XSS attacks were injected into web management consoles of Network Management Systems (NMS) using SNMP.
Again—several months back—while on a pen testing engagement, a coworker was running an open source tool used to launch relay style attacks. This tool captured hostname information from the network and stored it as part of its function and of course it had a web interface. Sadly his testing was interfering with my testing, so for fun I changed my Linux systems hostname to <script>alert(“YOU-HAVE-BEEN-HACKED”)</script> .
Initially I wasn't sure if this XSS attack would work, but soon enough I heard a loud scream come from his corner of the room. Now this brings me around to the purpose of this blog: What would the impact be if everyone changed the name of their host system to contain XSS data—such as <iframe>? I am scared to even imagine the number of products that use the hostname data and display it within their web management interface. Based on all my testing against various application and embedded devices that use web interfaces for management, I have found roughly 40% of the systems I have tested to be vulnerable to some form of XSS injection attacks.
So, I wonder how many administration web consoles have this sort of problem with hostname parsing?
Want to Help Us Find Out?
Now if this idea intrigues you, don't rush out and start renaming your systems, as even a simple XSS such as <iframe>—which should create a simple box on the screen (Figure 2)—can have serious impact on the web interface functionality of some products and could easily prevent it from functioning normally.
However, if you want to try this out, first make sure you have permission and that you do it within a controlled environment—not within your production environment. If you end up giving this a try, I ask that you share the results with us at security@rapid7.com (PGP KeyID: 0x8AD4DB8D) so we can follow-up with the results in a future blog.
Also, I highly recommend that you contact the product vendor for ethical disclosure so they can fix the issues.
I am looking forward to hearing back on what you find.