Issue Summary

A third-party dependency, Moment.js, published security updates to their library. 

Fixes for the Issue 

DNN Platform 9.11.0 upgrades this dependency to the latest version resolving all known security issues with this dependency at the time of release. 

Affected Versions 

9.0.0 - 9.10.2

Issue Summary

DNN Platform utilizes a third-party WYSIWYG editor called CKEditor, this editor published numerous high-priority security issues. 

Fixes for the issue 

DNN Platform 9.11.0 has updated to CKE Version 4.18.0 and removed certain plugins to address various security bulletins. If you use other plugins than the provided ones, we suggest you check if they have updates available.

Affected Versions. 

8.0.0 - 9.10.2

Issue Summary

An issue existed where an authenticated user could craft a data payload allowing arbitrary execution of JavaScript code on a page of an installation in certain configurations. 

Fixes for the Issue 

DNN Platform 9.11.0 introduced changes to the affected areas ensuring that all data display, as well as storage, is protected. 

Affected Versions 

7.0.0 - 9.10.2

Issue Summary

A malicious user could craft a request that would execute a XSS payload within the Digital Assets Manager. 

Fix for the Issue

The Digital Assets Manager module was removed from all installations in 9.11.0. Users that removed the Digital Asset Manager from older installations are protected from this issue. 

Affected versions 

7.0.0 - 9.10.2

Issue Summary 

jQuery and jQuery UI are utilized by DNN Platform, and both published multiple security bulletins. 

Fixes for the Issue 

JQuery and jQuery UI were updated to the latest versions in 9.11.0

Affected Versions

8.0.0 - 9.10.2

Issue Summary

DNN Platform distributed a third-party extension for an editor that allowed a possible redirect to an untrusted destination. 

Fixes for the issue. 

The affected component was removed from DNN platform in version 9.11.0

Affected Versions

8.0.0 - 9.10.2

Issue Summary

DNN Platform utilizes KnockoutJS for portions of administrative functionality and new security vulnerabilities were noted by the publisher of the library. 

Fixes for the Issue 

DNN Platform 9.11.0 was updated to the latest version of knockout 

Affected Versions 

9.0.0 - 9.10.2

Issue Summary 

A DNN administrator functionally was erroneously allowing a stored credential to be viewable by other administrators. 

Fixes for issue 

DNN Platform 9.11.0 updated the interfaces to ensure no prior stored credentials could be viewed. 

Affected Versions 

9.0.0 - 9.10.2

Issue Summary

DNN Platform uses Newtonsoft JSON for api serialization and the makers of this library published a high-priority security bulletin. 

Fixes for the Issue

DNN Platform 9.11.0 was updated to the latest version. 

Affected Versions 

6.0.0 - 9.10.2

Issue Summary

DNN Platform distributed and used SharpZipLib to provide File Compression functionality.  The makers of this library published a high-priority security bulletin. 

Fixes for the Issue

DNN Platform 9.11.0 was updated to the latest version. 

Affected Versions 

6.0.0 - 9.10.2

Issue Summary

DNN Platform uses log4net for application logging  and the makers of this library published a high priority security bulletin. 

Fixes for the Issue

DNN Platform 9.11.0 was updated to the latest version. 

Affected Versions 

6.0.0 - 9.10.2

Issue Summary

It was possible for a SuperUser to craft a request to obtain the contents of an arbitrary file in any directory of the DNN Platform installation. 

Fixes for the issue

DNN Platform version 9.11.0 addressed this issue

Affected Versions

9.0.0 - 9.10.2

Issue Summary

It was possible with a customized authentication provider to circumvent the logic traditionally completed upon application logging following a specific sequence of access. 

Fixes for the issue 

This issue was addressed in 9.11.0 by adjusting process flows. 

Affected Versions

7.4.2 - 9.10.2

Background

DNN Platform includes the Telerik.Web.UI.dll as part of the default installation, including current version..

Issue Summary

A malicious user may be able to replace or update files with specific file extensions with content of their selection, without being authenticated to the website.

Fix(es) for This Issue

Removal of Telerik is the only safe method, however, it is an optional step. All installations should follow the instructions found on DNN Docs

Affected Versions

DNN Platform Versions 5.2.0 through 9.10.1

Issue Summary

In certain configurations of DNN Platform it is possible for an anonymous user to request, and receive contents of files within the application.

Fixes for the Issue

Upgrading to DNN Platform 9.10.1 is the only solution for the issue, for those in impacted configuration. For questions regarding this issue you may contact security@dnnsoftware.com.

Affected Versions

DNN Platform version 6.1.0 through 9.10.0

The DNN Community would like to thank Karl Barrett - Lateral Security for reporting this issue

DNN Platform includes and uses the jQuery library as part of the base installation.

Issue Summary

The maintainers of jQuery published version 3.5.0 with a security fixincluded regarding HTML manipulation.

Fix(es) for this Issue

DNN Platform 9.6.0 was released with 3.5.0 included, and 9.6.1 was released with jQuery 3.5.1 after they released an urgent update. It is recommended to upgrade to the newest DNN Version to take advantage of these fixes. It is not possible to update jQuery alone without an DNN version upgrade.

Affected Versions

DNN Platform version 5.0.0 through 9.6.0

Background

DNN Platform includes the Telerik.Web.UI.dll as part of the default installation.

Issue Summary

A malicious user may be able to replace or update files with specific file extensions with content of their selection, without being authenticated to the website.

Fix(es) for This Issue

To remediate this issue an upgrade to DNN Platform Version (9.6.1 or later) is required.

Affected Versions

DNN Platform Versions 5.0.0 through 9.6.0

Acknowledgements

The DNN Community thanks the following for identifying the issue and/or working with us to help protect Users

• Robbert Bosker of DotControl Digital Creatives

Related CVE:

CVE-2019-19790

Background

DNN Platform contains multiple JavaScript libraries that provide functionality. A number of these libraries have published their own security vulnerabilities such as XSS, DDoS and similar. .

Issue Summary

A number of older JavaScript libraries have been updated, closing multiple individual security notices.

Fixes for the Issue

Due to the nature of the elements included, and their usage with DNN Platform an upgrade to DNN Platform 9.5.0 or later is the only resolution for this issue..

Affected Versions

DNN Platform version 6.0.0 through 9.4.4

Background

Issue Summary

For websites with user registration enabled, it is possible for a user to craft a registration that would inject malicious content to their profile that could expose information using an XSS style exploit.

Mitigating Factors

Websites not allowing registration will be unaffected by this issue.

Fix(es) for This Issue

Users must upgrade DNN Platform to version 9.5.0 or later to be protected from this issue.

Affected Versions

DNN Platform version 7.0.0 through 9.4.4

DNN Platform provides a number of methods to upload files, including zip files, allowing them to be extracted post upload.

Issue Summary

A malicious user may upload a file with a specific configuration and tell the DNN Platform to extract the file. This process could overwrite files that the user was not granted permissions to, and would be done without the notice of the administrator.

Fix(es) for This Issue

The only proper fix for this issue is to upgrade to DNN Platform 9.6.0 or later.

Affected Versions

DNN Platform version 5.0.0 through 9.5.0. (It is believed this may affect 3.x and 4.x installations as well, but has not been verified)

DNN has an internal user-to-user messaging system that allows users to communicate, this is not used by all installations. When sending a message it is possible to upload/send a file.

Issue Summary

A malicious user may utilize a process to include in a message a file that they might not have had the permission to view/upload, and with the methods that the DNN File system works they may be able to gain access to this file.

Mitigating Factors

Installations configured using the ‘Secure’ folder type would not have the file contents disclosed. This is the recommended manner to guarantee file security for confidential documents as it is the only method that provides a secure file check at download.

Fix(es) for This Issue

Upgrading to DNN Platform version 9.6.0 or later is required to mitigate this issue.

Acknowledgements

The DNN Community would like to thank the following for their assistance with this issue.

• Connor Neff

Affected Versions

DNN Platform version 7.0.0 through 9.5.0.

Background

DNN provides a number of methods that allow users to manipulate the file system as part of the content management system functionality that is provided. There is a reasonable expectation that only those explicitly granted permissions can add/edit files.

Issue Summary

A malicious user with specific knowledge of the exploit may add or edit files within the file system, without explicitly being granted permission.

Mitigating Factors

DNN provides file-type restrictions which limit the ability for this to vulnerability to allow file uploads. It is recommended that ALL users validate their allowed file types setting to ensure dynamic file types are excluded.

Fix(es) for This Issue

To remediate this issue an upgrade to DNN Platform Version (9.4.1 or later) is required.

At this point in time, there is no known patch for prior versions.

Affected Versions

DNN Platform Versions 7.0.0 through 9.3.2

Thanks

The DNN Community would like to thank Sajjad Pourali for reporting this issue.

Background

DNN provides a user account mechanism that can be used to register users in the system. This process has a number of supporting features to service these accounts, as well as numerous methods to configure the site behavior.

Issue Summary

In sites with certain configurations, a malicious user might be able to discover certain information regarding the existence of user accounts within the installation.

Mitigating Factors

This issue is only apparent with specific configurations of DNN Installations and the information obtained would already be known by a malicious user as part of the act of discovery.

Fix(es) for This Issue

To remediate this issue and upgrade to DNN Platform Version (9.4.1 or later) is required.

At this point in time, there is no known patch for prior versions..

Affected Versions

DNN Platform Versions 6.0.0 through 9.3.2

Acknowledgements

The DNN Community thanks the following for identifying the issue and/or working with us to help protect Users

• Robbert Bosker of DotControl Digital Creatives

Background

