While working on troubleshooting and causing HIP check failures, with my lack of understanding on how the VPN works I did this : ( working with client version 5.2.6.87
Ok so I though if the client can’t submit a hip result is will be considered a failure ?, ( ok that’s what I would have expected ) but that was not the expected result.
What happens is if a client does make a least 1 successful connection, passed the HIP check it seems that the last result is cached somewhere on the firewall. So the client connects, with those rename files, firewall says hey this client is not running the HIP check, lets just let him pass as he connected before.
I reported this PA support a few months ago and I don’t know if they have fixed anything yet.
So you are saying the firewall will let you fail a hipcheck but still applies security policies that require a hip check? This is not something ive seen in my experiences.
If you write your rules properly to require HIP checks, it will fail until passes the checks. If you’re doing HIP you shouldn’t be allowing until fail, it’s the wrong way to be looking at security in general.
So you need local admin rights to do this , and it most likely only works until the cache times out. Additonalyll you haven’t said if they firewall has any rules with hip profiles checked against. So I can’t imagine that Palo support cares much this isn’t a high priority exploit/find.
Yet another needs root to attack a machine , oh look i have root so i can do anything kind of exploit.
Relies on multiple exploits to get a result that means you can disable some more protection on your end point.
There are a lot of false positives with HIPS. It’s far from perfect when you start to dig into it. Palo Alto needs to work on these checks. We tried to use it, but it gets things wrong, and misses stuff.
So I am not involved with the configuration / management of our firewall globalprotect settings I just happen to play around with the desktop software to understand how stuff works.
Local admin rights to do any of this, but if one of your client machine get compromised nothings is going to stop a client machine from connecting with malicious software running if a simple HIP bypass is possible
So after renaming the 3 modules I bump the pangps service , a bump of service and flushing of the logs and config elements :
I can reconnect to the VPN without running any of Hip checks, the binary file that support those operations not even present.
Upon my connection the PanGPS.log show some interesting entries :
- (P11880-T1392)Error( 123): 07/29/21 23:48:23:222 Failed to create process PanGpHip.exe [“C:\Program Files\Palo Alto Networks\GlobalProtect\PanGpHip.exe”], error code: 2 (The system cannot find the file specified.) (! Yeah I renamed the file you going to find it. )
- (P11880-T1392)Debug( 364): 07/29/21 23:48:23:222 Cannot find in hip report.
- (P11880-T1392)Debug( 335): 07/29/21 23:48:23:222 CheckHip over ( Ok as simple as that !)
and no logging for failures. The HIP logging is only for successes which is super NOT helpful. Years ago I opened a feature request for this in another company.
The company I am at now, we don’t even have a GP license so no way to do HIP checks. We only have maybe 15-20 laptops and 4 vpn vendors. So $30k for GP licenses is stupid.
If you’re not responsible for configuration then why are you here? How do you know that you for starters have a Gateway license, the appropriate not match HIP objects/profile and security policies that enforce HIP and there’s not an any allow rule and you simply aren’t matching the expected deny policies?
As far as I know nothing will stop you from connecting with or without HIP. As you have to connect to transmit the HIP info. The only thing you can do is enforce HIP checks on security policies to prevent traffic leaving the network.
We get ahead of this by creating hip object without really checking anything important. In HIP report then I check the parameters for other HIP objects, that’s are actually relevant.
I am just here because you guys are knowledgeable, and I thought someone else will try my experiment its not hard, and if its reproduceable due to a real product flaw, then the more customer request a fix the faster it will fixed.
If its just a configuration mistake on our part then we will be very grate full for finding that out. Looking at my last CC email with PA support to seen to acknowledge that the product had an issue.
Maybe that is something that has been added with newer features. Per PAN support at the time, the only way was in the CLI and it was a super pain to do. It was 2018 when I was last doing HIP check on GP. My PA rep a couple of years ago said the feature request I put in was still open. Both jobs since this 2018 don’t have GP licenses so no HIP checks.