Multiple router web server vulnerabilities - Recommendations

Recently I came across a project in GNUCitizen called 'Router Hacking Challenge'. It was a project to gather vulnerabilities in home routers. Many interesting problems were found and mainly related to Embedded web servers in the routers. I did some search and found that these problems are not confined to small routers, but they are equally applicable to Enterprise networking devices too. Any security administrator get alarmed by this. It appears that embedded webserver is the weak part of network devices. In this article, I summarize kinds of vulnerabilities found and some recommendations to developers to overcome these problems.

There are many entries in 'Router Hacking Challenge' project. But at high level they fall onto:

• Authentication Bypass
  
• IP based session Management
  
• CSRF (Cross Site Request Forgeries)with default passwords.
• CSRF with Cookies
• XSS (Cross Site Scripting) attacks - Mainly persistent XSS attacks.
  
• Configuration files in document root.
  
• DOS attacks

There is a misconception that as long as web interface is not exposed to the outside world (untrusted network), the device is safe. It is not so. Administrators when lured to visit attacker sites, the malicious page could take control of the device. Attacker site may be exposing a image or hyperlink which internally connects to the local security device of administrator and changes the configuration. When the administrator inadvertantly clicks on these links, then the damage is done. Since, this link is connected from administrator browser, attack is successful. These links and associated java script can do things like opening remote administration, creation of new administrator and changing the policies.

Let me go ahead and give brief description of kinds of attacks.

Authentication Bypass

Normal browsing of network devices' web interface appear to be secure as it forces the user to enter login credentials. But it appears that, in some cases, if user knows internal URLs of web interfaces, he/she can access the interface without going through authentication process. In some cases, it appears that HTTP GET requests are authenticated, but not POST methods. Once the attacker knows the POST action URL and POST variable definition for various configuration items, the attacker can easily take control over the device or change any settings in the device.

IP Address based Session Management

Some devices seem to implement IP address based session management. Once the user is authenticated by the web server, web servers allows the HTTP requests from this IP address without any other validation.

• If there is a NAT router doing SNAT in between the administrator PC and the device, then any other user behind the same NAT router can access the device without signing in.
  
• If some body in organization knows the IP address of administrator PC, he/she can assign the same IP address to his/her PC when administrator is not present and access the device configuration. Of course timing is important in this case, that is, it is possible to access device only after administrator has successfully logged into the device and before the device removes the session due to inactivity.

CSRF with default passwords:

Many administrators don't change the default passwords that come with firmware. Also many home users don't even change IP address of the devices. They assume that devices are safe as long as remote administration of the device is turned off. When any user in the Enterprise or home are tricked into visit an attacker site, the malicious page could change the configuration of the device. Malicious page could have javascript which generates the HTTP request, logs in with default user name and password and send POST method with variables. It becomes easy for an attacker to create the malicious pages with default passwords and IP addresses. Of course the attacker should know the vendor and model of the device to frame the page with appropriate POST method and variables. But, this is not that difficult as some vendors are very popular and they use same software across multiple models.

CSRF with Cookies:

Even when the administrators change the default passwords, there is still possibility of changing the configuration of the devices. This can happen when the administrator is tricked into visiting attacker site when login session with the device is active. When the login session is active, the session cookie, which is used to validate the HTTP requests for authenticity, is still valid. When administrator visits the malicious page with javascript, then the script could make a connection and send HTTP request with details attackers wants. Since it is connecting to the device, browser sends the session cookie along with the HTTP request. HTTP Server does not suspect anything and honors the request.

XSS attacks:

When administrators visits any device page which was XSSed before, then XSS script gets executed. XSS injection could have happened before due to :

• CSRF vulnerability: The attacker site could introduce javascript or any other script in one of the configuration values or logs etc..
• Logs: Some web servers when presented with unknown URI might store URI in one of the log messages. Attacker can induce XSS as part of invalid URI. When administrator visits these log messages at later time, XSS script gets executed.
  

XSS scripting can be used to steal information such as passwords and device configuration. XSS scripts can be written to post this information to attacker websites, public forums etc..

XSS injection problem typically occurs when the input fields are not sanitized by the web servers.

Configuration files and Clear passwords:

It appears that some devices are storing the configuration in the same or nested directories as HTML pages. Due to this anybody having access to the device both privileged and non-privileged users get access to the configuration files. When devices store the passwords in clear, every user comes to know about admin passwords, PPPoE passwords etc.. These passwords can be used for malicious purposes.

DOS attacks:

It appears that webserver implementation of some devices is week. Different techniques are used to crash the web servers. Most of them seem to be buffer overflow attacks. Some of them are:

• Large URI in GET and POST requests.
• Large data as part of HTTP request header name
  
• Large data as part of HTTP request header value.
• Large data as part of HTTP Post Variable name.
• Large data as part of HTTP POST variable value.
• Unknown header name
  
• Sending duplicate headers.

Recommendations for developers:

• Always use challenge based authentication for HTTP access: Challenge must be generated from random data. Every new login session should be presented with different challenge value.
  
• It is advisable to use MD5 on challenge and password entered by user before sending to the web server. Don't send the password in clear. This can be achieved using javascript. Javascript code should be present in the page that takes user name and password from the user.
• Always use session cookies: Once the authentication is successful, webserver should set the session Cookie. This session cookie also must be generated from random data. Don't use source IP address as part of session cookie. Don't use persistent cookies, that is, If browser is closed, this cookie should disappear on the PC.
  
• Validate all requests against session cookie: All methods (whether they are GET or POST) must have session cookie that was sent as part of login session. Since it is not general purpose web server, there is no need entertain any URI without any authentication. If session cookie is not received in the request, then web server should send 'login' page to authenticate the user.
  
• Main page should predominantly show if any default passwords are still present in the device. It helps as a reminder to administrator to change the passwords.
• To avoid from the CSRF with cookies, it is advisable that web server sends a random token along with page having 'forms'. Javascript on the page should always send back the token along with submitted values. Web server validates the token before processing the request. This token value should not be sent to the browser using Cookie (Set-Cookie) as it defeats the purpose. This should be sent separately along with requested page. Web server should keep refreshing these token values periodically or even can change for every page. Web server should keep track of these tokens on per login session.
• To avoid from XSS attacks, web server and logic associated with functionality must validate all input values.
  Ensure that the values are not stored anywhere without validating them.
  
• Web Server should not send the user input values or URL in its response page. Also, it should not store these values in any log messages.
• To avoid from DoS attacks, penetration testing must be done. There are many tools available to inject large data in HTTP request header names and values. But, to test the application specific HTTP POST variable names and values OR XML fields and values, one must create application specific tools to send large amount of data in field names and values. Also, these application specific tools should also have capability to fuzz the data and ensure that system withstands and also ensure that system does not reflect these invalid values on the screen (to avoid reflective XSS sttacks). Many times, it is my observation that application specific tools are not created by developers to ensure that there are no buffer overflow attacks. That makes the web server and its associated logic a weak link.