A cross-site scripting issue is an issue whereby a malicious user can execute client scripting on a remote server without having the proper access or permission to do so. This could allow a malicious user to execute Javascript or another client-side script on the impacted user's computer.

Issue Summary

An unauthenticated user in specific configurations could construct a payload that would result in a stored scrip being executed at a later time by a user with elevated permissions

Mitigating Factors

The issue is only visible with very specific configurations within the DNN Platform, and the exploit would require specific knowledge to exploit, and the resulting impact is minimal.

Fixes for the Issue

To remediate this issue upgrading to DNN Platform version 9.4.1 or later is recommended.

Affected Versions

DNN Platform version 7.0.0 through 9.3.2

Background

DNN uses a provider model to allow various extension points to be leveraged by users of the platform. As new features are implemented, older providers may remain, even if not used.

Issue Summary

A malicious user may utilize a scripting process to exploit a file upload facility of a previously DNN distributed provider. The uploaded file could be malicious in nature.

Mitigating Factors

This issue will only impact DNN based websites that were previously upgraded from version 7.x or earlier using older providers that are no longer supported. Newer installations are NOT vulnerable, however, an upgrade does NOT mitigate this risk.

Fix(es) for This Issue

Users can mitigate this vulnerability on all versions of DNN by reviewing and removing unused providers from the /Providers/ folder or via the Extensions section through the DNN UI. It is imperative that when removing a provider that backups are made and that all files are removed.

NOTE: An upgrade will NOT automatically resolve this issue

Acknowledgments

The DNN community would like to thank the following for their assistance with this issue.

• Jessie Haggerty of DNN4Less

Issue Summary

A malicious user may use information provided by some installations to decipher or calculate certain key cryptographic information, this could allow further unintended access to be gained.

Mitigating Factors

A DNN installation must be configured in a specific manner and the malicious user would need specific knowledge to leverage the issue.

Fix(es) for Issue

To fix problem you can upgrade to the latest versions of the Products – DNN Platform Version 9.2.2 or EVOQ 9.2.2 at the time of writing. Affected Version(s):

• All versions from 5.0.0 up to 9.2.1

Acknowledgements

DNN thanks the following for identifying the issue and/or working with us to help protect Users

• Jon Park and Jon Seigel of Digital Boundary Group

Issue Summary

Information on requests, exceptions, or other actions are logged within the DNN system.  A malicious user could take specific action(s) to allow malicious content to be displayed.

Mitigating Factors

The malicious user must know how to utilize the exploit and must entice a limited subset of users into viewing the information.

Fix(es) for Issue

To fix this problem you can upgrade to the latest versions of the Products – DNN Platform Version 9.2.2 or EVOQ 9.2.2 at the time of writing.

Affected Version(s):

• All versions from 5.0.0 up to 9.2.1

• Saurabh B.

DCNN sites support user authentication through active directory using a special module.

• All versions using the Active Directory module with any DNN version prior to 9.2.0

• Sajjad Pourali (Cyber Security Analyst)

• All DNN version prior to 9.2.0

• Narendra Bhati from Suma Soft Pvt. Ltd. Pune, India

• Narendra Bhati from Suma Soft Pvt. Ltd. Pune, India

• Narendra Bhati from Suma Soft Pvt. Ltd. Pune, India

• Narendra Bhati from Suma Soft Pvt. Ltd. Pune, India

• Lance Cleghorn (Defense Media Activity Public Web)

Background

DNN added support for MVC that comes in ASP.NET in 2016. This support comes through an assembly coming from Microsoft.

Issue Summary

Microsoft released an MVC vulnerability fix (KB2990942) a while ago. As DNN is using the MVC assembly from Microsoft, there is a need to update this assembly in DNN sites.

Mitigating factors

The vulnerability could allow security feature bypass if an attacker convinces a user to click a specially crafted link or to visit a webpage that contains specially crafted content designed to exploit the vulnerability.

By default, DNN distributions don't have any code utilizing the code that causes this vulnerability. But if you have a third party MVC module(s) you might be vulnerable. Therefore, for safety reasons you need to upgrade this assembly to 5.1.20821.0. You need to replace the assembly you have with this one and add bindings in the “web.config” file for this new assembly if you are not upgrading to a newer version.

Fix(s) for issue

To fix this problem, you can upgrade to the latest versions of the Products - DNN Platform 9.1.1 or EVOQ 9.1.1 at the time of writing. Or you can replace the assembly in your site with the one that comes with DNN 9.1.0 and add the necessary binding in the “web.config” file. Our recommendation is to always follow DNN’s upgrade path.

Affected Version(s):

• All versions from 8.0.0 up to 9.0.2

Background

DNN installations contain some old format SWF (Shockwave Flash) files included for demo purposes.

Issue Summary

A malicious user can initiate XSS attacks on sites which contain old SWF files.

Mitigating factors

A malicious user must know what kind of SWF files exist in a site and where they are in the site. Then they must craft a specially formatted link to target this vulnerability.

Fix(s) for issue

To fix this problem, you are recommended to delete all SWF files (*.swf) from your site. The upgrade process does not delete these files and they need to be deleted manually. Newly installed sites as of 9.1.0 will not have any SWF file included in them.

Affected Version(s):

• All versions from 3.0.0 up to 9.0.2

Acknowledgments

DNN thanks the following for identifying this issue and/or working with us to help protect users:

• Daniel Kalinowski

Background

DNN uses web cookies to identify users.

Issue Summary

A malicious user can decode one of such cookies and identify who that user is, and possibly impersonate other users and even upload malicious code to the server.

Mitigating factors

A malicious user must know the specifics of this cookie and how to decode it. Then they must submit crafted cookie to target this vulnerability. Only one specific cookie was found to be vulnerable. This cookie is rarely used.

Fix(s) for issue

To fix this problem, you can upgrade to the latest versions of the Products - DNN Platform 9.1.1 or EVOQ 9.1.1 at the time of writing.

Affected Version(s):

• All versions from 5.0.0 up to 9.1.0

Acknowledgments:

DNN thanks the following for identifying this issue and/or working with us to help protect users:

• Alvaro Muñoz (@pwntester) and Oleksandr Mirosh from Hewlett-Packard Enterprise Security

Background

One of the new features of HTML5 is cross-document messaging. The feature allows scripts to post messages to other windows.

Issue Summary

A malicious user can create a specific script to communicate with the victim window in a way that can lead to spoofing, data theft, relay and other attacks.

Mitigating factors

A malicious user needs to know the endpoints that may be vulnerable to this and they need to craft special requests to utilize this vulnerability.

Fix(s) for issue

To fix this problem, you can upgrade to the latest versions of the Products - DNN Platform 9.1.1 or EVOQ 9.1.1 at the time of writing.

Affected Version(s):

• All versions from 8.0.0 up to 9.1.0

Background

DNN sites have the ability to redirect users to different pages per system rules. An example is the log-in experience, where a user can be sent to a specific landing page after login.

Issue Summary

Using the DNN’s redirect features, a malicious link can send users to outside of the current site (phishing).

Mitigating factors

A malicious user must know to craft such malicious links. The users must be lured to click on such links. This vulnerability is available only through socially engineered tactics and not possible to accomplish without users clicking on the phishing link.

Fix(s) for issue

To fix this problem, you should upgrade to the latest versions of the Products - DNN Platform 9.1.1 or EVOQ 9.1.1 at the time of writing.

Affected Version(s):

• All versions from 7.0.0 up to 9.1.0

Background

DNN contains a CMS component that allows site managers to upload certain files to the site.

Issue Summary

A malicious user can send specifically crafted requests to identify some parameters and then use these to upload malicious code to a site which gives them the ability to take control of the site (or even the machine hosting the site).

Mitigating factors

A malicious user must know the specifics of these endpoints and how to decode the information they contain. Then they must submit crafted requests to target this vulnerability.

Fix(s) for issue

To fix this problem, you can upgrade to the latest versions of the Products - DNN Platform 9.1.1 or EVOQ 9.1.1 at the time of writing. For versions older than 9.1.1, you can download and install a hot fix from here http://dnn.ly/SecurityFix201701 . The fix and the vulnerability are the same as discussed in the above link..

For further details, you can read this blog http://www.dnnsoftware.com/community-blog/cid/155436/critical-security-update--june-2017

Affected Version(s):

• All versions from 5.2.0 up to 9.1.0

Acknowledgments:

DNN thanks the following for identifying this issue and/or working with us to help protect users:

• ·         Thanh Van Tien Nguyen

Background

DNN provides a way for users to register in a site. User can choose to fill several profile properties such as first name, last name, profile picture, etc. Some of these profile properties can be supplied during user registration, but all of them can be updated under the user’s profile area of DNN. The registration forms usually have only a handful of such properties defined.

Issue Summary

Anonymous user can discover some or most of the profile properties from a DNN site due to a vulnerability present in DNN.

Mitigating factors

One needs to know the exact way to obtain this information. However, no information can be changed via this vulnerability.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest versions of the Products - DNN Platform 9.0.2 or EVOQ 9.0.2 at the time of writing. There is also a patch available that can be installed also. Follow this blog for more information: http://www.dnnsoftware.com/community-blog/cid/155416/902-release-and-security-patch

Affected Version(s):

06.02.00 till 09.00.01

Acknowledgments

DNN thanks the following for identifying this issue and/or working with us to help protect users:

-- Christopher Hammond

Background

ASP.Net recommends and provides Antiforgery tokens feature to prevent tampering of web requests and preventing cross-site scripting (XSS) attacks. DNN fully supports this notion and implements where applicable.

Issue Summary

