Default cookie jar location is unsafe on a multiuser system (/tmp/ with a predictable name)

[hlein]

Before submitting an issue, please make sure you fully read any potential error messages output and did some research on your own.

Subject of the issue

Use of /tmp/wpscan/ is predictable and no safe file operations (checking for symlinks, etc.) are done, so wpscan is unsafe to run on multiuser systems without using --cookie-jar and --cache-dir.

Your environment

• Version of WPScan: HEAD (20ce10e2ecaeeefc594d8b371de98838c15fa68b)
• Version of Ruby: 3.1.0
• Operating System (OS): Gentoo Linux

Steps to reproduce

Pick a filename in usera's homedir.

As userb, create /tmp/wpscan/ and a symlink to usera's file.

Then as usera, run wpscan.

usera@localhost ~ $ ls -ld ~/foo
ls: cannot access '/home/usera/foo': No such file or directory

userb@localhost ~ $ mkdir /tmp/wpscan
userb@localhost ~ $ ln -s /home/usera/foo /tmp/wpscan/cookie_jar.txt

usera@localhost ~ $ wpscan --url https://...

userb@localhost ~ $ ls -l /home/usera/foo
-rw-rw-r-- 1 usera usera 0 Feb 18 17:10 /home/usera/foo

This will also clobber/overwrite an existing file like $HOME/.ssh/authorized_keys

It's a matter of time to turn this into something significant (use cookie payloads to create interesting contents in .ssh/authorized_keys file, etc.). I believe for cookies, libcurl does the work - but that library seems to have a (reasonable) expectation that the file paths it is handed are safe.

I think cache filenames are also predictable, if the attacker knows or controls a site that will be visited (filenames based on hashes of URLs). If the attacker controls a site being visited, that could lead to a very easy malicious-file-content attack (serve an invisible .png that is actually a replacement authorized_keys file, .bashrc file, etc.).

Expected behavior

wpscan should either refuse to proceed if the dir cannot be trusted (easier said than done - many TOCTOU concerns), and/or simply use a safer default such as respecting $TMPDIR if it is set and prefer that instead of /tmp/. On a single-user system or container maybe nobody cares; on a multiuser system the system admin should have already set $TMPDIR appropriately.

Actual behavior

See above.

What have you already tried

Setting --cookie-jar and --cache-dir seems to be sufficient, although scanning the source for [^a-z]/tmp/ there are some other hits like /tmp/stackprof-{cpu,object,wall}.dump, /tmp/wordpress-tests-lib, /tmp/rspec_examples.txt that catch the eye.

Note that there was a rejected issue a while ago (#1438) about /tmp/wpscan/cache/ causing collisions between different users, and the suggestion to put it in $HOME instead was rejected. That discussion failed to consider the security implications.

Things you have tried (where relevant):

• Update WPScan to the latest version [ ]
• Update Ruby to the latest version [ ]
• Ensure you can reach the target site using cURL [ ]
• Proxied WPScan through a HTTP proxy to view the raw traffic [ ]
• Ensure you are using a supported Operating System (Linux and macOS) [ ]