bring all domains into scope for security program

[chadwhitacre]

But we should first configure SPF and whatever else to avoid tons of noise.

[TheHmadQureshi]

Agreed!

[chadwhitacre]

DNS at iwantmyname

gratipay-or-bountysource.guide grtp.co gttp.co

DNS at DNSimple

aspen.io gip.rocks gittip.co gittip.com gittip.org gratipay.co gratipay.com gratipay.net gratipay.org motivate.im simplates.org

[chadwhitacre]

I made some changes to DNS here, added v=spf1 -all to most everything. I didn't touch gittip.com or gratipay.com. I want better tooling (an Inside Gratipay appendix) to at least visualize if not manage our DNS.

[chadwhitacre]

Is SPF the only thing we need to configure to properly communicate that a domain doesn't send mail? We only need DKIM and DMARC for domains that do send mail, right?

[TheHmadQureshi]

Yes.

[chadwhitacre]

configure SPF and whatever else

This should dampen most of the noise reports:

• [ ] v=spf1 -all
• [ ] v=DMARC1\; p=reject\; pct=100\; rua=mailto:security@gratipay.com\; ruf=mailto:security@gratipay.com
• [ ] clickjacking
• [ ] wildcard DNS
• [ ] limit HTTP methods

[ghost]

Since Aspen will get his own HackerOne program, we should remove the related domains from the list.

I'll take a quick look at the Gratipay-related domains so we won't miss obvious vulnerabilities before adding it to the scope.

[ghost]

Spent ~30 minutes on this. Let's discuss of the results and create the appropriate issues if there is a need to. EDIT: I did not tried to see if there are issues related to what you already listed.

New domains

• [ ] gratipay.com
  • Already in scope so I won't dig in it.
• [ ] gratipay.co, gratipay.net, gratipay.org
  • Only redirects to the https://gratipay.com.
  • \r and \n are not well-handled (giving a 500) but no CRLF injection is possible.

Old domains

• [ ] gittip.com, gittip.org
  • See gratipay.co.
• [ ] grtp.co, gttp.co
  • DigitalOcean droplet, the SSH service is exposed too.
  • Should we include the SSH service into the bounty scope? I'd say yes (we don't have anything to loose) but:
  • I guess it'll only lead to bruteforcing tries, since OpenSSH remote exploits are really uncommon. It's so critical that it would be announced everywhere by packages managers that we should patch it.
  • Reports like "Disable the cipher X and Y" and "Change the port" are more paranoia hardening than real issues. If we follow each of these recommendations, it will be a real waste of time.
• [ ] gip.rocks
  • Old Pillow version, vulnerable to several DoS exploits (no RCE). The extension check is not enough to mitigate vulnerabilities like CVE-2016-0740, since we can pass a TIFF file but advertise it as Content-Type: image/jpeg. I'd advise to at least upgrade this library to the last version.
  • Gunicorn version is displayed in the headers. I guess we can patch it like it has been done for gratipay/gratipay.com.
  • A small bad practice that can be reported, the service displays a stack trace when giving an empty post body: Internal server error, program! Traceback (most recent call last): File "/app/.heroku/python/lib/python2.7/site-packages/algorithm.py", line 288, in run new_state = function(**deps.as_kwargs) File "/app/.heroku/python/lib/python2.7/site-packages/aspen/algorithms/website.py", line 113, in get_response_for_resource return {'response': resource.respond(state)} File "/app/.heroku/python/lib/python2.7/site-packages/aspen/resources/simplate.py", line 53, in respond exec(self.pages[1], spt_context) # mutating it File "/app/www/v1.spt", line 22, in <module> image = Image.open(fp) File "/app/.heroku/python/lib/python2.7/site-packages/PIL/Image.py", line 2330, in open % (filename if filename else fp)) IOError: cannot identify image file <cStringIO.StringI object at 0x7f7924680cf0>
  • …and we can get it too by providing a malformed image.
• [ ] gittip.co
  • No DNS records.

Misc domains

• [ ] gratipay-or-bountysource.guide
  • Serves gratipay/gratipay-or-bountysource.guide with Github Pages.
  • GitHub has its own bug bounty program, so we can tell the researchers to report there instead if they find a vulnerability. It can't be related to our content since it's only static files.

[ghost]

Just saw that gittip.org have still a TXT record "ALIAS for gittip.herokuapp.com". Since this application name does not exists anymore, I think we should remove this entry too so it can't be hijacked.

[ghost]

Uh, in fact, there is even a wildcard, routing all the requests to subdomains to gittip.herokuapp.com. The behaviour of gittip.org is the right one, redirecting to gratipay.com. We need to address this.

Obvious +1 for @whit537's "I want better tooling (an Inside Gratipay appendix) to at least visualize if not manage our DNS.". I'll do it on the paper first (what we currently have / what we should have instead) and let's discuss of it.

[chadwhitacre]

I don't think we should tackle this until we reach Security 0, otherwise we just invite more traffic, and we are barely managing what we already have.