Path-Based Cross-Site Scripting (XSS) issues

[andermat8]

Running version 1.1.28 on Windows 2012 with IIS

My company's security scan has picked up 151 application vulnerabilities with 72 of them being high. Most of these are for Path-Based Cross-Site Scripting (XSS). I don't see this addressed in any of the newer versions. The list is long but I can leave a few examples. Below are a couple. If this is of any value I can provide more.

Example #1:
URL:https://cacti-mfg.Corp.com/cacti/graph_view.php/z--%3E%3Cqss%3E

Threat

XSS vulnerabilities occur when the Web application echoes user-supplied data in an HTML response sent to the Web browser. For example, a Web application might include the user's name as part of a welcome message or display a home address when confirming a shipping destination. If the user-supplied data contain characters that are interpreted as part of an HTML element instead of literal text, then an attacker can modify the HTML that is received by the victim's Web browser. The XSS payload is echoed in HTML document returned by the request. An XSS payload may consist of HTML, JavaScript or other content that will be rendered by the browser. In order to exploit this vulnerability, a malicious user would need to trick a victim into visiting the URL with the XSS payload. In this case, the scanner identified the vulnerability by injecting a payload as part of the path component of the URL, as opposed to other kinds of XSS attacks that inject the payload into URL parameter values.

Impact

XSS exploits pose a significant threat to a Web application, its users and user data. XSS exploits target the users of a Web application rather than the Web application itself. An exploit can lead to theft of the user's credentials and personal or financial information. Complex exploits and attack scenarios are possible via XSS because it enables an attacker to execute dynamic code. Consequently, any capability or feature available to the Web browser (for example HTML, JavaScript, Flash and Java applets) can be used to as a part of a compromise.

Solution

Corp Guidance: The solution below is general guidance, not a Corp Solution ready for deployment. You will need to fully test/validate this solution and involve Corp IT to properly validate.

Filter all data collected from the client including user-supplied content and browser content such as Referrer and User-Agent headers. Any data collected from the client and displayed in a Web page should be HTML-encoded to ensure the content is rendered as text instead of an HTML element or JavaScript.

Detection Information

Parameter

No Param has been required for detecting the information. Booyah!

Authentication

Required

Access Path

Here is the path followed by the scanner to reach the exploitable URL:

N/A

Payloads ( Instance 1 of 1 )

#1 Request

Payload

@Append@/z-->

Request

GET https://cacti-mfg.Corp.com/cacti/graph_view.php/z--%3E%3Cqss%3E

#1 Referer: https://cacti-mfg.Corp.com/
#1 Cookie: Cacti=vl2tdiebfjdgt818imbcv2v8m2;

#1 Response

comment:
Response content-type: text/html

User Login '>

-------------------------------------------------------------------------------------------------------------- Example #2: URL:https://cacti-mfg.Corp.com/cacti/plugins/monitor/monitor.php/%27%20onmouseover%3D%27alert%289%29%3B%27

Threat

XSS vulnerabilities occur when the Web application echoes user-supplied data in an HTML response sent to the Web browser. For example, a Web application might include the user's name as part of a welcome message or display a home address when confirming a shipping destination. If the user-supplied data contain characters that are interpreted as part of an HTML element instead of literal text, then an attacker can modify the HTML that is received by the victim's Web browser. The XSS payload is echoed in HTML document returned by the request. An XSS payload may consist of HTML, JavaScript or other content that will be rendered by the browser. In order to exploit this vulnerability, a malicious user would need to trick a victim into visiting the URL with the XSS payload. In this case, the scanner identified the vulnerability by injecting a payload as part of the path component of the URL, as opposed to other kinds of XSS attacks that inject the payload into URL parameter values.

Impact

XSS exploits pose a significant threat to a Web application, its users and user data. XSS exploits target the users of a Web application rather than the Web application itself. An exploit can lead to theft of the user's credentials and personal or financial information. Complex exploits and attack scenarios are possible via XSS because it enables an attacker to execute dynamic code. Consequently, any capability or feature available to the Web browser (for example HTML, JavaScript, Flash and Java applets) can be used to as a part of a compromise.

Solution

Corp Guidance: The solution below is general guidance, not a Corp Solution ready for deployment. You will need to fully test/validate this solution and involve Corp IT to properly validate.

Filter all data collected from the client including user-supplied content and browser content such as Referrer and User-Agent headers. Any data collected from the client and displayed in a Web page should be HTML-encoded to ensure the content is rendered as text instead of an HTML element or JavaScript.

Detection Information

Parameter

No Param has been required for detecting the information. Booyah!

Authentication

Required

Access Path

Here is the path followed by the scanner to reach the exploitable URL:

N/A

Payloads ( Instance 1 of 1 )

#1 Request

Payload

@Append@/%27%20onmouseover%3D%27alert%289%29%3B%27

