Miscreants 'mass exploited' Fortinet firewalls, 'highly probable' zero-day used Miscreants running a "mass exploitation campaign" against Fortinet firewalls, which peaked in December, may be using an unpatched zero-day vulnerability to compromise the equipment, according to security researchers who say they've observed the intrusions. The team report the networking gear maker has yet to link the malicious …
"In these attacks, the unknown criminals somehow gained access to Fortinet FortiGate firewalls with internet-exposed management interfaces."
Why are there "internet-exposed management interfaces" ? What is the rational behind publically facing management sites ?
Not a trick question I just can't understand why someone would do that but I can only presume that there is a valid reason, I just don't see it.
If you are remotely supporting a client it is easier to login to their router to make a quick change. I used to support a few small businesses where it would have taken me 2 hours to reach their office, 2 minutes to make a change, and another 2 hours to get home. I do not think any of us are happy with an exposed web-interface; more so if it is a 3rd party system we have no control over. We really need the vendors to ensure their interfaces are as bullet-proof as possible.
It may help if we could utilise a global fail2ban type of system - along the lines of Spamhaus - that blocks access to devices from rogue IP addresses. As I have control over my home-systems, I block every IPv4 range from Russia and China. Unfortunately, that means around 12k input rules for iptables to handle and block. Anyone else trying to get through is clobbered by fail2ban after 2 attempts. The spread of cheap VPS systems has resulted in a huge increase in the number of bots trying to break in to people's email/ssh/etc.
Except POTS lines are being retired - at least here in the UK. The small businesses I worked with either had a single POTS line that also carried xDSL, or they had ISDN and a separate IPv4 connection. So it was front-door web-interface or travel to site. There was no scope or funding for an alternative route in.
The company I work for has a lot of Small / medium customers with remotely managed routers, we have started to switch out POTS Modems for GSM Modems. More expensive for sure but as the OP stated, cheaper than a truc kroll for an engineer to attend site for a 2 minute configuration change.
I would think the solution to this problem, from this point onward, is for Fortinet to include a small VPN server in the firewall product in order to enable secure remote admin logins. I am sure they didn't think of this previously but, factoring in this event, they really need to.
Fortinet does include IPSEC and SSL VPNs on their Fortigate firewalls. Unfortunately their SSL VPN has had multiple high severity CVEs, their IPSEC VPN has had a few lower (mostly DOS) CVEs. If you can't have a secured out-of-band POTs or Cellular admin link I'd recommend putting something like a Raspberry Pi behind the firewall with a outgoing VPN connection (probably Wireguard based) to a locked-down public relay host that you also VPN into and route your administrative traffic through. This way the Fortigate doesn't need to have any external ports open to the internet.
Yes, I am using IPsec VPN, and I noticed increased activity (VPN connection attempts, all failed) after the summer. First deployed filtering rules (/16 subnet of attacker) but was overwhelmed within a few weeks had 25 rules.
Things only calmed down once I disabled Radius and WireShark, and applied geo-rules to block/allow VPN traffic (ports). Then I took the hammer rule and not only blocked VPN ports, but all traffic from snoopers from around 10 subnets /32. Interestingly, now the logs show not a single failed phase1 or phase2, but lots of other ports being probed (blocked subnets) as mentioned in the article above.
Sounds nice but if they could make that secure then they would have just used that secure VPN for regular stuff instead of the less secure stuff. Really it seems if you want a "secure" VPN from a vulnerability standpoint the best solution is to avoid any SSL based/browser based VPNs and use another protocol like IPSec. I've never noticed any credential stuffing attacks against my Sonicwall IPSec endpoints but of course the SSL portions get hammered. My most "secure" Sonicwall firewalls have never had SSL VPN enabled and management access while exposed to the internet is limited to just a couple subnets that are allowed, so I consider that secure. I noticed another person comment that there have been some minor vulnerabilities against Fotinet IPSec though only denial of service.
Though IPsec VPNs tend to have a lot less functionality vs the pretty SSL VPNs. Cant' speak for Fortinet, never used it, but the Sonicwall SSL VPN is crap from a few different perspectives (though for me Sonicwall makes a solid IPsec site to site system as well as layer 4 firewall, haven't touched their layer 7). Citrix and Ivanti both have nice SSL VPNs (at least the basic VPN functionality and access control), though like everyone else they have had their share of security exploits over the years.
I haven't seen a modem used for remote access myself since 2002, and even then I recall turning that 3COM modem thing we had off as we migrated users to some Cisco VPN concentrator appliances.
"Not sure, would have thought VoIP would be too lossy with chopping the frequency off at the top and bottom."
That only happens if you're using shit CODECS.
If you stick to G711a/u you'll be fine. Rolled out hundreds of the buggers. But then you just introduce another issue...what happens to a compromised ATA?
Your firewall is far, far more likely to get patched than an an ATA, even by the better brands.
"first setting it to "standard" before switching it to "more," as in an input is needed to see more text, typically making these changes within 10 and 30 seconds of each other.
"The purpose of these changes is not known, but it may hint at threat actors' preferred mode of interacting with the web console," according to the report. "
Wait, these are experts and the "purpose of these changes" seems unknown to them? o_O
It seems simple even to me:
enable "more" - that is, paged display of logs - in order to better hide the events. If the typical admin setting is "standard" and all of a sudden a setting was changed to require an input in order that to see additional log details that you are used to receiving by default, the longer log details containing the intrusions may be overlooked by the "more" requirement being overlooked itself. A bit of "security through obscurity" here, but working for the intruders not the owners.
Seems you are ?
From what I can see their advisory was posted today, yet the article talks about systems being compromised last month.
It is interesting to note that apparently only their 7.0 build is affected they seem to have several other 7.x branches that are not.
https://fortiguard.fortinet.com/psirt/FG-IR-24-535
I recall reading comments on several occasions (few years back at least) where seemingly experienced network engineers would comment on Fortinet
"find a stable firmware version and don't upgrade" on a fairly regular basis, same folks often touted Fortinet as a good solution lower
cost than Palo Alto(which they ranked #1), but with the big caveat that their software wasn't that great(unless you happened to land on a
good build of it).
Clusterf**k Engineering
The entire PHP* contraption of the firewall should be locked behind a tiny crypto library, which can be mathematically proven correct.
https://github.com/DiplIngFrankGerlach/MST
Only a counterparty with the right symmetric key can ever send a send a single octet or more to the PHP stuff.
But hey, why make things secure, if you can expose a PHP hairball ?
Bonus points if some of the 400 000 LOC of the SSL/TLS library has exploits, too !
The informatics world seems to indulge in the latest insecure design pattern, instead of using simple, proven approaches.
*read as "management interface"
"gained access to Fortinet FortiGate firewalls with internet-exposed management interfaces."...and there you have it. Again. At what point in time will so called professionals get the memo that exposing anything like this to the Internet is a catastrophically bad thing? I've had almost straight up arguments with incompetent networking security "professionals" at our MSP about their insisting on having an Internet-exposed management interface and how it's fine and secure because after sign-in, the access is checked. They did not win that argument...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
