Fortigate exploit

FreePBX Security
1

[split from unrelated thread - mod]

OK so now there is a tweet out there telling Foritgate users to check their stuff because of FreePBX servers getting pwned due to Fortigate exploits. However, so far the only publicly reported issue of this (this one) wasn’t due to a Fortigate exploit since the firewall had a rule allowing access to the GUI. Last time I check, putting a firewall rule in is not an exploit.

So in this thread we have one person saying “A few reported it to me” and in the tweet it’s “several” so can we quantify that? Is it more than 2 but less than 12? More than that? Has enough data been provided that shows this is a Fortigate exploit or is it cases like this one?They are using Fortigate but then they had a rule to allow access.

Since I can’t see how logically this can be a Foritgate exploit and only impact FreePBX systems, are there reports from Fortigate about any of these exploits? Firmware updates with a patch? Are there any suggested support steps users can take?

While it is totally possible others were pwned by Fortigate exploits, clearly the OP wasn’t because the firewall allowed the access and thus this particular instance is pointing more to exploits in Apache vs the firewall.

2

I presume you refer to mine:
https://twitter.com/LorneGaetz/status/1169051835044417536?s=20

Last week I got several commercial support tickets where the customer was reporting excessive calls to high tariff destinations for toll fraud. The calls were mostly to the 605 area code, somewhere in the Dakotas, a destination we’ve been seeing of late since most admins are savvy enough to block international calls. I personally touched 3 separate systems behind 3 separate routers on 3 separate sites for 2 customers.

In all three cases, the PBX was behind a Fortigate device of some sort, I don’t know what product specifically. In all three cases, the firewall was hacked to forward untrusted traffic to the PBX from the 'net. What’s more, the firewall NAT exploit was such that incoming traffic was masqueraded with the LAN IP of the gateway so the router was proxying the incoming traffic. As is customary, the local LAN subnet(s) were white listed so both the pbx firewall and fail2ban ignored the intrusion.

Once the above was in place, it was just a matter of brute forcing the provisioning services until they got a valid provisioning filename. The provisioning file leaked extension secrets allowing registrations of their own clients, which in turn allowed outbound calls from malicious users.

The log fingerprints were there for all to see. Excessive SIP registration attempts in /var/log/asterisk/full* all appearing to come from the LAN IP of the router/firewall. Also excessive http 404s in /var/log/httpd/access_log* as they attempted to guess a provisioning filename again from the router. tftp was enabled on all three systems as well, and since verbose logging is not enabled for tftp by default, I could only see the brute forcing attempts against tftp on one system in /var/log/messages.

Had tftp been disabled and had http provisioning been protected with apache creds, it would have taken far longer to brute force anything, allowing more time for the firewall/router compromise to be discovered prior to actual toll fraud.

4 Likes
3
3 Likes
4

Looking at the published vulnerabilities for this vendor, I would suspect that there are lots of customers who should look to patching their environment sooner rather than later!

https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=Fortinet&search_type=last3months

1 Like
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.