In certain situations, the Antiforgery checks may not be checked in Web API calls. In such case, a malicious user may be able to perform XSS attacks.

Mitigating factors

A malicious user must know exactly which WEB API methods are subject to this vulnerability and must craft a special HTTP request that allows them to perform a WEB API call to exploit this vulnerability.

Fix(s) for issue

Background

DNN has provided several Web APIs to perform various CMS tasks from outside of the CMS. The Web APIs can be protected by specifying various levels of permissions, such as restrict to Super Users only, restrict to Administrators, etc. Some Web APIs can be accessed anonymously as well.

Issue Summary

A few Web APIs in DNN did not honor the permission specified for them and they could be accessed without any authorization. These vulnerable APIs are limited to a single sub-system of DNN, which is not very critical to the operation of DNN.

Mitigating factors

Only a few Web APIs were affected. These APIs have the abilities to make very minor system settings updates, which cannot cause any major damage; it will be more of an annoyance. In order to exploit this vulnerability, a malicious user must know in advance about such end points.

Fix(s) for issue

Affected Version(s):

• 09.00.00
• 08.00.04
• 08.00.03
• 08.00.02
• 08.00.01
• 08.00.00
• 07.04.02
• 07.04.01
• 07.04.00
• 07.03.04
• 07.03.03
• 07.03.02
• 07.03.01
• 07.03.00
• 07.02.02
• 07.02.01
• 07.02.00
• 07.01.02
• 07.01.01
• 07.01.00

Background

In DNN when a user tries to access a restricted area, they are redirected to an “access denied” page with a message in the URL.

Issue Summary

A malicious user may create a link to a DNN site's page in a way that clicking the link will display a crafted message telling the user to take some action, such as calling a phone number or sending message to a specific email. User may think that the message is coming from the site itself, as opposed to the malicious user.

Mitigating factors

A malicious user must know how to create this link and force unsuspecting users to click the link. Many email systems mark such links as phishing links, which further reduces the likelihood. Moreover, the generated message can display text only. Once user clicks on such a link and arrives at such a DNN page, the user must further act willingly to the message displayed.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest versions of the Products - DNN Platform 9.0.1 or EVOQ 9.0.1 at the time of writing.

Affected Version(s):

• 09.00.00
• 08.00.04
• 08.00.03
• 08.00.02
• 08.00.01
• 08.00.00
• 07.04.02
• 07.04.01
• 07.04.00
• 07.03.04
• 07.03.03
• 07.03.02
• 07.03.01
• 07.03.00
• 07.02.02
• 07.02.01
• 07.02.00
• 07.01.02
• 07.01.01
• 07.01.00
• 07.00.06
• 07.00.05
• 07.00.04
• 07.00.03
• 07.00.02
• 07.00.01
• 07.00.00

Acknowledgments

DNN thanks the following for identifying this issue and/or working with us to help protect users:

Background

DNN allows several file operations such as upload, delete, copy, etc. These operations are meant to manage files from within the CMS itself as opposed to using a service like FTP.

Issue Summary

A malicious user can craft a special HTTP request to generate multiple copies of an existing image file. The excessive number of files may result in disk space issues and cause the site to malfunction. This attack can be made as anonymous user also. It is important to note that this vulnerability is limited to image files only. Also, it does not allow unauthorized upload of new files.

Mitigating factors

A malicious user must know how to create this HTTP request and send thousands of such requests. Alternatively, the malicious user must entice other non-suspecting users to click on such a link, which are generally deemed as phishing links by most email clients.

Fix(s) for issue

Affected Version(s):

• 09.00.00
• 08.00.04
• 08.00.03
• 08.00.02
• 08.00.01
• 08.00.00

Background

DNN allows users to search for content in DNN sites.

Issue Summary

Upon typing certain keywords to search for content in DNN, user may get an error page instead of actual search results. This issue does not expose any data or causes data corruption.

Background

DNN has the ability to allow site administrators to update site's containers.

Issue Summary

Due to a bug in DNN, users with Edit permissions on a page can update container for all the pages in the site.

Mitigating factors

User must have Edit permission on a page.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest versions of the Products - DNN Platform 8.0.4 or Evoq 8.5.0 at the time of writing.

Background

DNN allows registered users to create content on site, where one create a links to other pages on the site.

Issue Summary

A malicious user may create a link to the site's registration page in such a way, that clicking in a certain area on the page may let a user visit an external page.

Mitigating factors

Malicious user should know how to create this link and place in an area where other users can see and click. 

Fix(s) for issue

To fix this problem, you are recommended to update to the latest versions of the Products - DNN Platform 8.0.4 or Evoq 8.5.0 at the time of writing.

Background

Whilst installing DNN a number of files are used to coordinate the installation of DNN.

Issue Summary

Whilst these files are necessary for installation of DNN, they were left behind after the process finishes. Potential hackers can use a specially crafted URL to access the install wizard and under certain circumstances create an additional host user. As such these files need to be removed to protect against security profiling.

Pre-condition(s)

The files InstallWizard.aspx and InstallWizard.aspx.cs must exist under Website Root\Install folder.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest versions of the Products - DNN Platform 8.0.3 or Evoq 8.4.2 at the time of writing.

As a temporary alternative, the following files under Website Folder\Install should be deleted:

• DotNetNuke.install.config
• DotNetNuke.install.config.resources
• InstallWizard.aspx
• InstallWizard.aspx.cs
• InstallWizard.aspx.designer.cs
• UpgradeWizard.aspx
• UpgradeWizard.aspx.cs
• UpgradeWizard.aspx.designer.cs
• Install.aspx
• Install.aspx.cs
• Install.aspx.designer.cs

Recommended cleanup steps after breach

• Go to Host > Host Settings page > Other Settings section > under Allowable File Extensions > and ensure that the .aspx extension is NOT allowed to be uploadable
• Go to Host > SuperUser Accounts page and review the list of users in the Super User section to ensure that only known and authorized users are listed. Remove any unauthorized users.
• Search the Root folder and subfolders of your site for any files with .aspx or .php extensions. Some .aspx files might be required for your site. Carefully inspect any files before deleting.
• Change SQL Server password and update connection string in the web.config of your DNN application. This is needed only when you are using a username and password in the connection string. It's not needed while using Trusted Connection.

Severity

CRITICAL

Background

Per design DNN allows authorized users to upload certain file-types into DNN’s folders. Depending on permissions, authenticated users can upload files such as images, module & skin extensions, documents, etc. DNN does not allow executables such as .exe, .aspx, etc. to be uploaded.

Issue Summary

The exploit allows upload of files without logging-in into DNN. Optionally, the uploaded file can replace an existing file also. The file can be uploaded within the Portals folder only; it cannot be uploaded outside of this folder or any other place on the server. System still respects “Allowable File Extensions” settings defined under Host > Host Settings > Other Settings, which means executables cannot be uploaded.

Mitigating factors

Attacker has to guess DNN’s internal Ids to upload files to specific locations.

Versions Affected

DNN Platform 8.0

DNN Platform 8.0.1

Evoq 8.3

Evoq 8.4

Fix(s) for issue

To fix this problem, you are recommended to update to the latest versions of the Products - DNN Platform 8.0.2 or Evoq 8.4.1 at the time of writing.

Background

In a few locations on the DNN site, page will redirect based on the “returnurl” query string parameter.

Issue Summary

A failure to sanitize the “returnurl” query string parameter can mean an open-redirect or cross-site scripting (XSS) issue occurs.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (8.0.1 at time of writing).

Acknowledgements

DNN thanks the following for working with us to help protect users:

• Ciaran McNally

Background

Page will redirect to http channel when enable SSL Client Redirect.

Issue Summary

A failure to sanitize URL query string parameters can mean a cross-site scripting (XSS) issue occurs.

Mitigating factors

SSL Enabled and SSL Enforce must be enabled in Site Settings by admins. And a setting name "AUM_SSLClientRedirect" with value "Y" must be in the host settings table in database.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (8.0.1 at time of writing).

Background

The Biography field on user's profile form allows HTML input but no JavaScript (filtering is performed on various tags). 

Issue Summary

User can add JavaScript to the Biography by including the following payload: <img src="test.jpg" onclick=prompt('XSS') alt="456">. The “Onclick” trigger and the “prompt” command are not filtered properly and JavaScript gets executed. A failure to sanitize Biography content can mean a cross-site scripting (XSS) issue occurs.

Mitigating factors

Admins need to change setting to make the Biography public to everyone; by default it is visible to admins only.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (8.0.1 at time of writing).

Acknowledgements

DNN thanks the following for working with us to help protect users:

• Nicklas Boecking

Background

Anti-forgery token called RequestVerificationToken is used in DNN Web APIs to help prevent Cross-Site Request Forgery (CSRF) attacks. 

Issue Summary

The RequestVerificationToken is not verified at all and all POST requests can go through even if that token is not present in the request header. A failure to verify the anti-forgery token can mean a CSRF issue occurs.

Mitigating factors

An attacker has to get a victim's browser to make a POST request to the server. 

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (8.0.1 at time of writing).

Background

DNN contains a tab's control that allows for content to be organised under clickable tabs. This approach is seen throughout the DNN administrative interface, and is intended to be used similarly in custom module development. However, this pattern can also be used just as easily outside of an administrative experience

Issue Summary

A failure to sanitize content used by the tabs control can mean a cross-site scripting (XSS) issue occurs.

Mitigating factors

A user would have to be induced to click on a specially configured URL to execute the XSS issue. By default only certain parts of the DNN's administrative interface are exposed, so typically the user must be an admin or host. In certain cases, 3rd party modules may expose the tabs control so users would need access to pages that host that control to be explotied

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (7.4.2 at time of writing).

