Your fortigate is not as secured as you think, when it comes to HTTPS

In this blog, I will show you a simple means on how someone who has access to a fortigate, can actually sniff your encrypted session  traffic by grabbing the private-server key. We will use the hidden command fnsysctl , and  use tshark  on a unix host to accomplish our hacking. You can also execute this via wireshark btw.


1st Let's look at where the key is stored. The local directory /tmp has quite a few cool stuff. Mainly keys :). Why fortinet choose to place a security item like private-key for HTTPS in this directory; " is mind boggling to say the least"

fnsysctl ls /tmp/

NOTE: I circled the  server-side private key and pointed out the  certificate. We only need the  key btw.


Okay so now we know where the key is. We will grab that key and installed it on our unix host. Now all we need to do is to capture https traffic to the fortigate. In my case, I'm writing a packet capture by using the expression.

(on my macbook air )
tcpdump -w http1.pcap -s 1500 -i en4

Okay, now that we have a packet capture, we now only need to  decode the https traffic using the private-key we grabbed earlier  from the /tmp directory.

(on my linux forsenic host that we will use to de-encrypt the traffic )

 tshark -o "ssl.keys_list: x.x.x.x,443,http,./server.key" -r http.pcap  -R http  -V > myblog

The x.x.x.x would  equal your fortigate ip_address

( results )

Okay here's a screen capture of the HTTP header from the POST with the username credentials from  the packet-capture from above. I sanitized the ip_address for security reasons.

Okay here's a screen capture of the HTTP header from the POST with the username  we created and his password.

Okay now that you see the fortigate is weak,  and is very in-secured from password grabbing. And let me remind you ; " this is appliance from a major security vendor ".

Okay now I will show you some ways to reduce this risk


1: define trusted hosts for users logins

Yes this will not keep some one from sniffing the password , but  would reduce from where they can login  from to begin with

2: reduce the number of "admin" or "super-user accounts"

Once again , does nothing from preventing someone from  sniffing the password

3: reduce the number of interfaces that has the set allowaccess  https  enabled 

Once again does nothing from preventing a person from sniffing the traffic and from gaining the password. This just restricts the number of interfaces that are exposed.

4: You can reduce this risk by deploying SSH only access 

Yes that would suck to have to configure all items via CLI on a firewall appliance with a WebGUI.


NOTE: installing  a  readonly account,  does NOT prevent a person from logining in and gaining the  private.key via ssh or executing a local WebGUI console. The risk is with someone gaining access to the server HTTPS private-key.


Finally note, this was done on a Fortigate run 4.0 MR3p17


Ken Felix
Network & Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   -   - )=

         o

      /     \