Chrome’s new security measure aims to reduce a whole class of web attack

Extreme close-up photograph of finger on Chrome icon on smartphone.

For more than a decade, the Internet has been vulnerable to a class of attacks that use browsers as a bridgehead to access routers and other confidential devices on a specific network. Now, Google is finally doing something about it.

Starting with version 98 of Chrome, the browser will start broadcasting requests when public websites want to access endpoints within the private network of the person visiting the site. For now, requests that fail will not prevent connections from being made. Instead, they will only be logged. Somewhere around Chrome 101, assuming the results of this test run do not indicate that major parts of the internet will be broken, it will be mandatory for public sites to have explicit permission before they can access the endpoints behind the browser .

The planned deactivation of this access occurs when Google enables a new specification known as access to the private network, which allows public websites to access internal network resources only after the sites have explicitly requested and the browser grants the request. PNA communications are sent using the CORS protocol, or Cross-Origin Resource Exchange. According to the scheme, the public site sends a preflight request in the form of the new header Access-Control-Request-Private-Network: true. For the request to be granted, the browser must respond with the corresponding header Access-Control-Allow-Private-Network: true.

Intrusion into the network through the browser

Until now, websites had by default the ability to use Chrome and other browsers as a proxy to access resources within the local network of the person visiting the site. While routers, printers, or other assets on the network are often blocked, browsers, due to the need to interact with so many services, can by default connect to virtually any resource within the perimeter of the local network. This has led to a class of attack known as CSRF, short for cross-write request forgery.

Such attacks have been theorized for over a decade and they have also taken place in nature, often with significant consequences. In a 2014 incident, hackers used CSRF to change DNS server settings for more than 300,000 wireless routers.

The change caused compromised routers to use malicious DNS servers to resolve the IP addresses that end users were trying to visit. Instead of visiting the authentic site, for example, the malicious server could return the IP address of an imposter site that the end user has no reason to believe is harmful. The image below, from the Team Cymru researchers, shows the three steps involved in those attacks.

Three phases of an attack that changes a router's DNS settings by exploiting a cross-site request vulnerability in the device's web interface.
Enlarge / Three phases of an attack that changes a router’s DNS settings by exploiting a cross-site request vulnerability in the device’s web interface.

Wales team

In 2016, the people behind the same attack again pushed the malware known as DNSChanger. As I explained at the time, the campaign worked against home and office routers made by Netgear, DLink, Comtrend, and Pirelli like this:

DNSChanger uses a set of real-time communication protocols known as WebRTC send calls STUN server requests used in VoIP communications. The exploit can finally funnel the code through the Chrome browser for Windows and Android to reach the network router. The attack then compares the accessed router with 166 known vulnerable router firmware image fingerprints.

Assuming the PNA specification goes into effect, Chrome will no longer allow such connections unless devices within the private network explicitly allow it. Here are two diagrams showing how it works.


The road ahead

Starting with version 98, if Chrome detects a private network request, a “preflight request” will be sent in advance. If the preflight request fails, the final request will still be submitted, but a warning will appear in the DevTools issues panel.

“Any unsuccessful preflight request will result in a failed search,” wrote Google engineer Titouan Rigoudy and Google developer Eiji Kitamura in a recent blog post. “This may allow you to test whether your website would work after the second phase of our implementation plan. Errors can be diagnosed in the same way as warnings using the DevTools panels mentioned above. “

As long as Google is confident that there will be no massive outages, preflight requests will need to be granted in order for them to take place.

Leave a Reply

Your email address will not be published. Required fields are marked *