Fuzzing Fortigate 7

Continuing my journey with the Mutiny Fuzzing Framework one of the apps I decided to test was a Fortigate 7.x VM (what I initially described during the last TheHackSummit conference). Below you'll find more details about it. Here we go... 

This time we'll start here:

At the beginning (so some about 6 months ago) my plan was:
- create a simple fuzzer for the Fortigate VM
- run it against my target VM in my mini-LAB
- find the bugs.

TL;DR

As I already described few ideas for version 5 as well as for the version 6 of the Fortigate on the blog I decided to move forward and install version 7 (to be more precise: I tested Fortigate 7.0.1).

After a while - when I moved forward to the Mutiny Fuzzer again - my VM was ready and I started collecting PCAPs.

Before that - let's get back for a while to the config part:

As you can see on the screen above I used "only" HTTP/S and SSH. This time I decided to 'bypass' the 'secure' part of the protocol and I enabled HTTP and Telnet access to check how it will look in Wireshark with Mutiny. ;)

So after a while we should be somewhere here:

 

I started (Wireshark to collect packets for) telnet connection. Next (as an admin user) I used few of the commands available in Fortigate's CLI. When my PCAP was ready I started mutiny (in a similar way I described it in previous post).

 We should be somewhere here:

At this stage my next step was to extract the packets from PCAP and check how can I reproduce the crash I found.

Checking:

Next:

I still wasn't sure what is the reason of the crash (read as: which hex value is my badchar in the payload prepared with mutiny). My next guess was to use diff tool to check the results generated by the fuzzer:

Here we go:

 

 

More with grep:

 

It was a lovely evening with the hex values... ;)

Well, a little hint:

So:

Continuing manual changes in the files from the fuzzer I think that CLI can not parse 'properly' characters like 0x24 or 0x27:

Using in the request:

 

Final fuzzer file for the mutiny can be found here.

At this stage I continued my CLI adventures and I moved forward to another execute command. ;) 

Check it out:

Looks like there are more overflows in this appliance. ;>

Opposite to the first bug (found with mutiny) this one looks to be more interesting because we can overwrite some values of the registers.

...and yeah...

"Guys, you do NOT want to do this. Trust me."

 

As you can see - even if I worked on a different CLI binary (than I meet on the target Fortigate VM) - there are more bugs to find. :)

Enjoy your weekend:

See you next time! ;)

 

Cheers

 

* Updated 04.05.2023 *

Bug was tested and confirmed in:
- FortiGate 7.0.1
- FortiGate 6.4.12
- FortiFirewall 7.0.11