How WatchTowr Explored the Complexity of a Vulnerability in a Secure Firewall Appliance (watchtowr.com) 9
Cybersecurity startup Watchtowr "was founded by hacker-turned-entrepreneur Benjamin Harris," according to a recent press release touting their Fortune 500 customers and $29 million investments from venture capital firms. ("If there's a way to compromise your organization, watchTowr will find it," Harris says in the announcement.)
This week they shared their own research on a Fortinet FortiGate SSLVPN appliance vulnerability (discovered in February by Gwendal Guégniaud of the Fortinet Product Security team — presumably in a static analysis for format string vulnerabilities). "It affected (before patching) all currently-maintained branches, and recently was highlighted by CISA as being exploited-in-the-wild... It's a Format String vulnerability [that] quickly leads to Remote Code Execution via one of many well-studied mechanisms, which we won't reproduce here..."
"Tl;dr SSLVPN appliances are still sUpEr sEcurE," their post begains — but the details are interesting. When trying to test an exploit, Watchtowr discovered instead that FortiGate always closed the connection early, thanks to an exploit mitigation in glibc "intended to hinder clean exploitation of exactly this vulnerability class." Watchtowr hoped to "use this to very easily check if a device is patched — we can simply send a %n, and if the connection aborts, the device is vulnerable. If the connection does not abort, then we know the device has been patched... " But then they discovered "Fortinet added some kind of certificate validation logic in the 7.4 series, meaning that we can't even connect to it (let alone send our payload) without being explicitly permitted by a device administrator." We also checked the 7.0 branch, and here we found things even more interesting, as an unpatched instance would allow us to connect with a self-signed certificate, while a patched machine requires a certificate signed by a configured CA. We did some reversing and determined that the certificate must be explicitly configured by the administrator of the device, which limits exploitation of these machines to the managing FortiManager instance (which already has superuser permissions on the device) or the other component of a high-availability pair. It is not sufficient to present a certificate signed by a public CA, for example...
Fortinet's advice here is simply to update, which is always sound advice, but doesn't really communicate the nuance of this vulnerability... Assuming an organisation is unable to apply the supplied workaround, the urgency of upgrade is largely dictated by the willingness of the target to accept a self-signed certificate. Targets that will do so are open to attack by any host that can access them, while those devices that require a certificate signed by a trusted root are rendered unexploitable in all but the narrowest of cases (because the TLS/SSL ecosystem is just so solid, as we recently demonstrated)...
While it's always a good idea to update to the latest version, the life of a sysadmin is filled with cost-to-benefit analysis, juggling the needs of users with their best interests.... [I]t is somewhat troubling when third parties need to reverse patches to uncover such details.
Thanks to Slashdot reader Mirnotoriety for sharing the article.
This week they shared their own research on a Fortinet FortiGate SSLVPN appliance vulnerability (discovered in February by Gwendal Guégniaud of the Fortinet Product Security team — presumably in a static analysis for format string vulnerabilities). "It affected (before patching) all currently-maintained branches, and recently was highlighted by CISA as being exploited-in-the-wild... It's a Format String vulnerability [that] quickly leads to Remote Code Execution via one of many well-studied mechanisms, which we won't reproduce here..."
"Tl;dr SSLVPN appliances are still sUpEr sEcurE," their post begains — but the details are interesting. When trying to test an exploit, Watchtowr discovered instead that FortiGate always closed the connection early, thanks to an exploit mitigation in glibc "intended to hinder clean exploitation of exactly this vulnerability class." Watchtowr hoped to "use this to very easily check if a device is patched — we can simply send a %n, and if the connection aborts, the device is vulnerable. If the connection does not abort, then we know the device has been patched... " But then they discovered "Fortinet added some kind of certificate validation logic in the 7.4 series, meaning that we can't even connect to it (let alone send our payload) without being explicitly permitted by a device administrator." We also checked the 7.0 branch, and here we found things even more interesting, as an unpatched instance would allow us to connect with a self-signed certificate, while a patched machine requires a certificate signed by a configured CA. We did some reversing and determined that the certificate must be explicitly configured by the administrator of the device, which limits exploitation of these machines to the managing FortiManager instance (which already has superuser permissions on the device) or the other component of a high-availability pair. It is not sufficient to present a certificate signed by a public CA, for example...
Fortinet's advice here is simply to update, which is always sound advice, but doesn't really communicate the nuance of this vulnerability... Assuming an organisation is unable to apply the supplied workaround, the urgency of upgrade is largely dictated by the willingness of the target to accept a self-signed certificate. Targets that will do so are open to attack by any host that can access them, while those devices that require a certificate signed by a trusted root are rendered unexploitable in all but the narrowest of cases (because the TLS/SSL ecosystem is just so solid, as we recently demonstrated)...
While it's always a good idea to update to the latest version, the life of a sysadmin is filled with cost-to-benefit analysis, juggling the needs of users with their best interests.... [I]t is somewhat troubling when third parties need to reverse patches to uncover such details.
Thanks to Slashdot reader Mirnotoriety for sharing the article.
Format string vulnerability? (Score:2)
Text inputs in anything should be a blob with length (printf, SQL, Shell, HTML, XML, it's all wrong).
It took decades to not get shouted down when suggesting that maybe having arbitrary pointer arithmetic in all your code wasn't a very good idea. The fundamental idiocy of control characters probably won't be widely recognized before AI takes over ... likely using exploits caused by them.
Re: (Score:1)
It took decades to not get shouted down when suggesting that maybe having arbitrary pointer arithmetic in all your code wasn't a very good idea.
*EVIL GRIN* Are you sure about that?
The fundamental idiocy of control characters probably won't be widely recognized before AI takes over ... likely using exploits caused by them.
And what would you replace them with numbnuts? You in your infinite wisdom already declared pointer math illegal. (FAT CHANCE. Every processor does pointer math at some point. Changing that would mean eliminating every code branch and precomputing every possible one so the entire code path from that point on could be replicated for it. (I.e. You'd need infinite memory to store it, and solve the halting problem.))
Now you want to remove control characters? What are you
Re: (Score:2)
For printf just separate out the text from the formatting string completely. Then the formatting string is no longer text with control characters, it's simply code. Also, of course even the formatting string is a blob with length if it's not a literal.
All strings with length, no strings with inline signalling, all markup languages should be binary.
My show is on (Score:2)
Can I just have the tract?
Does the author not understand certificates? (Score:3)
I'm pretty sure if I sign client certificates with my internal, private, sub-CA and deliver them securely to my co-workers, I can prevent anyone without one of these certificates from connecting to my webserver or vpn concentrator. I cannot fathom how someone without a certificate issued by me would be able to connect since the CA list that my sites use to validate certificates only contains one certificate: my CA certificate.
Re: (Score:3)
Actually, you cannot prevent connections. What you can prevent is successful TLS handshakes. That is a quite important distinction.
Re: (Score:2)
That doesn't seem to be the case with this exploit though. Rather it seems to be a bug in their ma
Just great (Score:2)
Jehovah Witnesses turned security researchers.
Re: (Score:2)
but... have you heard the GOOD NEWS?
How often do you hear GOOD NEWS in anything security related? Imagine the relief?