Strange grep /etc/shadow command appearing in my logwatch

Question

I'm seeing this entry in my daily logwatch output, sudo section:

/bin/grep -E ^pi: /etc/shadow

Should I be concerned? I certainly didn't run this command myself.

Answer 1

This is a trace of a default script (introduced in the November 2016 Raspbian release) which checks if you changed the password for the user pi.

The script is stored in /etc/profile.d/sshpasswd.sh and displays a warning if the SSH deamon was turned on, but the password for the pi user had not been changed from the default one (raspberry). It is called on each login.

The script in its original form:

check_hash ()
{
        local SHADOW="$(sudo -n grep -E '^pi:' /etc/shadow 2>/dev/null)"
        test -n "${SHADOW}" || return 0
        local SALT=$(echo "${SHADOW}" | sed -n 's/pi:\$6\$//;s/\$.*//p')
        local HASH=$(mkpasswd -msha-512 raspberry "$SALT")

        if systemctl is-active ssh -q && echo "${SHADOW}" | grep -q "${HASH}"; then
                echo
                echo "SSH is enabled and the default password for the 'pi' user has not been changed."
                echo "This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password."
                echo
        fi
}

check_hash
unset check_hash

---

In Raspbian Stretch the script has been changed to a one checking existence of /run/sshwarn file (on the other hand, created/deleted at boot time). It doesn't check the /etc/shadow on each login, but on the other hand if someone used an automated tool to change the password, they need also to explicitly remove the file, or reboot the machine:

export TEXTDOMAIN=Linux-PAM

. gettext.sh

if [ -e /run/sshwarn ] ; then
    echo
    echo $(/usr/bin/gettext "SSH is enabled and the default password for the 'pi' user has not been changed.")
    echo $(/usr/bin/gettext "This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.")
    echo
fi

Answer 2

Should I be concerned?

That depends what you mean by "concerned". If you mean, motivated to do some kind of more thorough audit to determine what process is responsible for this, then sure, why not. However, if you don't have a ready means of doing that, then I guess it depends on how motivated you are to find and use one (which could add up to "This is what I did on Saturday/the weekend/the first week of December..."); I would not bother unless that's something you are interested in for broader reasons.

A few points to consider:

• This is just a read of privileged information by a process that's obviously intended to be so privileged. That doesn't necessarily make it malicious.
• The information being accessed is pretty mundane (see man 5 shadow, and note that access to the "encrypted password" is not access to the password itself; passwords aren't actually stored anywhere, just a one-way hash of them, which is not useful except for verification).
• If someone wanted to be stealthy in doing this, this is not. However, that doesn't necessarily mean it isn't part of something malicious.

My guess is this is from some innocent but pi specific script. Raspbian is unusual in the unlimited superpowers it provides a regular user,¹ so this methodology (grepping /etc/shadow via sudo) would be pointless on most GNU/Linux systems. If the process responsible needs to do this, then normally it would be run as a process with a UID that did not need to use sudo, so very likely it's written by someone who knows how Raspbian is put together (such as someone responsible for some piece of Raspbian specific software).

It is not hard to imagine "non-innocent" here too, but you might just as well speculate about that without this, i.e., with no evidence at all. If someone is out to cause mischief, there's nothing about reading /etc/shadow that points to it by definition. It could be argued that there isn't much purpose in restricting read access to that file anyway.

---

^{1. Horrible, misguided, absurd. One of the first things I do with a Raspbian install (sometimes, before I even boot it the first time) is remove the pi user completely and snip out most of the nightmare in /etc/sudoers.}