On April 12th I saw that paloaltonetworks has aSecurity Notice(^1), the CVE number is CVE-2024-3400, the vulnerability is a command injection, and the affected versions are as follows:
Then during the recurrence process, I discovered watchTowr Labs(^2) I have already sent their analysis, so let’s follow their analysis and learn about this hole. Here I mention that my reproduction version is 10.2.9
Environment setup
As mentioned in the vulnerability notice (^1), the impact of this vulnerability requires PAN-OS to configure GlobalProtect portal or GlobalProtect gateway, so we need to completely set up our environment first.
Let me briefly talk about the configuration process. My configuration here is based on the environment configuration of the QWB S6 Final Pan topic (luckily I can still find the virtual machine for this topic). In addition, I would like to mention the CVE-2021-3064 exploited by the Qiangnet Cup at that time. This loophole is quite interesting.
First, my virtual machine has three network cards,
Network card 1 is the management port, and network card 2 is intended to be used as the network segment of the portal and gateway. The network segment I use here is 192.168.100.1/24.After logging in to the backend of the management port, set the
NETWORK->接口Set the Ethernet interface, set the interface type to Layer 3, and set the static IP of IPV4
DEVICE->证书管理->证书generateRootCertbased onRootCertDistribute onegp_cer
DEVICE->证书管理-> SSL/TLS 服务配置文件in accordance withgp_certConfigurationSSL_PROFILE
- then to
NETWORK->GlobalProtect->门户Configuring the portal, there may be something missing in the middle. I will post my configuration items here. Just make up for whatever is missing.
NETWORK->GlobalProtect->网关The gateway configuration is similar.
Then now in another virtual machine, set up the same 192.168.100.1/24 network segment network card, and you can access the portal.
Since there is no so-called device certificate, this vulnerability can command the execution of the mentioned telemetry Function is unavailable
access https://192.168.1.101/ssl-vpn/hipreport.esp that is https://192.168.1.101/ssl-vpn/hipreport.esp return
The shell and file system were obtained directly using the method provided by Larryxi(^3) during QWB at that time.
- patch vmem gets local shell
sed -i "s/\/usr\/local\/bin\/cli/\/\/\/\/\/\/\/\/\/\/\/\/bin\/sh/g" PA1029-9aad9851.vmemsed -i "s/admin:x:1001:1004/admin:x:0000:0000/g" PA1029-9aad9851.vmem
- To view the firmware content, just mount vmdk
j
1
2
3sudo modprobe nbd
sudo qemu-nbd -c /dev/nbd1 /mnt/hgfs/qwb-final/PA-disk1.vmdk
sudo mount /dev/nbd1p2 /mnt/panos/
OK admin After the user logs in, there is a shell with root permissions. Later, you can also use ssh to log in for debugging and the like.
Vulnerability analysis
The trigger path of the vulnerability has been mentioned in the (^1) article. First of all, gpsvc The file will have an arbitrary file written when processing the Cookie field, followed by telemetry Functional scheduled tasks device_telemetry_send will use /usr/local/bin/dt_send When sending data, the file name will be spliced into the command, causing command injection.
Let’s briefly analyze it in turn
gpsvc arbitrary file writing analysis
pass netstat command, we can see gpsvc Listening on port 20277,
Viewing /etc/nginx/sslvpn/localtion.conf In the configuration file, we see the following configuration
You can see that some interfaces related to ssl-vpn are forwarded to port 20177 through the nginx proxy, which is processed in the gpsvc program.
Reverse analysis
We took out the program to analyze. The bad news is that this program is written in golang and seems to have symbols. Moreover, we already know the approximate location of the vulnerability, which can be found directly by main__ptr_SessDiskStore_New function
In this function we can see an operation that uses the value in the cookie and then concatenates the file name.
For example, we set a breakpoint at line 146, and then trigger it using the following PoC:
1 |
curl -i -s -k -X $'POST' \ |
arrivemain__ptr_SessDiskStore_New The backtrace of the function is as follows:
1 |
(gdb) bt |
At this point you can see $rdi->array Stores the relevant characters of our payload: session_/../../../tmp/hackedwe walk step by step until we callmain_loadSessFile function location
(After analyzing this, I suddenly realized that it was an old version of golang API call. After searching the string, I found that his golang version was 1.13.15)
1 |
.rodata:0000000000C956F6 aGo11315 db 'go1.13.15' |
can be seen /../ Related characters arepath_filepath_JoinThe function has been removed after processing. The question arises, where was the file created?
we found syscall_Open function, perform a reference search on it, and find such a call chain
1 |
main_loadSessFile->main_fileLock->syscall_Open |
And at this time main_loadSessFile The parameter is the file we want to create
open is defined as int open(const char *pathname, int flags, mode_t mode); The second parameter is flags. When the value is 0x40, it is O_CREAT
O_CREAT defined at fcntl.h file, which can be seen in the linux kernel code (^4),
1 |
#define O_ACCMODE 00000003 |
O_CREAT The value is usually 0100, which is an octal value, equivalent to 64 in decimal and 0x40 in hexadecimal. Find relevant information (^5)
It is found that the file will only be created if the file does not exist.
For example, use the following payload to try to create /etc/passwd when
1 |
curl -i -s -k -X $'POST' \ |
You can see that open returns 0
This vulnerability creates a file with an arbitrary path and a controllable file name (the file cannot be overwritten). So how did the attacker combine such a vulnerability into a command for execution?This must be mentioned telemetry Functional
telemetry command file analysis
According to the official website (^5), this function is a function that regularly sends data to the remote end.Environment setupTurning on the mentioned function requires a device certificate, which is not supported in my current reproduction environment.We can only analyze the analysis function
exist /etc/cron.d You can see a lot of and telemetry Related scheduled tasks
in /usr/local/bin/dt_send It seems to be used to send data
This program is written in python. You can see that it simply determines whether the function is enabled, and then calls check_and_send function
check_and_send The function will then be called send_file_dirs_all
can be seen send_file_dirs_all The function will traverse DEFAULT_DEVTELEM_OUTPUT_DIR file, and then call send_file_dir
And in send_file_dir In the function, use send_file function
exist send_file In the function, the file name will be spliced into send_file_cmd Traversing
Then call cmd_status = techsupport.dosys(send_file_cmd, None) run dt_curl command, which is also a python program,
dt_curl will be called send_file function
In this function, you can splice the commands using pansys(curl_cmd, shell=True, timeout=250) Function call, pay attention here shell=True
The last call here is /opt/plugins/2.0/python-lib/pan/pansys/pansys.py in the file dosys
You can see it hereshellThe parameter defaults to False but becausesend_file The call is passed in and set to True, so command injection is possible.
Diff Patch
Added a new seesion check function?
From the log, you can see that a check has been added {"level":"error","task":"3-22","time":"2024-04-20T06:28:12.18264473-07:00","message":"ArgFilterCheck: authcookie input is invalid"}
It happens to be what this patch added, judging from the compilation path
1 |
(gdb) bt |
fixed shell=True The problem
think
An empty file is created until the command is executed. The attacker must have spent a lot of time looking for this function. In addition, the exploitation of this vulnerability currently needs to be enabled.telemetry function, so is there any place that can be created using this empty file?There may be such a large system. If you have time, you can take a closer look.
Reference link
(^1): CVE-2024-3400 https://security.paloaltonetworks.com/CVE-2024-3400
(^2): palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400 https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
(^3): Larryx's blog https://aslr.io/about/
(^4): fcntl.h#24 https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/fcntl.h#L24
(^5): device-telemetry-overview https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/device-telemetry/device-telemetry-overview
GIPHY App Key not set. Please check settings