Yesterday, Harry Sintonen, researcher at F-Secure, discovered 35-year-old vulnerabilities associated with SCP (Secure Copy Protocol) client, a network protocol, that uses Secure Shell (SSH) for data transfer between hosts on a network. These SCP clients are susceptible to a malicious SCP server, which could perform unauthorized changes to the target directory. In 2000, a directory traversal bug was found in the SCP client in SSH, which got fixed then.
Vulnerabilities discovered
One of the vulnerabilities associated with SCP clients lets the attackers write arbitrary malicious files to the target directory on the client machine. The attackers can change the permissions on the directory to allow further compromises. Another vulnerability is that the SCP clients are failing to verify how valid is the object returned to it after a download request. The consequences are severe as an attacker who controls the server can easily drop arbitrary files into the directory from which the user runs SCP (similar to a man-in-the-middle attack).
The list of major vulnerabilities discovered are:
CWE-20: SCP client improper directory name validation [CVE-2018-20685]
With the help of empty (“D0777 0 \n”) or dot (“D0777 0 .\n”) directory name, the SCP client permits the server to modify permissions of the target directory.
CWE-20: SCP client missing received object name validation [CVE-2019-6111]
Since the SCP implementation has been derived from 1983 rcp (1), the server can choose which files/directories are sent to the client. According to the post by Sintonen, “A malicious SCP server can overwrite arbitrary files in the SCP client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example overwrite .ssh/authorized_keys).” This vulnerability is known as CVE-2018-20684 in WinSCP.
CWE-451: SCP client spoofing via object name [CVE-2019-6109]
The object name can be used to manipulate the client output as there is a missing character encoding in the progress display. For example to employ ANSI codes to hide additional
files being transferred.
CWE-451: SCP client spoofing via stderr [CVE-2019-6110]
A malicious server can manipulate the client output by accepting and displaying arbitrary stderr output from the SCP server.
These vulnerabilities affect the SCP client implementations in Red Hat, Debian, and SUSE Linux, OpenSSH version 7.9 and earlier, and few versions of WinSCP.
How to overcome these vulnerabilities?
For OpenSSH
Users can switch to sftp or apply the https://sintonen.fi/advisories/scp-name-validator.patch for hardening scp against server-side manipulation attempts.
A note by Sintonen : This patch may cause problems if the the remote and local shells don’t agree on the way glob() pattern matching works. YMMV.
For WinSCP
One can upgrade to WinSCP 5.14 or later versions.
There are no fixes available for PuTTY yet and users are refraining from using PuTTY. One of the users commented on HackerNews, “I strongly discourage anyone from using PuTTY, not for this reason, but for its weird and nonstandard handling of SSH keys.”
Users are now more skeptical to deal with the network while downloading their files and transferring them. Most of us highly rely on SSH as we think it is secure and trusted, but should we continue trusting it? Is it advisable to blindly trust and not take preventive measure beforehand? One of the users commented on HackerNews, “We trust a lot of things, and maybe we shouldn’t. I use SCP infrequently and on machines that I control, so that’s a level of risk I’m comfortable with.”
Another user commented on the HackerNews thread, “The argument that you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine, is false in both cases.” Another user advises accessing data in offline mode by shutting down the instance and connecting the storage as secondary storage on another instance. The user further suggests discarding the storage as soon as the work is done. The data can also be downloaded at the hypervisor level. Another comment on HackerNews reads, “You can’t physically access the disk, but you often can download a snapshot or disk image, which is created at the hypervisor level.”
To know more about the vulnerabilities, check out the post by Sintonen advisories.
