Monday, August 11, 2014

SSLVPN portal is suspect for session inspection also

Somebody contact me offline about this earlier posting of mine ( http://socpuppet.blogspot.com/2014/08/your-fortigate-is-not-as-secured-as-you.html )   and ask me my thoughts about how secure is the fortigate  sslvpn portal from session sniffing.

Will I hate to say; " it's not secured as what we may think" and is vulnerable to the same issues as  indicated.

As in the earlier post, the private-key is accessible on all fortigate firewalls & by any administrator , & regardless of his roles. Unless you  prevented that person from having access to the file_systems, he has access to critical  certificate and private-key information. This would hold true to any https webserver also ( windows,apache,ngnix,etc...)

One of the earlier other question ask by a former colleague of mine; " how did I determine that the private-key  matches the  ssl website certificate "?

That's easy in the  /tmp directory  that we seen earlier, we only need to gather the certificate and the private-key and do a match comparison. This is a simple & trivial task to accomplish. Here's the most easiest way to do this;

1: Use the SSL cert/key matcher website located at the following URL;
https://www.sslshopper.com/certificate-key-matcher.html

Just paste the suspected certificate and private-key in the respective boxes.

i.e ( matching the  user_server.crt and user_server.key that gathered from the /tmp directory )


NOTE: The above shows the two are a match between certificate and private-key so we know the private-key that we have acquired is useable by that  particular ssl server.


2: The next method  is done by using  the common openssl  utility, and by comparing the modulus from the x.509 certificate and rsa key.


e.g ( matching a fortigate sslvpn portal certificate )



The last step; "  is now to pull the certificate from the "actual sslvpn portal" and compare it " to our findings.

( example1 using openssl  )

openssl s_client  -showcerts -connect x.x.x.x:10443

 (   example2 doing it realtime against a sslvpn portal server )



NOTE: As you can clearly see, the certificate matches the sslmatch website and we know the private-key is the correct private key for this certificate.

So when you put all of this together,  and we now capture SSLVPN portal traffic.  We will find that we can also decrypt this traffic just as easy as the firewall administration traffic.



I should mention few more options for reducing these types risks.


1: ensure that the clients are only using strong ciphers

You should use a test ciphers scripts or openssl for testing that your ciphers that the server offers. The clients will negotiate,  based on this offered listing and what that webrowser is  actually capable of. Most modern browser supports strong ciphers. ( IE9+, Firefox/Chrome, )


2: ensure the clients are using ephemeral session keys

This is known as PFS perfect forward secrecy.  I will speak more about this in the future and how all website should be using this. This is typically not in your control since you can't control the client's browser support and it's not 100% clear if all fortigate supports ephemeral sessions keys. You test cipher will show what ciphers it does supports.


3: Disable SSLVPN portal access in it's entirely

Okay not ideal, but if you remove the temptation, then you remove the risk per-se. I worked in  financial & banking sector for a  while , and that was one way we removed certain risks. 

Good CSO/CISOs would determine what risks if any with regards to forward facing application servers. And  than make a determination of allowing these types of access and by what means.


4: Setup a IPSEC access 1st access w/certificates, and then SSLVPN access portal server

Okay not easy to deploy, adds more complexity and still does nothing to prevents the capturing of HTTPS traffic if your private-key is compromised. This approach ensure the clients are encrypted with  a symmetrical encryption and then  path between   the IPSEC server to the  SSLVPN firewall is the only path at risk.  With the used of certificate based authentication, we can revoke an potential compromised clients machine or if the users leaves the organization.

NOTE: Ideally you could try to hack up a client-access that comes thru via IPSEC to the fortigate and then access to SSLVPN fortigate , but I never looked at what's all involved for accomplishing this .Maybe one day in the future I will stop being lazy and figure this out ;)


Conclusion




Now that we know our SSL traffic regardless of admin or sslvpn-portal , is exposed for session sniffing. The reason for bring these 2 posts up, is to ensure that you know your are not really secured.

If agencies like FBI/CIA/NSA  and other agencies both domestic or foreign,  has access to your data. Than you are potentially  exposed. This is regardless of a sslvpn firewall or a email business server.

What this means:


1: If PFS is not enable by some type  of ephemeral-key-creation, anybody that has access to the private-key has access to  you data ( period ! )

2: You have no control as to what an organization does with the private-keys for any SSL based services

3: A disgruntle employee could sniff your password or other  sensitive data, and sale this information off to the highest bidder

4: A IT security administrator could be bribed  or trick  with providing this data ( social engineering or lack of understanding SSL encryption & protection of the private-key  )

5: The government  demands via a "warrants or subpeona" access to the private-key for your system
( yes, this has happen do you trust your government ? )

6: A business organization uses  the private-server key for decrypting traffic for SSL deep inspection of content ( do you trust your external organizations?  google?yahoo? etc...... I sure as hell don't ! )

Keep in mind, without protection, a agency like NSA could capture your data today and  brute-force or gather the private-key later , and now have access to both ;  past , current and future data,  that used by that  private-key.

If you don't  believe me, just contact them and ask them ;)




Yes, just the merge fact that your sslvpn session was not secured with a strong crypto methods and lacks supports of ephemeral key generation. This means you are  Potentially compromised. And then you factor in that the private-key is readable by anybody who gains access to it.




One thing we should have learned from Eric Snowden, These peoples are not your friend;




For more scary reading do a "google" search on the  USA lead prism system and the goals of internet traffic capture & inspection.




Ken Felix
A NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com


   ^      ^
=(  $  $ )=
       o 
      /  \

No comments:

Post a Comment