Thursday, February 17, 2011

Cognitive Dissonance, Demonization and Anti-tribalism in Software Development

Here are the notes and links to the media for the "Cognitive Dissonance, Demonization and Anti-tribalism in Software Development" talk I gave on February 15th, 2011 at Eden Development. At Eden, we host Tuesday Talks on both technical and non-technical aspects of development and other interesting stuff. Please follow @edentalks for more information.

Part I: Viewing of PBS Frontline's "A Class Divided"

This is a classic documentary about an inspired teacher in a small town in Iowa teaching her students a lesson on discrimination. It's well worth watching independent of my talk because of it's message and quality, but it is an important way to "prime the pump" for part II.

You can view the program via the following URL. Note: if you do not want to watch the entire program, feel free to stop watching at the point she repeats the experiment with the adults at the prison (you will know what this means when you see it).

http://www.pbs.org/wgbh/pages/frontline/shows/divided/

Part II: Cognitive Dissonance, Demonization and Anti-tribalism in Software Development

The slides used in my talk are in this PDF file.

The video to the talk (if the slides are hard to see, please download them above to follow along). Also, it is recommended that you go to Vimeo to see the HD version of the talk:

Cognitive Dissonance, Demonization and Anti-tribalism in Software Development from Todd Anderson on Vimeo.


If you wish to comment, please comment on this blog post.

Further Reference

Cognitive Dissonance

Stanford Prison Experiment

Confirmation Bias

Richard Feynman

Carl Sagan

Friday, February 11, 2011

Potential Heroku App Data Exploit: Once a Collaborator, Always a Data Collaborator

TL;DR

Heroku apps have an exploit that allows anybody who has ever had access to a heroku app, or has had access to a machine running a heroku app, to view and manipulate live application data from any computer on the internet.

The Issue:

Heroku has an API that allows users to run SQL commands against their live Heroku apps. This service ( https://sql-console.heroku.com/ ) takes in a postgres connection string (DSN) and the SQL query command. Though this service, you can run any command you wish as if you had direct SQL access to the database. It is what the Heroku DB Console add-on uses to execute queries.

The problem with this service is that the only security needed to use the service is the postgres connection string. This connection string can be obtained by any collaborator (or by anybody with access to a collaborator's machine) by running the ENV['DATABASE_URL'] command on the Heroku console:

$ heroku console
Ruby console for xxx.heroku.com
>> ENV['DATABASE_URL']
=> "[EXPOSED DB URL HERE]"

With this URL, anybody (including collaborators, former collaborators, or anybody else) has access to view and manipulate data on your live application via the https://sql-console.heroku.com/. The user does not need to have a Heroku account.

When a collaborator has had their access revoked from a Heroku app their access to the database is not automatically revoked.

The Implications:

The implication of this exploit is that anybody who has ever been a collaborator (even if revoked) or has ever had access to a collaborator's machine, can view and manipulate data on any heroku application. The person using this exploit does not even need to have a heroku account and they can use this exploit from any computer on the internet.

Protective Actions:

Anytime you remove a collaborator, or suspect a collaborator's computer has been compromised, you need to contact Heroku support to get the database keys changes immediately. You might also want to consider changing keys on a regular bases to proactively protect yourself from this exploit.

Also, you should be careful to not leave a machine with access to a Heroku application unattended.

Heroku's Response:

Heroku have been fully informed of this issue and they have acknowledged this exploit is possible. As quoted from their support engineer:

"Thanks for reaching out to use with your concerns for tighter credentials control. We agree that what we currently have is not as good as we would like it to be. As we start building out new features allowing for finer-grained access control to your apps we'll keep these use cases in mind. Currently the only way for someone to gain access to your DB credentials (beyond leaking them) is by adding someone as a collaborator. As such you should only be adding trusted developers and/or contractors as collaborators, much the same as you would grant access to your codebase. In the meantime if you need to have your database credentials updated simply open up a support request and our support team will work with you to roll credentials."

"If your DB credentials are compromised for any reason or you need to revoke them from a former collaborator it is best to have us update the credentials for you. I want to be clear that we do not give out access to your app or any app-sensitive data to any other users unless the application owner authorizes it."

"The only way for someone to gain access to the database credentials is by adding them as a collaborator of if a collaborator (including the owner) leaks the credentials. We offer a means to update credentials should you ever need to. As such this is more of a security best-practices issue than a true security vulnerability.

We are planning on making it easier to manage your credentials but don't have an ETA on these changes."

I have also let them know that I intend to inform the community of this possible exploit via this blog post, of which they have had an advance copy.

What Heroku Could Do:

* Heroku could inform users that DB keys should be re-generated when a collaborator is removed.
* Require credentials to use the https://sql-console.heroku.com/ service.
* Heroku can automate this when there is a change in collaborators, though this would involved a restart of the application.

Heroku is working on more fine grain access. So we'll have to wait and see if this solves this issue.

The Code:

Below is example code to test this out for yourself:

As the code states, you first need to get the DATABSE_URL key from heroku console, then plug the result into the script. If the code does not show up correctly on a syndicated post, then please visit the original post.


One more thing...

This has been covered elsewhere, but it's important to note that your Heroku account username and password are exposed in plain text in your ~/.heroku/credentials file. These credentials can also be used to possibly exploit your application or spoof a collaborator's actions.

From Heroku:
"... we do not store passwords in the credentials file in more recent versions of the heroku gem. There are some older version where this was done but it has since been corrected and we now use an API key instead."