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
Network & Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
=( - - )=