Header aches in Firefox, Tor, Brave and Chrome as HTTP opens new security holes

The HTTP Alternative Services header can be abused to conduct network reconnaissance and attacks, to bypass malware protection services, and to foil tracking defenses and privacy assumptions, according to a paper scheduled to be presented at the WOOT ’19 security conference on Tuesday.

Back in March 2016, the Internet Engineering Steering Group approved the HTTP Alternative Services header as a proposed web standard for situations when a web server needs to send a client to another service.

There are a variety of legitimate reasons to do this: a web server may be overloaded with requests, may be undergoing maintenance, or may determine that another server is closer (and thus quicker to respond).

As Mark Nottingham, co-chair the IETF HTTP and QUIC Working Groups, explained at the time, such redirection can be handled by DNS load balancing under short-lived HTTP/1.1 connections.

But DNS load balancing doesn’t work as well with HTTP/2, which is designed to maintain a persistent connection.

HTTP Alternatives Services was designed as an alternative method to point requests elsewhere. It allows a web server to return a header that specifies another server as the host of its resources, in effect deputizing the stand-in to act as the Origin, the first-party source of content.

“The ability to redirect clients to use another server in a transparent, persistent fashion brings some obvious security concerns,” said Nottingham in his post.

A paper titled “Alternative (ab)uses for HTTP Alternative Services,” by boffins Trishita Tiwari, who co-authored the paper while at Boston University and is currently a cyber-security PhD student at Cornell University, and Ari Trachtenberg, professor of electrical and computer engineering at Boston University, makes these obvious security concerns more evident.

HTTP headers are a way for clients and servers to communicate metadata during a request-response interaction. An Alternative Services header, returned with a response to a client request, might look something like this:

Alt-Svc: h2=”new.example.org:443″; ma=600

This tells the client that for the next ten minutes (600 seconds), it can connect to new.example.org on port 443 using the HTTP/2 protocol. The redirect information might also include an optional persist parameter indicating that the alternative service can be remembered after session and network changes.

According to Tiwari and Trachtenberg, Google uses Alternative Services to advertise an alternate endpoint for serving content via its UDP-based QUIC protocol. Meanwhile Facebook, among other websites, detects Tor client browsers and uses Alternative Services to point users to onion hidden service endpoints. The protocol is supported by desktop browsers like Brave, Chrome, Firefox, Opera and Tor, as well as various mobile browsers.

The researchers found that the Alt-Svc header can be used to force a Firefox or Tor user to scan any TCP ports of any host accessible to the victim. They reported this vulnerability to Mozilla, which issued a fix for CVE-2019-11728 in its July release of Firefox 68 (which also covers Tor, based on Firefox ESR).

They also implemented this attack on Chrome and Chromium-based Brave using QUIC as an Alt-Svc endpoint. The researcher say they’ve disclosed this to Google and discussions about mitigations are underway; QUIC is currently hidden from Chrome users behind an experimental flag and must be activated by the user.

“The basis of this attack is the observation that if a website specifies an Alt-Svc header to a secondary host with an HTTP/2/QUIC endpoint, then browsers immediately try to initiate a handshake with the secondary host, without performing any checks on the host or port,” the researchers explain in their paper. “The secondary host could even be a private IP or localhost, and the port could be on the browser’s HTTP port blacklist.”

Alt-Svc also provides a way to bypass the Safe Browsing system used by Brave, Chrome and Firefox. “[I]f a clean, whitelisted first-party specifies a black listed domain as its Alt-Svc, then the Safe Browsing checks are skipped and all content is loaded from the malicious domain,” the research paper explains, noting that the blocked site must present the certificate of the clean site, which would require collusion between the two.

The header also provides a way to avoid online site checking tools like VirusTotal, URLVoid, Sucuri and IPVoid, the researchers say, noting that security checks like Safe Browsing need to not only check the first-party domain but also the designated Alt-Svc domain before marking websites safe.

Distributed denial of service attacks are possible in Firefox and Tor because, unlike Chromium-based browser, they do not remember broken endpoints. Thus it’s possible to use an iframe to create a reload loop that would force repeated TLS connection attempts, creating a denial of service attack.

What’s more, Alt-Svc can be used to track people despite privacy protections. “By specifying a unique Alt-Svc for each user, and observing subsequent user requests, an attacker could track a user both as a first-party website and a third-party iframe or image,” the paper explains.

Along similar lines, network service providers can abuse Alt-Svc to extract otherwise unavailable web history data through the observation of resource loading.

In an email to The Register, Tiwari said Mozilla addressed the port scanning and DDOS vulnerability with a patch that reduced the surface area of the attack by preventing Alt-Svc connections to certain sensitive non-HTTP ports.

“While this does not entirely eliminate the underlying issue (as is often the case with patches for many side-channel attacks), this patch brought Mozilla’s exposure down to the same level as Chrome and Brave (which most would consider to be an acceptable level of exposure),” she said.

The Safe Browsing issues discussed in the paper have yet to be fully addressed. “I was unconvinced of the explanation that Google provided us on how they address this issue,” she said.

“We have been trying to communicate with them, but they haven’t been particularly responsive about the concerns that we raised about their mitigations. This is really unfortunate given that Safe Browsing is employed by not just Chrome, but also Firefox, Brave, etc. and so is relied upon by a lot of people.”

Tiwari said that the security implications mentioned in Nottingham’s 2016 blog post were incorporated into the Alt-Svc spec.

“The spec does attempt to address these issues, but the mitigations proposed there (i.e., clearing the Alt-Svc cache when the user clears their browser cache) are not strong enough,” she said.

“Browser vendors understand this and are now proposing much stronger mitigations like cache isolation (which should, in my opinion, be included in the spec so that it is not at the mercy of individual browser vendors to implement it – user tracking has become a rising issue, and it is high time that these RFCs start requiring cache isolation upfront).”

“The rest of the attacks we show in the paper stem from how the Alt-Svc spec was improperly implemented, so, in a sense, the remaining attacks weren’t fundamental design flaws, but rather flaws in the way browser vendors implemented the design,” she said. ®

Sponsored: Balancing consumerization and corporate control

READ MORE HERE