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 significant 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 has granted 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
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 an attack class known as CSRF, short for cross-script request forgery.
Such attacks have been theorized for more than 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 Google.com 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.
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 called webRTC supposedly send STUN Server queries 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 post. recent blog post. “This can allow you to test if your website will work after the second phase of our deployment 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.