You might have received an email from me saying that your sentry instance allows user registration and access to your logs. I'm using the self-hosted version of sentry for my private projects. Even though sentry is a great tool for making better software, it has a major flaw. The default configuration allows anybody to register, joining a team and viewing your logs.

How I found your sentry instance

Since 2015 Google requires that every newly issued ssl-certificate has to be logged in a Certificate Transparency log. With sites like crt.sh you can view all certificates issued to your domain (simply enter %.example.com ). With the search query sentry.% I was able to get a list of nearly 3600 possible sentry instances. With a little script, I checked this list and reduced it to around 1200 instances online. In the next step, I reduced this list to 650 instances allowing registration. Now I used the chrome remote interface to register myself to each instance and checking if I was able to join a team. If so I saved the url of the instance and a list of all email addresses I can find on the members tab. I had found around 330 open instances. In the last step, I used mailgun to quickly send out email reports to all email addresses that I found.

How to disallow user registration

Update: With the latest Release of Sentry (8.18), after upgrading a dialog will question you to disable the registration.

You are most likely using Docker for running sentry. Because the default image has no option to disable it, we must create our own little Dockerfile that overwrites the default config:

Dockerfile

FROM sentry:8.17 COPY sentry.conf.py /etc/sentry/

Next we have to copy the default configuration (sentry.conf.py) from GitHub and add the following line;

sentry.conf.py

.... SENTRY_FEATURES['auth:register'] = False

After this the Dockerfile must be build:

At last we must stop all our existing containers and create new ones. Remember to change the image name from sentry to mycompany/sentry

docker run -d --name my-sentry -e SENTRY_SECRET_KEY='<secret-key>' --link sentry-redis:redis --link sentry-postgres:postgres mycompany/sentry docker run -d --name sentry-cron -e SENTRY_SECRET_KEY='<secret-key>' --link sentry-postgres:postgres --link sentry-redis:redis mycompany/sentry run cron docker run -d --name sentry-worker-1 -e SENTRY_SECRET_KEY='<secret-key>' --link sentry-postgres:postgres --link sentry-redis:redis mycompany/sentry run worker

This image is based on the latest build of sentry. If you are using a older build, you have to upgrade your database:

docker run -it --rm -e SENTRY_SECRET_KEY='<secret-key>' --link sentry-postgres:postgres --link sentry-redis:redis sentry upgrade

I've you want to download my files, you can do it on github

As an alternative you can simply add the following argument to your docker command.

-v ./sentry.conf.py:/etc/sentry/sentry.conf.py

Or with docker-compose:

volumes: - ./sentry.conf.py:/etc/sentry/sentry.conf.py

If you are using sentry without Docker you simply must add the following line to /etc/sentry/sentry.conf.py and restart sentry.

.... SENTRY_FEATURES['auth:register'] = False

Conclusion

Security by obscurity doesn't work. Please don't think, only because you haven't published an url an internal system people can't find them. You should use crt.sh to scan your domains. On the side of sentry it is not the best thing to make it the default that anybody can access the logs. One guy I've mailed had opened an issue on github

Bitcoin: 1LdhMzRWisULpfUzfC5RgQbetDGv5HwPRk

I've opened a pull-request on the docker-sentry repository. The commit disable registration when sentry is deployed with docker.

Today I’ve done a rescan with a slightly changed query to target more instances. I also disabled the verification of certificates to also include expires certificates. This time I didn’t only send emails to these instances where I’m able to join a team, because this might can be a feature security risk, if someone accidently allows joining a team. A potential attacker can also use the emails of members to do a social engineering attack.