Why you should always consult a professional
Originally posted at ViryaTechnologies.com.
The web is, undoubtedly, a wonderful resource, it allows us to quickly and easily find information on almost anything. When it comes to servers and websites, however, it can be incredibly dangerous if you (or worse, the author) do not know what you/they are doing.
I was browsing to see if there's a better way to reset a users password from PHP than the method I usually use, and stumbled across this tutorial. Quite frankly, my chin hit the desk at the advice being offered.
In all fairness to the person who posted the tutorial, they have attempted to mitigate some of the serious security concerns, but despite that, it's still a security nightmare. What makes it worse, is the comments below indicating that some users are blindly copying and pasting the PHP and following the steps without even a base understanding of how it works.
In this post we'll be looking at what the tutorial suggests, and why it's a bad idea.
Shell Script Issues
The tutorial suggests creating a shell script called chpasswd.sh, containing the following
#!/bin/sh
# \
exec expect -f "$0" ${1+"$@"}
set password [lindex $argv 1]
spawn passwd [lindex $argv 0]
sleep 1
expect "assword:"
send "$password\r"
expect "assword:"
send "$password\r"
expect eof
Firstly taking the context of the tutorial into account, we know that this script will only ever be run with superuser privileges, using Sudo. Suddenly, the script is very dangerous as a user who has been granted permission to run this one command with SU privileges is able to reset the root (the Linux Superuser) password - meaning an attacker will be able to run whatever they want.
To see how easy this is to exploit, we first need to look at the second issue - the way in which the script is called;
chpasswd.sh {username} {password}
So, whilst the script is running, anyone who sees a list of the processes running on the server will also see the password for whichever user is being reset. There's also no hackery involved in resetting the root password:
chpasswd.sh root mypass
Scary stuff, but sadly it gets worse:
Giving the Webserver Sudo privileges
As we briefly mentioned above, the shell script in question needs to be run with superuser privileges (at least if you want to reset other users' passwords). In order to achieve this, the tutorial talks you through the process of granting the Apache process permissions to run that one script as a superuser.
This is an incredibly bad idea, but something we'll come back to when we look at the mitigation steps the tutorial takes.
PHP Script Issues
I won't fully replicate the script here, but there is one truly serious issue with it - absolutely no input cleansing. Anything you enter into the username or password field is passed directly to the shell.
$cmd="$shellscript " . $_POST['username'] ." " . $_POST['passwd'];
exec($cmd,$output,$status);
So if I enter something & cat /etc/passwd into the password box, what do you think will happen? The script will run and reset the users password to 'something', but cat /etc/passwd will run as a completely seperate command and give me a list of all valid usernames on the server. Worse, because of the way is written, that output will always be returned to me, so if I enter & cat /path/to/a/configurationfile I'll get given the contents of that file, which may or may not contain credentials (think about if the configuration file is a Joomla or WordPress configuration file).
Mitigation Techniques
I mentioned earlier that the tutorial's author had included some mitigation for the security issues, so let's first look at what those steps were
- Always run over https
- Put script in a password protected directory
- Never trust user input, consider more powerful input validation
All wise moves, certainly, but it fails to look at the bigger picture. Because the Apache process has been given sudo privileges any page on the server can potentially run the shell script we looked at earlier. So, if I as an attacker can find a way to make any other page on your server run arbitrary code, mitigation step 2 is completely and utterly wasted. Given the insecurities we've already looked at, it also means I could reset your root password and fully compromise the server.
Mitigation step 3 is something every developer should consider, and yet even the most basic of input cleansing wasn't handled in the PHP script.
Blind leading the Blind
Although the author has identified some of the security failings, he's failed to adjust his post to correct them. This isn't an issue if the only readers/users were developers who know how to resolve the issues, but it's clear from some of the comments that this isn't the case. One of the comments refers to a PHP error that any PHP developer would be able to resolve more or less immediately, indicating that the user doesn't have even a basic knowledge of what the code actually does.
One user even helpfully suggests that rather than limiting sudo privileges to the shell script, you could grant sudo ALL privileges - i.e. the Apache process could run any command as a superuser.
Conclusion
It is a very old post, but because it ranks very highly in Google a lot of eyes are likely still seeing it. To those who don't understand what's being discussed it can easily look like an almost perfect solution to the issue of resetting a users password from PHP, meaning that some are going to blindly use it and so render their systems subject to a serious vulnerability.
Make no mistake, if an attacker gains root access, you have little choice but to re-image the server and start again, there's just no way to guarantee the integrity of the system if the root account has been compromised. It's easy to copy and paste a tutorial, but this is the realistic potential outcome of following instructions that you don't understand.
There's no reason you can't ask the advice of a professional and then implement the steps yourself if needed, but when doing anything you are unsure about you should always err on the side of caution. It may seem expensive to pay someone to do something you've found an 'idiotproof' tutorial for, but the cost of paying the same person to recover a seriously compromised server is far, far higher.
