Posting Private Keys in the Code Repository Hunting Grounds
In the new-world of programmable-everything, passwords are certainly not a viable vehicle for strong access control at the automation scale. Configuration files include public ssh keys to securely configure, access and manage the infrastructure, platforms and applications remotely.
But keys are worthless if exposed improperly. Developers will sometimes inadvertently post their private keys in Git repos, available for anyone to see. Last week, a developer, using simple techniques and code totaling under 80 lines, said he gained access to 5 Amazon EC2 servers in two hours by using Github Search.
Attackers are always on the lookout for the weakest link in the chain. If a trivial search or a small script can work over a public code repository API to extract hundreds of private keys in a few minutes, why bother investing the time and effort on targeted exploits. Add this to the patterns or predictive outputs from public cloud providers and you can combine the two to turn automation on its head to do really really bad things. Hide this attack behind a DDoS (Distributed Denial of Service) and the business will crumble down to nothing – see codespaces.com.
While public ‘cloud’ services can offer the scale and depth for such attacks, this scenario is equally possible in a privately hosted API. It will take a brave enterprise CSO (Chief Security Officer) to attest to a zero-compromise environment across the entire endpoints or servers. Hence, the risk of exposing sensitive access control data and its impact to the private code repositories is identical.
Developer Awareness
The first line of defense will always be the developer who works with sensitive access data like their private keys. Clearly, Github goes at length (see quote below) to highlight the risk to the developers. Github has detailed guidelines to do just that, albeit under Advanced Git. The importance of .gitignore cannot be emphasised enough.
Danger: Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised. If you committed a password, change it! If you committed a key, generate a new one.
Secure API Design
While humans are not perfect, APIs can surely strive to be. While the secure API design guides are aimed at securing the actual API services against security attacks, the design should also consider the data it presents and not respond to sensitive data requests. Obvious search keywords like .pem and BEGIN RSA PRIVATE KEY should not pull any results from the public code repositories unless there is an exception.
SecOps generally tend to follow DevOps and they are probably worn out by compliance requirements and checklists mostly. Before those next generation application security firewalls are installed to defend against the APTs (Advanced Persistent Threats), there is a very remote possibility that a script using that private key committed in error to a code repository might compromise or wipe out the critical infrastructure of the entire business.
Feature image via Flickr Creative Commons.