Since Minecraft and their YouTube heroes are often more appealing to them than the online chess platform, they broke their promises more than once, and instead of doing something to improve their critical thinking skills playing chess, I found them listening to idle talks about gaming in general.

I felt like I had to find a way to ensure they were using their idle time wisely. But the question remained, “What is the best way to ensure my children only use lichess.org, which is the online chess game I have approved?” Knowing that other parents are likely facing the same challenges, I started researching a few options.

I tried using some browser extensions, but my 10-year-old figured out how to defeat that approach only after few minutes. So I was thinking, “Now what? Should I develop an internet filtering solution myself? Naaaah…” Instead, I began looking for another solution that would not be as easy to evade – something that someone else already created.

With the help of CTparental, which is an open-source project that allows parents to better control where their children go on the internet, I managed to block every website other than lichess.org. My children tried to get past the block I implemented, but after a while, they gave up. My children now play chess much more often and I am delighted about that.

Now as a responsible Application Security Researcher whose career is based upon researching applications to find coding errors, poor coding practices, exploitable vulnerabilities, etc., I wanted to make sure CTparental was safe and its protections are not easy to evade.

After doing some investigation on CTparental, I did find a few vulnerabilities. And I am happy to report that the project’s maintainer was a true professional and responded very quickly to resolve them. Since the vulnerabilities have been resolved, here are the exact details of what I found.  

Vulnerability #1 – Reflected XSS, CWE-79, CVE-2021-37365

In CTParental versions before 4.45.03, the file “bl_categories_help.php” is vulnerable to XSS.

CVSS Score

CVSS: 3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Score: 6.1 (Medium)

Vulnerability Impact

If a child had some level of ingenuity, they could potentially trick their parent into clicking a crafted link that sends the parent authentication cookie to a server under the child’s control and they would able to gain access to the parent admin panel.

Proof of Concept

To reproduce exploiting the vulnerability, enter the following link in the browser:

https://admin.ct.local/bl_categories_help.php?cat=<script>alert(`xss`);</script>

Cause of the Reflected XSS Vulnerability

At line 85 of bl_categires_help.php, the ‘categories’ variable is assigned with the content of the query string param ‘cat’ without sanitization or encoding, enabling an attacker to inject malicious code into the output webpage with echo in line 145.

083: if (isset($_GET['cat']))
084: {
085:     $categorie = $_GET['cat'];
086: }
087: 
.
.
.
137:    <div class="container">
138:             <div class="header clearfix">
139:                 <nav>
140:                     <ul class="nav nav-pills pull-right">
141:                         <li class="active" role="<?php echo "$l_close"; ?>">
142:                             <a href="javascript:window.close();"><?php echo "$l_close"; ?></a></li>
143:                     </ul>
144:                 </nav>
145:                 <h3 class="text-muted"><?php echo $categorie ;?></h3>

Even though I found the vulnerability manually, I scanned the CTparental lines of code using Checkmarx SAST. CxSAST easily detected this vulnerability as shown in the screenshot below:

Suggested Mitigation

In the context of secure coding practices, never trust the user input. Always sanitize or encode user input before further processing. The input should be encoded according to the context, from URL, from HTTP form, etc. A recommended solution, in this case, is to use a dedicated library that prevents XSS or a templating engine that does all the encoding under the hood.

Vulnerability #2 – CSRF, CWE-352, CVE-2021-37366

An attacker can trick an administrator into clicking a malicious link to a crafted web page in the child’s control that would add the attacker to a privileged group and cancel the filtering for herself and other users. By combining it with XSS, it’s possible to perform the same attack without an external webpage but entirely in CTparental admin panel.

CVSS Score

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

Score: 8.8 (High)

Vulnerability Impact

Again, if a child had some level of ingenuity, they could trick their parent into clicking a link to a certain web page. The webpage would run on the parent browser, redirect the browser to the CTparental admin panel, and cause a permission change. Combine this vulnerability with the XSS vulnerability, a child could save the effort of creating a web page, and instead, trick their parent into clicking a crafted link that changes their and/or any other user’s permission in the system and, as a result, cancel the desired filtering.

Proof of Concept

The following POC demonstrates the exploitation of both XSS and CSRF vulnerabilities. To reproduce it, enter the following link below into the browser. The link contains an XML HTTP request that sets the second user as privileged.

https://admin.ct.local/bl_categories_help.php?cat=<script>var xhr=new XMLHttpRequest(); xhr.open(“POST”, “https://admin.ct.local/index.php?dgfile=privileged%20group/”, true); xhr.setRequestHeader(“Content-Type”, “application/x-www-form-urlencoded”);xhr.send(“chk-2%3don%26choix%3dchange_user”); </script>

Cause of the CSRF Vulnerability

The code at line 21 in file gctoff.php generates a form that updates the gctoff.conf without validating that the HTTP POST request is from an authenticated admin panel. (i.e., lack of anti-CSRF protection)

