Hacker News Reader

Comment by thomas-st | Hacker News Reader

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.

View on HN

Revoke application access here: https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en

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

Since you store the Google auth_token couldn't anyone with access to the database also gain access to sessions?

We'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

It'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.

You should also notify any users who already signed up and stored their access token in the database.

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

Actually, 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.

thanks xb95, it took a minute to take effect, but issue is now fixed.

As 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)

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

I have confirmed that there is no longer any data in the database I can connect to. Thank you for taking care of this.

/xb95 rides off into the sunset.

Dur.... everybody should revoke their OAuth tokens immediately if you've used this app

How did you get that info and how would I prevent this from happening?

Don'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.

Reply on news.ycombinator.com