Bastille Tracking Number 33 CVE-2017-9489 CVE-2017-9490 Bastille Vulnerability Label: Cross-site Request Forgery Bastille Provided Severity: High Overview Web applications that are vulnerable to cross-site request forgery (CSRF) allow for malicious third-parties to submit forged HTTP requests on the behalf of application users. These requests can invoke any of the functionality exposed by the application that the affected user has permission to invoke. In the case of the Comcast modems identified in this disclosure, the presence of CSRF vulnerabilities enables attackers to log in to the affected modems with default credentials (if the user is not already authenticated) and administer users' home modems. Affected Platforms Cisco DPC3939B, firmware version dpc3939b-v303r204217-150321a-CMCST Arris TG1682G, eMTA&DOCSIS version 10.0.132.SIP.PC20.CT, software version TG1682_2.2p7s2_PROD_sey Proof-of-Concept To observe the lack of CSRF protections, follow the steps below: (1) Install Burp Suite proxy (https://portswigger.net/burp/) (2) Open a browser and navigate the browser to a login page of one of the affected modems (typically http://10.0.0.1/) (3) Configure the browser to use Burp Suite as an HTTP proxy (http://www.lib.berkeley.edu/using-the-libraries/proxy-chrome-windows) (4) In the browser, log in to the portal and navigate to any page that allows the user to administer components of the modem. Once at an administration page, make any number of modifications to the modem configuration and submit the page. (5) In Burp Suite's Proxy tab, view the contents of the HTTP POST request that was submitted to the modem and observe that no references to CSRF tokens or other CSRF protections are present. (6) Right-click on the HTTP POST request in Burp Suite and choose "Send to Repeater". (7) Click on the "Repeater" tab at the top of the Burp Suite user interface. (8) In the "Repeater" interface, the HTTP POST request will be seen on the left. For completeness, the following tests can be conducted to prove that no CSRF protections are present: - Add an HTTP request header with "Origin: " and re-submit the HTTP request. Observe that the request is successful. - Modify the "Referer" HTTP request header to anything other than its default value and re-submit the HTTP request. Observe that the request is successful. Additional guidance for testing for the presence of CSRF vulnerabilities can be found here: https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005) Test Environment Cisco DPC3939B, firmware version dpc3939b-v303r204217-150321a-CMCST Arris TG1682G, eMTA&DOCSIS version 10.0.132.SIP.PC20.CT, software version TG1682_2.2p7s2_PROD_sey Mitigation Protecting against cross-site request forgery requires a mechanism that ensures that requests originating from a user's browser are intentionally submitted by the user. While there are more than one approaches to mitigating CSRF, the least cumbersome is the "Double Submit Cookie." This method requires two things: (1) Set a random (unguessable) value in a cookie field that is returned to the user. (2) Require that the cookie value is submitted alongside all forms sent by the user. The cookie value should be placed into the protected forms through JavaScript prior to form submission. This approach makes it so that an attacker must have access to cookie values in the affected user's browser to forge requests on their behalf. The main way that an attacker would have access to these values is through cross-site scripting, which by definition is a CSRF bypass already, thereby effectively mitigating the CSRF exposure. It should be noted that this mitigation pattern was observed to be in place and working in the most recent firmware build of the Comcast DPC3939 modem. Additional details on this mitigation pattern can be found here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie Recommended Remediation N/A Credits Marc Newlin and Logan Lamb, Bastille Chris Grayson, Web Sight.IO