21:     echo "<form action='".$_SERVER["PHP_SELF"]."?dgfile=privileged group' method='post'>";
22:     echo "<input type=hidden name='choix' value="gct_Off">";
23:     echo "<input class='btn btn-success' type=submit value=".gettext('Disable privileged group.').">";
24:     echo "</form>";

Suggested Mitigation

Critical actions like adding a user to the privileged group should be protected against CSRF. The application should utilize anti-CSRF protection, such as synchronizer tokens. For more information, check the following link:

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Vulnerability #3: Code Execution, CWE-94, CVE-2021-37367

Because The file “bl_categories_help.php” is vulnerable to directory traversal, an attacker can create a file with a name that contains bash scripts and run arbitrary OS commands.

CVSS Score

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

Score: 7.8 (High)

Vulnerability Impact

Finally, if a child had some level of ingenuity, they could create a file with a name that contains OS commands and craft a link that traverses to this file and runs an OS command with www-data OS user permission.

Proof of Concept

The attacker has a user on the CTparental machine, and they create a file with the following name:

/tmp/ 1;whoami;#.conf

The attacker clicks the following link:

https://admin.ct.local/bl_categories_help.php?cat=../../../../../../..//tmp/1;whoami;%23

We used the whoami command as a proof-of-concept, but it could be any arbitrary OS command, thus giving an attacker control over the server with www-data user privileges.

Cause of the Vulnerability

The code in the bl_categories_help.php file does not validate that the file from the ‘cat’ query string param is one of CTparental’s configuration files, allowing an attacker to pick up a configuration file of their choice. Later, the code concatenates the file name with an exec command without sanitization or escaping.

83: if (isset($_GET['cat']))
84: {
85:     $categorie = $_GET['cat'];
86: }
87: 
88: $bl_categorie_domain_file = $bl_dir.$categorie.".conf";
89: $ipv4_categorie_domain_file = $ipv4_dir.$categorie.".conf";
90: $ipv6_categorie_domain_file = $ipv6_dir.$categorie.".conf";
91:
92: if (file_exists($bl_categorie_domain_file))
93: {
94:     $nb_domains = exec ("wc -w $bl_categorie_domain_file|cut -d' ' -f1");
95: }
96: else
97: {
98:     $nb_domains = $l_error_openfilei." ".$bl_categorie_domain_file;
99: }

CxSAST easily detected this vulnerability as well as shown in the screenshot below:

Suggested Mitigation

Never trust the user input and concatenate user input to an exec command. Always sanitize or encode user input before further processing. The input should be encoded according to the context, from URL, from HTTP form, etc. In this scenario, check that the requested file matches one from the allowed list of the CTparental configuration files.

Timeline of Disclosure

July 12, 2021 – Disclosure to CTparental

July 14, 2021 – release 4.45.03, mitigating the XSS and CSRF

July 22, 2021 – release 4.45.07, mitigating the OS Command execution

August 10, 2021 – CVE-2021-37365, CVE-2021-37366, CVE-2021-37367 assigned

August 19, 2021 – Public disclosure

Conclusion

I’m delighted to have discovered and helped resolve these issues, to not only protect my children, but other children as well. Again, the maintainer of the CTparental project was a pleasure to work with and they should be commended for their due diligence.

I’m also satisfied when I use my skills and experience to increase security for all parents who may use CTparental or other similar tools. In doing so, I had the chance to research, report, and contribute to the safety of children world wide.

This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in secure coding practices for those who contribute to open source projects, and in doing so, improve security for everyone overall.

Impact Summary

CKEditor 4 is commonly used and may affect a variety of environments, such as blogs, content management systems, and other websites that accept rich text content from users. Successful exploitation of the vulnerability leads to arbitrary web script injection. The impact depends on where the plugin is used. It may lead to account takeover, credential stealing, sensitive data exposure, etc.
When we found the vulnerability in CKEditor 4, we informed the maintainers. They didn’t initially consider our finding as a security issue, but released a new version with the fix (4.16.1). We continued our research and found that Drupal and django-ckeditor are vulnerable to XSS because of the issue we found. We informed both, and they pulled the CKEditor 4 version 4.16.1.
From here, we asked MITRE to issue a CVE because we strive to inform all CKEditor 4 dependents to get the CKEditor 4 latest version. Later on, CKEditor 4 realized the significance of our finding took the responsibility to issue CVE-2021-33829.

CVSS Score

CVSS: 3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Score: 6.1 (Medium)

Description

In June 2020, CVE-2020-9281 was published due to a cross-site scripting CKEditor 4. The cause for this issue is in the HTML data processor that doesn’t sanitize a payload that contains the reserved ck_protected keyword.
The reserved  “cke_protected” keyword is used internally by CKEditor 4 developers. It is an HTML comment that’s content is encoded. For simplicity, we’ll use the term ‘protected ‘comment’ in this blog.
The CKEditor 4 developers’ solution was to ensure there are no externally injected protected comments before parsing by removing instances of the protected comment. Since the keyword is only removed once, nesting the keyword yields the keyword (e.g., keykeywordword -> keyword). This allows an attacker to bypass this protection mechanism and exploit the XSS vulnerability, which was assumed to be fixed.

