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
Let me go ahead and give brief description of kinds of attacks.
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:
CSRF with Cookies:
When administrators visits any device page which was XSSed before, then XSS script gets executed. XSS injection could have happened before due to :
- 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 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.
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.
- 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 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.