Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Attacking the local LAN via XSS
From: "Dude VanWinkle" <dudevanwinkle () gmail com>
Date: Tue, 8 Aug 2006 09:22:10 -0400

On 8/7/06, Nikolay Kubarelov <admin () gramophon com> wrote:
On Friday 04 August 2006 16:06, pdp (architect) wrote:
> IMHO, if you want to do stuff on lower level, you need to think of
> something else. JavaScript, Flash and Java Applets are technologies
> that are designed to run on the WEB. This is why, IMHO, they are quite
> good platform for performing WEB/HTTP based attacks.

OK, I'm really interested what are those login web pages with default password
for admin:password I see all my network. I bet there are more than 10%
routers with open http ports.
I can attach snapshots if you buy me a beer.

The question is what where is the xss bug on major http admin panel's.

Does this count?
From an earlier post by GinsuRabbit:

Tested product: Linksys WRT54g home router, firmware revision 1.00.9.

Problem #1: No password validation for configuration settings.

The WRT54g does not attempt to verify a username and password when
configuration settings are being changed.  If you wish to read configuration
settings, you must provide the administrator ID and password via HTTP basic
authentication.  No similar check is done for configuration changes.

This request results in a user-id and password prompt:
GET /wireless.htm

This request disables wireless security on the router, with no password
POST /Security.tri
Content-Length: 24


Problem #2: Cross-site request forgery

The web administration console does not verify that the request to change
the router configuration is being made with the consent of the
administrator.  Any web site can force a browser to send a request to the
linksys router, and the router will accept the request.

II. Exploitation

The combination of these two bugs means that any internet web site can
change the configuration of your router.  Recently published techniques for
port-scanning and web server finger printing via java and javascript make
this even easier.  The attack scenario is as follows:

- intranet user visits a malicious web site
- malicious web site returns specially crafted HTML page
- intranet user's browser automatically sends a request to the router that
enables the remote administration interface
- the owner of the malicious web site now has complete access to your router

I'm not going to share the "specially crafted HTML page" at this time, but
it isn't all that special.


If your router is vulnerable, the following curl command will disable
wireless security on your router.  Tests for other router models and
firmware revisions may be different:

curl -d "SecurityMode=0&layout=en"


1) Make sure you've disabled the remote administration feature of your
router.  If you have this "feature" enabled, anybody on the internet can
take control of the router.

2) Change the IP address of the router to a random value, preferably in the
range assigned to private networks.  For example, change the IP address to
10.x.y.z, where x, y, and z are numbers between 0 and 255 inclusive.  This
makes it more difficult for an attacker to forge the request necessary to
change the router configuration.  This mitigation technique might not help
much if you have a java-enabled browser, because of recently published
techniques for determining gateway addresses via java applets.

3) Disable HTTP access to the administration interface of the router,
allowing only HTTPS access.  Under most circumstances, this will cause the
browser to show a certificate warning before the configuration is changed.

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]