Closed Bug 455119 Opened 16 years ago Closed 12 years ago

[security] /@api/deki/ exposes a bunch of stuff it really shouldn't

Categories

(developer.mozilla.org Graveyard :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: justdave, Assigned: sheppy)

References

Details

our penetration testers reported the following:

Class: Information Disclosure

Severity: Medium

Difficulty to Exploit: Low

Targets: http://developer.mozilla.org/@api/deki/users (User entries)

Description: The web application API provides an md5 hash of the email addresses for each of the users available at http://developer.mozilla.org/@api/deki/users. The users' usernames and full names are also listed. This likely provides enough information to obtain the email addresses for a large percentage of the userbase. Many of the accounts probably use one of many free email services such as Gmail, Hotmail, Yahoo Mail, etc. Further, people tend to use a variation of their full name or reuse their username on these services. With a relatively small number of attempts, an attacker can determine legitimate email addresses by formulating a guess, hashing it, and comparing to the provided hash. As an example: username: dmagick full name: Tsani Jones email hash: f36829045e3ef1b8b07ea67b17197e64 email address: tsani.jones@gmail.com Calculating the md5 hash of tsani.jones@gmail.com confirms that this is the correct email address.

Exploit Scenario: A spammer or administrator of a competing site wants a list of email addresses for users of developer.mozilla.org. They can retrieve enough information listed at http://developer.mozilla.org/@api/deki/users to minimize the amount of effort in guessing email addresses and confirming their validity.

Short Term Solution: In addition to not sending the hierarchy under @api to the public web, don't send email hashes. If the information hashed is something fairly guessable, an attacker can generate likely plaintext email addresses, hash them, and compare them against the hash found on the website.

Long Term Solution: Ensure that the frameworks used to build websites don't send hashes of users email addresses. It is often very straightforward to calculate the email address down to the email address hash.
They reported this separately, but it's close enough related to the above that I don't think it deserves a separate bug...

Account Information Disclosure via Wiki API

Class: Information Disclosure

Severity: Low

Difficulty to Exploit: Low

Targets: http://developer.mozilla.org/@api/deki (API hierarchy)

Description: The http://developer.mozilla.org/@api/deki hierarchy has a large amount of user and site imple-mentation information that shouldn‟t be exposed to the network at large. The most concerning is the hierarchy under http://developer.mozilla.org/@api/deki/users. Each user on the system is listed at this address, along with their name, username, user id, permissions on the system, role number, last logged in date, and a hash of their email ad-dress. This information can be used to gain a great deal more information about users than is advisable.

Exploit Scenario: An attacker wants a list of valid usernames on the system to attempt password brute forcing, phishing attacks, or other directed attacks. This hierarchy gives them a full list of users on the system.

Short Term Solution: Don‟t vend the data under @api to the public web. Block this part of the website from public visibility.

Long Term Solution: Adopt disabling the visibility of this API as a standard procedure whenever this wiki framework is deployed.
Summary: [security] Valid Email Addresses are Harvestable Through Email Hashes → [security] /@api/deki/ exposes a bunch of stuff it really shouldn't
It's been over a month.  What kind of timeframe do we expect a response in?
MindTouch does not consider this a significant problem; I'm trying to convince them otherwise, but currently they don't have plans to address it.
given we are paying them, why are they making the call on if it's significant or not?
I'm working on that.
OK, MindTouch has addressed this by adding a configuration option that allows you to specify a salt term to prepend to the email address prior to hashing, to make reversing the hash into an email address through guessing.

I'm looking into when this fix will be available (it's in their trunk now).
(In reply to comment #7)
> OK, MindTouch has addressed this by adding a configuration option that allows
> you to specify a salt term to prepend to the email address prior to hashing, to
> make reversing the hash into an email address through guessing.
> 
> I'm looking into when this fix will be available (it's in their trunk now).

Is that a global salt?  The proper way to do this is a salt-per-hash.  If someone gets your global salt you're in the same boat you are in now.

Have you suggested they not add the hash to the page?
Sheppy: any update?
[masschange]

Sheppy: can you please give us an update here?  Is anyone working on this?  Your blog post said we've had two updates in the past week - is this being addressed?
Assignee: nobody → eshepherd
The hash unfortunately needs to be on the page; this is for the purpose of working with a tool that some of their clients use that we do not.

They're working with the developer of that other tool to find a way to correct it, but for now, they've added the global salt, which will at least help make it harder to reverse the hash.

This should be fixed in the 8.08.1a release that we can pick up today.
(In reply to comment #11)
> They're working with the developer of that other tool to find a way to correct
> it, but for now, they've added the global salt, which will at least help make
> it harder to reverse the hash.

See comment #8 for why a global salt is bad.
I recognize that, but how are they going to get the global salt, for one thing, and for another, right now it's the best we can get.  They know we don't like it and they're working on it, but this is still an improvement.
Aside from finding another security hole they could always upload a few known values and start looking for the salt that way.

Anyway, I agree it's better than nothing and it sounds like it's going into core (and eventually to us) anyway.  I'm not comfortable closing this bug with only a global salt in place though.
We'll be able to pick any salt value we want to.  It would be awfully hard to guess what random string of characters we choose to use.
Are there any updates on this issue? Were the updates of per user or selectable salts pushed out?
Deki no longer provides email addresses with the user data exposed via the API or script unless the request comes from an admin login, or the user in question. So that's good.

The global salt feature is in, but we haven't enabled it. Enabling it will require a wiki restart immediately after applying the change (it's one of those config changes that makes the wiki stop working until it's restarted).

I just need to set the value of the security/authtokensalt preference to a string to use as the salt.

Assigning to oremj temporarily to get his attention so we can schedule this config change and restart.
Assignee: eshepherd → jeremy.orem+bugs
Do you want to do this tomorrow?
Yeah, let's do that. I'll ping you tomorrow and we'll coordinate so you're available to kick the server after I make the configuration change.
Actually, I'm checking on some details here. Despite MindTouch saying email addresses are no longer included by default, they seem to still be, so I'm checking on this. We might have an additional setting to change, and it makes sense to do both at once.
OK, MindTouch just today checked in a change that lets us disable the email and gravatar links from being included. The next MindTouch release will include that feature.

For my reference at that time, I just need to the "gravatar/secure" value to "hidden".
Can you reassign to server-ops when there's a fix to deploy?
Assignee: jeremy.orem+bugs → eshepherd
What is the status of this bug? We had a researcher report this issue to us yesterday via Bug 624273?

What is this api needed for? What would break if we disabled that page or put it behind an auth?
This should be fixed when we install MindTouch 2010, which I hope to get done in the next few weeks. Sooner if we don't have any technical issues, longer if we have problems getting the upgrade done.
Ping. Did this upgrade occur?
Component: Deki Infrastructure → Other
Given that deki is gone, I'm guessing we can close this out?
(In reply to James Socol [:jsocol, :james] from comment #28)
> Given that deki is gone, I'm guessing we can close this out?

Yep.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
For bugs that are resolved, we remove the security flag. These haven't had their flag removed, so I'm removing it now.
Group: websites-security
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.