bugtraq - CVE-2014-1599 - 39 Type-1 XSS in SFR DSL/Fiber Box

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>] [day] [month] [year] [list]

Message-ID: <53169F61.4030209@gmail.com>
Date: Wed, 05 Mar 2014 03:52:01 +0000
From: "alejandr0.w3b.p0wn3r" <alejandr0.w3b.p0wn3r@...il.com>
To: bugtraq@...urityfocus.com
Subject: CVE-2014-1599 - 39 Type-1 XSS in SFR DSL/Fiber Box

CVE-2014-1599
39 Type-1 XSS in SFR ADSL/Fiber Box.
SFR is the french Vodafone (estimated DSL user base of 5.2 Millions).

* affected product:
SFR BOX NB6-MAIN-R3.3.4

* vulnerabilities:
/network/dns
	5 non-filtered Type-1 XSS
/network/dhcp
	6 non-filtered Type-1 XSS
/network/nat
	7 non-filtered Type-1 XSS
/network/route
	12 non-filtered Type-1 XSS
/wifi/config
	1 non-filtered Type-1 XSS
/network/lan
	8 non-filtered Type-1 XSS


* exploitation hypotheses:
	- user already logged-in (or tricked by SE techniques to authenticate)
	- ip address of the SFR Box router is known (most users use the default
settings: 192.168.1.1/24)

* #number of attack vectors:
	39 Type-1 XSS
		
* exploitation scenario:
If a user is tricked into authenticating into its interface,
an attacker can XSS the user, and thus getting read and write access to
the router configuration webpages.
Such as scenario is mainly possible due to:
 - non filtered reflections (mainly Type-1 / reflected)
 - lack of Content Security Policy
Moreover, no anti-CSRF token such as view-states are present, thus there
is the possibility of modifying the routing tables even without an XSS,
if the user is authenticated in the box.

A non limitative list of actions include:
 - getting authentication credentials (wireless, DSL credentials)
 - rebooting the router
 - modifying the route table (thus possibility of content injection if
an attacker controlled server is on the route)
 - DDOSing a target with numerous XSS'ed clients

* timeline:
 - 2013-12-21: discovery
 - 2014-01-06: notification to vendor, ask for patch release
 - 2014-01-06: vendor acknowledges but does not answer on the patching
timeframe
 - 2014-01-20: request for update or planned date of patch release
 - 2014-02-25: public disclosure