1268346 - Mozilla support cache poisoning to open redirect

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[Yassine ABOUKIR]

Hi,

I discovered a security vulnerability that allows an attacker to poison any legitimate user cache and redirect him/her to malicious websites designed to hijack the user's login credentials.

At first, I noticed a minor bug that was leading to an invalid redirection. When you add a slash to the last part of the URL such as : 

https://support.mozilla.org/en-US//evil.Com (Bug 1)

You will be redirected to https://en-Us//Evil.Com  which is not exploitable so far.

I also found that we can set arbitrary languages via: https://support.mozilla.org/en-US/locales?lang=test (Bug 2)

So when you browse to https://support.mozilla.org you will be redirect to :

https://support.mozilla.org/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/test/

Finally, I chained both bugs (1 and 2) to craft a successfull poisoning and redirect attack. When we send our victim the following link :

https://support.mozilla.org/en-US/locales?lang=/evilzone.org

The language will be set to /evilzone.org so when the victim browse to https://support.mozilla.org he/she will be redirected to https://support.mozilla.org//evilzone.org and due to our first bug the victim will be taken to https://evilzone.org

Notice that everytime the victim reloads https://support.mozilla.org he/she will automatically be redirect to our phishing/malicious page.

Final Exploitation : An attacker can simply post the following link in a support discussion or comment: https://support.mozilla.org/en-US/locales?lang=/evilzone.org once any SUMO user clicks on it, his/her browser cache will be poisoned, consequently the user will be redirected to evilzone.org each time he/she visits SUMO platform.

Proof Of Concept : https://www.youtube.com/watch?v=RZP3UDYjwac (Video publicly unlisted)

Kind regards

Comment 1

[Daniel Veditz [:dveditz]]

Confirmed. Made SUMO impossible to reach until the cache was cleared.

Comment 2

[Adam Muntner [:adamm] (use NEEDINFO)]

Thank you for reporting, Yassine, very nice catch. 

David, who should the security point of contact be for sumo? Could you please update our contact spreadsheet?

https://docs.google.com/spreadsheets/d/14Gp6TPAibO7UkgJTXSeOIeFNMdfDbrUXQpqRFW3tDbg/edit#gid=0

Comment 3

[Yassine ABOUKIR]

Hi,
I have taken a look over some sec bugs and noticed that [e-mail] is in charge of SUMO security if that might help get this bug patched ASAP.

Comment 4

[Michael Cooper [:mythmon]]

I'm not working on Sumo anymore. I'll redirect this to Giorgos, who is more fit to work on this right now.

Giorgos: I'd start by looking at the LocaleUrlMiddleware[0]. That is what is reading the locale from the URL and the lang query parameter. It also uses a class called Prefixer[1] to actually modify the URLs. Beyond that, I never worked on the language redirects, so I'm not sure where to look next.

[0]: https://github.com/mozilla/kitsune/blob/e95b95d1032462ecf5d417d32157a1eaba6124b3/kitsune/sumo/middleware.py#L22
[1]: https://github.com/mozilla/kitsune/blob/e95b95d1032462ecf5d417d32157a1eaba6124b3/kitsune/sumo/urlresolvers.py#L124

Comment 5

[Giorgos Logiotatidis [:giorgos]]

Attachment: Only redirect if lang is in SUMO_LANGUAGES

Comment 6

[Yassine ABOUKIR]

Hi,
The fix seems to be resolving the issue. 
I hope it will be deployed to production environment soon.

Comment 7

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

The fix seems to work in STG, but the behavior mentioned as bug 1 is still reproducible.

Comment 8

[Yassine ABOUKIR]

You are right! The first bug is still reproducible :

>https://support.mozilla.org/en-US//evil.Com (Bug 1)
>You will be redirected to https://en-Us//Evil.Com

Comment 9

[Giorgos Logiotatidis [:giorgos]]

Indeed but without the first bug this cannot be exploited in a meaningful manner. I'll go ahead and deploy those changes today.

Comment 10

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

OK. Let's mark this bug as FIXED than and make a new clone for the behavior described as bug 1, so we won't loose it. If you won't have time to look at it, I might give it a try during the weekend or the next week.

Comment 11

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Have you successfully deployed the fix, Giorgos?

Comment 12

[Giorgos Logiotatidis [:giorgos]]

No, we're currently blocked. I'll update when I have more info.

Comment 13

[Daniel Veditz [:dveditz]]

Although we don't normally award bounties for denial of service bugs, this one is clever and a nice find.

Comment 14

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

What are we being blocked by now? How can I help?

Comment 15

[Giorgos Logiotatidis [:giorgos]]

Your offer is appreciated. The whole team is in London these days and things move extremely slowly on this front. Please hang tight.

Comment 16

[Giorgos Logiotatidis [:giorgos]]

This is finally now on production. Yassine can you please confirm that this is fixed?

Comment 17

[Yassine ABOUKIR]

Hi,
The first bug is still reproducible : https://support.mozilla.org/en-US//evil.Com (Bug 1)

Comment 18

[Giorgos Logiotatidis [:giorgos]]

Yes, but the security issue needs both. So without the second bug you cannot poison the cache, correct?

Comment 19

[Yassine ABOUKIR]

Correct. The cache poisoning is no longer possible in this case ;)

Comment 20

[Giorgos Logiotatidis [:giorgos]]

Great! thanks again for reporting.

Comment 21

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Yeah, Kitsune is not vulnerable this way now, but still the first issue should be fixed. Close this bug and resolve the first issue separately later?

Comment 22

[Giorgos Logiotatidis [:giorgos]]

Verified per comment #19

Comment 23

[Adam Muntner [:adamm] (use NEEDINFO)]

Removing the security flag, the vuln is fixed and the issue remaining is not a security issue

Comment 24

[Adam Muntner [:adamm] (use NEEDINFO)]

Michal - This bug is closed, if you want to track the remaining issue, best to track it in a new bug