Category Archives: Howto Tutorials (EN)

Knowledge Network for Tutorials, Howto’s, Workaround, DevOps Code for Professionals.

FortiOS CVE-2018-13379 Advisory FG-IR-18-384

Allegedly, many admins did not update their FortiGate VPNs, so that attackers attack systems. The reason is the exploit code for the vulnerability (CVE-2018-13379) from 2019 that has now emerged.

Successful attacks on the SSL-VPN configured FortiOS should be made possible by sending prepared HTTP requests. Attackers could access system files and thus gain access to unencrypted access data, for example. They could then log into vulnerable VPN firewalls and compromise them.

FortiOS, which is used on FortiGate firewalls, has a total of six security holes in several versions of the Security Network operating system that affect the SSL-VPN web portal. Fortinet has published the FortiGuard Security Advisories with update notes.

FortiGuard PSIRT Advisory

Der original Textauszug:

FortiOS system file leak through SSL VPN via specially crafted HTTP resource requests

Summary

A path traversal vulnerability in the FortiOS SSL VPN web portal may allow an unauthenticated attacker to download FortiOS system files through specially crafted HTTP resource requests.
Impact

Information Disclosure
Affected Products
FortiOS 6.0 – 6.0.0 to 6.0.4
FortiOS 5.6 – 5.6.3 to 5.6.7
FortiOS 5.4 – 5.4.6 to 5.4.12
(other branches and versions than above are not impacted)
ONLY if the SSL VPN service (web-mode or tunnel-mode) is enabled.
Solutions

Upgrade to FortiOS 5.4.13, 5.6.8, 6.0.5 or 6.2.0 and above.

Workarounds:

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

Note that firewall policies tied to SSL VPN will need to be unset first for the above sequence to execute successfully.

As an example, when source-interface is “port1” and SSL VPN interface is “ssl.root”, the following CLI commands would be needed to ensure “unset source-interface” executes successfully:

config vpn ssl settings
config authentication-rule
purge (purge all authentication-rules)
end
end

config firewall policy
delete [policy-id] (SSL VPN policy ID(s) that srcintf is “ssl.root” and dstintf is “port1”)
end

Note that code to exploit this vulnerability in order to obtain the credentials of logged in SSL VPN users was disclosed. In absence of upgrading to the versions listed above, mitigating the impact of this exploit can be done by enabling two-factor authentication for SSL VPN users. An attacker would then not be able to use stolen credentials to impersonate SSL VPN users.

VNCSERVER VNC could not acquire name on session bus

VNCSERVER session VNC. vncsession is used to start a VNC (Virtual Network Computing) desktop. vncsession performs all the necessary steps to create a new user session, run Xvnc with appropriate options and starts a window manager on the VNC desktop.

VNCSERVER – could not acquire name on session bus

 If you see this message, then your VNC configuration is incorrect or not complete!

VNCSERVER session VNC could not acquire name on session bus

Cause

cause deployment of user environment that not performed automatically during installation process of vncserver.

Solution

See this tutorial here in this blog, it shows the complete installation of vncserver suitable for most known distributions.

VNCSESSION VNCSERVER session VNC

Several VNC-related files are found in the directory $HOME/.vnc:
/etc/tigervnc/vncserver-config-defaults

The optional system-wide equivalent of $HOME/.vnc/config. If this file exists and defines options to be passed to Xvnc, they will be used as defaults for users. The user’s $HOME/.vnc/config overrides settings configured in this file. The overall configuration file load order is: this file, $HOME/.vnc/config, and then /etc/tigervnc/vncserver-config-mandatory. None are required to exist.

/etc/tigervnc/vncserver-config-mandatory

The optional system-wide equivalent of $HOME/.vnc/config. If this file exists and defines options to be passed to Xvnc, they will override any of the same options defined in a user’s $HOME/.vnc/config. This file offers a mechanism to establish some basic form of system-wide policy. WARNING! There is nothing stopping users from constructing their own vncsession-like script that calls Xvnc directly to bypass any options defined in /etc/tigervnc/vncserver-config-mandatory. The overall configuration file load order is: /etc/tigervnc/vncserver-config-defaults, $HOME/.vnc/config, and then this file. None are required to exist.

$HOME/.vnc/config

An optional server config file wherein options to be passed to Xvnc are listed to avoid hard-coding them to the physical invocation. List options in this file one per line. For those requiring an argument, simply separate the option from the argument with an equal sign, for example: “geometry=2000×1200” or “securitytypes=vncauth,tlsvnc”. Options without an argument are simply listed as a single word, for example: “localhost” or “alwaysshared”.

The special option session can be used to control which session type will be started. This should match one of the files in /usr/share/xsessions. E.g. if there is a file called “gnome.desktop”, then “session=gnome” would be set to use that session type.

$HOME/.vnc/passwd

The VNC password file.

$HOME/.vnc/host:display#.log

The log file for Xvnc and the session.