Acknowledgements

DNN thanks the following for working with us to help protect users:

• August Karlstedt

Background

DNN supports the ability to set user registration modes - these include the ability to disable user registration ("none")

Issue Summary

A failure to re-validate that site registration is set to "none" means that potential hackers can work around DNN's protection and register "spam" user accounts.

Mitigating factors

• The new user accounts cannot be created via the UI - they require the spammers to capture the page and reuse asp.net's event validation to work around the failure to recheck the logic before creating the user.
• This only affects sites that use "none" for registration.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (7.4.2 at time of writing).

Acknowledgements

DNN thanks the following for working with us to help protect users:

• Scott Welch
• Eric Swanzey

A request could be crafted to that allows a user to confirm the existence of a file. The code has been updated to ensure only existence of image files in standard folders can be confirmed
Mitigating factors

N/A

Background

Whilst installing DotNetNuke a number of files are used to coordinate the intallation or upgrade of a portal.

Issue Summary

Whilst these files are necessary for installation/upgrade of DNN, they are left behind after the process finishes. Potential hackers can use these files to determine what version of DNN is running. This information could help them to target versions with known security issues, anf therefore, need to be removed to protect against security profiling.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (7.4.1 at time of writing).

 

Background

DNN contains an upload function that allows the upload of a resource from a 3rd party location.

Issue Summary

The code that provides for this upload does not filter sufficiently for valid values. A carefully crafted request could reveal the existence of files that are not normally available via publically addressable URL's

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (7.4.1 at time of writing).

Background

Whilst installing DotNetNuke a number of files are used to coordinate the installation of DNN.

Issue Summary

Whilst these files are necessary for installation of DNN, they were left behind after the process finishes. Potential hackers can use a specially crafter URL to access the install wizard and under certain circumstances create an additional host user. As such these files need to be removed to protect against security profiling.

Mitigating factors

• the installwizard.aspx/installwizard.aspx.cs files must exist
• if the installwizard can be forced to load, the potential hacker must provide valid database connection details. For sql server databases, the user must supply the servername and database. If the database is using sql security then a valid username and password must also be supplied. As such the greatest danger exists for sites that use sql server express user instances, as no user credentials are required, and the instance name is predictable.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DNN (7.4.1 at time of writing).

As an alternative, deleting the install/installwizard.aspx and install/installwizard.aspx.cs files can be manually deleted.

Note: We recommend users install http://www.dnnsoftware.com/community-blog/cid/155214/dnn-security-analyzer as it will automate the deletion of these files, as well as provide additional security functionality.

Acknowledgments

DNN thanks the following for working with us to help protect users:

Marios Nicolaides

Mitigating factors
The issue is in a rarely used piece of legacy code that ships with DNN. No usage of this was found in platform, or any of the modules shipped with it. However one usage was found in a 3rd party module so we have chosen to create this bulletin to make users aware.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of the DNN platform (7.4.0 at time of writing)

Acknowledgments

DNN thanks the following for working with us to help protect users:

• The reporter has chosen not to share their name.

Background

The DNN Framework contains code to allow internal messaging of users. A flaw in this code meant that user permissions were not fully evaluated and could lead to users sending mails to more users than intended.

Fix(s) for issue To fix this problem, you are recommended to update to the latest version of the DNN platform (7.3.3 at time of writing)

Acknowledgments

DNN thanks the following for working with us to help protect users:

• The original reporter does not wish to claim credit.

Background
The DNN Framework supports the ability for sites to allow users to register new accounts. A number of users have reported that excessive and unexpected registration was happening on their sites, and then these new accounts were adding html links to other sites within their profiles.

Mitigating factors

• This does not effect sites that have disabled registration.
• Sites that have enabled verified registration typically do not see this issue as the spam accounts do not use real email addresses, and user profile fields for unverified users are not visible to normal users (admin/host can view the profile)
• Sites that have enabled private registration typically do not see this issue as the site administrator will not authorize the spam accounts.

Details of the solution

Typically we do not provide details of security fixes, as those may only serve to help the potential hackers, but in this case as this fix is not expected to resolve 100% of automated registration issues, some detail is merited. The fixes cover three main areas:

1. Additional color and distortion was introduced to the current Captcha object to make automated Captcha cracking harder.
2. The default biography field on the user's profile was changed from a rich text box to use a multiline text box for new installs. This means the content is htmlencoded, meaning any HTML (such as a link to a spammers site) is encoded as plain text. This removes the "value" in creating spam accounts.
3. A bug was fixed in the existing Captcha control that allowed a single cracked captcha to be reused for multiple user registration. Based on analysis of IIS logs from affected sites, this bug was being used by spammers to create large numbers of new accounts at at time. Resolving this issue will greatly reduce any spam registration.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of the DNN platform (7.3.2 at time of writing)

Acknowledgments

DNN thanks the following for working with us to help protect users:

• Hal Interactive, Slovenia, DNN partner

Background



The DNN Framework contains code to support sanitizing user input. A failure to detect certain input as malicious could allow a hacker to use a cross-site scripting attack to execute html/javascript. 

Mitigating factors



The potential hacker must have a valid, authorized user account on your site. They must also induce a different user to click on a URL that contains both the location of a trusted site and the malicious content.

Fix(s) for issue



To fix this problem, you are recommended to update to the latest version of the DNN platform (7.2.2 at time of writing)

Acknowledgments

DNN thanks the following for working with us to help protect users:

• "Anonymous"

Background

The DNN Framework contains code to support searching across a lucene based search.  Part of this code fails to sanitize against input and could allow a hacker to use a cross-site scripting attack to execute malicious html/javascript.

  

Mitigating factors

The potential hacker must induce a user to click on a URL that contains both the location of a trusted site and the malicious content.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of the DNN platform (7.2.0 at time of writing)

Background
The DNN Framework contains code to support client to server operations that was added to the codebase before Microsoft Ajax was released. Part of this code fails to sanitize against input and could allow a hacker to use a cross-site scripting attack to execute malicious html/javascript.
  

Mitigating factors
The potential hacker must induce a user to click on a URL that contains both the location of a trusted site and the malicious content.

Fix(s) for issue
To fix this problem, you are recommended to update to the latest version of the DNN platform (6.2.9/7.1.1 at time of writing)

Acknowledgments
DNN thanks the following for working with us to help protect users:

• Sajjad Pourali (Sajjad@securation.com)

• Nasser Salim Al-Hadhrami

Background
The DNN Framework contains code to sanitize user input where html/javascript is not intended. A particular piece of malformed HTML was not correctly detected by this code, and the potential for a persistent cross-site scripting (XSS) attack could occur.
  

Mitigating factors
The potential hacker must have an authorized user on the site.

Fix(s) for issue
To fix this problem, you are recommended to update to the latest version of the DNN platform (6.2.9/7.1.1 at time of writing)

Acknowledgments
DNN thanks the following for working with us to help protect users:

• Shubham Mittal via Secunia SVCRP

Background
During usage of the DNN Framework, in a number of cases a redirect must occur after an action (such as working across portals). DNN has code to ensure that these redirects are always to valid locations and not to untrusted external locations. An issue was fixed where a particular URL could lead to a redirect to an external location -in security terms this is known as a "phishing" attack.
  

Mitigating factors
The potential hacker must induce a user to click on a URL that contains both the location of a trusted site and a redirect to an untrusted site. 

Fix(s) for issue
To fix this problem, you are recommended to update to the latest version of the DNN platform (6.2.9/7.1.1 at time of writing)

Acknowledgments
DNN thanks the following for working with us to help protect users:    

• Amir Azam of ProCheckUp Ltd (www.procheckup.com)

DotNetNuke 7.0 introduced rich support for client uploads via service framework requests. The code that handles this supports selecting the folder but fails to revalidate these permissions.

Mitigating factors

• users must still have rights to upload a file, they can only change the intended folder. All other checks such as extension checking occur as expected

Affected DotNetNuke versions

• 7.0.0 and above

Non-Affected Versions:

• prior to 7.0.0

When running with multiple languages a flag selector is available. This echoes the page address with the different culture's available, but fails to remove any potential html/javascript injection.

Mitigating factors

• sites must have more than 1 language enabled
• sites must be using core language skin object

Affected DotNetNuke versions

• All

Non-Affected Versions:

• N/A

We were alerted that a particular tag could be added that would allow for a site redirect. Whilst the W3C specification for this tag states that it will not work unless it is in the HEAD of the document, testing found that it does work within the BODY in a number of major browsers. Whilst not a DotNetNuke issue, we are electing to add an additional filter to protect users.

Mitigating factors

• Internet explorer prior to release 8 will not allow this tag in the BODY.
• other browsers may or may not allow it.

Affected DotNetNuke versions

• All versions

Non-Affected Versions:

• N/A

The function creates a new file for any new profile image height and width - if sufficent requests are made a possibility exists that all available disk space could be consumed, leading to the website not performing as expected.

Mitigating factors

N/A

Affected DotNetNuke versions

• 6.2.1-6.2.5
• 7.0.0

Non-Affected Versions:

• pre 6.2.1
• 6.2.6 and above
• 7.0.1 and above

This module does not correctly protect against certain inputs that may lead to data compromise.

Mitigating factors

• N/A

Affected DotNetNuke versions

• All

Non-Affected Versions:

• 6.2.6 and above
• 7.0.1 and above

A number of browsers incorrectly implement a particular HTML tag, in violation of the official W3C standards. A possibility exists to use this tag to redirect requests for certain files to another site. Whilst this is not a DotNetNuke problem, we have elected to add defensive coding to mitigate this.

