1100004 - Firefox OS Find My Device ClickJacking Security Vulnerability

Status: RESOLVED FIXED

(Cloud Services Graveyard :: Find My Device, defect)

Description

[Mohamed A. Baset]

Attachment: Firefox OS Find My Device ClickJacking Security Vulnerability

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141110195804

Steps to reproduce:

Hi Mozilla Security Team,

My name is Mohamed Abdelbaset Elnoby an Information Security Evangelist from Egypt, responsible for the "Samsung Find My 

Mobile" CSRF Security Vulnerability, here is some details about it:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8346
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8346
http://thehackernews.com/2014/10/samsung-find-my-mobile-flaw-allows.html
http://www.computerworld.com/article/2839240/zero-day-in-samsung-find-my-mobile-service-allows-attacker-to-remotely-

lock-phone.html
http://mashable.com/2014/10/28/hackers-samsung-find-my-mobile/
http://www.businessinsider.com/hackers-use-find-my-mobile-to-wipe-any-samsung-phone-2014-10
http://www.dailymail.co.uk/sciencetech/article-2812286/Samsung-flaw-lets-hackers-remotely-lock-devices-Bug-Mobile-service-

leaves-handsets-open-attack.html

Today I would like to report a Security Vulnerability in Firefox OS Find My Device feature, details as follow:

Vulnerability :
ClickJacking

Info:
https://www.owasp.org/index.php/Clickjacking

Affected URL(s):
https://find.firefox.com

Highlights on the Vulnerability:
Regardless The security protection mechanism which is that that attacker definitely can't guess or brute force the Device id 

"8fcXXXXc40de04b3803945XXXXXXXXXX" to make a successful clickjacking attack iframe, This protection mechanism is too low 

coz all the attacker to do is just to point the logged in user to his iframe source https://find.firefox.com and Mozilla will care about 

the other things "will redirect him to the correct logged in active device id.

What attacker can do:
-Erase the victim's device data with just only 3 clicks by the victim himself if he tricked with "click here to win a 50 BTC for 

Example"
- Lock The victim device or change his lock code if it is the first time to be set "4 clicks"
- Makes the Device ringing "2 clicks"

More Details About clickjacking:
Because of No Frame Busting Techniques or X-Frame-Options header, the whole website is vulnerable to Clickjacking attacks 

which could lead to a full account takeover considering such scenario:
1. Attacker will iframe any sensitive the website page and adjust the iframe size and add a "divs" as a layers on the unwanted-to-

show parts of the original web page to fool and trick the user.
2. User get tricked by the crafted page and followed the attacker's instruction to do a specific clicks to the iframed page
3. Unwanted actions happened in the logged in user's session in result to the attack's clicks.

Remedy:
1- Add an X-Frame-Options HTTP Header and set it's value to "Deny" or "Sameorigin" as you can see it suitable to mitigate such 

attacks
2- Use iframe busting techmiques in JS code like this:

<script type="text/javascript">
 if (self === top) {
 var antiClickjack = document.getElementById("antiClickjack");
 antiClickjack.parentNode.removeChild(antiClickjack);
 } else {
 top.location = 'Your_Website_URL_Here';
 }
</script>

or

<script type="text/javascript">
 // Disable frame hijacking 
 if (top != self) 
 top.location.href = location.href;
 </script>

References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

Waiting for your reply
Thanks


Actual results:

Find My Device web interface is iframable which makes it vulnerable to ClickJacking Attacks


Expected results:

Find My Device web interface mustn't be iframed Apply XFO or Frame Busting techniques:

<script type="text/javascript">
 if (self === top) {
 var antiClickjack = document.getElementById("antiClickjack");
 antiClickjack.parentNode.removeChild(antiClickjack);
 } else {
 top.location = 'Your_Website_URL_Here';
 }
</script>

or

<script type="text/javascript">
 // Disable frame hijacking 
 if (top != self) 
 top.location.href = location.href;
 </script>

References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

Comment 1

[Mohamed A. Baset]

Any Updates?!

Comment 2

[chris hofmann]

dougt, who should own?

Comment 3

[Mohamed A. Baset]

