About the padding oracle vulnerability
A serious ASP.NET vulnerability has been publicly disclosed over the last weekend. The vulnerability, exploiting an oracle to crack the encryption used by ASP.NET, is critical to DotNetNuke websites. By exploiting the vulnerability, an attacker can read any website file, including the web.config, and impersonate any DotNetNuke user, including the host account.
More info:
ScottGu's blog entry
Cathal Connolly's blog entry
ScottGu's faqs
The vulnerability in details
If you host with us: your installation is safe
Microsoft issued a workaround to effectively close the vulnerability and stop it from being exploited. As soon as the workaround was disclosed, we have automated the deployment of the patch to protect every website that we host. In addition, we now monitor every web.config file and re-apply the patch if the patch is removed for any reason, to ensure that no website can become vulnerable to the exploit.
If you do not host with us
We have created a package to help you secure your installation. You can download it here: http://www.premiumdnn.com/Portals/0/DNNPaddingOracleProtector.1.0.0.zip
Further steps to secure your DNN installation
To improve your DNN installation security:
- Consider disabling the host account and creating another login than 'host' for your superuser account
- Using this, if someone tries to impersonate 'host', it will fail
- Same applies to administrator, consider not using 'administrator' for your administrator login
- Make sure your sql server is not publicly reachable
- If someone gets your sql connection string, they won't be able to connect to your sql server
- Configure our Session Scoped Authentication provider
If you are hosting with us, you are already setup this way, nothing to change.
About Session Scoped Authentication
DNN stores sensitive information in encrypted cookies. Information stored in the cookie include the 'username' and the 'roles' of the current user. By exploiting the padding oracle vulnerability, an attacker can impersonate any DNN user by creating a custom encrypted cookie.
The long term solution for this problem is for DNN not to store sensitive information in any cookie. We hope this gets reviewed and changed in the DNN core.
A short term solution to get protected now - requiring no core change - is making sure that any authentication cookie can only be used for the ASP.NET session it has been issued for.
The system works by assigning the username and roles in the ASP.NET session and making sure that the username in the session corresponds to the authentication cookie. If not, the authentication cookie is cleared and user is redirected to the portal home page. This makes authentication cookie forgery almost impossible to accomplish.
There are some limitations to this approach:
- "Remember me" for login will not work anymore
- Will not work for webfarms without session support
- Users will be logged out on application recycle
If there is interest, we can create a new implementation not relying on the session that would not have these limitations. But again, this is temporary and should be implemented in DNN.
Need help?
If you have questions or need assistance:
Clients
open a support ticket from the client portal
Non Clients
use our contact form or join us on Twitter @PremiumDNN