Mitigating factors

• a potential hacker must have access to a html module editor instance
• a user must be using a browser that incorrectly implements the previously discussed behaviour

To add or edit a module's title a user must have either page editor or module editor permissions. As these permissions can be delegated to non admin/host users, these less trusted users can update the module title to potentially contain html or javascript leading to a cross-script injection,

Mitigating factors

• user must have module or page editor permissions

Affected DotNetNuke versions

• All

Non-Affected Versions:

• 6.2.5

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke ( 6.2.5 at time of writing)

When entering list items, the name and value are treated as text and not encoded to guard against potential script/html injection.

Mitigating factors

• user must have access to the lists function - by default only admin and host users can access this module

Affected DotNetNuke versions

• All

Non-Affected Versions:

• 6.2.5

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke ( 6.2.5 at time of writing)

DotNetNuke user and profile properties fields support an extended visibility property to determine if fields are available to all, members, friends/followers or admin only. The member directory fails to apply these checks to a number of fields.

Mitigating factors

• user must have access to a member directory module
• member directory module must be available to all (including anonymous) users

Affected DotNetNuke versions

• 6.2.0-6.2.4

Non-Affected Versions:

• pre 6.2.0
• 6.2.5 and above

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke ( 6.2.5 at time of writing)

The function fails to validate for illegal values and can be abused to load invalid files.

Mitigating factors

N/A

Affected DotNetNuke versions

• 6.2.1-6.2.4

Non-Affected Versions:

• pre 6.2.1
• 6.2.5 and above

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (6.2.5 at time of writing)

The database operation which fills the folder list failed to distinguish between "deny" and "allow" folders and could potentially reveal the names of folders the user did not have access to.

Mitigating factors

This issue only allows for the existence of a folder to be confirmed and does not allow the user to upload to that folder (a further check is made before allowing write to the folder). In addition this only affects installations which use "deny" permissions at the folder level

It is possible to use a specially crafted URL to directly load a module, and due to a flaw in the logic, at that time the module permissions are not correctly loaded, but instead the page permissions are applied.

Mitigating factors

This issue only affects sites where module permissions are more restrictive than the page permissions on which they sit. This primarily affects sites where a page is visible to all, but individual modules are only visible to more restricted groups.

The lists module does not correctly sanitize the name(s) of list/sublists - this can lead to a reflective cross-site scripting (XSS) issue.

Mitigating factors

Site administrators/Host users would have to be induced to click on a link to their website that contained the XSS code. This XSS is not stored but rather reflected as part of the request - in addition DotNetNuke has a number of pieces of defensive code to protect against the targets of common XSS attacks

The Journal module allows a user to post a link to an image they have previously uploaded. By intercepting and replacing the request, it is possible to add additional javascript to the image and have it rendered. The code has been updated to validate and remove such requests.

Mitigating factors

• the Journal module must be installed
• the site must allow users to post to other users journals

In 6.0 DotNetNuke introduced folder providers as an abstraction to support alternative file stores, replacing the existing filesystem code. However the check for file extensions was missed in one of functions, allowing users to rename files to extensions not allowed by the portal.

Mitigating factors

The user would need access to the file manager and the relevant permissions - by default this functionality is only available to portal admins and host (superusers)

Affected DotNetNuke versions

• 6.0.0-6.1.3

Non-Affected Versions:

• Versions prior to 6.0.0

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (6.1.4 at time of writing)

Acknowledgments

Mark Litchfield from NGSSecure

Brandon Haynes

Security Policy

Click here to read more details on the DotNetnuke Security Policy

It's possible for a potential hacker to craft a particular URL which would cause the javascript for the modal popup to be polluted with a cross-site scriping attack.

Mitigating factors

• The user would have to click on a URL that contained the javascript injection and then immeadiately after would need to click a modal popup link.
• DotNetNuke contains protection against cross-site scripting attacks accessing the users authentication cookie.

Affected DotNetNuke versions

• 6.0.0-6.0.2 

Non-Affected Versions:

• versions prior to 6.0.0
• 6.1.0 and higher

Fix(s) for issue

To fix this problem, you are recommended to update to the 6.1.0 or higher - ideally upgrade to the latest version of DotNetNuke (/6.1.3 at time of writing)

As a common page is used for both functions, the code checks for the users permissions and redirects approriately. However a weakness in the code means that a potential hacker can stop the redirect and gain access to the functions available to portal admins and host users. They can then use these to create new users, delete users, and edit existing users and roles for those users.

Mitigating factors

N/A

Affected DotNetNuke versions

• All

Non-Affected Versions:

• N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.6.7/6.1.3 at time of writing)

The function uses direct filesystem methods to check for these files existence and not the DotNetNuke API so it can allow for the existence of a file with an unmapped extension to be made e.g. a .resources or .config file. Code has been added to ensure that only image types can be used.

Mitigating factors

This issue only allows for the existence of a file to be confirmed and does not allow the file to be read or altered. 

Affected DotNetNuke versions

• 6.0.0 - 6.1.2

Non-Affected Versions:

• Versions prior to 6.0.0

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (6.1.3 at time of writing)

If demo portals are enabled, and an incorrect username/password is used, then the page reloads and to help fix the incorrect detail renders the entered details. As this page can be cached in a browsers temporary internet files, and the rendered password may have been close to the actual password (e.g. a typo such as "pssword"), a hacker with physical access to a machine may be able to access the cached page and gain help in guessing a password.

Mitigating factors

• Demo portals must be enabled
• New user must use an invalid username/password combination during signup
• Potential hacker must have physical access to the users machine to retrieve the browser temporary internet files (if not cleared)

Affected DotNetNuke versions

• All

Non-Affected Versions:

• N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.6.6/6.1.2 at time of writing)

If during initial installation the website does not have the correct filesystem permissions to install an exception is thrown. This exception contained the path to help with diagnosing errors. Theoretically knowning the drive and folder of the website is useful information to a potential hacker so this has been removed.

Mitigating factors

This issue is more theoretical than practical as even if the path details are viewed, the site has insufficent permissions for a hacker to access. In addition the path is likely to be easily guessable e.g. c:\inetpub\dotnetnuke , and have little value.

Affected DotNetNuke versions

• All

Non-Affected Versions:

• N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.6.6/6.1.2 at time of writing)

The telerik implementation of the editor will automatically remove javascript to try and ensure that cross-site scripting (XSS) cannot occur. However it does not cover all XSS variants, so additional filters were added to catch these attempts.

This issue would typically be rated as "low", but since version 5.5.0, DotNetNuke has shipped with a messaging component which is available to all users. As this can be used to create an XSS, and this XSS is then persistant, this issue has been elavated to a "medium" issue.

Some additional code was also added to encode additional fields in the message editor.

Mitigating factors

Versions prior to 5.5.0 do not have access to the messaging component, so hackers would need access (and edit permissions) to a html module to execute it.

Sites can protect against this issue by removing the messaging component.

Sites that do not allow public/verified registration also are less likely to have unknown users who can access this vulnerable component

A logical flaw in the permissions checks for modules could allow a potential hacker to use a carefully crafted url to escalate their permissions beyond module edit permissions.

Mitigating factors

The user must have a valid account, and must have been granted edit module permissions to at least 1 module.

If a user re-registers with the same username/password combination as an existing account, they are undeleted. If the site owner had intended to block access to that user permanently they should use the "hard-delete" function or use the unauthorized checkbox, but in some cases sites may not be aware of the "soft-delete" function and this would allow unwanted users to recreate their account

Mitigating factors

The user must have a valid account, and must know the username/password combination.

DotNetNuke has a number of user management functions that are exposed both for users and administrators. Whilst there is code in place to validate the user roles and permissions to determine which functions are shown to users, it is possible to craft requests that bypass these protections and execute admin functions.

Mitigating factors

N/A

If an incorrect username/password is used, then the page reloads and to help fix the incorrect detail renders the entered details. As this page can be cached in a browsers temporary internet files, and the rendered password may have been close to the actual password (e.g. a typo such as "pssword"), a hacker with physical access to a machine may be able to access the cached page and gain help in guessing a password.

Mitigating factors

N/A

A request could be crafted to this control to allow a user with only file permissions to upload a skin or container. As both of these extensions support filetypes that can contain executable code, this would allow a user to upload dangerous files.

Mitigating factors

User may have a valid account to login and must have permissions to upload files

If a user has edit permissions to a module, this incorrect grants them access to manage the module, allowing them to access all permissions and change them as desired.

Mitigating factors

User may have a valid account to login and must have edit permissions on a page or module.

A logical error was introduced which meant that a user who had "edit" access, also was able to access module settings. Once module settings were accessed, the user could grant themselves additional granular permissions.

Mitigating factors

This only affects sites where users are granted "edit" permissions i.e. sites where single users administrate all the content are not affected.

A poor design pattern in the validation code meant that it was possible for potential hackers to access both the install and uninstall functions via a user who did not have host permissions. Once accessed these functions allowed for the uninstalling of modules, or installation of modules. Whilst the modules would then fail to install fully due to user file permissions, it was possible to access the failed installation and hence run code.

Mitigating factors

Sites that have the viewstate encrypted are protected against accessing failed user uploads.

Whilst correctly encoding the error messages to protect against cross-site scripting attacks, the error page was assuming values returned by the asp.net framework were safe. A potential hacker could generate a custom URL which contained an invalid viewstate value, composed of an XSS attack. If a user could then be fooled into clicking on that link, a reflective XSS issue would occur

Mitigating factors

