DNN (DotNetNuke) CMS, not as secure as you think
DNN (formerly DotNetNuke) is the most popular CMS which uses “.NET” framework. DNN has been used by many important organizations from various sectors, including financial, defense, and government agencies such as NSA. DNN claims that the software has passed stringent vulnerability tests from Government Agencies and Financial Institutions — https://www.dnnsoftware.com/.
So I accepted it as a challenge, and to my surprise, I found three vulnerabilities during a quick analysis. I already reported these vulnerabilities to the DNN Security Team, explained the impact, and followed up with the team continuously. However, unfortunately the DNN team skipped patches for two reported issues.
File upload vulnerability through bypassing client-side file extension check (CVE-2020-5188)
The DNN has a file upload module for superuser. As a superuser, you can upload files with the following formats — “jpg, jpeg, jpe, gif, bmp, png, svg, ttf, eot, woff, doc, docx, xls, xlsx, ppt, pptx, pdf, txt, xml, xsl, xsd, css, zip, rar, template, htmtemplate, ico, avi, mpg, mpeg, mp3, wmv, mov, wav, mp4, webm, ogv”.
As a normal user you are allowed to upload files with “bmp,gif,ico,jpeg,jpg,jpe,png,svg” extensions. The same file upload module used for superuser is reused for normal users with extra validation for a few additional extensions e.g. CSS extension is not allowed.
Unfortunately, only for superuser, whitelisted extension check is performed at the server end. For normal users, extra extension validation is performed at client-side only. Hence, a low privileged normal user can bypass the client-side validation and upload files with extensions which are allowed only for superuser only.
For example, a normal privileged user can upload a file with extension which is allowed only for superuser, by executing the following code on a browser’s console (in the tab that manages profile’s page has opened). This attack may also be performed using proxy tools such as Burp, ZAP etc.
Status: This vulnerability has not been fixed.
Cross-site scripting by uploading a malicious XML file (CVE-2020-5186)
DNN allows normal users to upload XML files by using journal tools in their profile. An attacker could upload XML files which may execute malicious scripts in the user’s browser.
In XML, a namespace is an identifier used to distinguish between XML element names and attribute names which might be the same. One of the standard namespaces is “http://www.w3.org/1999/xhtml” which permits us to run XHTML tags such as <script>.
For instance, uploading the following code as an XML file executes javascript and shows a non-harmful ‘XSS’ alert.
Though stealing of authentication cookies are not possible at this time (because the authentication’s cookies are set as HttpOnly by default), XSS attacks are not limited to stealing users’ cookies. Using XSS vulnerability, an attacker can perform other more damaging attacks on other or high privileged users, for example, bypassing CSRF protections which allows uploading “aspx” extension files through settings page which leads to upload of backdoor files.
Status: This vulnerability has not been fixed.
Zip Slip vulnerability (CVE-2020-5187)
In a nutshell, Zip Slip is a kind of “directory traversal” attack, which exploits lack of directory names check while extracting archives. Using this vulnerability attacker may overwrite files with specific extensions on the system and may execute malicious code.
The zip file extraction function of DNN file upload feature is vulnerable to zip split until 9.5 version (9.5 is not vulnerable).
An attacker could replace any files with following extension on system -
“jpg, jpeg, jpe, gif, bmp, png, svg, ttf, eot, woff, doc, docx, xls, xlsx, ppt, pptx, pdf, txt, xml, xsl, xsd, css, zip, rar, template, htmtemplate, ico, avi, mpg, mpeg, mp3, wmv, mov, wav, mp4, webm, ogv”
Ideally, only high privileged user is allowed to upload zip files, but using Vulnerability #1 — extension bypass(CVE-2020-5188), a normal user can exploit this vulnerability. For example, a normal privileged user can replace CSS files on web application and perform defacement of the website.
Status : This issue is resolved in DNN_Platform_9.5.0-rc0001.
Disclaimer:
Even after sending multiple emails to the DNN Security team, vulnerability #1 and #2 are not still fixed.
Also, about reported vulnerability #3, the affected version information is not correctly published in the DNN security bulletin — 2019–04 (Critical) Possible Unauthorized File Access. The bulletin mentions that DNN version 9.3.2 and previous versions are affected, however, vulnerability was fixed in DNN version 9.5.
Timeline:
18 Jul 2019 — First technical report sent to DNN (security@dnnsoftware.com).
22 Jul 2019 — As per request, additional PoC details sent to DNN.
25 Sept 2019 — Requested DNN to share any update.
25 Sept 2019 — DNN replied, still working on patches.
22 Nov 2019 — DNN security bulletin published, no credit given!
29 Nov 2019 — Requested DNN to add my name as a reporter
2 Dec 2019 — DNN closed the conversation on kayako
12 Feb 2020 — Out of curiosity, retested issues and they are still open in the last stable release! With additional details, I sent a technical report again! (security@dnnsoftware.com). DNN mentioned that all issues are already resolved.
13 Feb 2020 — Reported DNN that, in v9.5.0-rc1 only vulnerability #3 is patched.
14 Feb 2020 — DNN asked for technical details again!!
16 Feb 2020 — Technical details shared again!!!!!
— — No response from DNN — -
23 Feb 2020 — Public Disclosure
