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
• 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 ssh command is OpenSSH_3.1p1, SSH
  protocols 1.5/2.0
• scp, sftp commands
• http//tools.ietf.org/wg/secsh/
• See also http//library.uml.edu Safari books

4
Example session

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

5
SSH Layers
6
Transport protocol

• 1. Introduction (from http//tools.ietf.org/html/r
  fc4253)
• 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.
• 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.

7
6. 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
6.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
6.4 Data Integrity
?

• The value of 'mac' resulting from the MAC
  algorithm MUST be
• transmitted without encryption as the last part
  of the packet. The
• number of 'mac' bytes depends on the algorithm
  chosen.
• The following MAC algorithms are currently
  defined
• hmac-sha1 REQUIRED
  HMAC-SHA1 (digest length key
• length 20)
• hmac-sha1-96 RECOMMENDED first 96 bits
  of HMAC-SHA1 (digest
• length 12,
  key length 20)
• hmac-md5 OPTIONAL HMAC-MD5
  (digest length key
• length 16)
• hmac-md5-96 OPTIONAL first 96 bits
  of HMAC-MD5 (digest
• length 12,
  key length 16)
• none OPTIONAL no MAC NOT
  RECOMMENDED

10
6.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.
• Two REQUIRED key exchange methods have been
  defined diffie-hellman-group1-sha1 and
  diffie-hellman-group14-sha1
• Additional methods may be defined as specified in
  SSH-ARCH.

11
8. DH Key Exchange
2. S generates a random number y (0 lt y lt q) and
computes f gy mod p. S receives "e" from C. It
computes K ey mod p, H hash(V_C V_S
I_C I_S K_S e f K). S sends K_S
f s to C. ... _C, _S client, server V_
identification string I_ SSH_MSG_KEXINIT
message K_S server host key s signature of H
with private host key Values of 'e' or 'f' that
are not in the range 1, p-1 MUST NOT be sent or
accepted by either side.
12
7.2 Output from Key Exchange

• 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,
• 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.

13
7.2 Output from Key Exchange

• Encryption keys MUST be computed as HASH of a
  known value and K as follows (sid is session ID,
  which is the first H chosen before any rekeying)
• 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)

14
SSH Layers
15
User authentication layer

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

16
Connection Management layer

• 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 (try ssh X mercury.cs.uml.edu)
• Flow control

17
SSH as building block

• Port forwarding
• ssh L localporttohosttoport remotehost
• Tunnels localhostlocalport to remotehost's
  resolution of tohosttoport
• Can use to punch through firewalls
• Example access from classroom to Mercury rupdate
• -D for SOCKS forwarding and R for
  remote-to-local forwarding
• VPNs
• Can run PPP connection over SSH
• A bit convoluted, but it works
• Project 3
• Would handle confidentiality, integrity, and
  authentication
• Could use openssh or cryptlib toolkit

18
Example submit program

• Needs to read arbitrary files and deliver them to
  instructor's directory
• So instructors add line like this to their
  authorized_keys file
• command"/usr/local/bin/submit" ssh-dss
  AAAAB3NzaC1kc3MAAACBAMAKQ7sJVEkwNFLwYEZaEB4hvFr0Z
  ...
• the submit command then tars up files and sends
  them through ssh instructor_at_mercury using the
  appropriate key
• Allows submitting from any host that has the key

19
Interesting attacks

• The user authentication protocol is subject to
  man-in-the-middle attacks if the encryption is
  disabled. Secsh-arch
• Herbivore keystroke analysis (Usenix Security
  2001)
• 50x password cracking advantage over brute force
• 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)

20
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.

21
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

22
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.

23
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

24
Biggest Problem?

• Host keys
• Works right out of the box
• What happens when key changes?
• ssh.fi version warning, type y to continue
• openssh version error, instruction on how to fix
• Much, much better than cleartext or rhosts