CVE-2018-13379 : Question / Confirmation

[remosito]

Howdie all,

got an e-mail about this threat ( https://www.fortiguard.com/psirt/FG-IR-18-384 ). Upon rereading it now I noticed the line that the only workaround is to unset the source interface completely.

What I did back when it got released is set the source interface to an interface we are not using (status down, not eth cable connected).

Portscan on external interface showed the specified non-standard port was not responding.

My question now is. Is setting non-used interface sufficient? Or is unsetting source interface really the only way to safeguard apart from updating fortigate?

thanks a bunch in advance

[ede_pfau]

IMHO unsetting the listened-on interface is the most simple way, and the recommended one as well. Apart from that all current FortiOS versions are patched against this exploit.

[remosito]

ede_pfau wrote:

IMHO unsetting the listened-on interface is the most simple way, and the recommended one as well. Apart from that all current FortiOS versions are patched against this exploit.

Undoubtetly. The going forward is very clear. I already unset the interface completely this morning.

The ramifications of us setting interface to an unused interface for the last 18 months is what is not clear.

Basically we need to know if we've been save from the exploit in the last year and a half. Or if we've been exposed.

[ede_pfau]

As the exploit hinges on stuffing the URL to the web portal with 'special' arguments, you just cannot have been exposed if there was no public facing interface on which the sslvpn daemon was listening. For any exploit, you need to have access from the internet for a vulnerable service, and in your case sslvpn just was not accessible.

Not withstanding that best practise cries for not opening management services on the WAN port(s), HTTPS, SSH and FMG.

[remosito]

ede_pfau wrote:

As the exploit hinges on stuffing the URL to the web portal with 'special' arguments, you just cannot have been exposed if there was no public facing interface on which the sslvpn daemon was listening. For any exploit, you need to have access from the internet for a vulnerable service, and in your case sslvpn just was not accessible.

Not withstanding that best practise cries for not opening management services on the WAN port(s), HTTPS, SSH and FMG.

That's what I originally assumed. 

But then the lines in the linked document would be wrong:

> As a temporary solution,  the only workaround  is to totally disable the SSL-VPN service (both web-mode and tunnel-mode) by applying the following CLI commands:

>config vpn ssl settings >unset source-interface >end

Theoretically it could be possible that unless unset totally. The sslvpn daemon is still running and because of bad impelementation actually listening on all interfaces. But just replying on those set via source-interface.

And one of those evil formatted requests unhinge the daemon to such a degree that he starts replying even on interfaces that are not set.

Hope that makes sense. 

Cant come up with a car analogy. But a human analogy comes to mind:

If my name were sslvpndaemon. And I have been told to only reply to john_smith talking to me. And play dead to everybody else. If wicked_john shows up and blasts a 200db horn right into my ear (the evil formatted requests). I'll probably not play dead anymore but answer with a scream (system file reply) as my eardrum just exploded and I am in pain.

PSIRT are pretty serious and official documents. So if there is an actual error in one I would like to have confirmation from fortinet that unsetting and totally diableing SSL-VPN service is NOT the only workaround. 

And setting it to an unused interface is sufficient. 

[boneyard]

remosito wrote:

PSIRT are pretty serious and official documents. So if there is an actual error in one I would like to have confirmation from fortinet that unsetting and totally diableing SSL-VPN service is NOT the only workaround. 

And setting it to an unused interface is sufficient. 

contact Fortinet support, the chance they will respond on this here is very small.

[remosito]

boneyard wrote:

contact Fortinet support, the chance they will respond on this here is very small.

will most certainly :)

Always go via forums first in case somebody else already asked. And to leave a searchable trace for future.