Request

GET https://cacti-mfg.Corp.com/cacti/plugins/monitor/monitor.php/%27%20onmouseover%3D%27alert%289%29%3B%27

#1 Referer: https://cacti-mfg.Corp.com/
#1 Cookie: Cacti=vl2tdiebfjdgt818imbcv2v8m2;

#1 Response

comment:
Response content-type: text/html

nBody'>

User Login

[cigamit]

Maybe its just an issue on IIS servers? My nginx servers give a 404 because the extra / is denoting a directory, which doesn't exist.

[andermat8]

Do you use HTTP X-XSS-Protection?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

I'm going to update my web.config with this and see if it makes a difference with the security scan.

[cigamit]

I've dug into this a bit deeper, your scanner needs an update. It's attempting to access pages, and those pages are being redirected to the login page. The intended JavaScript is being placed into the action attribute of the login form. With that said, I'll dig in a little deeper to see that this form attribute is being properly escaped.

[cigamit]

Okay, just followed up on this in a bit more detail. The action comes from the function get_current_page(). The get_current_page() function returns in order, and from what is found $_SERVER['PHP_SELF'], $_SERVER['SCRIPT_NAME'], and $_SERVER['SCRIPT_FILENAME']. According to the PHP documentation found at http://php.net/manual/en/reserved.variables.php, the $_SERVER['PHP_SELF'] is unsafe to use as it can include XSS payload.

The reason that this does not fire on nginx is that by default PHP_SELF is not initialized on that platform. So, this is a legit XSS. Addressing right now.

[cigamit]

@andermat8, please upgrade to Cacti 1.1.36 and then apply the lib/functions.php from the develop branch, and have your security team please rescan and provide feedback. Thanks to you and your team for contributing to the success of the project.

After the second scan, please upload the results file to this ticket and we will have a more detailed look.

[andermat8]

Thanks cigamit. I'll work on getting this done as soon as possible. My plate is rather full but hopefully I can get something my next week.

[cigamit]

Okay, it's likely we will do a release this weekend due to the significance of the discovery. It all depends on @ronytomen schedule. However, we will keep this open. We are very interested when people are able to do these types of scans for us. We really appreciate it.

[andermat8]

I'd say an improvement after the upgrade and applying the dev functions.php but still many High vulnerabilities. Here is one:
URL:https://cacti-mfg.corp.com/cacti/index.php
Finding #

8446650

corp Ranking/Score/Target Date

corp High / 8 / 04/13/2018
Group

XSS

First Time Detected

CWE

CWE-79

Last Time Detected

14 Mar 2018 08:53PM corp
OWASP

A3 Cross-Site Scripting (XSS)

Last Time Tested

14 Mar 2018 08:53PM corp
WASC

WASC-8 Cross-Site Scripting

Times Detected

1
CVSS Base 4.3 CVSS Temporal 3.9
Details
Threat
XSS vulnerabilities occur when the Web application echoes user-supplied data in an HTML response sent to the Web browser. For example, a Web application might include the user's name as part of a welcome message or display a home address when confirming a shipping destination. If the user-supplied data contain characters that are interpreted as part of an HTML element instead of literal text, then an attacker can modify the HTML that is received by the victim's Web browser. The XSS payload is echoed in HTML document returned by the request. An XSS payload may consist of HTML, JavaScript or other content that will be rendered by the browser. Its payload is inside of one of the "injectable" headers of the HTTP protocol.
Impact
XSS exploits pose a significant threat to a Web application, its users and user data. XSS exploits target the users of a Web application rather than the web application itself. An exploit can lead to theft of the user's credentials and personal or financial information. Complex exploits and attack scenarios are possible via XSS because it enables an attacker to execute dynamic code. Consequently, any capability or feature available to the Web browser (for example HTML, JavaScript, Flash and Java applets) can be used to as a part of a compromise.
Solution
corp Guidance: The solution below is general guidance, not a corp Solution ready for deployment. You will need to fully test/validate this solution and involve corp IT to properly validate.

Filter all data collected from the client including browser content such as Cookies, Referrer and User-Agent headers. Any data collected from the client and displayed in a web page should be HTML-encoded to ensure the content is rendered as text instead of an HTML element or JavaScript.
Detection Information
Parameter

referer
Authentication

Required
Access Path

Here is the path followed by the scanner to reach the exploitable URL:
https://cacti-mfg.corp.com/
https://cacti-mfg.corp.com/cacti/graph_view.php?action=tree&node=tbranch-1592&hgd=gt:32&hyper=true
Payloads ( Instance 1 of 1 )
#1 Request
Payload

http://localhost/' onEvent=X151847516Y0Z
Request

