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


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

Starting with Chrome version 98, the browser will start relaying requests when public websites want to access endpoints inside the private network of the person visiting the site. At this time, failing queries will not prevent connections from occurring. Instead, they will only be saved. Somewhere around Chrome 101 – assuming the results of this trial don’t indicate major parts of the internet will be down – it will be mandatory for public sites to have explicit permission before endpoints can be accessed behind the browser.

The planned abandonment of this access comes as Google activates a new specification known as Private Network Access, which allows public websites to access internal network resources only after the sites have explicitly requested it. and the browser grants the request. PNA communications are sent using the CORS, or Cross-Origin Resource Sharing, protocol. Under this program, 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 accepted, the browser must respond with the corresponding header Access-Control-Allow-Private-Network: true.

Network intrusion via browser

Until now, websites had the default ability to use Chrome and other browsers as a proxy to access resources inside the local network of the person visiting the site. While routers, printers or other network assets are often locked down, browsers, due to the need for them to interact with so many services, are allowed by default to connect to virtually any resource at inside the perimeter of the local network. This gave rise to a class of attack known as CSRF, short for cross-script request forgery.

Such attacks have been theorized for over a decade and have also been carried out in the wild, often with significant consequences. In one incident in 2014, hackers used CSRFs to change DNS server settings for over 300,000 wireless routers.

The change caused compromised routers to use malicious DNS servers to resolve IP addresses that end users were trying to visit. Instead of visiting the genuine site, for example, the malicious server may return the IP address of a booby-trapped site that the end user has no reason to believe is harmful. The image below, from researchers at Team Cymru, shows the three stages involved in these 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.

Team Cymru

In 2016, the people behind the same attack came back to push malware known as DNSChanger. As I explained at the time, the campaign worked against home and business routers made by Netgear, DLink, Comtrend and Pirelli this way:

DNSChanger uses a set of real-time communication protocols known as webRTC to send so-called STUN server requests used in VoIP communications. The exploit is ultimately able to funnel code through the Chrome browser for Windows and Android to reach the network router. The attack then compares the accessed router to 166 firmware image fingerprints of known vulnerable routers.

Assuming the PNA spec goes into full effect, Chrome will no longer allow such connections unless devices on 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 preliminary request fails, the final request will still be sent, but a warning will appear in the DevTools issues panel.

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

If and when Google is confident that there won’t be massive disruptions, preflight requests will need to be granted to be processed.


Comments are closed.