Phonebook :: Invite :: Potential possibility of middle man attack can make a person as vouched while she/he was not invited.

VERIFIED INVALID

Status

VERIFIED INVALID
6 years ago
5 years ago

People

(Reporter: ravi, Unassigned)

Tracking

Details

Attachments

(2 attachments)

1.32 MB, application/octet-stream
Details
1.39 MB, application/octet-stream
Details
(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22

Steps to reproduce:

Vulnerable Attack Stories:

Day-1 Attack:
----------------

The staff of Mozilla sends a Mozillians invite to a person. The third man who is watching the network and sitting in middle holds this HTTP request. Looking at the invite being sent, excited and thrilled third man changed the email-id to exploiter email-id and forwarded the request. 

The invitation was sent to exploiter and not to the intended person.  If the inviter did not watch the email-id closely, it is a problem. If observed too, nothing can be done for it because the inviter has no permission to revoke back the invitation. System administrator of Mozillian has to do this job.


Day-2 Attack:
----------------

The staff of Mozilla or vouched mozillian sent out an invitation again to yet another user.  The exploiter sitting in middle sniffs this request and captures its request header details.  Attacker follows the same steps and was able the send invitation to another one exploiter only.

He remembered that the request was captured in history. Now he sniffed into it and generated the payload of different email-id to which the invitation has to be sent.  Then he marks the 'recipient' parameter as payload variable for replacing the payload list into it.  Entering other exploiters email-id, he initiates the attack.

Sadly by this time invitation was sent out to all exploiters successfully.  Exploiter intimated about the invitation sent to every other exploiter, who all accepted the invitation and became the vouched users of Mozillian. These exploiters got access into Mozillian database and started to find more loop holes in the design and existing product. Later it was attacked to an extent, product server was supposed to shut down.  The other Mozilla products with which Mozillian was coupled, it also had exploit traces.


*** End of Attack Stories ***



Steps to Reproduce:
--------------------

Prerequisite:
a] Have proxy set up and watching for the request on the network.


1. Sign in as vouched user of Mozillian.
2. Send the invite to a user.
3. Stop the request and observe the contents of it. Replace or append the email-id of your interest and forward the request.
4. Notice to whom the invitation is sent. It is for the email-id added by exploiter.
5. Pick the request and generate the payload. Keep the payload as list of email-id.
6. Start the attack (i.e. send the request).
7. Notice to invitation being sent to all email-id's which was used as payload items.



Actual results:

It is possible to change the details in between and send request to someone else. One request can send multiple invitations when payload list is used. The user who sent the genuine invitation will not be aware of this. But all the invitation goes from her/his account.  This is not intimated to the inviter.


Additional risks by problem in Design:
--------------------------------------

Once the exploiter accepts the invitation and fill up the profile details, she/he will be vouched user in Mozillans community.  This design behavioral appears to be highly catastrophic in this context. As the inviter will not be aware what has happened from her/his one request. Just by clicking on invitation token link, 'vouched' feather is added to invitee.

This should be seriously reconsidered. This user flow is not appropriate and more vulnerable to attacks.



Expected results:

1. Inviter should get intimation in email to whom all the invitation is sent.

2. Invitation should have an expiry time.

3. Should not be possible for invitee for becoming vouched user for accepting the link. The inviter should grant it, later. Though this looks tedious job for inviter, nothing is bigger than security and brand business name of Mozilla.  Else it is suggested that another design and user flow should be designed and implemented for invitation and vouching.  Be whatever the design is, there are ways to exploit it; let it not be too straight forward and obvious.
(Reporter)

Comment 1

6 years ago
Created attachment 723472 [details]
Video file


Video files 849829a.3gp and 849829b.3gp attached shows the above said details.

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
Status: NEW → UNCONFIRMED
Ever confirmed: false
Note that I can't open the video file, 7-zip thinks this is an invalid archive and it doesn't open as a video in VLC either.
(Reporter)

Comment 3

6 years ago
Created attachment 723766 [details]
Video file (reattached)

Reattaching the compressed video files.

Video files 849829a and 849829b attached shows the above said details.
This file format also can be played using Windows Media Player too.
(Reporter)

Updated

6 years ago
Flags: sec-review?
The Mozillians site is https and thus the ability to MITM in the site traffic is mitigated by this. The testing here is using a local proxy which is intercepting the traffic before it is protected. Protecting from a MITM attack that is present on a given client is out of scope and thus this bug is invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Flags: sec-review?
Resolution: --- → INVALID
Group: websites-security
(Reporter)

Comment 5

6 years ago
Yes. While data is on wire using HTTPS, it will be encrypted. This was a report to show how the present design is fallible while an encrypted data is cracked.

Will try it out using Wireshark and identify the patterns of data, and then update this bug.
Bumping to verified invalid per comment4
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.