How WatchTowr Explored the Complexity of Vulnerability in a Secure Firewall Appliance
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.
Read more of this story at Slashdot.
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.
Read more of this story at Slashdot.