User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Build Identifier: some files visible from here http://graphs.mozilla.org/server/ contain credentials Reproducible: Always Actual Results: I can see some info about the db used and some credentials Expected Results: directory listing should be avoided as for python source code with credentials
I can't move this to IT without dropping the security group, so just assigning it to server-ops@ and making a blocker.
Assignee: nobody → server-ops
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Specifically, http://graphs.mozilla.org/server/graphsdb.py is the main problem here, though there may be some other credentials that I haven't seen yet.
Group: websites-security → infra
Component: other.mozilla.org → Server Operations: Security
Product: Websites → mozilla.org
QA Contact: other-mozilla-org → clyon
Version: unspecified → other
I dropped the following into .htaccess in that directory: -----8<----- Options -Indexes <FilesMatch ^(.*\.py|.*\.pyc|.*\.orig|.*\.rej)$> deny from all </FilesMatch> -----8<----- I'll work on resetting the db credentials, and this app could use an audit of the rest of its directory structure for similar issues.
the "rhelmer" version on the staging site has a different directory structure, and also looks like it has .py files meant to be executed from the web server at first glance. Otherwise I did the same to the staging sites.
Assignee: bkero → nobody
Group: infra → webtools-security
Component: Server Operations: Security → Graph Server
Product: mozilla.org → Webtools
QA Contact: clyon → graph.server
In the 2.0 version we've centralized auth to the .wsgi file (which had a similar problem, bug 645958). We should move the file used for auth out of the docroot altogether, I think.
So I'm going to need to coordinate with someone on IRC to actually change the DB credentials. We've apparently got users on 4 different boxes using these credentials (some of which I don't have access to in Santa Clara) that'll all need to have their configs changed when the password is reset, and it'll probably cause a minute or two of downtime when it happens.
(In reply to comment #6) > So I'm going to need to coordinate with someone on IRC to actually change the > DB credentials. We've apparently got users on 4 different boxes using these > credentials (some of which I don't have access to in Santa Clara) that'll all > need to have their configs changed when the password is reset, and it'll > probably cause a minute or two of downtime when it happens. I think I have the access needed to change this; feel free to ping me in irc if you need.
I can't see the files anymore, but I assume these were valid credentials that could have furthered a network attack on our infrastructure?
Is any other action needed here?
This is not eligible for the bug bounty program. The site is not on the bug bounty list and the exposed data is only for these servers and cannot be used without access to the internal network.
(In reply to comment #10) > Is any other action needed here? Closing bug. No other actions mentioned. Issue addressed with password changes.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.