SSD Advisory – Kerio Control Authentication Bypass and RCE

Summary

An analysis primarily of Kerio Control revealed a design flaw in the implementation of the communication with GFI AppManager, leading to an authentication bypass vulnerability in the product under audit. Once the authentication bypass is achieved, the attacker can cause the execution of arbitrary code and commands.

Credit

An independent security researcher, z3er01 of zeronvll, working with SSD Secure Disclosure.

Vendor Response

The vendor has issued a fix for this vulnerability, customers affected by this vulnerability should upgrade to GFI Kerio Control version 9.5.p1 or newer.

Affected Versions
  • Kerio Control version: 9.4.5 build: 8526
Technical Analysis

The conducted audit revealed that an unauthenticated user, with access to the Kerio Control Proxy Server, can bypass the authentication mechanism and gain root access to the system. The vulnerability responsible for this bypass is related to the GFIAgent service.

GFIAgent is a software component that is pre-installed by default on the Kerio Control appliance (from 9.4.3 version), functioning as a monitoring and management agent. It collects and transmits system status and configuration information, enabling communication with GFI AppManager, a centralized platform that allows administrators to monitor and manage multiple Kerio Control devices from a single interface. “GFIAgent” facilitates operations such as remote configuration, performance analysis, and software updates.

The service in question exposes multiple ports (7994, 7995, 7996, 7997), each serving a specific web server with a designated purpose. For the purposes of reproducing the scenario, only the web services exposed on ports 7995 and 7996 will be considered.

The web servers on ports 7995 and 7996 do not require authentication for interaction. Specifically, the server on port 7996 only requires the Appliance ID (UUID), which can be retrieved without authentication through the service on port 7995.

Unlike the other services, port 7996 is accessible across all interfaces. Therefore, if the appliance has an inbound firewall rule allowing access to this port, authentication can be bypassed without exploiting further vulnerabilities. However, it is important to note that on Kerio Control appliances, such firewall rules are typically not necessary and are unlikely to be configured. Indeed, searches using tools like Shodan and Censys revealed that very few Kerio Control appliances expose port 7996 (although several Kerio Connect appliances do).

As a result, to bypass authentication, an additional vulnerability is leveraged through the default-enabled “non-transparent proxy” service, which operates on port 3128.

This proxy is used to monitor and filter web traffic, and it does so without the need for the client devices to be reconfigured. When enabled, all traffic directed to the firewall is processed through the proxy server, which can filter and log HTTP, HTTPS, and FTP traffic.

The Proxy Server in Kerio Control enables the forwarding of requests to local appliance ports, which can allow access to internal services like GFIAgent (7996), even in the absence of inbound firewall rules that would grant access to these service.

To estimate the number of appliances exposing the proxy server to the internet, Censys was used. Censys identifies 291 hosts exposing the service. However, this number likely represents only a portion of the total instances. Given the customizable port configuration of the service, it is reasonable to assume that additional hosts are reachable on alternative ports, additionally, due to the nature and purpose of the proxy server, it is estimated that a substantial portion of appliances allow access to services by users and systems within the network.

In conclusion, an external actor (if appliances within the network expose the service) or an internal actor within the Kerio Control network can exploit a combination of these two vulnerabilities to bypass authentication controls and gain administrative access to the appliance. Additionally, an issue related to the product’s update functionality allows the upload of a modified system image, enabling root access or, more broadly, the ability to upload any modified image to the appliance.

Laboratory Analysis Setup

To replicate the scenarios and findings detailed in this report, an overview of the test lab used during the audit activities is provided.
This overview is not to be considered a real-world scenario and/or product configuration but merely as a laboratory setup employed to test and reproduce the findings.

Laboratory Layout Diagram
Laboratory Description
Laboratory
  • VMware® Workstation 17 Pro: version 17.6.1 build-24319023
  • KerioControl: version 9.4.5 build 8526
Installation and Lab Configuration
  1. Download the product VMX Version from: Download link
  2. Extract and save the *.vmx and *.vmdk files in a work folder.
  3. Open with VMware Workstation the *.vmx file. (File > Open > work folder > *.vmx)
  4. Configure Network Adapter (Settings > Network Adapter)
    a. In the setup used (NAT subnet 192.168.234.0/24 DHCP enable).
  5. Start the Kerio Control Guest Machine.
  6. On the kerio-consolepress enter to access console.
  7. Press Enter on “Network Configuration” and check the ip address or configure the interface.
  8. On kerio-console go to “Remote Administration” and modify traffic policy to reach the Administration Panel on :4081. (Press F8 con confirm).
  9. Go to Administration Panel and initial configuration of the product.
  10. After initial configuration login to *:4081/admin/
  11. Add a Traffic Rules to reach the Proxy Server
    b. “Traffic Rules > Add
    c. “Services > Port (TCP 3128) – OK
    d. Apply

Enable SSH\
The enabling of the SSH service is not required for exploitation or for reproducing the activities performed; it is mentioned here only for completeness and in case it is useful for verification and conducting further analysis.

  1. At kerio-console press: Alt + F2
  2. Login using the username root and the password set during the initial configuration.
  3. Edit the /etc/default/ssh file by changing the key-value pair RUN_SSHD=no to RUN_SSHD=yes.
  4. Make the filesystem writable using the command: mount -o remount,rw /.
  5. Modify the /etc/ssh/sshd_config file to disable public key authentication and enable password authentication.\
    a. PubkeyAuthentication no
        PasswordAuthentication yes
  6. Reboot the system.
  7. Add a firewall rule to allow access to the SSH service through the VMware network interface.\
    a. Login to Console Administration (*:4081/admin/)\
    b. “Traffic Rules > Add\
    c. “Services > Port (TCP 22) – OK\
    d. Apply