Users would have to be fooled into clicking on a link that contained the invalid viewstate. In addition DotNetNuke contains a number of pieces of protection against cross-site scripting issues including the use of the HTTPOnly attribute which stops XSS code accessing users cookies.

If a site does not have sufficent permissions to do an install/upgrade, then a  HTTP 403 status is thrown and a custom permisions page is generated. This page used to identify the operating system version to help users diagnose what permissions were missing. However, this information is also potentially helpful to hackers, so the OS identification functionality was removed.

Mitigating factors

N/A
Note: Whilst not a mitigation, the identification of the operating system of a website is a trivial action with a number of websites/tools offering tools which probe and identify operating system's accurately. As such this function has little added value, but it's removal complies with best practices.

The messages returned from the forgot password utility were too detailed, and could be used to identify the existance of user accounts.

Mitigating factors

This only affects sites where the forgot password utility is used. If the authentication provider does not support this, or has enablePasswordRetrieval set to false in web.config, no action is required.

Whilst the majority of profile properties encode output, some contain HTML and cannot do so. An additional filter to remove potential XSS issues was added to these profile properties.

Mitigating factors

This only affects sites which display richtext profile properites. The user profile module supports templating so these properties are optional.

It's possible to make invalid requests for the syndication handler that will consume resources searching for the relevant data before timing out. If enough of these requests are sent then resources can be consumed, leading to eventual exhaustion i.e. a "denial of service" attack

Mitigating factors

The number of invalid requests depends on a number of factors including the size of the DotNetNuke site and the capacity of it's webserver(s) and database server(s).

If during install/upgrade an error occurs, the exception details are written to the logfiles. There is a small possibility that information in these files could prove useful to a potential hacker.

In addition, the existance of log files can be helpful to hackers when attempting to profile an application to determine it's version.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.4.3 at time of writing).

Alternatively users can block access to log files by adding the following to their web.config's HttpHandler section.

<add verb="*" path="*.log" type="System.Web.HttpForbiddenHandler"/>

DotNetNuke contains a number of layers of protection to ensure that one user cannot execute actions as another user. These include both encoding and encrypting data to ensure it isn't tampered with. In addition code exists to maintain data integrity over postbacks. However, if a site allows new users to register, these users can access a number of public functions shared by all users. They can then capture some of the site specific data integrity values and use these via a CSRF attack to alter data via these public functions for other users.

Mitigating factors

1. If the site doesn't support public or verified registration the hacker cannot create a user to gain access to copy the data integrity values.

2. For a CSRF to work against a different user it requires that the user is logged in - by default DotNetNuke does not use persistent cookies so this will not always be the case. Note theres a host setting to disable presistent cookies ("remember me").
 
3. a user has to be tricked into visiting a page on another site that executes the CSRF.

The code for the user messaging module was attached to the (now legacy) Mail.Send function, meaning mails were delivered to the message store instead of always being emailed. The user messaging store is keyed off the email address meaning that a potential hacker could impersonate another user and potentially receive their emails.

Mitigating factors

1. The user messaging module is only available to logged in users. If your site contains a controlled set of users i.e. does not allow public or verifed registration then this issue is greatly mitigated. In cases where a site has a single user the issue obviously is non existant.

2. This mail function delivers to the first result, which may or may not be the correct user. Depending on the user configuration, mails may always go to the correct user.

The code for the user profile properties has a bug where an unautheticated user could access member-only properties under certain configurations.

Mitigating factors

No member-only profile properties are exposed if all profile properties are set to member-only or admin.

At present profile properties automatically strip dangerous XSS characters from data. In addition they support regular expressions to allow sites to configure the allowable characters. To conform to security best practices we've added an additonal htmlencoding to ensure dangerous html cannot be output.

Mitigating factors

1. Profile properties contain support for validating data passes a regular expression match. A site can configure these to ensure dangerous values do not slip through.

2. The user profile function is fully templatable, a site can configure this to minimise or eliminate potential issues.

3. The core already implements HttpOnly cookies to stop XSS attacks potentially stealing authentication cookies.

The code for the user messaging module does not sanitize all entered text, meaning it would be possible to generate a message that contained a script or html vulnerability.

Mitigating factors

The user messaging module is only available to logged in users. If your site contains a controlled set of users i.e. does not allow public or verifed registration then this issue is greatly mitigated. In cases where a site has a single user the issue obviously is non existant.

The install wizard has code which evaluates the database connection string and provides error details if a connection cannot be made. Under rare circumstances such as the sql server not being available it is possible to invoke the wizard and navigate to a screen that checks the connection. Once the connection fails the sql exception details are shown which can contain sensitive information such as the database name or the username that is attempting to connect.

Whilst this issue may reveal valuable information it is not easily exploitable, requiring 3rd party software to not perform or a full denial of sevice attack to cause the system to break, the issue has been rated as Low.

Mitigating factors

This issue can only manifest in the case of the database becoming unavailable.

Whilst system messages are often innocuous and simply warn a user if their profile has been updated (e.g. by an administrator) or if they've been added to a security role, there are a number of system messages which can contain sensitive data, in particular password reminders contain data that users would not want stored in clear text

Mitigating factors

N/A

Affected DotNetNuke versions

5.3.0 - 5.3.1

Non-Affected Versions:

All others

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.4.0 at time of writing). Please note, if you've been running 5.3.0 or 5.3.1 you may already have messages that you would want to clear. Upgrading to 5.4.0 does not automatically remove these, as there may be many legitmate messages from portal administrators. If you believe that there are no messages you wish to retain then you can remove all messages sent by a portal administrator using a query similar to:

DELETE FROM [dbo].[Messaging_Messages] where [FromUserID] in (select administratorid from portals)

If you wish to review the set of messages first, a query similar to this will allow you to view the messages and determine which to delete

* FROM [dbo].[Messaging_Messages] where [FromUserID] in (select administratorid from portals)

SELECT

DotNetNuke has a search function which redirects to a custom results page.

Issue Summary

Whilst the search function filters for dangerous script , recently code was added to show the search terms and this failed to filter. Whilst this code filters for common XSS issues, a variant was found that could bypass the filter, so additional protection was added

Mitigating factors

The expression that could bypass the filter is only exploitable in a small subset of browsers namely Netscape Navigator 8.1 and Firefox 2.x.

To protect against attacks that attempt to use invalid URL's, users can install the free Microsoft URLScan utility(http://www.iis.net/expand/UrlScan). This is a recommended install as it offers protection against a number of other non-DotNetNuke specific URL based issues.

Affected DotNetNuke versions

5.0.0 - 5.2.3

Non-Affected Versions:

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.3.0 at time of writing)

Acknowledgments

Security Policy

Click here to read more details on the DotNetNuke Security Policy

DotNetNuke supports the concept of multiple portals working within one website (e.g. www.mysite.com). These portals can take the form of a "child" or the main portal (e.g. mysite.com/child) or else a "parent" (e.g. parent.mysite.com). As each portal is unique, if a user moves between portals they are automatically expired and their permissions are regenerated - meaning that an Administrator on one portal is not automatically an Administrator on another.

Issue Summary

There is a weakness in how the users roles are expired that opens a window to allow a user with rights on one portal, a possibility of gaining those rights on another portal.

Mitigating factors

There are a number of substantial mitigations for this issue:

• This issue is only possible on portals within the same website instance i.e. under the same copy of the dotnetnuke code in IIS. It is not possible to do this with details from one instance (i.e. IIS website) to another instance, even on the same server.
• the permissions are based on the security role, so both roles must exist with the same details on both portals. By default only the Administrators role exists with the same details on all portals.
• The window to do this is limited by an automated function which expires the users security roles every minute. As potential hackers need to log into one portal, capture credentials, then log out and log into the other portal and use the captured credentials, this minimises greatly the risk of exposure.
• A potential hacker must have authorized accounts on 2 or more portals , and one of these must have additional security roles.

The install wizard has code which evaluates the database and assembly versions to determine if an upgrade is required. It is possible to view this information as an anonymous user.This information could be useful to hackers attempting to profile an application. 

As the information is important it will still show if the versions differ, but if they are in sync which is the normal case, the version is not revealed.

Mitigating factors

N/a

Affected DotNetNuke versions

• 4.0 - 5.1.4

Non-Affected Versions:

• All other versions

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.2.0 at time of writing)

Acknowledgments

Dan Gilleland, Dynamic Generation Inc.

Security Policy

Click here to read more details on the DotNetnuke Security Policy

Whilst the search function filters for dangerous script , recently code was added to show the search terms and this failed to filter. The code has been refactored to filter the input to ensure that cross-site scripting attacks cannot occur.

Mitigating factors

To protect against attacks that attempt to use invalid URL's, users can install the free Microsoft URLScan utility(https://www.iis.net/downloads/microsoft/urlscan). This is a recommended install as it offers protection against a number of other non-DotNetNuke specific URL based issues.

Affected DotNetNuke versions

4.8 - 5.1.4

Non-Affected Versions:

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (5.2.0 at time of writing)

Acknowledgments

Scott Bell, Security Consultant, Security-Assessment.com

Background

To support switching between languages via the Language skin object, the skin object renders the existing page path along with the relevant country flag and a language token. It also supports the ability to supply replaceable tokens.

Issue Summary

The language skin object failed to encode the newly generated paths which meant that a hacker could inject html/script to perform cross-site scripting attacks.

Mitigating factors

Only DotNetNuke sites that have multiple language pack installs and use the Language skin object suffer from this flaw.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.5/5.1.2 at time of writing)

Acknowledgments

Leo Lin (Wisedata.com.tw)

Background

The DotNetNuke ClientAPI is a combination of client and server code, that allow developers to create a rich client-side experience. It's usage predates many of the more modern Ajax libraries.

