Security Vulnerability

CVE-2021-31800: How We Used Impacket to Hack Itself

Omri Inbar — Wed, 16 Jun 2021 04:31:57 +0000

According to its official documentation, Impacket is a collection of Python classes for working with network protocols. Impacket is focused on providing low-level programmatic access to the packets for some protocols (e.g. SMB1-3 and MSRPC), and for others, the protocol implementation itself.
After investigating Impacket, the Checkmarx Security Research Team discovered a Path Traversal vulnerability, which could allow an attacker to write malicious files to any path on the target and achieve Remote Code Execution (RCE). This vulnerability, assigned CVE-2021-31800, was found not only in the Impacket library, but also in other tools that implement the vulnerable code such as CrackMapExec and “Honeypots.”

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:

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:

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.

cme

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.

honeypots

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

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

Honeypots

CVE-2021-33829: Stored XSS Vulnerability Discovered in CKEditor4 Affects Widely-Used CMS

Or Sahar — Mon, 14 Jun 2021 12:10:37 +0000

CKEditor 4 is a popular WYSIWYG editor, widely used in websites, web frameworks, and content management systems (CMS) such as Drupal and Backdrop. According to its website, the editor is “approved by millions, fully customizable, and the #1 rich text editor with the most features.” The Checkmarx Security Research Team discovered a stored cross-site scripting (XSS) vulnerability – assigned CVE-2021-33829 – that affects CKEditor 4 users in edit mode.

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

Click the source button in CKEditor 4
Paste the following payload:

Xss -->Attack

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

CVE-2020-9281 Fix With the Payload Above

Click the source button in CKEditor 4
Paste the following payload:

Xss-->Attack

Click the source button again to return to the regular editor

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

Click the source button in CKEditor 4
Paste the following payload:

Xss Attack

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

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

Edit a basic page
Click the source button in CKEditor4
Paste the following payload:

Xss Attack

Save the page
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

Click the source button in CKEditor4
Paste the following payload:

Xss Attack

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.

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

.
If the input contains a comment with an extra exclamation mark, like this
,
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 “- ->”.

The third element of the array that resulted from the regular expression processing is a comment.
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.
The browser identifies the suffix of the following input <- -comment – -!> as an error and mutates the input into proper html 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:

An attacker injects this payload

Xss -->Attack

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

Xss -->Attack

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

Xss -->Attack

The protectRealComments identifies the comment as protected comment and doesn’t encode its content.
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 -->Attack

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.

Drupal Core: Behind the Vulnerability

Dor Tumarkin — Thu, 19 Nov 2020 07:59:34 +0000

Earlier this year, the Checkmarx Security Research Team conducted an investigation of the new version of Drupal Core (Drupal 9) – a content management system (CMS) written in PHP – uncovering several interesting issues whose technical details are worth discussing openly.
This article covers the technical facets of CVE-2020-13663 that were made public by Checkmarx in June 2020, but whose details were never discussed publicly, and serves as part 1 of breaking down the vulnerabilities identified during our Drupal research. The issues outlined below were resolved by the Drupal security team shortly after we reported them.

CVE-2020-13663 – Overview

Drupal Security Risk: Critical – https://www.drupal.org/sa-core-2020-004
Vulnerable versions:

Drupal 7 – before 7.72
Drupal 8.8 – before 8.8.8
Drupal 8.9 – before 8.9.1
Drupal 9 – before 9.0.1

NOTE: This issue was also reported internally by Samuel Mortenson of the Drupal Security Team.

CVE-2020-13663 – Reflected DOM XSS in Rejected Forms

Vulnerability Proof of Concept (PoC)

The following code would recreate the issue on any vulnerable version of Drupal Core, so long as Basic Page functionality exists and URL rewrites are not altered. It will affect any user who is authenticated and has permissions to both add the page and use a Full HTML mode. Otherwise, values such as form “action” and form_id “value” may require alteration:

An authenticated user with HTML content creation permissions will observe the result of script execution:

While Cross-site Request Forgery (CSRF) mitigation prevents the form from going through and adding a new page, Drupal attempts to fail gracefully so that content that has been submitted is not lost because a security mechanism rejected it. A message is shown to indicate the form is rejected, but the user may still retrieve its contents from the form:

The posted content is reflected in the page to allow users to copy it to a valid form in a CKEditor view. The CKEditor view, like a Microsoft Word document, contains live elements such as images, figures, and more. These live elements are rendered HTML elements, which, in theory, could contain malicious code. While CKEditor does generally account for this by offering some protection against this type of DOM XSS and specifically strips script tags, the way it is configured on Drupal allows bypassing that by planting the script tags inside an iframe.

Vulnerability Breakdown

A reflected XSS vulnerability occurs when an attacker can provide values to a victim via a crafted URL or webpage, which, once interacted with by the victim, passes tainted parameters to a webpage in the user’s browser. If the user is authenticated, these scripts can then interact with the webpage from within the user’s browser, session context, and on the user’s behalf.
A DOM XSS implies the DOM itself, within the user’s browser, programmatically retrieves tainted values from within itself and populates the insecure page with these tainted values, essentially parsing HTML containing an XSS payload, or injecting Javascript into itself. Reflected XSS implies that the generated page contains user input from the request that prompted it. In this case, it is both:

User input is reflected in the expired form error page, and CKEditor then uses this payload to populate itself:

Note that this mutates the DOM somewhat; the script tag is removed from the iframe, and rendered right next to it.
The vulnerable forms here are the node/add/[type] and node/[node-id]/edit endpoints—when POSTing to these pages, with the correct parameters:

form_id parameter: e.g. node_article_form, node_page_form, which are the default form types
A parameter name to inject a value into: in both default cases here (“Article” and “Basic Page”), this is body[0][value], but generally, a CKEditor element can be derived from the field’s classes, e.g., text-formatted or field-type-text-with-summary to realize it is a component generated by CKEditor, and field-name-body to get the field’s name
Forcing format mode to “Full HTML” for the payload to trigger, e.g., body[0][format]; otherwise, this will simply be the current value, which could be restricted and block out the payload

Other variables for CSRF protection and expiry checks can be left out or left empty; the attacker cannot supply these, and when wrong or missing, will reflect the expired form and trigger the XSS.

Inject malicious code into webpages via Cross-Site Scripting to:
- Hijack user accounts
- Inject malicious web-content, such as malicious login or payment forms

Summary of Disclosure and Events

Once reported to the Drupal Security Team, they invited Checkmarx to their discussions on fixing these issues, and were very receptive to the report and subsequent analysis. The Drupal Security Team was quick to acknowledge the flaw and repair it.

Timeline of Disclosure

07-Jun-20 – Drupal Security Team notified of DOM XSS (CVE-2020-13663) via e-mail
09-Jun-20 – Drupal Security Team responds with invitation to consult on resolving this issue, as it was also internally identified by Samuel Mortenson of the Drupal Security Team
17-Jun-20 – Drupal Core new sub-versions release across all major version, mitigating CVE-2020-13663