7.2 SSH

Secure Shell (SSH) provides encrypted access to Unix
and Win32 command shells. Weaknesses in plaintext services such as
Telnet were often abused by attackers to compromise networks, so SSH
was introduced to provide encrypted access to Unix-based hosts for
maintenance purposes.

Before 1999, the only SSH servers available were for commercial use
and provided by SSH Communications (http://www.ssh.com) and
F-Secure
(http://www.f-secure.com). In
late 1999, the
OpenBSD team worked
to provide SSH support in Version 2.6 of their operating system, and
OpenSSH 1.2.2 was born. Commercial versions provided by SSH
Communications and F-Secure remain supported and are sold, but
OpenSSH has proved to be extremely popular and is now included with
most Linux distributions.

Due to its cryptographic nature, an SSH client is required to connect
to and authenticate with SSH. The free
OpenSSH package can
be downloaded from http://www.openssh.com.

For Windows users,
PuTTY
is a freely downloadable tool available with a host of other SSH
client utilities (including PSCP,
PSFTP,
andPlink) available from http://www.chiark.greenend.org.uk/~sgtatham/putty/.

7.2.1 SSH Fingerprinting

To correctly ascertain
vulnerabilities
that may be present in the target SSH service, first perform banner
grabbing by using telnet or
nc to connect to the SSH service. Example 7-1 shows how telnet can do
this: the banner shows the host is running
OpenSSH 3.5 patch level 1 using the SSH 2.0 protocol.

Example 7-1. Grabbing the SSH service banner using telnet

Security conscious administrators will often modify the SSH banner to
present false information. Example 7-2 shows this:
the SSH service supports the SSH 2.0 protocol, but the actual type
and version of the service itself is unknown (it's
set to 0.0.0).

If SSH-1.99 is reported by the SSH service, both
SSH 1.5 and 2.0 protocols are supported. Some SSH clients, such as
PuTTY, previously didn't support SSH 2.0, and many
administrators accordingly ran their services to be
backward-compatible.

7.2.2 SSH Brute-Force Password Grinding

By its very design, SSH is a protocol resilient to
brute-force attacks. The service first accepts the username and then
allows for three passwords to be provided. If the user fails to
provide the correct username and password combination, the
unauthorized access attempt is written to the system log.

Sebastian Krahmer wrote a threaded SSH2
brute-force tool called
guess-who. The utility allows for up to 30
attempts per second on internal networks, so mileage varies across
the Internet depending on server configuration and connection speed.
The tool compiles cleanly in Unix environments; find it at
http://packetstormsecurity.org/groups/teso/guess-who-0.44.tgz.[1]

[1] URLs for tools in this book are mirrored at the
O'Reilly site, http://examples.oreilly.com/networksa/tools.

An expect script available from http://examples.oreilly.com/networksa/tools/55hb.txt
is a simple way to perform brute force against both SSH1 and SSH2
services. The 55hb script simply parses usernames and passwords to
the Unix SSH client binary.

7.2.3 SSH Vulnerabilities

The presence of process manipulation
vulnerabilities within SSH services depends on two things:

The SSH server and version in use (OpenSSH, LSH, Cisco, or commercial
SSH)

The SSH protocol version the target server supports (1.0, 1.5, 1.99,
or 2.0)

Knowing the SSH service type, version, and which protocols are
supported, you can check vulnerability databases and sites, including
MITRE CVE, ISS X-Force, SecurityFocus, and Packet Storm, to ascertain
whether the services at hand are vulnerable to attack.

Two serious remote vulnerabilities uncovered in SSH since 2001 are
the SSH1 CRC32 compensation
vulnerability and the
OpenSSH 2.9.9-3.3
challenge-response bug. In the next few sections, I discuss these
bugs along with examples of exploitation. Many other bugs have been
found in SSH, but they rely on nondefault options enabled at
compilation or on valid username and password combination (these are
known as post-authentication vulnerabilities).

7.2.3.1 SSH1 CRC32 compensation vulnerability

On February 8, 2001, CORE-SDI released an advisory documenting a
remote integer overflow in several implementations of the SSH1
protocol. Ironically, this vulnerability is located in a segment of
code that was introduced to defend against exploitation of CRC32
weaknesses within the SSH1 protocol (see http://www.kb.cert.org/vuls/id/13877).

The attack detection function (detect_attack(
) located in
deattack.c) uses a dynamically allocated hash
table to store connection information that is then examined to detect
and respond to CRC32 attacks. By sending a crafted SSH1 packet to a
vulnerable host, an attacker can cause the SSH service to create a
hash table with a size of zero, resulting in an overflow and
arbitrary code being executed.

Full details of this vulnerability and vendor patches are available
at:

http://www.securityfocus.com/advisories/3088

http://www.kb.cert.org/vuls/id/945216

http://xforce.iss.net/xforce/xfdb/6083

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0144

Nowadays, most SSH servers support only Version 2 of the protocol and
aren't susceptible to this attack. If you see a
server respond with a 1.5 or 1.99 protocol string in its banner, it
is probably vulnerable.

7.2.3.2 SSH1 CRC32 compensation exploit

Later in 2001, a publicly available (but Linux precompiled) exploit
known as x2, x4,
or shack became available, mirrored
at http://packetstormsecurity.org/0201-exploits/cm-ssh.tgz.

Example 7-3 shows how I download, unpack, and run
the precompiled Linux shack exploit, revealing command-line options
and available target offsets.

The exploit takes a few minutes to run because it performs binary
searching and return-address brute-forcing to inject and run its
shellcode. Chapter 13 discusses exploitation
issues in some detail, discussing differences between simple stack
overwrites, integer overflows, and heap-corruption vulnerabilities.
The original x2 exploit source code is extremely
rare, but it's available from the
O'Reilly archive at http://examples.oreilly.com/networksa/tools/x2src.tgz.

7.2.3.3 OpenSSH challenge-response vulnerability

On June 26, 2002, Internet Security Systems (ISS) released an
advisory documenting a remotely exploitable heap overflow bug within
the challenge-response authentication mechanism of
OpenSSH (present within Versions
2.9.9 to 3.3). To exploit this vulnerability, the target SSH service
must compiled with BSD_AUTH or SKEY authentication options enabled,
which is the case within OpenBSD 3.0 and 3.1 in particular.

Full details of the vulnerability and respective vendor patches are
available at:

http://xforce.iss.net/xforce/xfdb/9169

http://www.cert.org/advisories/CA-2002-18.html

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0639

7.2.3.4 OpenSSH challenge-response exploit

ISS hasn't release any public exploit code relating
to this vulnerability. The GOBBLES security team, however, released
an SSH client patch exploit to remotely compromise OpenBSD 3.0 and
3.1 hosts running OpenSSH 2.9.9 to 3.3; it's
available at http://www.immunitysec.com/GOBBLES/exploits/sshutup-theo.tar.gz.

After compiling a patched SSH client
(gobblessh), you can run the tool and reveal the
usage and supported options, as shown in Example 7-5.

7.2.3.5 Other remotely exploitable SSH flaws

At the time of writing, the CERT vulnerability notes at http://www.kb.cert.org/vuls/ list the
remotely exploitable vulnerabilities in
SSH services (not including
denial-of-service or locally exploitable issues); they are detailed
in Table 7-1.

Table 7-1. Remotely exploitable SSH vulnerabilities

CERT ID

Date

Notes

VU#40327

09/06/2000

OpenSSH 2.1.1 and prior with the UseLogin option
allows remote execution of commands as root