155.04 KB, image/png
160.35 KB, image/png
160.22 KB, image/png
2.87 KB, text/plain
Hi Team, The page at https://marketplace.mozilla.org/en-US/developers/submit/app/manifest offers the ability for users to provide the URL for an App's manifest on the Internet. A POST request is made to https://marketplace.mozilla.org/en-US/developers/upload-manifest using the POST variable "manifest". An attacker can port scan a server using this functionality by providing port numbers as part of the URL and using the unique responses recieved for closed and open ports as a signature. For example, I am using scanme.nmap.org for this POC. It is known that the ports 22 and 80 are open on scanme.nmap.org. 1. Test for Closed port: Provide input as "http://scanme.nmap.org:2243" and click validate. The response is always "[Errno 101] Network is unreachable" for any closed port. 2. Test for Open NON HTTP Ports (like SSH, FTP, SMTP etc) Provide input as "http://scanme.nmap.org:22" and click validate. The response will contain the string "Your manifest must be served with the HTTP header "Content-Type: application/x-web-app-manifest+json"." 3. Test for Open HTTP Ports Provide input as "http://scanme.nmap.org:80" and click validate. The response will contain the string "Your manifest must be served with the HTTP header "Content-Type: application/x-web-app-manifest+json". We saw "text/html".". Based on these unique error messages, one can identify the status of ports on remote servers. Please see the attached screenshots for the unique errors. I have found similar issues on other popular web applications on the Internet as well and am in the process of writing a paper on port scanning remote servers using popular web applications. I will be including this as an example in the paper which I will be presenting at an upcoming security conference. Please provide me with an update when there is a change in bug status. I have filed a bug on bugzilla.mozilla.org, https://bugzilla.mozilla.org/show_bug.cgi?id=767066. Also, does this qualify for a bug bounty? Please let me know if you would require any other information. Regards, Riyaz Walikar
Duplicate of this bug: 767066
Created attachment 636049 [details] Verbose error on accessing a Closed Port on remote server. This is the correct attachment. Please delete/ignore previous attachments.
Attachment #636049 - Attachment description: This is the correct attachment. Please delete/ignore previous attachments. → Verbose error on accessing a Closed Port on remote server.
Created attachment 636051 [details] Verbose error on accessing an Open NON HTTP Port on remote server.
We shouldn't be looking up ports other than 80 or 443, although there isn't any technical reason to prevent a manifest being hosted on any port the developer requires. All manifest lookups require a logged in user, so a large number of suspicious lookups can be logged and sent to ArcSight and users banned/blocked etc.
Limiting manifest URLs to port 80 and 443 seems reasonable. As I recall, the reason we allowed other ports was so people can do development easier with adhoc servers (node.js, Python, etc). These typically look like some-ip:8000 or some-ip:3000. It would be nice to retain that feature for our development/stage servers somehow (although they are publicly accessible).
This bug sounds like a wontfix to me. If you have to be logged in to access this page, andy is right, we can deal with this via logging. As noted by the OP, this is not an uncommon scenario on the web.
Somebody who wants to abuse this functionality can merely create a new account and try this all over again. An ideal fix would be to mask the responses in case a valid manifest file wasn't found. For example, if a valid manifest file is found, continue, if a request is made to a port that does not serve a valid manifest file display an error like "Invalid Manifest file" regardless of whether the port was open or closed. This will allow the functionality to be maintained as well as fixing the problem. The vulnerability arises because the page at https://marketplace.mozilla.org/en-US/developers/upload-manifest shows different responses for open and closed ports. If the responses are made generic and indistinguishable for open and closed ports then the problem is essentially solved.
There could be the possibility of timing attacks if it takes longer for an open port to respond, but that might be negligible - hard to say without trying. Anyway, rforbes - what do you want to do here?
Created attachment 637690 [details] PoC python script to do a port scan using the vulnerable URL This is a Python script PoC that does a port scan using the vulnerable URL: You could scan scanme.nmap.org, publicly known to have 22,80 and 9929 open, using the following syntax: python marketplace_mozilla_portscan.py scanme.nmap.org 22,23,80,445,3389,9929,10201
so, this is an issue we should see if we can resolve. Somebody getting port scanned this way will think it is us doing the port scan and that wouldn't be good. What can we do to generalize this error? i totally agree about the timing attack, and I am not sure what we can do about that. I am thinking on that and bringing that up with the security team.
A slight variation of this PoC allows me to scan localhost (127.0.0.1) showing me that port 22, 25 and 80 is open on the server that is making the HTTP requests. Will attach the PoC is a minute.
(In reply to riyazwalikar from comment #19) > A slight variation of this PoC allows me to scan localhost (127.0.0.1) > showing me that port 22, 25 and 80 is open on the server that is making the > HTTP requests. Will attach the PoC is a minute. That issue is already reported in bug 769043
-> ashort to make all errors give a generic message to the front end (feel free to log() something useful though)
Assignee: nobody → ashort
Target Milestone: --- → 2012-07-05
Would this bug be eligible under the Mozilla Bug Bounty program?
(In reply to riyazwalikar from comment #23) > Would this bug be eligible under the Mozilla Bug Bounty program? It is nominated but the final determination will be up to the bounty committee.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Fixed the Marketplace equivalent of this bug: https://github.com/mozilla/app-validator/commit/96cda9f858dd3455c21492b73225e0217e2dfa48 We really should have a good way of communicating problems like this to the team so that other areas that may suffer from the same problem can be corrected.
(In reply to Matt Basta [:basta] from comment #27) > Fixed the Marketplace equivalent of this bug: > > https://github.com/mozilla/app-validator/commit/ > 96cda9f858dd3455c21492b73225e0217e2dfa48 > > We really should have a good way of communicating problems like this to the > team so that other areas that may suffer from the same problem can be > corrected. Let me know what you have in mind. Review of any security bugs filed/closed in our weekly meetings?
I think that's a really good idea.
Very well. So let it be written.
You need to log in before you can comment on or make changes to this bug.