PCI Compliance
Permalink
Hi all,
A client of mine is running C5 v5.6.3.1 and has failed the PCI compliance check.
Here are the details of the failures:
1. The Access::buildAssignmentFilterString() method implemented via the /concrete/src/Permission/Access/Access.php source file, fails to sanitize user supplied input received via the $accessType parameter. This could allow an authenticated, remote attacker to inject and execute arbitrary SQL commands on a targeted system. Successful exploitation could allow an unauthenticated, remote attacker to manipulate SQL queries by injecting arbitrary SQL code or further exploit latent vulnerabilities in the underlying database.
2. The following source files fail to sufficiently sanitize user supplied input, that could allow remote, unauthenticated attackers to conduct XSS attacks:
/concrete/views/panels/details/page/versions.php
/concrete/src/Form/Service/Widget/UserSelector.php
/concrete/elements/group/search.php
/index.php/dashboard/system/multilingual/setup/load_icon
/concrete/attributes/select/form.php
/index.php/dashboard/pages/single
3. The Open::update_registration_type() method implemented via /concrete/controllers/single_page/dashboard/system/registration/open.php source file fails to sanitize user supplied input received via the register_notification_email parameter, allowing remote attackers to execute arbitrary code using the sendmail program.
4. Multiple cross-site scripting (XSS) vulnerabilities exist because the following source files fail to validate user-supplied input received via banned_word, channel, accessType, msCountry, arHandle, design, pageURL, SEARCH_INDEX_AREA_METHOD, unit, register_notification_email or PATH_INFO parameters:
index.php/dashboard/system/conversations/bannedwords/success
index.php/dashboard/reports/logs/view
index.php/tools/required/permissions/access_entity
index.php/dashboard/system/multilingual/setup/load_icon, design/submit
index.php/ccm/system/dialogs/area/design/submit
index.php/dashboard/pages/single
index.php/dashboard/system/seo/searchindex/updated
index.php/dashboard/system/optimization/jobs/job_scheduled
index.php/dashboard/system/registration/open/1
index.php/dashboard/extend/connect/
Do they need to migrate to 5.7.4.1 in order to avoid these vulnerabilities, or do the vulnerabilities not exist in 5.6.3.3? If they do exist in 5.6.3.3 do they also exist in 5.6.3.4? If they exist in 5.6.3.4 are there any plans to patch them soon?
A client of mine is running C5 v5.6.3.1 and has failed the PCI compliance check.
Here are the details of the failures:
1. The Access::buildAssignmentFilterString() method implemented via the /concrete/src/Permission/Access/Access.php source file, fails to sanitize user supplied input received via the $accessType parameter. This could allow an authenticated, remote attacker to inject and execute arbitrary SQL commands on a targeted system. Successful exploitation could allow an unauthenticated, remote attacker to manipulate SQL queries by injecting arbitrary SQL code or further exploit latent vulnerabilities in the underlying database.
2. The following source files fail to sufficiently sanitize user supplied input, that could allow remote, unauthenticated attackers to conduct XSS attacks:
/concrete/views/panels/details/page/versions.php
/concrete/src/Form/Service/Widget/UserSelector.php
/concrete/elements/group/search.php
/index.php/dashboard/system/multilingual/setup/load_icon
/concrete/attributes/select/form.php
/index.php/dashboard/pages/single
3. The Open::update_registration_type() method implemented via /concrete/controllers/single_page/dashboard/system/registration/open.php source file fails to sanitize user supplied input received via the register_notification_email parameter, allowing remote attackers to execute arbitrary code using the sendmail program.
4. Multiple cross-site scripting (XSS) vulnerabilities exist because the following source files fail to validate user-supplied input received via banned_word, channel, accessType, msCountry, arHandle, design, pageURL, SEARCH_INDEX_AREA_METHOD, unit, register_notification_email or PATH_INFO parameters:
index.php/dashboard/system/conversations/bannedwords/success
index.php/dashboard/reports/logs/view
index.php/tools/required/permissions/access_entity
index.php/dashboard/system/multilingual/setup/load_icon, design/submit
index.php/ccm/system/dialogs/area/design/submit
index.php/dashboard/pages/single
index.php/dashboard/system/seo/searchindex/updated
index.php/dashboard/system/optimization/jobs/job_scheduled
index.php/dashboard/system/registration/open/1
index.php/dashboard/extend/connect/
Do they need to migrate to 5.7.4.1 in order to avoid these vulnerabilities, or do the vulnerabilities not exist in 5.6.3.3? If they do exist in 5.6.3.3 do they also exist in 5.6.3.4? If they exist in 5.6.3.4 are there any plans to patch them soon?
Thanks for your reply. C5 is pretty popular now, it just strikes me there must be other people achieving PCI compliance.
Against which concrete5 version have they run the tests?
The files and the paths in the test results seem a lot like 5.7.
C5 tries to constantly improve on its security, there have been e.g. a lot fixes regarding the XSS vulnerabilities at GitHub but of course as the project evolves, new issues may be introduced.
C5 also has a a profile at hackerone where people find out and report about possible security issues which are then solved at GitHub:
https://hackerone.com/concrete5...
There's also some possible vulnerabilities listed here (most of them for some legacy versions that are now fixed):
https://www.cvedetails.com/vulnerability-list/vendor_id-11506/Concre...
The best thing you can do is what John already mentioned above, to report these to GitHub. These particular issues should be reported to the 5.7 repository, as these relate to the 5.7 version.
I would asume such security issues would get quite high priority from the core developers if reported to GitHub.
The files and the paths in the test results seem a lot like 5.7.
C5 tries to constantly improve on its security, there have been e.g. a lot fixes regarding the XSS vulnerabilities at GitHub but of course as the project evolves, new issues may be introduced.
C5 also has a a profile at hackerone where people find out and report about possible security issues which are then solved at GitHub:
https://hackerone.com/concrete5...
There's also some possible vulnerabilities listed here (most of them for some legacy versions that are now fixed):
https://www.cvedetails.com/vulnerability-list/vendor_id-11506/Concre...
The best thing you can do is what John already mentioned above, to report these to GitHub. These particular issues should be reported to the 5.7 repository, as these relate to the 5.7 version.
I would asume such security issues would get quite high priority from the core developers if reported to GitHub.
Hi,
Thanks for the info. The website is 5.6.3.1 but the confusing thing is that the report is mentioning versions before 5.7.4.1 or 5.7.3.1 as issues. 5.6.3.4 came out in parallel with 5.7 releases so that's why I'm a little confused.
Thanks for the info. The website is 5.6.3.1 but the confusing thing is that the report is mentioning versions before 5.7.4.1 or 5.7.3.1 as issues. 5.6.3.4 came out in parallel with 5.7 releases so that's why I'm a little confused.
"Versions before 5.7.4.1 or 5.7.3.1"
This can only mean versions 5.7.0-5.7.3.1 or 5.7.0-5.7.4.1.
If it says "version before 5.7.X", it means these only apply to 5.7.
In 5.7 most of the core architecture was at least restructured and many parts were rewritten completely, so any test results for 5.7.X are not probably relevant regarding the concrete5 legacy version (5.6.X and earlier).
This can only mean versions 5.7.0-5.7.3.1 or 5.7.0-5.7.4.1.
If it says "version before 5.7.X", it means these only apply to 5.7.
In 5.7 most of the core architecture was at least restructured and many parts were rewritten completely, so any test results for 5.7.X are not probably relevant regarding the concrete5 legacy version (5.6.X and earlier).
Thanks, that sounds reasonable to me.
I suspect the only way for complete safety is to design a system that doesn't need PCI, such as the way eCommerce interacts with payment methods. The payment service suppliers need to be PCI, but eCommerce does not.
Some of the vulnerabilities listed may be imagined rather than real, in that they are only a problem if further software on the site uses those interfaces without performing its own input sanitization.
Putting that aside, the report you have posted makes interesting reading, so thank you for posting it. Perhaps you could cross post it as an 'issue' on github for both 5.6 and 5.7 and as a bug report on concrete5.org. That way, the points will become tracked against future core releases and hopefully at least some of them will be resolved.