This is a copy of a report that we received through VINCE from the CERT/CC Vulnerability Coordination Team #Affected Vendor Google Google Apple Mozilla Microsoft #Affected Product Google Chrome, Chromium, Edge, Safari, Firefox #Affected Version multiple - see How was the vulnerability discovered #Significant ICS/OT impact? no #Reporter Viktor Bocz [viktor@vbocz.com] #Vendor contacted? yes Description of the vulnerability, PoC code and video demonstration submitted to google. Issue is currently being triaged. #Description This CORS bypass vulnerability combined with DNS rebind allows an attacker to send arbitrary requests to services listening on arbitrary ports regardless the CORS policies of the target. ##Exploit The attacker needs a webserver and a domain to perform the DNS rebind with. The victim must visit the website controlled by the attacker. The malicious site executes the javascript code that periodically sends POST and the preflight OPTIONS request to the attacker on the target port using the domain name. The attacker hosted service responds to the preflight with permissive CORS headers. The IP address of the A record is changed by the attacker to the target IP. After the DNS responds with the changed IP, the javascript sends the POST request to the target. This request is successful regardless the CORS headers returned by the target. Eg. attacker IP - 87.65.43.21 target service - http://10.20.30.40:12345/xyz DNS - www.cors.test - A record, low TTL (eg. 10s), initially resolves to 87.65.43.21 1. Victim visits http://87.65.43.21/ 2. Javascript periodically (eg every second) sends POST to http://www.cors.test:12345/xyz (87.65.43.21). 3. Browser sends preflight OPTIONS request to the attacker that responds with permissive CORS headers (Access-Control-Allow-Origin: *, Access-Control-Allow-Headers: *) 4. Attacker updates A record so that www.cors.test resolves to 10.20.30.40 5. TTL expires, DNS is queried again, IP address changes to 10.20.30.40 on the victims device 6. the malicious javascript sends the request to http://www.cors.test:12345/xyz that at this point is 10.20.30.40:12345. Depending on the browser used and the frequency the POST requests are sent to the target the malicious request is sent to the target 1 or more times. 7. Browser sends another preflight OPTIONS request to the target that does not have the permissive CORS headers in the responses. 8. Browser stops sending the requests to the target due to the CORS policies. The POST requests sent to the target are often not visible in the developer tools of the browsers. These were discovered in the packet capture. ##Impact Actual impact depends on the target. The vulnerability was discovered while trying ways to send UPnP/IGD requests to a upnp server vulnerable to CVE-2021-29462 (libupnp dns rebind vulnerability) from the browser. By exploiting this browser vulnerability it was possible to set up port forwarding simply by visiting the malicious page. ##Discovery The discovery started by assessing the impact of having UPnP enabled on a gateway that used an old libupnp vulnerable to DNS rebind (CVE-2021-29462). The UPnP service endpoint responded to the preflight request with code 503 and no CORS headers. Therefore, when sending the SOAP request to the UPnP/IGD endpoint using XHR the browser blocked it. After various failed attempts I checked what would happen if first I responded to the OPTIONS/POST requests with permissive CORS headers before the DNS IP is changed and to my surprise the request appeared in wireshark and the port mapping request was indeed successful. I've written a quick and dirty python script that automatically performs all actions for the attack. It acts as the DNS server (automatically changes the IP 10s after the first DNS query), hosts the PoC malicious web page, exposes the service on the target port and responds to the POST and preflight requests with the permissive CORS headers. To use it, change the TARGET_URL variable and run the script as python3 PoC-server-ext.py <listen IP> <attacker IP> A simple flask service is also included in the archive that can be used as a target. ##List of browsers that sent the request to the target: Chromium 134.0.6998.35 (ubuntu 22.04.5) Google Chrome 134.0.6998.88 (ubuntu 22.04.5) Google Chrome 134.0.6998.89 (Windows 11 Version 23H2 (OS Build 22631.5039)) Microsoft edge 134.0.3124.66 (Windows 11 Version 23H2 (OS Build 22631.5039)) Safari 18.3.1 (20620.2.4.11.6) (Macos Sequoia 15.3.2 (24D81)) Firefox 136.0.2 (Ubuntu 22.04.5) - happens very rarely ##Browsers that were never seen sending the POST to the target: Opera GX core 117.0.5408.100 (Macos Sequoia 15.3.2 (24D81)) Firefox 136.0.1 (Android 14 on Samsung S24 Ultra) Samsung Internet (Android 14 on Samsung S24 Ultra) All tests were performed without disabling cache in the developer tools. All vulnerable browsers send several POST requests between preflights.
Bug 1960834 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is a copy of a report that we received through VINCE from the CERT/CC Vulnerability Coordination Team # Affected Vendor Google Google Apple Mozilla Microsoft # Affected Product Google Chrome, Chromium, Edge, Safari, Firefox #Affected Version multiple - see How was the vulnerability discovered # Significant ICS/OT impact? no # Reporter Viktor Bocz [viktor@vbocz.com] #Vendor contacted? yes Description of the vulnerability, PoC code and video demonstration submitted to google. Issue is currently being triaged. # Description This CORS bypass vulnerability combined with DNS rebind allows an attacker to send arbitrary requests to services listening on arbitrary ports regardless the CORS policies of the target. ##. Exploit The attacker needs a webserver and a domain to perform the DNS rebind with. The victim must visit the website controlled by the attacker. The malicious site executes the javascript code that periodically sends POST and the preflight OPTIONS request to the attacker on the target port using the domain name. The attacker hosted service responds to the preflight with permissive CORS headers. The IP address of the A record is changed by the attacker to the target IP. After the DNS responds with the changed IP, the javascript sends the POST request to the target. This request is successful regardless the CORS headers returned by the target. Eg. attacker IP - 87.65.43.21 target service - http://10.20.30.40:12345/xyz DNS - www.cors.test - A record, low TTL (eg. 10s), initially resolves to 87.65.43.21 1. Victim visits http://87.65.43.21/ 2. Javascript periodically (eg every second) sends POST to http://www.cors.test:12345/xyz (87.65.43.21). 3. Browser sends preflight OPTIONS request to the attacker that responds with permissive CORS headers (Access-Control-Allow-Origin: *, Access-Control-Allow-Headers: *) 4. Attacker updates A record so that www.cors.test resolves to 10.20.30.40 5. TTL expires, DNS is queried again, IP address changes to 10.20.30.40 on the victims device 6. the malicious javascript sends the request to http://www.cors.test:12345/xyz that at this point is 10.20.30.40:12345. Depending on the browser used and the frequency the POST requests are sent to the target the malicious request is sent to the target 1 or more times. 7. Browser sends another preflight OPTIONS request to the target that does not have the permissive CORS headers in the responses. 8. Browser stops sending the requests to the target due to the CORS policies. The POST requests sent to the target are often not visible in the developer tools of the browsers. These were discovered in the packet capture. ## Impact Actual impact depends on the target. The vulnerability was discovered while trying ways to send UPnP/IGD requests to a upnp server vulnerable to CVE-2021-29462 (libupnp dns rebind vulnerability) from the browser. By exploiting this browser vulnerability it was possible to set up port forwarding simply by visiting the malicious page. ## Discovery The discovery started by assessing the impact of having UPnP enabled on a gateway that used an old libupnp vulnerable to DNS rebind (CVE-2021-29462). The UPnP service endpoint responded to the preflight request with code 503 and no CORS headers. Therefore, when sending the SOAP request to the UPnP/IGD endpoint using XHR the browser blocked it. After various failed attempts I checked what would happen if first I responded to the OPTIONS/POST requests with permissive CORS headers before the DNS IP is changed and to my surprise the request appeared in wireshark and the port mapping request was indeed successful. I've written a quick and dirty python script that automatically performs all actions for the attack. It acts as the DNS server (automatically changes the IP 10s after the first DNS query), hosts the PoC malicious web page, exposes the service on the target port and responds to the POST and preflight requests with the permissive CORS headers. To use it, change the TARGET_URL variable and run the script as python3 PoC-server-ext.py <listen IP> <attacker IP> A simple flask service is also included in the archive that can be used as a target. ## List of browsers that sent the request to the target: Chromium 134.0.6998.35 (ubuntu 22.04.5) Google Chrome 134.0.6998.88 (ubuntu 22.04.5) Google Chrome 134.0.6998.89 (Windows 11 Version 23H2 (OS Build 22631.5039)) Microsoft edge 134.0.3124.66 (Windows 11 Version 23H2 (OS Build 22631.5039)) Safari 18.3.1 (20620.2.4.11.6) (Macos Sequoia 15.3.2 (24D81)) Firefox 136.0.2 (Ubuntu 22.04.5) - happens very rarely ## Browsers that were never seen sending the POST to the target: Opera GX core 117.0.5408.100 (Macos Sequoia 15.3.2 (24D81)) Firefox 136.0.1 (Android 14 on Samsung S24 Ultra) Samsung Internet (Android 14 on Samsung S24 Ultra) All tests were performed without disabling cache in the developer tools. All vulnerable browsers send several POST requests between preflights.