GET https://cacti-mfg.corp.com/cacti/index.php
#1 Referer: http://localhost/' onEvent=X151847516Y0Z
#1 Cookie: Cacti=0tinr3op5tg3mfjdrfg3t37kj7;
Click this link to try to reproduce the vulnerability using above payload.Note that clicking this link may not lead to visible results, either because the vulnerability requires context to be previously set (authentication, cookies...) or because the exploitation of the vulnerability does not lead to any visible proof.
#1 Response
comment:
Response content-type: text/html

You are not permitted to access this section of Cacti.

If you feel that this is an error. Please contact your Cacti Administrator.

[ Return | Login Again]

Version 1.1.36 | (c) 2004-2018 - The Cacti Group

[andermat8]

here is another:
URL:https://cacti-mfg.corp.com/cacti/graph_realtime.php?top=0&left=0&local_graph_id=23942
Finding #

8446656

corp Ranking/Score/Target Date

corp High / 8 / 04/13/2018
Group

XSS

First Time Detected

CWE

CWE-79

Last Time Detected

14 Mar 2018 08:53PM corp
OWASP

A3 Cross-Site Scripting (XSS)

Last Time Tested

14 Mar 2018 08:53PM corp
WASC

WASC-8 Cross-Site Scripting

Times Detected

1
CVSS Base 4.3 CVSS Temporal 3.9
Details
Threat
XSS vulnerabilities occur when the Web application echoes user-supplied data in an HTML response sent to the Web browser. For example, a Web application might include the user's name as part of a welcome message or display a home address when confirming a shipping destination. If the user-supplied data contain characters that are interpreted as part of an HTML element instead of literal text, then an attacker can modify the HTML that is received by the victim's Web browser. The XSS payload is echoed in HTML document returned by the request. An XSS payload may consist of HTML, JavaScript or other content that will be rendered by the browser. Its payload is inside of one of the "injectable" headers of the HTTP protocol.
Impact
XSS exploits pose a significant threat to a Web application, its users and user data. XSS exploits target the users of a Web application rather than the web application itself. An exploit can lead to theft of the user's credentials and personal or financial information. Complex exploits and attack scenarios are possible via XSS because it enables an attacker to execute dynamic code. Consequently, any capability or feature available to the Web browser (for example HTML, JavaScript, Flash and Java applets) can be used to as a part of a compromise.
Solution
corp Guidance: The solution below is general guidance, not a corp Solution ready for deployment. You will need to fully test/validate this solution and involve corp IT to properly validate.

Filter all data collected from the client including browser content such as Cookies, Referrer and User-Agent headers. Any data collected from the client and displayed in a web page should be HTML-encoded to ensure the content is rendered as text instead of an HTML element or JavaScript.
Detection Information
Parameter

referer
Authentication

Not Required
Access Path

Here is the path followed by the scanner to reach the exploitable URL:
N/A
Payloads ( Instance 1 of 2 )
#1 Request
Payload

http://localhost/' onEvent=X149424364Y0Z
Request

GET https://cacti-mfg.corp.com/cacti/graph_realtime.php?top=0&left=0&local_graph_id=1638
#1 Referer: http://localhost/' onEvent=X149424364Y0Z
#1 Cookie: Cacti=0tinr3op5tg3mfjdrfg3t37kj7;
Click this link to try to reproduce the vulnerability using above payload.Note that clicking this link may not lead to visible results, either because the vulnerability requires context to be previously set (authentication, cookies...) or because the exploitation of the vulnerability does not lead to any visible proof.
#1 Response
comment:
Response content-type: text/html

You are not permitted to access this section of Cacti.

If you feel that this is an error. Please contact your Cacti Administrator.

[ Return | Login Again]

Version 1.1.36 | (c) 2004-2018 - The Cacti Group

http://localhost/' onEvent=X149426688Y0Z
Request

GET https://cacti-mfg.corp.com/cacti/graph_realtime.php?top=0&left=0&local_graph_id=23942
#2 Referer: http://localhost/' onEvent=X149426688Y0Z
#2 Cookie: Cacti=0tinr3op5tg3mfjdrfg3t37kj7;
Click this link to try to reproduce the vulnerability using above payload.Note that clicking this link may not lead to visible results, either because the vulnerability requires context to be previously set (authentication, cookies...) or because the exploitation of the vulnerability does not lead to any visible proof.
#2 Response
comment:
Response content-type: text/html

You are not permitted to access this section of Cacti.

If you feel that this is an error. Please contact your Cacti Administrator.

[ Return | Login Again]

Version 1.1.36 | (c) 2004-2018 - The Cacti Group

[cigamit]

Okay, please run you scan again with latest develop. This time, do not attach the report, but instead email it to developers@cacti.net.

Thanks again!

[andermat8]

Okay, assuming you mean that I should download the latest functions.php off the development branch and apply it to my current 1.1.36 instance, correct?

[netniV]

No, it would be more than that as changes have been applied to other sources as well. You'd need to have a copy of the latest develop code to test against.