Issue Summary

There are a number of places where the ClientAPI did not encode the contents of data passed to it, and echoed it back to the client. This unvalidated input could lead to html and script injections such as cross-site scripting.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to one of the latest versions of DotNetnuke - either 4.9.5 or 5.1.2 at time of writing.

Note: Whilst 4.9.5 has a fix for this issue, site admins are recommended to use the 5.1.2 version which contains additional defensive coding to harden the ClientAPI against potential future issues.

Acknowledgments

• Information Security Consultant Cengiz Han Sahin.
• Tim McAllister

Background

DotNetNuke has a custom errorpage for handling displaying information to users.

Issue Summary

The errorpage contains details of the current running version. This information could be useful to hackers attempting to profile an application. 

Mitigating factors

N/a

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.4 at time of writing)

Acknowledgments

N/A

Background

Whilst installing DotNetNuke if an error occurs, as the custom error handling system may not be in place a redirect is performed to an error handling page.

Issue Summary

The error handling page optionally reads back a querystring parameter that may contain additional error information. Whilst this parameter is typically encoded, an invalid tag could be used to bypass the filter, potentially to unencoded content being echoed to the screen and could allow for script or html injection issues.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.4 at time of writing)

Acknowledgments

Ben Hawkes - Lateral Security (www.lateralsecurity.com)

Background

To support paypal IPN functionality, DotNetNuke posts information to and receives status information from the paypal webservice. To do this it uses a name/value pair as part of the request, which is echoed to the form action attribute to ensure that any actions post to the correct page.

Issue Summary

It was possible to amend the name/value pairs and inject html/script which could allow hackers to perform cross-site scripting attacks.

Mitigating factors

If your site is not using paypal functionality, you can delete or rename (to a non aspx extension) the file at Website\admin\Sales\paypalipn.aspx

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.3 at time of writing)

Acknowledgments

N/A

Background

DotNetNuke uses role membership to control access to content and modules

Issue Summary

An issue exists where a user with login details to a DotNetNuke site could add additional roles to their user account. Code has been added to stop this happening.

Mitigating factors

This vulnerability can only be exploited by users with a valid username/password combination on a website.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.1 at time of writing)

Acknowledgments

N/A

Background

When a DotNetNuke portal is installed the version number if displayed on the link to first access the portal.

Issue Summary

Under some circumstances it was possible to view the install wizard page, allowing potential hackers to view the portal number. This information could be useful to hackers attempting to profile an application. 

Mitigating factors

N/a

Affected DotNetNuke versions

• 4.0 - 4.8.4
• 5.0 - Note: the code was put in place for 4.9, but was not correctly merged into the 5.0 (cambrian) branch. This issue was resolved in 5.0.1

  Fix(s) for issue

  To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.2/5.0.1 at time of writing)

  Acknowledgments

  N/A

Background

DotNetNuke supports using parameters to change the current skin, to allow users to preview skin files and also to dynamically load functions on request.

Issue Summary

Skin files are based on asp.net user controls (ascx) but add additional functionality such as security validation. Due to a weakness is validating the parameter it is possible to load an existing ascx file directly rather than loading a skin file that then loads the control. In a limited number of scenarios this can allow certain existing controls to subvert the security mechanism and could result in users gaining access to admin or host functions. Code has been added to close this authentication blindspot. 

Mitigating factors

This vulnerability only allows existing ascx files to be loaded, many of which have additional security checks, ensuring that they could not be exploited.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.0 at time of writing)

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Brandon Haynes

Background

When a user is logged in when they access user functions a unique id is used to ensure that these functions are performed for the correct user.

Issue Summary

Due to a weakness is validating the user identity it is possible for a potential hacker to access other user's account leading. This means that a hacker could impersonate other users or perform an escalation attack by accessing a user such as the admin or host user.
 

Mitigating factors

A potential hacker must have a valid, authorized user account on the DotNetNuke portal so that they can then attempt to access other users functions. If you do not have any additional users on your portals (e.g. sites where a user is both admin and host user and no other users exist), then this is not an issue. If you have additional users the risk of user permission escalation or impersonation exists.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.9.0 at time of writing)

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Brandon Haynes

Background

Whilst installing DotNetNuke a number of files are used to coordinate the intallation or upgrade of a portal.

Issue Summary

Whilst these files are necessary for installation/upgrade of DotNetNuke, they are left behind after the process finishes. Potential hackers can use these files to determine what version of DotNetNuke is running. This information could help them to target versions with known security issues, anf therefore, need to be removed to protect against security profiling.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.3 at time of writing).

If you are unable to upgrade to the latest version, you can alternatively remove all of the *.txt files from the /Portals/_default folder. This will protect your site from being susceptible to automated security scanners or other probing tools typically used by malicious parties.

Acknowledgments

p>Background

When performing an installation or upgrade DotNetNuke forces the application to unload and reload so that changes can be processed.

Issue Summary

It is possible to remotely force DotNetNuke to run through it's install/upgrade step. As this causes the application to unload, a large number of similar requests could cause a denial of service attack(http://en.wikipedia.org/wiki/Denial-of-service_attack) which could lead to the application running slow or not responding to requests at all. An additional side effect of this attack could cause the web.config file to update it's InstallDate value to a value different from the correct one.

Mitigating factors

Although the config file will receive a new Last Modified Date as a result of this exploit, the content of the config file can not be viewed, downloaded, or arbitrarily modified.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.3 at time of writing).

If you are unable to upgrade to the latest version, you can rename or delete the following file from your installation: /Install/Install.aspx .

Acknowledgments

 Tony Valenti and Joseph Ravioli

Background

During installation or upgrade DotNetNuke runs through database scripts in sequence to create the database schema and insert various pieces of data.

Issue Summary

It is possible to remotely force DotNetNuke to run through it's install wizard. This could cause the SQL commands in the database scripts included with the application to re-execute. Since the database scripts are not designed to be re-executed; this could cause data loss or corruption in an installation.

Mitigating factors

This exploit relies on SQL scripts being located in a specific default installation location for the DotNetNuke application. Since there is no way for an attacker to upload their own SQL scripts to this folder, the risk of arbitrary SQL script execution is not a factor.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.3 at time of writing).

If you unable to upgrade to the latest version, you can rename or delete the following file from your installation: /Install/InstallWizard.aspx .

Acknowledgments

Tony Valenti and Joseph Ravioli

Background

DotNetNuke uses rich text editor controls in a variety of modules. The application uses a provider model to allow this functionality to be easily replaced with controls of the users choice, including default support for the popular FTB and FCK editor controls. These rich text editor controls typically leverage the DotNetNuke URLControl to provide a convenient method for selecting URLs, pages, and files for the portal. In the files area, there is also the ability to upload files from your client machine. Once selected, the file(s) are passed to the DotNetNuke API which handles the saving of the file, including services such as the ability to store in secure filesystem or secure database.

Issue Summary

The logic for both the UrlControl and the FileSystem API was missing some key security validation. It assumed that any input passed from a rich text editor control was valid, and did not revalidate the folder permissions. In addition, it had flawed logic which allowed a user to WRITE files to Folders for which they only had READ access. A hacker could use these two flaws in combination to upload files to folders for which they should have been restricted. Since by default in most DotNetNuke portals, Anonymous Users have READ access to all folders beneath the "Portals" home directory, the incorrect logic flaw allowed a user to upload a file to any folder under this directory. Files which were typically deposited as part of this security exploit were named ISCN.txt and simply contained notice of credit for the attack.

Mitigating factors

The FileSystem API performs a verification check for "safe" file extensions. By default the list of "safe" file extensions ( defined in Host Settings ) is quite small, meaning that only files such as text files, jpgs and gif's can be uploaded, and not more dangerous files with dynamic extensions such as aspx/asp etc.

Note: whilst the payload of this attack is limited by the check for extension, as it can be remotely exploited for anoymous users, it was decided to elevate this issue's rating to "Critical".

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.3 at time of writing)

Acknowledgments

Tomotoshi Sugishita ( DotNetNuke Japan User Group )
Mitchell Sellers

Background

Whilst installing DotNetNuke if an error occurs, as the custom error handling system may not be in place a redirect is performed to an error handling page.

Issue Summary

The error handling page optionally reads back a querystring parameter that may contain additional error information. This parameter was not being encoded before being echoed to the screen and could allow for script or html injection issues.

Mitigating factors

N/A

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.4 at time of writing)

Acknowledgments

Jimmy Summers- -Southern Progress Corporation

Background

To support URL Rewriting, DotNetNuke determines the current path of the page and echoes it to the form action attribute to ensure that any actions post to the correct page.

Issue Summary

It was possible to avoid the existing URL filtering code by using invalid URL's. These URL's could then be used to inject html/script which could allow hackers to perform cross-site scripting attacks.

Mitigating factors

To protect against attacks that attempt to use invalid URL's, users can install the free Microsoft URLScan utility(http://www.microsoft.com/technet/security/tools/urlscan.mspx). This is a recommended install as it offers protection against a number of other non-DotNetNuke specific URL based issues.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.4 at time of writing)

Acknowledgments

AmnPardaz Security Research & Penetration Testing Group

Background

To support switching between languages via the Language skin object, the skin object renders the existing page path along with the relevant country flag and a language token.

Issue Summary

The language skin object failed to encode the newly generated paths which meant that a hacker could inject html/script to perform cross-site scripting attacks.

Mitigating factors

Only DotNetNuke sites that have multiple language pack installs and use the Language skin object suffer from this flaw.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.4 at time of writing)

Acknowledgments

