1553002 - DDoS using Alt-Svc on Firefox

Status: RESOLVED DUPLICATE of bug 1552993

(Core :: Networking: HTTP, defect)

Description

[Trishita Tiwari]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Contributors: Trishita Tiwari (me) and Prof. Ari Trachtenberg (my advisor) from Boston University.

General Description:
The HTTP Alternative Services header (Alt-Svc) implementation on the Firefox browser may be abused by an attacker to compromise security measures, for instance, to DDoS other (non-http) services. (Note that other attacks related to the Alt-Svc implementation on Firefox have been filed in separate reports, as indicated in the bugzilla guidelines)

To effect these compromises, an attacker need only have the victim visit a website under the attacker’s control (either as a first party or a third party through an image/iframe). The attacker’s website specifies an Alt-Svc header that enables the various attacks in a manner that is not visible to the victim (i.e. URL and domain name visible in the browser are not affected).

Details on DDoS:
Firefox does not maintain a memory of broken Alt-Svc values (unlike Chrome and Brave browsers). Hence every time a page is reloaded, a connection to it’s Alt-Svc is attempted (if one is specified). This happens even if the browser had attempted a connection to the same Alt-Svc in a previous load and realized that it was broken (i.e., certificate mismatch or some other issue). As such, if we have a reload loop in an iframe, we could force victims’ browsers to repeatedly initiate TLS connections with a target server/port combination (as in the "port scanning" attack, Bug 1552993), effectively DDoSing it.

This is different from regular JavaScript DDoS attacks, because Firefox does not check the port number of the Alt-Svc connection. For example, the attacker could force the victim to repeatedly initiate TLS handshakes to non-HTTP speaking services (e.g., email and FTP servers that run on ports whose access is otherwise blocked through JavaScript), and make them to present their certificates repeatedly. This is fairly low effort on the client’s part (because the client hello packet is very small), but high effort on the server’s part (as the server hello packet may be quite large due to large server certificates). We have observed certificates as large as 29KB (e.g, smtp.bu.edu:465) for client hello packets of roughly 0.5KB. As a result, this amplification attack could exhaust a target server’s resources, either from a single client or as part of a distributed attack where multiple browsers continuously ask these non-http services to present their certificates.

In fact, even services that do not speak TLS can be targeted. Many plain-text email and FTP servers have long timeouts for every connection (smtp.bu.edu:25, ftp.bu.edu:21, smtp.zoho.com:587 etc). For instance, let us say that the attacker forces the victim browser to send a TLS client hello packet to a plain-text email service (i.e., SMTP port 25) by appropriately setting its Alt-Svc to point to the service. Even though the email server does not understand the hello packet, it still keeps the connection open for as long as the browser requests (e.g. 30-40 seconds, after which point the browser itself typically terminates the connection). If enough victim browsers are made to target a server, it may be possible to exhaust all available connections on the target server.

Actual results:

Demo: We provide a website that contains an iframe. This iframe specifies an Alt-Svc that points to a target machine that is to be DDoSed (in this demo, this is set to 128.197.128.238:25, which runs a TLS speaking service.). The iframe is made such that it continuously reloads through JavaScript. Indeed, every time the frame reloads, the browser sends a fresh TLS client hello packet to the target web server, thus opening a brand new connection. As described above, if enough browsers are made to do this, it might be possible to take down the target server.

Demo link: http://trishita.ddns.net:9000/h2/ddos-landing.html

Expected results:

Mitigations:
Firefox might want to institute the same port blacklist for Alt-Svcs as they do for JavaScript. This will help protect non-http services from being attacked this way.

Comment 1

[:Gijs (out for now; he/him)]

To be clear, for http/https services / generally accessible ports, this is no worse than the response from the attacker's iframe either including (via <link> tag or similar) or redirecting (using e.g. http 302) to the victim page, or doing so repeatedly via JS on the page, right? That is, this is only a security issue due to the possibility of targeting ports that are normally blocked?

Comment 2

[Ari Trachtenberg]

I believe that this is correct. This approach allows repeated query attacks on blocked ports.

Comment 3

[Trishita Tiwari]

(In reply to :Gijs (he/him) from comment #1)

To be clear, for http/https services / generally accessible ports, this is no worse than the response from the attacker's iframe either including (via <link> tag or similar) or redirecting (using e.g. http 302) to the victim page, or doing so repeatedly via JS on the page, right? That is, this is only a security issue due to the possibility of targeting ports that are normally blocked?

Yes, this attack's specific advantage is that you can DDoS services that you should not be able to access through a web-browser at all.

Comment 4

[:Gijs (out for now; he/him)]

(In reply to Trishita Tiwari from comment #3)

(In reply to :Gijs (he/him) from comment #1)

To be clear, for http/https services / generally accessible ports, this is no worse than the response from the attacker's iframe either including (via <link> tag or similar) or redirecting (using e.g. http 302) to the victim page, or doing so repeatedly via JS on the page, right? That is, this is only a security issue due to the possibility of targeting ports that are normally blocked?

Yes, this attack's specific advantage is that you can DDoS services that you should not be able to access through a web-browser at all.

OK, in that case, I think bug 1552993 (which prevents using alt-svc with services on such ports) should be sufficient to also deal with this problem, so I'll mark this as a duplicate - even if the consequences cited are different, the remedy is the same.