The goal of this project is to accumulate the secret keys / secret materials related to various web frameworks, that are publicly available and potentially used by developers. These secrets will be utilized by the Blacklist3r tools to audit the target application and verify the usage of these pre-published keys.
We are releasing this project with.Net machine key tool to identify usage of pre-shared Machine Keys in the application for encryption and decryption of forms authentication cookie.
Auth Bypass using pre-published Machine Key
In this blog post, Sunil Yadav talks of an interesting test case with blacklisted/pre-published Machine keys in use, leading to an authentication bypass in one of our recent pentests.
While conducting a regular pentest we came across a peculiar HTTP cookie name which caught our attention.
We immediately went on to search for that particular cookie name on various code aggregator, forums to find out if it was associated with any particular framework or component of the application. We then stumbled on a GitHub repository which had that specific cookie name in the forms authentication section. Within the same file in the repository, we also found a section containing a Machine Key which again caught our attention. On further research, we found out that machine key is used for encryption and decryption of forms authentication cookie data and view-state data, and for verification of out-of-process session state identification.
We quickly wrote an encryption and decryption routine which could take machine keys and decrypt and encrypt such cookies. We first tried decrypting the auth cookie for the test user and to our surprise, the cookie was successfully decrypted using the machine key which we discovered earlier. The cookie value was decrypted using the System.Web.Security.FormsAuthentication.Decrypt method, as shown below.
Now, the next step as we all know is to gain access to the administrator account. We created an auth cookie for the admin user using the System.Web.Security.FormsAuthentication.Encrypt method as shown below and passed the cookie to the application. The application accepted the cookie and gave us access to the existing account with username ‘admin’ which had administrative privilege.
By default, ASP.NET creates a Forms Authentication Ticket with unique a username associated with it, Date and Time at which the ticket was issued and expires. So, all you need is just a unique username and a machine key to create a forms authentication token.
So what went wrong here?
It is fairly common for developers to use the portion of code, as they see fit, from third-party source code repositories and answers on forums such as Stack Overflow. In doing so, there are often cases when the secrets published in these sources are embedded into production code. Encryption routines are common for being grabbed (as crypto is very complicated) and used in the application. Often developers do not understand the consequences of using the secrets from an untrusted source. Using the secrets from an untrusted source could lead to severe issues in the application such as an authentication bypass, accessing sensitive data and files, etc.
In this blog post, we will show some examples where we have seen machine keys published on GitHub, Stack Overflow and many more places.
We will first begin with understanding the Machine Keys
What is Machine Key?
The cardinal feature that is used to specify encryption settings for application services, such as view state, forms authentication, roles, and anonymous identification play a vital role in a system. Machine Key contains a set of fields like validation key, decryption key and so on where unique keys are to be entered. The role of these keys as mentioned earlier is to manage the encryption for application services like cookies, viewstate etc. The entry for Machine Key looks something like this.
More information on Machine Key can be found here: https://msdn.microsoft.com/en-us/data/w8h3skw9(v=vs.110)
Let us understand the attributes and elements of Machine Key:
Scenarios when a pre-disclosed Machinekey may get used
In event of an error, like validation of viewstate mac failure or crypto related errors, or issues with forms authentication cookie validation etc., applications developer may perform a search of multiple sites for answers. The developer might then actually use the machine key posted in the answer on portals like Stack Overflow or from the official guide provided by the product vendor.
For an instance, if the developer is troubleshooting forms authentication issues in a web farm scenario, they might land up on the official Microsoft reference page which has a Machine Key published and they might end up using the same key to fix the issue. If the issue is resolved, the developer might not change the keys. Additionally, the reference material is unlikely to warn the developer to generate their own encryption key rather than use the example key, For example , the following reference has no warning:
Similarly there could be another scenario where the developer is troubleshooting a Viewstate MAC validation issue, and looks for possible solutions on platforms like stackoverflow , asp.net forums etc. If the top voted answers also mention such machine keys without any warning, the developer is prone to using it directly in production application without giving it much attention.
This lead us to think about how commonly developers use secret keys from publicly available sources to protect sensitive data, which lead to the foundation of project Blacklist3r. Under this project we aim to create tools to audit applications against pre-published keys for various frameworks and encryption routines.
With this blog post, we are also releasing a tool to encrypt and decrypt data using pre-published machine keys. A repository is built by accumulating the 2000+ machinekeys that are available publicly on forums, Microsoft sites, Github repositories, Stack Overflow and various other sources.
In order to generate a new cookie, update the cookie information in “DecryptedText.txt” and run the utility from the command prompt as shown below.
Download tool from Github (link to follow):
We are asking the community to contribute to the tool by adding the following:
- Increase the database of blacklisted keys for .Net
- We think the same problem exist for other frameworks too and a utility to audit those frameworks can be added to BlackList3r.