Chrome browser will now block Internet websites from querying and interacting with devices and servers in local private networks for security reasons and past exploits by malware operations
Before requesting a private network for a subresource, Chrome will start sending a CORS preflight request, asking for explicit permission from the target server.
This preflight request will have a new header Access-Control-Request-Private-Network: true, and the response should have a corresponding header Access-Control-Allow-Private-Network: true must be added to the response.
If a local device such as a server or router does not respond, the Internet website will be blocked from connecting.
This change will be made through the implementation of a new W3C specification called Private Network Access (PNA), which will be rolled out in the first half of this year.
Private Network Access (formerly known as CORS-RFC1918) restricts the ability of a web site to send requests to servers on a private network.
This adds a mechanism within the Chrome browser that allows Internet sites to ask for permission from systems in the local network before establishing a connection
Browsers are being used as proxies to attack the local network
This PNA specification is one of the most important security features to be added to Chrome in recent years.
Since the early 2010s, cybercrime groups have realized that browsers can be used as “proxies” to relay connections to corporate networks.
For example, a malicious web site may contain code that attempts to access an IP address such as 192.168.0.1.
This address is a typical management IP address for router devices on the local network, and is an address that can only be accessed from the local network.
When a user accesses such a malicious site, the browser may make an automatic request to the router without the user’s knowledge and send malicious code that bypasses the router’s authentication and changes the router’s configuration.
This type of attack is not just a theory, it has been done before and examples of it have been described in detail.
Proofpoint has often reported that Exploit Kit (EK) activity is declining.DNSChanger is a malware that attacks Internet routers via the web browsers of potential victims.
Since the end of October, we have seen an improved version of the DNSChanger EK being used in ongoing malvertising campaigns. Since the end of October, an improved version of DNSChanger EK has been confirmed to be used in an ongoing ad campaign.
EK attacks vulnerabilities in the victim’s home or small office (SOHO) router, not in the browser or device.
Most router malware attacks, like DNSChanger, are done through the Chrome browser on Windows desktops and Android devices. However, once a router is compromised, all users connecting to the router, regardless of operating system or browser, are vulnerable to attack, and furthermore, advertising attacks are more likely to occur.
This variation of the Internet to local network attack can also target other local systems such as internal servers, domain controllers, firewalls, or locally hosted applications (via the http://localhost domain or other locally defined domain or through other locally defined domains), which can also target other local systems.
Google hopes to prevent such automatic attacks from becoming possible by introducing the PNA specification inside Chrome and building a permission negotiation system.
Google says that a version of the PNA is already bundled with Chrome 96, released in November 2021, but full support will be rolled out this year in two phases, Chrome 98 (early March) and Chrome 101 (late May), as follows.
How it works in Chrome 98
Chrome sends a preflight request before a private network subresource request.
If the preflight fails, you will only see a warning in DevTools, and it will not affect your private network requests.
Chrome will collect compatibility data and contact the most heavily impacted websites.
We expect it to be widely compatible with existing websites.
It will be implemented in Chrome 101 at the earliest
This will only be initiated if compatibility data indicates that the change is sufficiently safe, and with direct outreach as needed.
Chrome requires preflight requests to succeed, otherwise it forces the request to fail.
A deprecated trial will be started at the same time so that websites affected by this phase can request a time extension.
This trial will continue for at least 6 months.
Translated with www.DeepL.com/Translator (free version)
Comments