Research, demonstrations, and popcorn

How to get hacked with source code mismanagement

I have spent a great deal of time researching the best way to avoid security exposure via source control.  This has become a hot-button issue right now due to the Deloitte hack.  As it turns out, one of their developers checked in a file to GitHub that actually has VPN credentials in it.  Looking back at the change history… these credentials were checked in back on May 4th.  I would like to say this is a rare occurrence, but that would be a lie.

Developers by their nature are lazy.  This isn’t meant as an insult.  Anything that I can automate to streamline work is a good thing.  There is an old proverb that says “necessity is the mother of invention.”  I disagree… I think laziness is the mother of invention.

When it comes to source code management there are a lot of things you have to keep in mind

  1.  Do not check in connection strings that contain credentials or hostnames.  Checking in a web.config, transform, etc. with connection strings is fine, but make sure you obfuscate the details and remove anything that could expose you.  Before checking-in code, replace the valid connection string with dummy information.  You need to do this EVERY time you check the code in.  If you miss even one, it will be retained in the change set (which brings us to number 2).
  2. Don’t just remove credentials from a file already checked in to source control.  Once something is in source control, it becomes much more cumbersome to secure.  You can remove the credentials and check the file back in, but guess what… the credentials are still retained in the previous change sets, staged builds, etc.  Make sure you purge the data from all previous change sets, builds, work items, etc.  Once you are done, you still need to change the credentials.  The chances of no-one having seen the credentials could be low, but that doesn’t mean zero chance.  Change the credentials to insure the old information possibly still in source control is no longer valid.
  3. Sanitize other elements in the project, not just application config files.  There are many places people can save credentials.  The application settings file is just one place.  You also need to check Jenkins files, batch scripts, shell scripts, PHP scripts, python scripts, PowerShell scripts, test projects, and readme files.  Many developers create test harnesses for processes that reach out to external data systems, cloud services, etc.  These generally contain authentication details that need to be sanitized before check-in the source control.  Never assume everything sensitive is in the application configuration file.
  4. CHECK THE PUBLISH PROFILES.  Publish profiles in Visual Studio often contain credentials for the web servers local publishing account used to perform web deployments.  Remove this information before checking a project in.  This will generally give someone access to much more than just the data sources for the application being deployed… it would give them access to everything hosted on the server, including any credentials in configuration files for all other applications hosted on the server.  These accounts are most often localized windows accounts on the actual server.  This means you can’t just disable the account from AD.  You have to disable the account locally on each server if it is compromised.



Kalypto • September 26, 2017

Previous Post

Next Post