Case study: SSH

1
Case study SSH

• Lecture Notes for 91.561UMass Lowell Computer
  ScienceDavid Martin

2
Secure Shell

• Not really a shell
• Originally replacement for r-commands
• Encryption
• Good authentication

• Generally, interactive secure sessions
• Login
• Remote command execution
• Port and X forwarding
• Authentication forwarding
• Flow control
• Terminal handling
• Signal propagation
• Compression

3
Secure Shell

• Program versus protocol versus company
• Will concentrate on SSH-2 protocol
• Mercury, Saturn ssh command is OpenSSH_3.1p1,
  SSH protocols 1.5/2.0
• scp, sftp commands
• http//www.ietf.org/html.charters/secsh-charter.ht
  ml
• See also http//library.uml.edu Safari books

4
SSH Layers
5
Transport protocol

• 1. Introduction (from draft-ietf-secsh-transport-1
  5.txt)
• The SSH transport layer is a secure low level
  transport protocol. It provides strong
  encryption, cryptographic host authentication,
  and integrity protection. Authentication in this
  protocol level is host-based this protocol does
  not perform user authentication. A higher level
  protocol for user authentication can be designed
  on top of this protocol. ... Key exchange method,
  public key algorithm, symmetric encryption
  algorithm, message authentication algorithm, and
  hash algorithm are all negotiated. It is expected
  that in most environments, only 2 round-trips
  will be needed for full key exchange, server
  authentication, service request, and acceptance
  notification of service request. The worst case
  is 3 round-trips.

6
Example session

• telnet mercury 22
• SSH-2.0-foo
• vs
• SSH-1.5-foo
• ssh v mercury
• (Host keys)
• (User authentication methods)

7
4. Binary Packet Protocol

• Each packet is in the following format
• uint32 packet_length
• byte padding_length
• byten1 payload n1 packet_length -
  padding_length - 1
• byten2 random padding (4..255 bytes) n2
  padding_length
• bytem mac (message authentication code)
  m mac_length

8
4.3 Encryption

• An encryption algorithm and a key will be
  negotiated during the key exchange. When
  encryption is in effect, the packet length,
  padding length, payload and padding fields of
  each packet MUST be encrypted with the given
  algorithm. The encrypted data in all packets sent
  in one direction SHOULD be considered a single
  data stream. For example, initialization vectors
  SHOULD be passed from the end of one packet to
  the beginning of the next packet. All ciphers
  SHOULD use keys with an effective key length of
  128 bits or more. The ciphers in each direction
  MUST run independently of each other, and
  implementations MUST allow independently choosing
  the algorithm for each direction (if multiple
  algorithms are allowed by local policy).
• 3des-cbc REQUIRED
  three-key 3DES in CBC mode
• blowfish-cbc RECOMMENDED Blowfish in
  CBC mode
• ...
• aes256-cbc OPTIONAL AES
  (Rijndael), CBC, 256-bit key

9
4.5 Key exchange methods

• The key exchange method specifies how one-time
  session keys are generated for encryption and for
  authentication, and how the server authentication
  is done.
• Only one REQUIRED key exchange method has been
  defined diffie-hellman-group1-sha1
• Additional methods may be defined as specified in
  SSH-ARCH.

10
6. DH with Server Authentication
2. S generates a random number y (0 lt y lt q) and
computes f gy mod p. S receives "e". It
computes K ey mod p, H hash(V_C V_S
I_C I_S K_S e f K) (these elements
are encoded according to their types see below),
and signature s on H with its private host key. S
sends "K_S f s" to C. ... 3. C verifies
that K_S really is the host key for S (e.g. using
certificates or a local database). C is also
allowed to accept the key without verification
however, doing so will render the protocol
insecure against active attacks (but may be
desirable for practical reasons in the short term
in many environments). C then computes K fx
mod p,
11
5.2 Output from Key Exchange

• The key exchange produces two values a shared
  secret K, and an exchange hash H. Encryption and
  authentication keys are derived from these. The
  exchange hash H from the first key exchange is
  additionally used as the session identifier,
  which is a unique identifier for this connection.

12
5.2 Output from Key Exchange

• Encryption keys MUST be computed as HASH of a
  known value and K as follows (sid is session ID)
• Initial IV client to server HASH(K H "A"
  sid)
• Initial IV server to client HASH(K H "B"
  sid)
• Encryption key client to server HASH(K H
  "C" sid)
• Encryption key server to client HASH(K H
  "D" sid)
• Integrity key client to server HASH(K H
  "E" sid)
• Integrity key server to client HASH(K H
  "F" sid)

