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