Skip to main content
remosito
remosito
New Member
November 16, 2020
Question

CVE-2018-13379 : Question / Confirmation

  • November 16, 2020
  • 1 reply
  • 6059 views

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

 

 

 

 

    1 reply

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    November 16, 2020

    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
    remositoAuthor
    New Member
    November 16, 2020

    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
    SuperUser
    ede_pfau
    SuperUser
    November 16, 2020

    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.

    Terms & ConditionsAccessibility statement