Vulnerabilities
Server Proxy Permit Access to GFIAgent

The proxy server allows the forwarding of HTTP requests to internal or non-exposed services of KerioControl, bypassing firewall rules and enabling authentication bypass

Description

By default, the initial configuration of Kerio Control enables the non-transparent proxy service, which is exposed and reachable on TCP port 3128. In order to interact properly with this service, appropriate firewall rules must be configured using the “Traffic Rules” functionality (see: Installation and Lab Configuration).

The Proxy Server allows requests to be forwarded to internal services on the appliance’s localhost and/or other network interfaces.

Therefore, it is possible to force access to internal services through the proxy server, including the GFIAgent service. (Local services can be accessed via 127.0.0.1, localhost, or control).

Proof of Concept
cURL
curl http://localhost:7995/appliances --proxy http://192.168.234.128:3128/
HTTP request
GET http://control:7995/appliances HTTP/1.1
Host: 192.168.234.218
Connection: close
Missing Authentication in GFIAgent

The GFIAgent service, responsible for communication with GFI AppManager to remotely control the appliance (in the cloud), lacks adequate authentication, allowing unauthenticated execution of any request that can be performed via the administrative web portal (*:4081/admin/*).

During the analysis of the GoLang binary for the GFIAgent service, it was found that requests handled on ports 7995 and 7996 do not implement any authentication mechanism. However, the service listening on port 7996 (github.com/trilogy-group/gfi-agent/servers.RemoteServe) requires the presence of the app-id header (a UUID identifying the appliance) within the requests. It is important to note that the value of this identifier can be easily retrieved through the :7995/appliances endpoint.

In detail, inspection the github.com/trilogy-group/gfi-agent/servers.(*RemoteServer).RegisterHandlers code it is possible to note a registration of /proxy path.

The logic of /proxy handler is implemented in github.com/trilogy-group/gfi-agent/servers.(*RemoteServer).RedirectToAppServer, which “to semplify“, forwards incoming requests to the *:4081/admin/ endpoint. Allowing to call, for example: admin/api/scim/v2/Users, /admin/api/jsonrpc/ ecc…

This configuration effectively allows external users with access to ports 7995 or 7996 of the GFIAgent service to issue requests to the appliance with administrative privileges, bypassing authentication entirely.

It is important to note that many other endpoints within the GFIAgent service enable administrative actions, though they are not covered in this document.
For instance, it might be possible to deregister the appliance (if already registered with AppManager) using the :7995/register-cancel endpoint. Additionally, the :7995/register endpoint could allow retrieval of the public key or, more broadly, the URL required to register the appliance with a GFI AppManager account.

Proof of Concept
  1. Retrieving of appliance Id:
    sh curl http://localhost:7995/appliances --proxy http://192.168.234.128:3128/
  2. Make administrative requests in unauthenticated manner:
    sh curl http://192.168.234.128:7996/proxy/admin/ -H 'app-id: <ApplianceId>'
Missing Validation of System Image Authenticity during Upgrade

The system does not adequately verify the authenticity and integrity of the uploaded image during appliance upgrades, potentially allowing the upload of a tampered or modified image.

Description

The Kerio Control appliance upgrade functionality allows the upload of modified system images.

It is possible to retrieve the original upgrade image from:
http://download.kerio.com/archive/ – https://cdn.kerio.com/dwn/control/control-9.4.5-8526/kerio-control-upgrade-9.4.5-8526-linux.img.

The downloaded *.img file is a compressed gzip POSIX TAR file. The TAR file contains configuration files and the upgrade script (upgrade.sh), the disk image (part2.img), and GRUB components.

It is possible to modify the kerio-control-upgrade-9.4.5-8526-linux.img file by correctly following the steps for decompression, writing, copying, and recompressing. This allows for the insertion of code into the upgrade image that could later provide persistent access to the appliance after the upgrade process is completed.

Proof of Concept
  1. Decompress kerio-control-upgrade-9.4.5-8526-linux.img file
    sh gzip -d kerio-control-upgrade-9.4.5-8526-linux.img --suffix=.img
  2. Extract content of TAR archive
    sh tar -xvf kerio-control-upgrade-9.4.5-8526-linux
  3. Modify the content of upgrade.sh script for example.
  1. Remove the original upgrade.sh script
    sh tar --delete -f kerio-control-upgrade-9.4.5-8526-linux upgrade.sh
  2. Add the modified upgrade.shscript to tar archive
    sh tar -rf kerio-control-upgrade-9.4.5-8526-linux upgrade.sh
  3. Recompress the TAR archive with gzip
    sh gzip -c kerio-control-upgrade-9.4.5-8526-linux > kerio-control-upgrade-9.4.5-8526-linux_modfied.img
  4. Upload and start upgrade of modified img file
  1. Confirm on the KerioControl appliance the correct execution of added code.
Chain Scenario

By concatenating the vulnerabilities reported within this document, it is possible to achieve arbitrary code execution on the target system. In short, requests can be forwarded to the ports exposed by the GFIAgent service. The GFIAgent service, in turn, allows forwarding requests to the “administrative portal” of Kerio Control via the /proxy handler, Which lacks proper authentication. Once access to the system with administrative privileges is gained, a modified image can be uploaded, thereby providing remote and persistent access to the appliance as the root user.

?

HOME
THE
COMMUNITY
SCOPE
ADVISORIES
SUBMIT
CONTACT

?

Get in touch

Skip to content