bugtraq - Re: Linksys WRT54 GL - Session riding (CSRF)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <878x2w63ab.fsf@mid.deneb.enyo.de>
Date: Fri, 11 Jan 2008 11:54:20 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: tomaz.bratusa@...mintell.com
Cc: bugtraq@...urityfocus.com
Subject: Re: Linksys WRT54 GL - Session riding (CSRF)

* tomaz bratusa:

> Linksys WRT54GL is prone to an authentication-bypass
> vulnerability. Reportedly, the device permits changes in its
> configuration settings without requring authentication (CSRF).

This specific attack scenario has been publicly documented for a long
time (note the final paragraph):

| Isn't your exploit somewhat complicated?  Just put
| 
| <img src="http://192.0.2.1/level/15/configure/-/enable/secret/mypassword"/>
| 
| on a web page, and trick the victim to visit it while he or she is
| logged into the Cisco router at 192.0.2.1 over HTTP.  This has been
| dubbed "Cross-Site Request Forgery" a couple of years ago, but the
| authors of RFC 2109 were already aware of it in 1997.  At that time,
| browser-side countermeasures were proposed (such as users examining
| the HTML source code *cough*), but current practice basically mandates
| that browsers transmit authentication information when following
| cross-site links.
| 
| Such attacks are probably more problematic on low-end NAT routers
| whose internal address defaults to 192.168.1.1 and which generally
| offer HTTP access, which makes shotgun exploitation easier.  So much
| for the "put your Windows box behind a NAT router" advice you often
| read.

<http://article.gmane.org/gmane.comp.security.bugtraq/20579>

Cisco PSIRT had been approached about this issue a couple of months
before that BUGTRAQ posting, IIRC.