CVSS Score

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVS Score: 9.9 (Critical)

Impact Summary

If the vulnerability is exploited, an attacker could write files to any location on the affected computer. This could be elevated to an RCE in a variety of ways depending on the environment and the operating system. This will be demonstrated later in this write-up.

Description

Impacket’s smbserver is vulnerable to Path Traversal Attacks. An attacker that connects to a running smbserver instance can list and write arbitrary files to any location on the attacked host (not just the chosen workdir for the server).
The reason for that is that while there is validation against relative paths in filenames in smbclient (and of course Windows Client), the Impacket SMB server implementation, smbserver does not validate it, which allows an attacker with an edited version of smbclient to exploit anyone who deploys an instance of smbserver.

Vulnerability Analysis

The following 2 lines take the filename path from the received SMB request and try to list its directory without making sure that the path is inside the intended working directory. This could enable an attacker to read the contents of the file system:

• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L3485
• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L876

The following 2 lines take the filename path and contents from the received SMB request and try write the contents to the received path without making sure that the path is inside the intended working directory. This could enable an attacker to arbitrarily write files:

• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L2008
• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L2958

Proof-of-Concept

To exploit this vulnerability, we have edited Impacket’s own smbclient.py to exploit its server implementation with 2 extra functions: do_ls_exploit and do_put_exploit. The functions do the exact same thing as do_ls and do_put (which is list directory and put file), only they do not sanitize the file paths on the client.
Since this is not enforced on the server, when combined with a path containing Path Traversal strings (../), these customized functions allow an attacker to read directories and write files anywhere on the file system.
Below are the differences between the two smbclient functions and their original counterparts:

Below is a Proof-of-Concept flow of the attack:

Creating a file for injection, connecting to a running smbserver instance (run locally for demonstration purposes) using the edited smbclient.py script and connecting to WORKDIR

Listing the directory contents (empty directory)

Listing /tmp using Path Traversal exploit

Injecting poc.txt and confirming using the exploit again.

CrackMapExec

Another tool that we found containing the same vulnerability is CrackMapExec. CrackMapExec (or CME for short) is a post-exploitation tool used primarily for offensive purposes and is heavily based on the Impacket library. We have found three attack modules that use the vulnerable smbserver which are: netripper, get_timedscreenshot and get_keystrokes. When an attacker attacks a victim with one of these modules, CME opens an smbserver instance in order to collect the results. As we’ve seen before, this could be exploited by a third party.

Proof-of-Concept

Exploitation of the get_timedscreenshot module of CrackMapExec using an injected PHP Webshell in /var/www/html.

Honeypots and Chameleon

Finally, we found two honeypot-based tools (used for creating intentionally vulnerable environments that act as tripwires for incoming attacks) called “honeypots” and “Chameleon,” which again contain the same vulnerability. “Honeypots” is a python library which contains 16 different honeypots (including Impacket’s smbserver) in a single PyPI package for monitoring network traffic.
Chameleon is a project from the same creators which features a GUI for handling multiple honeypots (imported from the “honeypots” library), which again contains the same vulnerability.

Proof-of-Concept

Exploitation of the “honeypots” smbserver using an injected SSH Key.

Recommendations

To avoid issues like this, update the Impacket package to the latest version.

Summary of Disclosure and Events

After notifying SecureAuthCorp, they informed us that they were aware that there might be possible vulnerabilities in the implementation, as can be seen by this 10 year old comment. Nevertheless, they did acknowledge the vulnerability and promptly accepted our fix. We would like to thank SecureAuthCorp for their fast response and continuous contribution to the security and research community.

Timeline of Disclosure

• Apr 20, 2021 – Disclosure
• Apr 20, 2021 – Issue acknowledged by SecureAuthCorp
• Apr 26, 2021 – Fix committed
• Apr 26, 2021 – CVE-2021-31800 assigned
• May 3, 2021 – Fixed version released
• June 16, 2021 – Public disclosure

Final Words

