2

Suppose I have the following code in a PHP web application.

$encrypt ? $password = generatePassword($passwordstrength): $password="";
$estring = "7z a -p$password -mx0 packFoo.aes.7z mydir/foo";
if($encrypt) {
    exec($estring);
}
mailuser($password);//uses standard PHP mail function

The password is generated at random by a function that uses PHP rand().

I have not found the password in /var/logs and not in .bash_history.

I need to know if the value of $password can be recovered from the server in the event that the server is compromised. Ultimately, can I claim that the value of $password is not stored on the server?

user
  • 28,901
user127379
  • 121
  • 3
  • Your best bet is probably your mail system's logs or outbound mail archive. – Mat Jun 07 '13 at 11:23
  • do you know the command to grep every text file on the system for a given string? I will search for "7z a -p" . – user127379 Jun 07 '13 at 11:25
  • 2
    Chances are about 0 that that string will have been logged unless you've specifically set up auditing or non-default levels of logging of some sort (not even sure there are logging options for that in PHP). – Mat Jun 07 '13 at 11:27
  • 1
    (BTW your option #2 is illegal in some places, regardless of the reason you'd do that.) – Mat Jun 07 '13 at 11:28
  • LOL yeah I guess that's not my responsibilty, I just have to make the server secure. I think I'll hash the email address as well. – user127379 Jun 07 '13 at 11:30
  • For what reason do you need the $estring value? Is this after the fact, or in anticipation of a breach? Is the code in the question intentional or left by the attacker? What is the significance of mailing something to somewhere? IMO there are just too many loose ends for this question to be answerable as it stands, even if we do take the stated question ("is there any trace of...?") as it stands. – user Jun 07 '13 at 11:51
  • The reason, I have just edited above. I don't think the rest of your the comments are fair. – user127379 Jun 07 '13 at 12:23
  • @user127379 I have edited your question to try to make it clearer and more answerable, based on the comments. Feel free to edit further or revert the edit in case you feel I changed the meaning of your question. – user Jun 07 '13 at 13:21

2 Answers2

3

As pointed out by Mat in the comments, unless you specifically set up auditing it is highly unlikely that the command as such is deliberately stored anywhere and kept in a directly accessible form. grep -lR ... / as root might be an enlightening experience (you may want to remount everything noatime first...).

However, there is always a "but". In this case, one obvious possibility that I can see (especially as you don't securely clear the $password or $estring variables in the code you have shown) is that the contents of those might be written out to swap space. That would mean that they are committed to permanent storage at least for a while even not in the presence of an active attacker. This can be largely mitigated by either disabling swap entirely, or running swap encrypted with a random encryption key, which makes the swap inaccessible after a reboot (because the decryption key needed to make sense of it is lost when the system RAM is cleared).

I would imagine that 7zip is well-behaved enough to clear out the password from its command line quickly and then further from its internal variables as soon as it is no longer needed, but things like expanded key schedules might be kept for a longer period of time thus increasing the potential for them being swapped out. Those won't necessarily allow recovery of the password, but they may very well allow recovery of the plaintext from the encrypted archive. A simple ps axw issued at just the right moment will show someone who is logged in the password in plain text from the command line, but it isn't stored and the window of opportunity is small.

When you send the e-mail, I presume that it contains the password in clear text form (or something that is easily derived into the corresponding plaintext, such as a Base64 encoded message body). That e-mail almost certainly will be temporarily written to the system's mail queue, which means that the password does end up on disk (unless you have the mail queue directory on a RAM disk, which besides the fact that the mail queue is supposed to be on persistent storage presents its own set of problems operationally). Especially if you are running a smarthost setup the queue file will likely be deleted very soon afterwards, but since it has been written to disk, "the damage is done" so to speak. Something like strings /dev/sd? on any server the mail passes through will probably recover the password to anyone who knows what to look for unless you take specific steps to mitigate this threat.

Of course, e-mail in the first place isn't designed to be completely secure. The only way to have reasonable confidentiality assurances with e-mail over SMTP (even if you are using SMTP over SSL, or STARTTLS, throughout the entire chain of mail servers) is end-to-end encryption like S/MIME or OpenPGP.

TL;DR: Your web application probably doesn't deliberately store anywhere the command including the password, or the password itself, but other components it relies on very well might during the course of normal operations.

Community
  • 1
user
  • 28,901
2

First, note that you have a bigger security problem: rand() is not suitable to generate a password. It uses a fast, predictable pseudo-random number generator. Use openssl_random_pseudo_bytes() instead, as clearly stated in the documentation.

It is common to log the names of commands, but uncommon to log their arguments. So the password will not end up in a system log unless that server has been configured for an unusual amount of logging.

The command line can be snooped on by any process running at the same time as 7z, all it has to do is run ps.

You can avoid putting the password on the command line by passing just -p (7z a -p -mx0 packFoo.aes.7z mydir/foo); in that case you'll need to use Expect to send the password (twice) to 7z, because it insists on the password coming from a terminal and being entered twice. Here's a similar example with ssh.

On the other hand, the password will be stored in the filesystem for some time. It will definitely be stored in a temporary file in the mail spool. After the mail is sent, the temporary file will be deleted, but the password may remain accessible by a process running as root that accessing the disk directly to read the free space. The password may also be swapped out at some point.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060