Nowadays, we all relentlessly use search engines and developers extensively use version and source code control systems to keep track of their source code. Services such as Google or GitHub are great to search and retrieve information they gathered and stored. But when it comes to public indexing services, one big problem raises up: your whole repository, your code and your configuration files are by default also uploaded – in sight to everyone. Therefore, sensitive data such as license keys, passwords or cryptographic key material becomes available with simple web searches.

Different sensitive information was leaked due to improper use of such version controls or improper handling of sensitive configuration files in the past. A recent story published in October 2014 by “Krebs on Security” demonstrates that very well.

So while I was recently reading a PowerShell blog post on “Hey Scripting Guy” about the .publishsettings file for Microsoft Azure access, I immediately thought of a nice GitHub search to find all these files. As with other sensitive files (e.g. private key files), people doesn’t care much about the confidentially of such files.

This .publishsettings file includes a certificate and sometimes also clear text FTP credentials for accessing Microsoft Azure repositories. Within a Microsoft Azure article, Microsoft highlighted the importance of removing this file:

We recommend that you delete the publishing profile that you downloaded using Get-AzurePublishSettingsFile after you import those settings.
Because the management certificate includes security credentials, it should not be accessed by unauthorized users.

The article “Download and Import Publish Settings and Subscription Information for Azure” describes the file structure:

<?xml version="1.0" encoding="utf-8"?>
<PublishData>
 <PublishProfile
   PublishMethod="AzureServiceManagementAPI"
   Url="https://management.core.windows.net/"
   ManagementCertificate="<CERTIFICATE>"
   <Subscription
    Id="<ID>"
    Name="<SUBSCRIPTION NAME" />
 </PublishProfile>
</PublishData>

Searching for this configuration file within Google or GitHub returns multiple entries:

https://www.google.ch/search?q=ext:publishsettings

Google search for the site GitHub and the file .publishsettings:

https://www.google.ch/search?q=ext:publishsettings+site:github.com

Google search for the site GitHub and the file .publishsettings:

https://www.google.ch/search?q=ext:publishsettings+site:code.google.com

Other interesting GitHub searches…

Private keys
Search for private keys within GitHub:

https://github.com/search?q="RSA+PRIVATE+KEY----"&type=Code&ref=searchresults

PHP wrapper
Search for PHP wrapper within GitHub:

https://github.com/search?l=php&q=ssh2_auth_password&type=Code

With this search for PHP wrappers we would find something like:

<!--?php
$user = "doXXXon";
$password = "pfXXXXOS";
$connection = ssh2_connect([CUTBYCOMPASS], 22);

ASP.NET machine keys
Search for machine keys within ASP.NET application configuration files.

Structure:

<!--?xml version="1.0" encoding="utf-8"?-->
<configuration>
 <system.web>
 <machineKey decryptionKey="Decryption key goes here,IsolateApps" 
             validationKey="Validation key goes here,IsolateApps" />
 </system.web>
</configuration>

Search:

https://github.com/search?p=3&q="machineKey+decryptionKey="&ref=searchresults&type=Code

Conclusion:
Never include your configuration files and other sensitive information within a public repository like GitHub and keep in mind that any public information will eventually get indexed by search engines. As a developer, refrain from pushing unknown files, as they might have unexpected sensitive content and as system administrator, keep an eye on the directory and file permissions of your web servers to not accidentally expose sensitive files. Exhaustive lists of other Google searches (also called “Google Dorks) can be found in this infosec institute post or in the dedicated part for dorks on exploit-db.com.

Feel free to comment below to share your preferred other search queries!

Thanks to Philipp Promeuschel, Ivan Bütler and Alexandre Herzog for some additional queries.

References