Global Protect Saving User Credentials Security?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Global Protect Saving User Credentials Security?

L4 Transporter

After reviewing a few documents, I'm hearing that doing this is not a best practice....  If I choose to do so, does anyone know where those credentials are saved and how they are saved  in the agent on the endpoint? 

 

I'm guessing encrypted cookies are the way to get around this with longer validity times?

1 accepted solution

Accepted Solutions

I can only guess about the actual implementation so I assume everything is done correctly. We have two different methods: authentication cookie and safed credentials. Both methods store something encrypted on the client computer but only with the cookie you have control over the encryption key as you can choose an encryption certificate and this key is stored on the firewall. For encrypting the username and password a key is required too but about this key we know almost nothing (at least me). The only thing I know is that this encryption key is somehow available on the client computer as GP needs to decrypt username/password in order to send it in cleartext (over an encrypted connection) to the portal and gateway. Both of these encrypted blobs in theorie can be stolen from a device and used by an attacker to connect but if the attacker is able to decrypt the username and password he is able to do (in the case of domain credentials or credentials in general that are not only used for the vpn connection) even more when connected where this isn't possible with the cookie (even the decryption isn't possible as long as the attacker does not have already compromised your firewall).

--> So giving these facts my opinion is, it is more secure to use the authentication cookie instead of saving username/password on the device.

View solution in original post

13 REPLIES 13

L7 Applicator

theyy are saved and encrypted on the device under current user reg settings.

 

HKEY_CURRENT_USER\Software\Palo Alto Networks\GlobalProtect\Settings\LatestCP

 

Mac stuff is stored in local keychain.

 

we do not class username and password as an acceptable auth method, so not an issue or concern for us.

 

It must be a security concern if Palo is suggesting that this is not a best practice I'm guessing? But the encrypted cookie is a better "workaround" of sorts from saving the user from login prompts?

@Sec101 , Hi.

 

where have you seen this suggestion.  i have browsed the gen help files and can't see such advice.

I only ask because if it was a VPN access concern then why would they not suggest the same for SSO and certificate authentication as once you are logged into the device then access is available without adding further credentials.

 

or.. do they feel that they have not encrypted securely enough.....

 

 

i'm also wondering if this is more directed at OTP authentication as using the stored credentials would cause the gateway auth to fail every time.

 

 

 

 

best practices assessment tool is where I saw it.  You may be correct on this, as the reference for cookie auth does directly mention OTP. 

I wonder what the encryption settings are for storing the username/password, or if that is propietary?  I'm not sure I've read anything regarding this however.  Any further detail on how this is stored/secured on the endpoint?

well this is what it looks like...    so i assume this is not a ceaser cypher...

 

䱎䵌塮桹奔灮灊睷㕯汄㈫歱㑬婒佈偗浵ㅇ䑌䑉䝰㴴

ha.  Nice.  I wonder what it is?  Probably too picky, but am curious on it now....

well it's almost lunchtime over at washington DC so somebody will jump in with the answer, I know who it will be, but  lets see,,,,,

Bumping this post- to see if anyone else responds.  Are there benefits to using an ecrypted cookie, vs. flatout saving the credentials? If not, how does the agent save the user credentials on  the machine itself?  -I believe we've determined that if "save users credentials" is on- the users credentials are encrypted on the local machine in the registery, but how are they encrypted, and is that any better/or safter than using the encrypted cookie for auth bypass?

 

  I noticed there was just a warning out -Vulnerability Note VU#192371- about GP and other agents storing cookies insecurely, but i'm guessing if your using an encrypted cert for auth bypass- this shouldn't matter?

I can only guess about the actual implementation so I assume everything is done correctly. We have two different methods: authentication cookie and safed credentials. Both methods store something encrypted on the client computer but only with the cookie you have control over the encryption key as you can choose an encryption certificate and this key is stored on the firewall. For encrypting the username and password a key is required too but about this key we know almost nothing (at least me). The only thing I know is that this encryption key is somehow available on the client computer as GP needs to decrypt username/password in order to send it in cleartext (over an encrypted connection) to the portal and gateway. Both of these encrypted blobs in theorie can be stolen from a device and used by an attacker to connect but if the attacker is able to decrypt the username and password he is able to do (in the case of domain credentials or credentials in general that are not only used for the vpn connection) even more when connected where this isn't possible with the cookie (even the decryption isn't possible as long as the attacker does not have already compromised your firewall).

--> So giving these facts my opinion is, it is more secure to use the authentication cookie instead of saving username/password on the device.

That was the answer i was looking for.  WOW.   Thank you very very much!

Not sure if this will add to what you already know.. 

 

GlobalProtect does not store the credentials in the Registry, this may have been how it worked historically, but It changed sometime prior to v4.1.11, and several TAC engineers I've spoken with also thought this - But I know from experience this is not the case, after working on an AD Domain migration project, which required us to clear stored credentials on all endpoints as part of the migration process, we followed all the advise given from PA (and I spend hours on remote-sessions with TAC), but still, stored credentials remained!

 

In the end, I identified they were being stored in the Windows Credential Manager, stored under "gpcp/LatestCP", they did eventually confirm this, and I'm surprised this is still not commonly known. If you cannot see it using Control Panel->User->Credentials Manager, run the legacy Key and Credentials Manager from the CMD - rundll32.exe keymgr.dll, KRShowKeyMgr

running this cmd -

 

 rundll32.exe keymgr.dll, KRShowKeyMgr

 

I do not show mine stored, however, I'm not saving credentials either - only username.

  • 1 accepted solution
  • 24789 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!