Tuesday, January 22, 2008 12:40 PM
cmosby
Symantec Security Response Weblog: Flashing Home Routers
Flashing Home Routers
In a recent blog posting (http://www.gnucitizen.org/blog/hacking-the-interwebs) the GNUCITIZEN security think tank published some new research on the security of home routers – specifically on how to modify router settings from an external location using Adobe Flash. The techniques, if I understand them correctly, are quite powerful and have widespread implications, so I wanted to describe them here.
Home broadband routers have a management configuration interface that allows users to change settings on the device. Typically, routers are configured through a Web interface. For example, the router’s owner would go to the administrative page for the router (which would be located on an internal network host, such as http://192.168.1.100), authenticate by entering a username and password, and then log in.
In an earlier blog entry I talked about how one could modify router settings from an external location through this interface. We recently observed an instance of this attack in the wild. The attack, which was built on JavaScript host scanning techniques described by Jeremiah Grossman at BlackHat 2006, could be used to modify the router’s DNS server settings and thereby lead to instant pharming. The attack relies on the user not changing their default password (which is true in most cases) and the presence of a cross-site request forgery vulnerability on the router (which was present in all the major router models I had tested). At the time I thought this was a pretty devastating attack and I still think it’s worrisome.
Well, the GNUCITIZEN Flash attacks are a hundred times more dangerous. They take advantage of a second, perhaps lesser known, management interface on home routers – namely, the Universal Plug and Play (UPnP interface). This interface leverages the simple object access protocol (SOAP). In reality, SOAP messages are basically just HTTP POST requests where the contentType is set to application/xml, and that includes a SOAPAction header as well as a request body that is compliant with the protocol’s message format.
SOAP messages can be used to modify router settings, such as the choice of DNS Server. While one can construct these messages using the JavaScript XMLHttpRequest object, it’s not possible to successfully mount an attack in this way since the Web browser’s Same Origin policy would be violated, which cannot be done unless one takes advantage of other vulnerabilities.
However, these messages can be set using the Adobe Flash plug-in. What’s worse is that many home routers accept SOAP messages without requiring any type of authentication. When you combine these two observations, it’s possible to create a Web page (containing an appropriate malicious Flash object) that when simply viewed will reconfigure your home router settings. Even if you employ traditional protections such as password protection on the router or employing WPA encryption, you will not be protected against these types of threats.
These threats come about because of the increased complexity that arises from interactions among numerous technological components. For example, the Flash Web browser plug-in as well as the SOAP interface on routers. Often these components can interact in unexpected ways, causing new vulnerabilities to arise.
Fortunately, the particular attack I just described has not, as far as I know, been seen in the wild. And it’s not clear to me that we’ll see it any time soon either. Attackers like to take the simplest approach that works – and the reality is that more attackers leverage “human” vulnerabilities rather than technological vulnerabilities. There’s little reason to exploit a hole in a particular product when you can simply just convince a computer user into lowering their own security. Nonetheless, attacks like these are powerful and we would all be in serious trouble if attackers started employing them.
Posted by Zulfikar Ramzan on January 21, 2008 05:00 AM