(In reply to chris hofmann from comment #2)
> dougt, who should own?

!!!

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I just verified this issue works as reported. 

Just to summarize the attack scenario above: 
- User must be currently logged into the find.firefox.com website
- User is coerced into visiting a malicious website, and then coerced to click 3 times

The impact is wiping the device. Potentially locking the phone could be an impact, but this requires setting a PIN so less likely attack vector (clicks alone don't work). 

Note that the user has to already be logged in. Even with a password manager which might allow clickjacking the login screen as well, the login sequence breaks when it is framed.

The simplest fix would be to set the x-frame-options header to DENY for this domain.

Yvan, Joe - any idea who owns this infrastructure? If you're not sure, just assign back to me and I'll chase for an owner.

Comment 5

[Joe Stevensen [:joe]]

Paul,

I have no idea who owns it. I'll try to find the owner and get the fix you suggested implemented.

Comment 6

[Joe Stevensen [:joe]]

Paul,

Cloud services owns this. Recommend assigning to Yvan.

Comment 7

[Mohamed A. Baset]

Any Updates?!

Comment 8

[Al Billings [:abillings - ex-MoCo]]

(In reply to Mohamed A. Baset from comment #7)
> Any Updates?!

This is not helping. If there were updates, they would be here. Since there are no further comments, there are no updates at this time. People will work on this issue as they have time and availability.

Comment 9

[Mohamed A. Baset]

Oka(In reply to Al Billings [:abillings] from comment #8)
> (In reply to Mohamed A. Baset from comment #7)
> > Any Updates?!
> 
> This is not helping. If there were updates, they would be here. Since there
> are no further comments, there are no updates at this time. People will work
> on this issue as they have time and availability.
Okay :)

Comment 10

[JR Conlin [:jrconlin,:jconlin]]

This appears to be on the web

Comment 11

[JR Conlin [:jrconlin,:jconlin]]

Jeremy, can you add the list of recommended headers from 
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
to the STAGE deployment servers of FMD? We will test and verify that there's no additional customer impact before rolling this change to PRODUCTION.

Comment 12

[Jeremy Orem [:oremj]]

We are running straight Go on the FMD servers, so we can either start fronting the services with nginx or add the headers to the app. Fronting the app with nginx would need more QA.

jr, do you have a preference?

Comment 13

[JR Conlin [:jrconlin,:jconlin]]

Wait, I know that we're running straight to go for / but for /static/* components (/bower*, /style/*, etc.) we shouldn't be using the "use_insecure_static" option. Those should be handled by something else like nginx. 

I'm adding a patch to the go code to handle the root paths, and see about confirming the source of the additional site files.

Comment 14

[Mohamed A. Baset]

Hi,

You can add just insert JS code (in the vulnerable pages) to handle the framing problem, no need for the XFO headers (if that will break something in the compatibility integration with other services)

For example:

<script type="text/javascript">
 if (self === top) {
 var antiClickjack = document.getElementById("antiClickjack");
 antiClickjack.parentNode.removeChild(antiClickjack);
 } else {
 top.location = 'Your_Website_URL_Here';
 }
</script>

or

<script type="text/javascript">
 // Disable frame hijacking 
 if (top != self) 
 top.location.href = location.href;
 </script>

Thanks

Comment 15

[Jeremy Orem [:oremj]]

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #13)
> Wait, I know that we're running straight to go for / but for /static/*
> components (/bower*, /style/*, etc.) we shouldn't be using the
> "use_insecure_static" option. Those should be handled by something else like
> nginx. 
> 
> I'm adding a patch to the go code to handle the root paths, and see about
> confirming the source of the additional site files.

If we want them both to be on the same domain, it is all or nothing.  We'd have to host the static files with nginx and proxy /.

Comment 16

[JR Conlin [:jrconlin,:jconlin]]

Added headers to all outbound server responses:

https://github.com/mozilla-services/FindMyDevice/pull/327

also increased the STS delay per bug 1143977

Comment 17

[Mohamed A. Baset]

Hi,

I have checked the fix if it was online or not and found that it is vulnerable till now, so is the patch online or not being pushed yet?!

Thanks

Comment 18

[JR Conlin [:jrconlin,:jconlin]]

We're a bit tight on QA resources. The fix is working it's way through stage at the moment to ensure that we don't break any devices or interfaces that are already deployed.

Comment 19

[Daniel Veditz [:dveditz]]

JR: is this bug fixed or not? Hopefully the former because it's public now
http://seclists.org/fulldisclosure/2015/Oct/82

Comment 20

[April King [:April]]

I saw that X-Frame-Headers: deny was set on the page, earlier today.

Comment 21

[April King [:April]]

Err, X-Frame-Options.

Comment 22

[JR Conlin [:jrconlin,:jconlin]]

Following up per sec request, the fix was applied to the code Mar 18 deployed to STAGE 
https://bugzilla.mozilla.org/show_bug.cgi?id=1146226

And deployed to Prod shortly there after. Unfortunately, I don't have a bug handy for that deployment since it came from QA. I will attempt to track that down. 

The absolute latest it was deployed was part of 1.4.7 (the latest deployed version) on 04/21
https://bugzilla.mozilla.org/show_bug.cgi?id=1156348

Comment 23

[Mohamed A. Baset]

Hi Guys, I'm requesting a CVE for this!.

Comment 24

[Al Billings [:abillings - ex-MoCo]]

(In reply to Mohamed A. Baset from comment #23)
> Hi Guys, I'm requesting a CVE for this!.

From whom?

Comment 25

[Mohamed A. Baset]

Maybe Mozilla can work along with MITRE to get this. or should i report it individually to them?

Comment 26

[April King [:April]]

CVEs are for publicly released software packages, not for services or websites.  Since the vulnerability lies in the service and not the software (ie, FxOS), there wouldn't be a CVE issued for something like this.

Comment 27

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Ravi - this was a configuration issue on a server. It was fixed months ago - it has nothing to do with 2.2r as per comment 22.

Comment 28

[Ravi Dandu]

Paul, thanks for the explanation.