650656 - some files with embedded credentials are exposed on internet

Status: VERIFIED FIXED

(Webtools Graveyard :: Graph Server, defect)

Description

[gubretnuh]

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

Comment 1

[Reed Loden [:reed]]

I can't move this to IT without dropping the security group, so just assigning it to server-ops@ and making a blocker.

Comment 2

[Reed Loden [:reed]]

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.

Comment 3

[Dave Miller [:justdave]]

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.

Comment 4

[Dave Miller [:justdave]]

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.

Comment 5

[Robert Helmer [:rhelmer]]

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.

Comment 6

[Dave Miller [:justdave]]

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.

Comment 7

[Robert Helmer [:rhelmer]]

(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.

Comment 8

[Daniel Veditz [:dveditz]]

I can't see the files anymore, but I assume these were valid credentials that could have furthered a network attack on our infrastructure?

Comment 9

[Daniel Veditz [:dveditz]]

Attachment: Web Bounty non-qual

Comment 10

[Michael Coates [:mcoates] (acct no longer active)]

Is any other action needed here?

Comment 11

[Michael Coates [:mcoates] (acct no longer active)]

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.

Comment 13

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to comment #10)
> Is any other action needed here?

Closing bug. No other actions mentioned. Issue addressed with password changes.