Original Proof-of-Concept for CVE-2020-9281

1. Click the source button in CKEditor 4
2. Paste the following payload:

Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)> -->Attack

3. Click the source button again to return to the regular editor.

CVE-2020-9281 Fix With the Payload Above

1. Click the source button in CKEditor 4
2. Paste the following payload:

Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)>-->Attack

3. Click the source button again to return to the regular editor

Proof-of-Concept of the Flawed Fix of CVE-2020-9281

1. Click the source button in CKEditor 4
2. Paste the following payload:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

3. Click the source button again to return to the regular editor.

Proof-of-Concept of the Flawed Fix of CVE-2020-9281 in Drupal

1. Edit a basic page
2. Click the source button in CKEditor4
3. Paste the following payload:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

4. Save the page
5. The following user that edits the same page is exposed, as demonstrated in the screenshot below:

Proof-of-Concept of the Flawed Fix of CVE-2020-9281 in django-ckeditor

1. Click the source button in CKEditor4
2. Paste the following payload:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

3. Click the source button again to return to the regular editor or click the save button

Vulnerability Analysis

The htmldataprocessor’s removeReserveKeywords function aims to ensure there are no externally injected protected comment keywords before parsing.  However, it fails to remove instances of the protected comment recursively.

1. The removeReserveKeywords removes instances of the protected comment keyword.
2. The parse method splits to elements array what is left from the payload using a regular expression.
3. The regular expression identifies comments with the following structure

<!--Comment -->.
If the input contains a comment with an extra exclamation mark, like this
<!--comment --!>,
the regular expression does not consider the – -!> suffix as a closing tag of the comment and treats the rest of the input as a comment until a proper closing suffix appears, like this “- ->”.

4. The third element of the array that resulted from the regular expression processing is a comment.
5. The protectRealComments encodes the third element of the array if it considers it as a real comment. In a case of a nested protected comment, the protectedRealComments input contains a protected comment. For that reason, the protectedRealComments doesn’t encode it.
6. The browser identifies the suffix of the following input <- -comment – -!> as an error and mutates the input into proper html comment: <!- -comment – ->. The remainder of the payload stays out of the html comment unencoded.

When the algorithm processes the new Proof-of-Concept, the following occurs:

1. An attacker injects this payload

Xss<!--{cke_{cke_protected}protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

2. The removeReserveKeywords removes the {cke_protected} and what is left from the payload is:

Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

3. Since –!> is not treated as a comment end tag , the CKEditor4 parse method considers the whole highlighted text as a protected comment

Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

4. The protectRealComments identifies the comment as protected comment and doesn’t  encode its content.
5. The browser mutates the payload, and the exclamation mark is removed. Because of that, the comment is closed, and the rest of the payload remains unsanitized, with the ineffectual closing comment at the end.

Xss<!--{cke_protected}--><img src=1 onerror=alert(`xss`)> -->Attack

6. The browser runs the unsanitized img onerror event

Recommendations:

The fix for this issue has been released, and it is highly recommended to update CKEditor 4 and Drupal to the latest available version. Regarding CKEditor, moving to CKEditor 5 is also an option.
While CKEditor 5 exists, CKEditor 4 is still maintained because they are not entirely alike. CKEditor 5 doesn’t have an out-of-the-box source button for freestyle HTML coding. It’s possible to achieve the source button functionality by developing a plugin or consuming a plugin of third parties.

Timeline of Disclosure:

April 28, 2021 – Disclosure to CKSource

May 18, 2021 – Disclosure to Drupal

May 20, 2021 – CKEditor4.16.1 release, mitigating the vulnerability

May 26, 2021 – Drupal 9.2 release and security advisory mitigating the vulnerability

May 26, 2021 – Backdrop CMS (a fork of Drupal) 1.19.1 release and security advisory mitigating the vulnerability

May 29, 2021 – django-ckeditor 6.1.0 release, mitigating the vulnerability

June 03, 2021 – CVE-2021-33829 assigned

June 14, 2021 – Public disclosure

Conclusion

This type of activity is part of the Checkmarx Security Research Team’s ongoing efforts to protect the software supply chain. Once the Checkmarx Security Team reveals a vulnerability in a package or a component, we immediately inform and help the maintainers mitigate the vulnerability. We also warn CxSCA customers if they use the vulnerable solution. Once the maintainer releases a fix, Checkmarx customers are the first to know.
No matter how a code is secured, using third party components exposes websites, services, and other software solutions. Therefore, it’s extremely important to mitigate vulnerabilities in widely used components and protect the supply chain.