[andermat8]

I think I'm assuming wrong, seeing a lot of references to 1475. Should I download the whole dev branch?

[netniV]

Yes. That was a timing thing, as I just answered before your update lol 👍

[andermat8]

Also, this is probably a new item / request but has there been any consideration in changing how clear-text passwords are stored in the config.php and spine.conf. It is just a matter of time before I get hammered on an audit for this.

[netniV]

I would imagine that if we left off the requirement for a password, that would be as far as we would go. I suspect it would be considered the DB admin's responsibility for installation and configuration of the extra plugin to MySQL.

Such a change I would imagine would be a 1.2 change at this point since it's more a feature request than bug per sae. So, could you open a separate issue for that and then I will update with the proposal. Once that is done, we can then remove the authentication comments from this issue, to keep it on track about the XSS stuff.

[andermat8]

Added #1479.

[cigamit]

Yea, that is really a site customization. You can also use ssl with keys, but we are not supporting them correctly right now. Feature request.

As far as the security check is concerned, if your Security Team does not want to test develop, you can tell that that all the high stuff has been addressed. Most of the low stuff as well. There are a few low items that could not be addressed mainly due to timing. Could you ask them what tool they are using and let us know. I was so glad to be able to have a good report and be able to resolve the issues identified. It's the first real good scan that someone has contributed to the team in a while, and the fact that it came back so clean (really just 4 issues), is pretty good.

[andermat8]

I submitted a request for another scan. Not sure what tools they use. I was told they use a variety of them but they seem tight lipped about specifics.

[netniV]

Not so surprising. I find a lot of security people are like that despite the fact that allowing others to know actually helps those trying to fix it.

[andermat8]

Okay, improvement... went from 203 High and 28 Low vulnerabilities to 93 High and 7 Low. I'll work on sending the report to development.

[cigamit]

As far as I can tell, all the High issues are now resolved. The low issues are not impacting anything. They are basically warnings. Thanks again for working with us on this.

[cigamit]

Closing this now. Thanks for all the help.

[andermat8]

Okay, so download from the Dev Tree again and rescan?

[cigamit]

If your security team is willing to continue to help yes. I'm pretty certain we have all the issues covered, but getting positive confirmation would be great. I just did not want to push.

[andermat8]

Yes, I'll have them do another scan. FYI, I installed again from the dev tree and I'm noticing an oddity with clog where I put in a search filter and it will remove on refresh. I have refresh set to 1 Minute and after the interval my search string is removed. Not sure where you log issues with the dev build. Also, I can't send test emails anymore.

[netniV]

That sounds like something else is wrong. The filter will only be removed if it fails validation. What string are you putting in?

[andermat8]

system stats, worked without issue Tuesday with the previous dev build.

[netniV]

I've updated (via Git) to the latest development code and i'm not seeing any issue. I would do a full refresh and make sure you're not having an CSRF issues.

[andermat8]

Fresh download from Dev for version 1.1.37 and I'm still having issue in clog using Firefox, IE, and Chrome. Also, the test email link is gone under settings/Mail/Reporting/DNS.

[netniV]

Are you using the admin user? Have you got access to all the realms you should have?

[andermat8]

My ID has access to everything. I logged in with the admin ID and experience the same thing. Maybe it's a Windows thing?

[netniV]

Have you double checked the permissions are all correct?

[andermat8]

The security scan passed!! Thank you all for your assistance. As for the clog issue I'll try and find some cycles next week to dig into it further. Once 1.1.37 is in production I'll reinstall and cross my fingers.

[netniV]

It would be good to be able to run this kind of scan before any release to make sure no bugs creep back in. Would they be willing to either run that test or provide details to the developers email privately to ensure things are kept to this standard?

[andermat8]

I can get scans from time-to-time but it would be difficult to do it for every new release. Wonder if there are any freeware apps that can do this kind of scanning for you before releasing.

[netniV]

That was kind of why the questions over what they were using 😄

[andermat8]

The security guy I worked with mentioned a mix of purchased and opensource applications but he did not provide specifics. I found the following link:

http://resources.infosecinstitute.com/14-popular-web-application-vulnerability-scanners/#gref

Maybe Grabber and SQLMap?

[paulgevers]

Today three CVE have been assigned to this issue:

CVE-2018-10059: Cacti before 1.1.37 has XSS because the get_current_page function in lib/functions.php relies on $_SERVER['PHP_SELF'] instead of $_SERVER['SCRIPT_NAME'] to determine a page name.

CVE-2018-10060: Cacti before 1.1.37 has XSS because it does not properly reject unintended characters, related to use of the sanitize_uri function in lib/functions.php.

CVE-2018-10061: Cacti before 1.1.37 has XSS because it makes certain htmlspecialchars calls without the ENT_QUOTES flag (these calls occur when the html_escape function in lib/html.php is not used).