13
User authentication

• rhosts (severely deprecated v 1 only)
• Network layer tests only
• Passwords
• Protocol sends username/password as unit, not
  interactively
• But chained connections
• Public keys
• Kerberos
• Host keys
• Authentication agent forwarding with A

14
Connection Management

• Think of an embedded set of TCP streams
• Each has
• Local and remote ID
• Window size
• Max packet size (bulk vs interactive)
• Handles most UI aspects
• Pseudo-terminals
• Remote commands
• X11
• Flow control

15
Interesting attacks

• The user authentication protocol is subject to
  man-in-the-middle attacks if the encryption is
  disabled. Secsh-arch
• Keystroke analysis (Herbivore)
• Bellare Kohno Namprempre ACM CCS 2002
• Verifying plaintext guesses
• Through IV chaining
• Through MAC wraparound
• CRC32 compensation detector attack in SSH-1
  security patch (next slides)

16
deattack.c bug

• Taken from CORE-SDI, http//www1.corest.com/common
  /showdoc.php?idxseccion10idx81
• Technical Description - Exploit/Concept
  CodeMost SSH distributions incorporated the
  file deattack.c released by CORE SDI in 1998. The
  file implements an algorithm to detect attempts
  to exploit the CRC-32 compensation attack by
  passing the ssh packets received from the network
  to the detect_attack() function in deattack.c
  .../ detect_attack Detects a crc32
  compensation attack on a packet
  /intdetect_attack(unsigned char buf, word32
  len, unsigned char IV) static word16 h
  (word16 ) NULL static word16 n
  HASH_MINSIZE / HASH_ENTRYSIZE register
  word32 i, j word32 l ...
• buf is the ssh packet received, len is the length
  of that packet. The received packet is comprised
  of several blocks of cipher text of size
  SSH_BLOCKSIZE and each of them is checked against
  the others to verify that different packets dont
  have the same CRC value, such behavior is symptom
  of an attack.The detection is done using a hash
  table that is dynamically allocated based on the
  size of the received packet.

17
deattack.c continued

• ... for (l n l lt HASH_FACTOR(len /
  SSH_BLOCKSIZE) l l ltlt 2) if (h NULL)
  debug("Installing crc compensation attack
  detector.") n l h (word16 )
  xmalloc(n sizeof(word16)) else ...Due
  to the improper declaration of 'n' above (it
  should be a word32) by sending crafted large ssh
  packets (length gt 216) it is possible to make
  the vulnerable code perform a call to xmalloc()
  with an argument of 0, which will return a
  pointer into the program's address space.It is
  worth mentioning that existing standards promote
  two possible behaviors for malloc() when it is
  called with an argument of 0 - Failure,
  returning NULL - Success, returning a valid
  address pointing at a zero-sized object.Most
  modern systems implement the later behaviors and
  are thus vulnerable. Systems which have the older
  behaviors will abort the connection due to checks
  within xmalloc()It is then possible to abuse
  the following code to in order write to arbitrary
  memory locations in the program (ssh server or
  client) address space, thus allowing an attacker
  to execute arbitrary code on the vulnerable
  machine

18
deattack.c continued

• for (c buf, j 0 c lt (buf len) c
  SSH_BLOCKSIZE, j) for (i HASH(c) (n
  - 1) hi ! HASH_UNUSED i (i 1)
  (n - 1)) if (hi HASH_IV)
  if (!CMP(c, IV)) if
  (check_crc(c, buf, len, IV)) return
  (DEATTACK_DETECTED) else
  break else if (!CMP(c, buf
  hi SSH_BLOCKSIZE)) if
  (check_crc(c, buf, len, IV)) return
  (DEATTACK_DETECTED) else
  break hi j A
  would-be attacker does not need to authenticate
  to the SSH server first or to have the packets
  encrypted in a meaningful way to perform the
  attack.Even if that was the case, the session
  key used for encrypting is chosen by the ssh
  client and it is therefore trivial to implement
  an exploit (in the sense of the cryptography
  knowledge required to do it). However, a small
  degree of knowledge in exploit code development
  would be needed to implement a working exploit.

19
Local Statistics (Spring 2003)

• Users with .ssh directories who also have private
  keys 10 (18)
• Users with .ssh directories who also have
  authorized_keys 44 (79)
• CS cluster users 2419
• CS users with .ssh directories 56 (2)
• So most users just type their passwords

20
Biggest Problem?

• Host keys
• Works right out of the box!
• What happens when key changes?
• Better behavior in openssh
• Much better than cleartext or rhosts