The research and resulting findings with Impacket serve as a valuable reminder that almost any piece of code that could be deployed in an organization must be tested regularly and made compliant, even if it does something as benign as serve some files via an SMB share. In this case, multiple tools that can be deployed by security experts in the company, either for testing or entrapment (honeypots), would actually be leaving themselves vulnerable.
Impacket is very popular amongst security professionals, and so are the derivatives uses of the vulnerable code within it. The Checkmarx Security Research Team is dedicated to performing investigations of this nature to better improve the security posture of tools and organizations more broadly.

Copyright Notices

Impacket

Copyright (c) 2000 The Apache Software Foundation.  All rights reserved.
This product includes software developed by SecureAuth Corporation (https://www.secureauth.com/)

CrackMapExec

Copyright (c) 2020, byt3bl33d3r All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Chameleon

Copyright (C) 2007 Free Software Foundation, Inc. https://fsf.org/  Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Honeypots

Copyright (C) 2007 Free Software Foundation, Inc. https://fsf.org/  Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

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.

What exactly are injection vulnerabilities?

Before going into a short explanation, first let’s discuss how abundant injection vulnerabilities are. For example, Injection has made the OWASP Top 10 for the most critical Web Application Risks in 2010, 2013, and 2017. Injection also made the list on the OWASP Top 10 for API Security in 2019 as well. Clearly, injection risks and associated attacks have been in existence for nearly 20 years and have often been the catalyst in many reported data breaches.

Injection vulnerabilities cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally involve data theft, data loss, data corruption, denial of service, etc.

According to OWASP Top 10 2017, “Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.” For more information on SQL injection and LDAP injection for example, Checkmarx provides detailed descriptions in our vulnerability knowledge base.

In light of nearly 20 years of widespread injection vulnerabilities, I asked our guest expert Inon Shkedy to provide his insight on a few questions as shown below. Inon worked closely with Erez Yalon, Head of Security Research at Checkmarx, on the OWASP API Security Project.

Together, they spearheaded the development of the OWASP API Security Top 10 2019, which defines the top ten most critical API security risks.

Guest Expert Interview

…
Question: Why is injection still making the list of Top Ten risks, and shouldn’t this problem have been remedied by now?
Inon:
There are two main trends in the field of injections:
On one hand, some types of injections become less and less prevalent, because of proper security education and a set of modern technologies which address them.
On the other hand, new frameworks and technologies open a door for new types of injections. For example, NoSQL injection is a relatively new attack vector for systems that use NoSQL.
These two trends make injections less severe and prevalent, but at the same time they still have a place on the list.

Question: What is the cause of developers writing injection vulnerabilities into the code they produce?
Inon:
There are a few main reasons:
Lack of awareness: it’s common to see junior software engineers writing code that is vulnerable. The “injection” concept may be not very intuitive for them, and they deliver vulnerable code because it’s the easiest / fastest way for them to implement a specific component.
Rush: we all know how stressful and demanding modern software development environments can be. Concepts like Agile and CI/CD are great for fast delivery, but when developers are focused only on delivering the code, they might forget to check for security issues.
Complexity: APIs and modern apps are complex. A modern app, like Uber for example, might look very simple from the UX (user experience) perspective, but on the backend there are many databases and microservices that communicate between them behind the scenes. In many cases, it’s hard to track which inputs come from the client itself and require more security attention (as filtering and scanning), and which inputs are internal to the system.

Question: What will it take to finally get developers to stop writing injection vulnerabilities into their code, and / or organizations releasing code with injection vulnerabilities?
Inon:
Raising awareness: I believe that secure coding is a result of education. It’s super important to raise awareness by providing security guidelines for new software engineers in the company and to have ongoing training, talks, and discussions about security.
Pre-production automation: use automatic tools like SAST and IAST to find injections vulnerabilities in your code before it gets exposed to the whole world.

Use ORMs: It’s harder to write vulnerable code when you use ORMs. They provide security mechanisms by design.

Conclusion

Clearly, injection flaws must be addressed during the software development process by first detecting them, then mitigating them by fixing the vulnerabilities. If applications with injection flaws make their way to the internet, it’s only a matter of time before they’re found by attackers, and are eventually exploited.