Archiv der Kategorie: Workaround

UNBLOG Tutorials Usability and Addons Integration with Technical Workarounds and Tutorials for Professionals.

Workaround

KiTTY Terminal Character Set Translation

Home  »  Workaround
Schreibe einen Kommentar

PuTTY und KiTTY Character Set Translation der Terminal Zeichenkodierung

Wird im Terminal die Ausgabe von Linux Shell Commands nicht wie gewünscht dargestellt, liegt es an der Übersetzung der Zeichen Codepage des Terminals, oder es liegt ein nicht korrektes Unicode Systemgebietsschema auf dem Host vor. Der Beitrag zeigt die Einstellung der Unicode Zeichen Tabelle auf dem Linux Host, und die Character Set Translation der Zeichenkodierung beim Terminal Client PuTTY und KiTTY.

Immer mehr Linux-Systeme nutzen UTF-8 statt ISO-8859 für die Zeichenkodierung.

PuTTY unter Windows ist per Standard mit der Zeichenkodierung UFT-8 für die Character Set Translation korrekt eingestellt.

PuTTY Configuration Remote Zeichenkodierung UFT-8
Abbildung: PuTTY Character Set Translation

KiTTY der ebenso freie Clone von PuTTY, hat Standardmässig bei Character Set Translation die Zeichenkodierung ISO-8859-1:1998 (latin-1, West Europa) voreingestellt.

Abbildung: KiTTY Character Set Translation

Die Zeichenkodierung sollte bei KiTTY auf UTF-8 geändert werden. Die gespeicherten Host werden im Abschnitt Session aus der Liste Saved Sessions mit Load geöffnet und angepasst.

Beim Linux-System wird die Zeichenkodierung mit locale abgefragt.

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"ddd
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Die Verfügbaren Locales ausgeben.

$ locale -a

In der Datei /etc/default/locale sind die Default Einstellungen.

$ cat /etc/default/locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_TIME=en_GB.UTF-8

Das Systemgebietsschema wird unter Debian 10 (Buster) mit dpkg-reconfigure locales festgelegt. UTF-8 sollte der Standard sein.

Abbildung: dpkg-reconfigure locales

Bei CentOS/RHEL Linux wird das Systemgebietsschema wie folgt festgelegt.

$ sudo localectl set-locale LANG=de_DE.UTF-8

Globale Gebietsschemaeinstellungen findet man in den Dateien.

  • /etc/default/locale – Ubuntu/Debian
  • /etc/locale.conf – CentOS/RHEL
Workaround

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

Home  »  Workaround
Schreibe einen Kommentar

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.