In the recent past days, Google published an article that is probably a milestone in the history of the information security. Google announced the first SHA-1 collision.
But, what does that announcement represent?
Let’s first understand what a collision is. According to Bruce Schneier a hash function must be collision free, “This means that it is impossible to find two messages that hash to the same hash value”. If a collision can be detected faster than brute force, it could be easy to vulnerate a hashed value.
For this reason, any piece of data (file, certification, password, etc) that uses this encryption method is now vulnerable and is at risk.
Umbraco, the open source ASP.Net CMS, uses HMAC-SHA1 as its cryptographic default method to store passwords in the database. HMAC-SHA1 is no more than the combination of two different hashing methods: SHA1 and HMAC, as the HMAC reference documentation states.
The problem with this default method came when Google published the first SHA1 collision. This announcement raises all alerts for those sites that uses Umbraco, specifically for those that uses the default encryption method to store user passwords. For more input, visit the Umbraco Forum case.
How can I identify if my site is using HMAC-SHA1 encryption method?
According to the Umbraco source code (method GetHashAlgorithm, see image below), if the configuration value useLegacyEncoding is “true”, then it will use HMAC-SHA1 encryption by default.
To determine if your site is using this configuration:
- Go to the Web.config file.
- Find the <membership> → <providers> → <add name=”UsersMembershipProvider”> section.
- Check attribute useLegacyEncoding
- If its value is “true”: Your site is using default encryption method HMAC-SHA1.
My recommended solution is to change the encryption method from the Web.config file and use a stronger secure method. For instance HMAC-SHA256. This change is straightforward, the problem is that current user passwords are stored with the HMAC-SHA1 method. So if you change the encryption method, then a user tries to log in, Umbraco will decrypt its stored password with the HMAC-SHA256 method, generating a mismatch with the entered password and raising a login error.
For this reason, to get a full fix, follow these steps (using a similar solution Paul Sean purpose for resetting the Umbraco admin account password):
Step by Step
- Identify an Umbraco user, for instance, admin.
- Write down a SQL script to replace the hashed password in the database by a simple plain text.
- Run the script in your Umbraco database. This has now made sure that admin account is enabled and set the password to “default”.
- Due to all passwords are stored as hash values, you won’t be able to log in until you edit the config file temporarily. So please go to the Web.config file, and find “UsersMembershipProvider”.
- Change the passwordFormat from “Hashed” to “Clear” and save the Web.config file.
- Go to the Umbraco login page and log in with the username of admin (or whatever user you changed its password) and the password of default.
- Once you logged in, go again to the Web.config file and set the new hashing method to HMAC-SHA256. To accomplish this change you must:
- Change the useLegacyEncoding value to “false”.
- Set the passwordFormat value to “Hashed” again.
- Add the attribute hashAlgorithmType=”HMACSHA256″.
- Go back to the Umbraco page and change the user password to a new and safe one and click save.
- Check the umbracoUser table again to confirm the new hash for your admin user.
- All other user passwords must be changed in order to set them a new hash using the HMAC-SHA256 algorithm and so let them login without errors.
What if I can’t change the default encryption method?
It’s possible that some restrictions don’t let you accomplish the previously proposed solution. Some possible restrictions could be:
- You don’t have access to the Umbraco database.
- You don’t have access to the Web.config file.
- There are internal policies that don’t allow to make any of the proposed changes.
A simple workaround to avoid an attack to the CMS is to whitelist the access to /umbraco folder. Beyond a workaround, it’s highly recommended to implement this whitelist in order to restrict access to only valid users.
This workaround could be implemented with a rewrite rule on the server side.