4 ms·
psql -h ec2-107-22-171-68.compute-1.amazonaws.com -p 5732 -U u1npugarlguimh -d ddbs2kvmqeieon Since DEBUG=True, finding the password is left as a trivial exerc
by thomas-st 14y ago
psql -h ec2-107-22-171-68.compute-1.amazonaws.com -p 5732 -U u1npugarlguimh -d ddbs2kvmqeieon
Since DEBUG=True, finding the password is left as a trivial exercise for the reader. I wouldn't trust the service until they fix the issue.
- thomas-st 14y agoRevoke application access here: https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en
- philfreo 14y agoDur.... everybody should revoke their OAuth tokens immediately if you've used this app
- deleted 14y ago[deleted]
- tonyx 14y agoHi thomas-st, thanks a lot for bring this up. we just fixed the issue and changed credentials on the server as well. All transmission also happen securely through HTTPS and contents are only stored on Google's server, not ours.
- anemitz 14y agoSince you store the Google auth_token couldn't anyone with access to the database also gain access to sessions?
- tonyx 14y agoWe've turned off debug mode and reset our database credentials. We are looking through the database server access log right now and going to make sure that 1) all connections were made from our own servers and 2) users in the timeframe affected will be notified of the issue and guided to resolve it as soon as possible
- anemitz 14y agoIt's also good practice to disallow all public traffic to your db instances on your firewall. AWS's security groups make this really easy to manage.
- thomas-st 14y agoYou should also notify any users who already signed up and stored their access token in the database.
- jordanlee 14y agoHi Thomas, just following up on this. After fixing the security issue, we revoked access for all of the potentially affected user accounts and emailed users individually to apprise them of the situation and the steps we took to address it.
- xb95 14y agoActually, your Postgres credentials still work. I am currently able to connect to the database and I can still view people in the role I grabbed. I'm not sure how to validate that this is still timely, though... oh, I created a table: public | hacker_news_1342216769 | table | ruwdncbzdkulsh With the current timestamp. So, if you changed anything, it hasn't actually taken effect in the part that matters -- the exposed database.
- tonyx 14y agothanks xb95, it took a minute to take effect, but issue is now fixed.
- xb95 14y agoAs of right now, 3:16 PM PDT, I can still connect to (one of) your Postgres databases. # psql --host=ec2-23-21-85-231.compute-1.amazonaws.com --port=5432 -U ruwdncbzdkulsh dc6jnvg2ce8qim Password for user ruwdncbzdkulsh: psql (9.1.4) SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type "help" for help. dc6jnvg2ce8qim=> SELECT NOW(); now ------------------------------- 2012-07-13 22:17:51.821052+00 (1 row)
- jordanlee 14y agoHi Xb95, we first removed the heroku add-on and thought that it would automatically destroy the database, but that turned out not to be the case. So what we did to fix the issue was purge all of the tables from the database. Now the credentials still work, but they reach an empty database without any content. We're working on revoking the access token for all affected users right now. Thanks for helping us through this.
- xb95 14y agoI have confirmed that there is no longer any data in the database I can connect to. Thank you for taking care of this.
- 147 14y agoHow did you get that info and how would I prevent this from happening?
- philfreo 14y agoDon't deploy Django apps with DEBUG=True in production. Or more generally, don't let your production environment spit our error messages with debug information that reveals internals of your app.