Mauricio Marquez

• Tom Walters

Background

For the 3.0 release of DotNetNuke we added a file manager module. By default this module is only accessible to Admin or Host users. There is a problem with the code that could allow an admin user to upload arbitrary files. With this level of access it would be possible for an Admin user to gain full Host access to the portal.

Issue Summary

The file manager component has a problem where a user could upload a file of a type that does not match the list of allowable file types. This vulnerability allowed for an Admin user to upload a file that could then grant them access to the entire portal i.e. an admin user account permission escalation.

Mitigating factors

• The user must have access to the file manager.
• By default this issue only affects Admin users.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.2 at time of writing)

Acknowledgments

Morteza Kermani

Background

For the 3.0 release of DotNetNuke the security model was changed to use a validationkey to encrypt the forms authentication cookie and the viewstate. Under certain rare circumstances this key may not be updated during install/upgrade, and this information could allow a potential hacker the ability to access the portal as any user, including both the host and admin accounts.

Issue Summary

During installation of new releases, or upgrade of any release prior to 3.0, DotNetNuke automatically generates a unique validationkey to secure the users forms authentication cookie and viewstate. If this value is not updated, the "known" value can be used to access the portal. To install DotNetNuke the user must have write access to the root folder. For the validationkey to fail to be updated, the same user must fail to update this file i.e. either not have write permissions to it or else the file is set as "read only".

Mitigating factors

This issue will only manifest under a reasonably rare set of permissions.

Fix(s) for issue

1. To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.2 at time of writing)

2. Check your web.config file. If the validationkey value is not set to "F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902" then your portal does not suffer from this issue.

Acknowledgments

Brian Holyfield - Gotham Digital Science

Background

Since DotNetNuke 3.0 there has been a Skin Management option in the Admin interface. The Skin Manager is primarily used to apply a new skin to a site; however, it can also be used by designers for development of new skins using the Parse capability.

Issue Summary

A problem was identified where an Administrator could upload static files which could then be converted into dynamic scripts. This would allow server-side execution of application logic.

Mitigating factors

• The host user must have added the HTM or HTML file type to the default File Upload Extensions
• The user must have access to the file manager.
• By default this issue only affects Admin users.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.8.2 at time of writing)

Acknowledgments

Timo Breumelhof

Background

Whilst installing DotNetNuke if an error occurs, as the custom error handling system may not be in place a redirect is performed to an error handling page.

Issue Summary

The error handling page optionally reads back a querystring parameter that may contain additional error information. This parameter was not being encoded before being echoed to the screen and could allow for script or html injection issues.

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.7 at time of writing)

Background

The HTML/Text module is one of the core modules that is installed by default and provides an easy way to add custom html to a page.

Issue Summary

This module suffers from an authentication blindspot which could allow a malicious user to update content that they do not have permission to administer.

Mitigating factors

If your portal does not use the text/html module you are not affected.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.7 at time of writing)

Background

DotNetnuke allows administrators to utilise a standard login page or create their own custom login page. When an unauthenticated user arrives at a site and attempts to access a protected resource they will be redirected to the correct login page. As part of this process the original request for the protected resource is remembered so that once the user has succesfully logged in, they can be redirected to the originally requested resource.

Issue Summary

The return path for the protected resource uses a querystring to store the url. This value is an implicitly trusted URL, so it is possible for a hacker to publish a url to your site that already contains this querystring parameter. In this case the hacker could point it to an untrusted source. A fix has been added to ensure that only paths relative to the website are supported.

Further information on phishing can be found here.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.5.4 at time of writing).

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Niel Nielsen of FortConsult A/S
• Graeme Neilson, Security Consultant, Aura Software Security

Background

DotNetNuke contains core code (FileServerHandler) to manage items that can be linked to such as files and URL's. This code allows the ability to apply user permisions and logging the number of clicks on the resource.

Issue Summary

Whilst the FileServerHandler validates user permissions for files, it implicitly trusts URL's, so it is possible for a hacker to publish a url to your site that does a redirect to another site. As the base url is your site, then it could fool users into believing that the url has been approved by your site e.g. a url like the following

http://www.dotnetnuke.com/linkclick.aspx?link=http://untrustedwebsite.com

would suggest to users that dotnetnuke.com trusted that site, when in fact it's not a link that has been published.

Note: To fix this issue, the handler now checks in the database to see if the link exists. If the link does not exist in the database then it is assumed to be a phishing request and will not redirect.

Further information on phishing can be found here.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (4.5 at time of writing).

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Antony Slater of WEBPC

Background

In earlier versions DotNetNuke supported anonymous vendor signup, so that advertisers could be added be added automatically without needing to authenticate. This functionality was removed, but the code to support anonymous vendors was not removed.

Issue Summary

The controltype for the vendor signup still supports anonymous access, if a user can determine the correct access url, they can gain access to adminster vendor details.

Mitigating factors

Users must have enabled banner advertising, and must have 1 or more instances of the banner module installed for the changes to be reflected on the site.

Fix(s) for issue

Alternative 1: To fix this problem, you are recommended to update to the latest version of DotNetNuke (3.3.7/4.3.7 at time of writing). This is the recommeded fix.

Alternative 2: Log in as the host user, and go to the host->sql menu, paste the following script into the textbox, and check the 'run as script' checkbox

/* fix security issue with vendor management */
update {databaseOwner}{objectQualifier}ModuleControls
set    ControlType = 1
where  ControlSrc = 'Admin/Vendors/EditVendors.ascx'
 

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Peter Schotman of Cestus Websites.

Background

For the 3.3/4.3 releases of DotNetNuke, the membership/roles/provider components were significantly overhauled to allow better granularity of control, and to allow us to make a number of enhancements.

Issue Summary

During the process of rewriting the code to extend the Profile component, an issue was introduced where a user had the ability to inject javascript on the Role management page. This vulnerability allowed for potential hackers to enable access to functionality intended only for administrators/superusers i.e. a user account permission escalation.

Mitigating factors

The user must have access to edit the details of a user account to inject the required javascript.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (3.3.6/4.3.6 at time of writing)

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• David Kirby of Risborrow Information Systems Ltd.

Background

When users are attempting to access portal functions, we strive to strike a balance between providing informative messages, but not revealing unnecessary detail to people attempting to profile the application.

Issue Summary

Two areas have been altered to fix issues where more information that was necessary was made available.

1. When attempting to access a a page that the user does not have permission to, the user is correctly redirected to the login page. However, the page title preserves the name of the originally requested page, which has been determined to be an unnecessary information leakage.
2. When logged in, if the user attempts to access another users profile, they are correctly redirected to a failure page. However, at that point the user can tell by the error message if the user account they tried to access is a standard user or a superuser.
    

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (3.3.6/4.3.6 at time of writing)

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Christiaan Mellars of Risborrow Information Systems Ltd.

Background

To ensure pages work as desired, the page name and any associated parameters are copied to the form action tag on every page request.

Issue Summary

Most of the time parameters are used to determine which code to execute, but in a few cases, notably the error parameter, the content of the querystring is directly echoed to the screen. Until recently, the querystring parameters were only screened for javascript to prevent potential cross-site scripting attacks, but it was possible to inject arbitrarty HTML into the page e.g. a page redirect to an IFRAME. This vulnerability has now been closed in 3.3.5/4.3.5.

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (3.3.5/4.3.5 at time of writing)

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Roberto Suggi Liverani & Antonio Spera of Secure Shapes

Background

To support a number of core functions and modules, DotNetNuke ships with a WYSIWYG editor control, a Word-style editor that allows users to add and format html. Rather than hard-code one particular product as the editor, DotNetNuke uses a html editor provider to allow administrators to easily change to other editor's. The default html editor that is shipped with DotNetNuke uses the freetextbox component.

Issue Summary

As a security measure, DotNetNuke restricts the filetypes that can be uploaded. An issue with the freetextbox component has been reported, where users can upload filetypes that are not allowed by DotNetNuke, thereby avoiding the built-in filtering. This could be used as the basis to gain unauthorised access to portal files or data.

Mitigating factors

To be affected, a site would have to grant edit permissions to one or more users for a module that uses the editor component such as the text/html module. In addition, the user would have to have permission to upload files. Sites that do not grant these permissions to users, or do not use the freetexteditor implementation of the html editor provider are not vulnerable to this issue e.g. a site where all the content is maintained only by one administrator who has host and portal admin permissions would not be affected.

Fix(s) for issue

To fix this problem, you can use either of these two options :

Option 1

Upgrade your version to either 3.3.3/4.3.3 or later - this is the recommended solution

Option 2

Use an alternative html editor provider, such as the free FCKEditor . Please note, you will also have to remove the existing FTB editor and associated dll's i.e. delete the HtmlEditorProviders\Ftb3HtmlEditorProvider folder from your installation, and remove FreeTextBox.dll and DotNetNuke.Ftb3HtmlEditorProvider.dll from your bin folder.

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Peter Schotman
• Richard from DNN-modules

Background

For the 3.3.3/4.3.3 releases of DotNetNuke, the membership/roles/provider components were significantly overhauled to allow better granularity of control, and to allow us to make a number of enhancements.

Issue Summary

During the process of rewriting the code to extend the Profile component, an authorization issue was introduced that could allow a user (including anonymous users) to access another users profile.
Due to the seriousness of this issue, further details are not available, users of 3.3.3/4.3.3 are recommended to upgrade to 3.3.4/4.3.4.
 

Mitigating factors

N/A

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (3.3.4/4.3.4 at time of writing)

Acknowledgments

DotNetNuke thanks the following for working with us to help protect users:

• Steinar Svendsen