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.
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:
--------------------------------------------------------------------------------------------------------------
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'>
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 )
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.
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.
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?
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.
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.
Don't take this as gospel but from my view point, that is a standard Linux configuration. Most passwords are stored there in plain text but have access only to the database of the software in question. Even if we encrypted the password, there would be a function within the PHP code to decrypt this so I can't see that really adding much protection except to the most basic script kiddie.
Whatever user you use for Cacti should only EVER have access to the cacti database.
I am running Cacti on a Windows server (long story as to why) but I know for our other applications DB connections are encrypted. There are no applications that I'm aware of in our environment, aside from Cacti, that stores passwords in plain-text.
Most MySQL installations will not have that. I guess we could add an option to not supply the password should it be on a windows platform though I'm not sure how we would know if that plugin was set because we might not have rights to read the schema. The only thing we could do is try to connect.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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).
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
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.
</div *The reflected string on the response webpage indicates that the vulnerability test was successful Payloads ( Instance 2 of 2 )
2 Request
Payload
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.
</div
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!
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?
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.
I think I'm assuming wrong, seeing a lot of references to 1475. Should I download the whole dev branch?
Yes. That was a timing thing, as I just answered before your update lol 👍
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.
Don't take this as gospel but from my view point, that is a standard Linux configuration. Most passwords are stored there in plain text but have access only to the database of the software in question. Even if we encrypted the password, there would be a function within the PHP code to decrypt this so I can't see that really adding much protection except to the most basic script kiddie.
Whatever user you use for Cacti should only EVER have access to the cacti database.
Yup, I understand but I don't think I'll be able to convince our Security team.
How are they dealing with other such packages?
I am running Cacti on a Windows server (long story as to why) but I know for our other applications DB connections are encrypted. There are no applications that I'm aware of in our environment, aside from Cacti, that stores passwords in plain-text.
My bad, it was mentioned above about that. So the main reason that Cacti doesn't have this by default is that you have to customise the MySQL installation to include the Windows Authentication plugin: https://dev.mysql.com/doc/refman/5.5/en/windows-pluggable-authentication.html
Most MySQL installations will not have that. I guess we could add an option to not supply the password should it be on a windows platform though I'm not sure how we would know if that plugin was set because we might not have rights to read the schema. The only thing we could do is try to connect.
Yes, it would be great if we could use an AD service account to authenticate to the DB instead.
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.
Added #1479.
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.
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.
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.
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.
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.
Closing this now. Thanks for all the help.
Okay, so download from the Dev Tree again and rescan?
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.
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.
That sounds like something else is wrong. The filter will only be removed if it fails validation. What string are you putting in?
system stats, worked without issue Tuesday with the previous dev build.
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.
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.
Are you using the admin user? Have you got access to all the realms you should have?
My ID has access to everything. I logged in with the admin ID and experience the same thing. Maybe it's a Windows thing?
Have you double checked the permissions are all correct?
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.
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?
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.
That was kind of why the questions over what they were using 😄
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?
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).