Analysis of SlapperA Worm Behavior

1
Analysis of Slapper-A Worm Behavior

• Mark Stacey
• February 20th, 2005

2
Agenda

• Background
• Technical Dissection
• Severity and Remedy

3
Slapper-A Worm

• Background

4
Project Overview

• University of Idaho Security Techniques CS404
• Recreate an exploit in the RADICAL lab and
  analyze its behavior
• Small group consisting of two other people
• Exploit was chosen by this group
• Three weeks to complete
• Obtained fragmented code
• 35 hours of team collaboration
• Individual work

5
Laboratory Environment

• Radical Lab
• Completely enclosed from all outside networks
• Consists of twelve computers accessed from dumb
  terminals
• Each computer is bootable to various
  Linux/Windows/Solaris distributions
• Individual computers or entire lab can be quickly
  reloaded
• Selected students are given administrative access

6
Slapper-A History

• July 30th, 2002 A.L. Digital, Let and The Bunker
  disclosed four critical OpenSSL vulnerabilities
• Advisory 1
• A.L. Digital Ltd and The Bunker
  (http//www.thebunker.net/) are conducting a
  security review of OpenSSL, under the DARPA
  program CHATS.
• Vulnerabilities
• All four of these are potentially remotely
  exploitable.
• 1. The client master key in SSL2 could be
  oversized and overrun a buffer. This
  vulnerability was also independently discovered
  by consultants at Neohapsis (http//www.neohapsis.
  com/) who have also demonstrated that the
  vulnerability is exploitable. Exploit code is NOT
  available at this time.
• 2. The session ID supplied to a client in SSL3
  could be oversized and overrun a buffer.
• 3. The master key supplied to an SSL3 server
  could be oversized and overrun a stack-based
  buffer. This issues only affects OpenSSL 0.9.7
  before 0.9.7-beta3 with Kerberos enabled.
• 4. Various buffers for ASCII representations of
  integers were too small on 64 bit platforms.

Found at http//www.openssl.org/news/secadv_200207
30.txt
7
History Cont.

• Less than two months later Slapper-A is released
• Detected September 13th, 2002
• Virus characteristics published September 17th,
  2002
• Written in pure C to propagate between Linux
  systems
• Distributed denial of service attack
• Source code size 68.4 Kbytes

8
Vulnerable Systems

• Intel-based machines with OpenSSL version .9.6d
  or older and .9.7-beta
• Apache versions 1.3.xx
• Various Linux distributions
• Red Hat 1.3.6, 1.3.9, 1.3.12, 1.3.19, 1.3.20,
  1.2.22, 1.3.23, 1.3.26
• SuSE 1.3.10, 1.3.19, 1.3.19, 1.3.20, 1.3.23
• Mandrake 1.3.14, 1.3.19, 1.3.20, 1.3.23
• Debian 1.3.26
• Original Gentoo release

9
Vulnerable Population

• Apache installations more than 60 of public
  websites
• Estimated 10 of these have enabled OpenSSL
• After released, by September 16th, 2002, 100
  countries had reported infections

10
Slapper-A Worm

• Technical Dissection

11
Technical Overview

• Exploits long SSL2 key argument buffer in libssl
  library used by the mod_ssl module for Apache 1.3
  Web servers
• Specifically the free() function
• Technically two overruns two phases
• Similar to Free BSD Scalper worm

12
Propagation

• Scans network for IPs formed as standard a.b.c.d
• a is chosen randomly but limited to one of 162
  hard-coded values ranging from 3 to 239
• b is chosen randomly as full one byte
• c and d are iterated thought all possible
  values from 0.0 to 255.255
• Skips some private local network classes

13
Propagation Cont.

• For every IP, if not looping back, connects to
  port 80
• Invalid GET request to fingerprint system
• HTTP header returned contains Apache version and
  Linux distribution on which it was compiled
• magic number
• Assumes Red Hat with Apache 1.3.23 if not
  detected
• 23 hard-coded architectures used to refine the
  attack

14
Global Offset Table GOT

• Architecture version supplies address of the
  Global Offset Table (GOT) entry of the free()
  library function
• Each function address is placed into the GOT when
  the system loader maps the image for execution
• Attack free() function address

15
GOT Example
0 8 0 9 a d f 8 fork 0 8 0 9 a e 6
4 malloc 0 8 0 9 a f 8 c free 0 8 0 9 a f a
8 fopen 0 8 0 9 a f b c socket
Function address looked up by magic number
16
Overruns

• Multiple overflows (phases)
• First phase locate critical field addresses
• Build attack buffer
• Second phase injects attack buffer and shell
  code
• Shell code executes embedded x86 machine-code
• Purpose
• Attack buffer needs exact address of shell code
• Placed in memory dynamically allocated on the
  heap
• Overwrites the cipher field of the SSL_SESSION
  structure with attack buffer located after the
  unchecked key_arg buffer

17
Phase I Overview

• Tasks
• Overflow buffer
• Change value of specified field
• Receive specified address from server to be
  placed in attack buffer
• Require absolute address of the shell code

18
Phase I

• Attempts to connect by default SSL port 443 with
  SSLv2 handshake
• Sends hello message and gets server response
• Sends client master key and key argument
• Key argument is specified with length longer than
  the maximum allowed
• (ssl_max_arg_length(8 bytes))
• Packet is parsed on the server in
  get_client_master() function of libssl

19
Phase I Cont.

• No boundary check is done on the key argument
  length
• Value is copied over to fixed length buffer
  key_arg in heap-allocated SSL_SESSION structure

20
Phase I Example

• Reveals the location of the heap

Value
Contents
Address
int ssl_version 2 unsigned int
key_arg_length 8 unsigned char
key_arg8 random int master_key_length 48
unsigned char master_key48 random unsigned
int session_id_length 32 unsigned char
session_id32 random ...other fields 68
bytes long... SSL_CIPHER cipher 0x081fxxxx uns
igned long cipher_id n STACK_OF(SSL_CIPHER)
ciphers 0x081f3698 ...more fields 16 bytes
long... prev_size 200 size PREV_INUSE
bit 20 1 STACK_OF(SSL_CIPHER)
0x081f35c8
Overflows key_arg buffer by 56 bytes, up to
session_id_length
Overwrites session_id_length with 0x70 (112)
21
Phase I Example Cont.

• client finished is sent and the server sends
  server finished
• Instead of the 32 byte session_id, 112 bytes are
  returned

Address
Contents
Value
int ssl_version 2 unsigned int
key_arg_length 8 unsigned char
key_arg56 random int master_key_length 48
unsigned char master_key48 random unsigned
int session_id_length 0x70 (112) unsigned char
session_id112 random ...other fields 68
bytes long... SSL_CIPHER cipher 0x081fxxxx uns
igned long cipher_id n STACK_OF(SSL_CIPHER)
ciphers 0x081f3698 ...more fields 16 bytes
long... prev_size 200 size PREV_INUSE
bit 20 1 STACK_OF(SSL_CIPHER)
Identifies the encryption method for SSL
Points to structure on heap directly after the
SSL_SESSION (where the shellcode will go)
The addresses of cipher, ciphers and the TCP port
used are added to the attack buffer
22
Apache Information

• The cipher field identifies the cipher for SSL
  to use, if this value is lost, the session ends
• In second phase this value is re-injected at the
  same location within the SSL_SESSION structure
• This requires two identical connections to the
  server and is only possible because Apache is
  process-based and not thread based

23
Apache Information Cont.

• Apache spawned processes have same heap
  structures and addresses for both connections
• We need two identical processes but Apache has a
  pool of running servers waiting for requests
• Slapper exhausts this pool before attacking
• Opens a 20 connections running at 100 millisecond
  intervals

24
Phase II Overview

• Corrupt heap management
• Inject shellcode in ciphers field
• Abuse free() library call to modify an arbitrary
  dword in memory (GOT entry of free())
• Call free() again redirecting control

25
Phase II

• Try to complete a second SSH handshake
• Sends client master key and key argument
• Key argument (attack buffer) has
• Overflow key_arg buffer again
• 24 bytes of specially crafted data
• 124 bytes of shell code
• After overflow, all members of the SSL_SESSION
  structure are overwritten
• Numeric fields are filled with A
• Pointer fields are set to NULL
• Pointer values cipher and ciphers are set back to
  their original values

26
Phase II Cont.

• Fake heap data overwrites the 24 bytes after the
  SSL_SESSION structure
• The glibc allocation routines have boundary
  tags in between memory blocks for management
• Free blocks are kept in double linked lists
  formed by next and previous pointers

27
Phase II Cont.

• Data injected after the SSL_SESSION structure
  poses a minimal-sized unallocated block with next
  and previous pointers
• Next GOT entry of free() minus 12
• Leaked (magic number)
• Previous Address to shell code
• Leaked ciphers field 16 for boundary tag

28
Phase II Example
Address
Contents
Value
int ssl_version 2 unsigned int
key_arg_length 332 unsigned char
keuy_arg8 'AAAAAAAA' int master_key_length
'AAAA' unsigned char master_key48 'AAA...AAA'
unsigned int session_id_length 'AAAA' unsigned
char session_id112 'AAA...AAA' ...other
fields 68 bytes long... SSL_CIPHER
cipher 0x081fxxxx unsigned long
cipher_id 'AAAA' STACK_OF(SSL_CIPHER)
ciphers 0x081f3698 ...more fields 16 bytes
long... prev_size 0 size PREV_INUSE
bit 26 1 next_ptr, previous_ptr 0x080994cc
0x081f36a8 prev_size 16 size PREV_INUSE
bit 16 0 shellcode ...execve
(/bin/sh)...
Values leaked in phase I
GOT entry of free() -12 architecture-dependant
29
Phase II Cont.

• Client sends a client finished to the server
  with a bogus session id
• Server aborts the session and frees the memory
  associated with it
• The SSL_SESSION_free() function of the OpenSSL
  library is invoked
• This calls glibc free() pointing to the modified
  SSL_SESSION structure

30
Aftermath

• free() consolidates blocks merging contiguous
  free blocks to avoid fragmentation
• This consolidation manipulates the linked list
  through the next and previous pointers
• Assumed to point to heap memory
• Next pointer is treated as pointing to block
  header, de-referenced
• Previous pointer (shellcode) is written to offset
  12 of the headers
• Result the shellcode address ends up in the GOT
  entry of free()

31
Aftermath Cont.

• Finally, on the next call to free() by the
  server, the modified GOT free() address is used
  and the control flow is directed to the shellcode

32
Final Operations

• Shell searches for the socket of the TCP
  connection with the attacking machine by using
  the getPeerName() function call
• Duplicates matching socket descriptor to the
  standard input, output, error
• Standard shell /bin/sh called
• Attempts to gain root privileges by calling
  setuid()with all UIDs set to 0
• Fails Apache starts with root and switches to
  unprivileged user apache using setuid()

33
Executing Inside the System

• Saves an encrypted copy of source code in
  /tmp/.uubugtraq
• Decrypts code to /tmp/.bugtraq.c
• Compiles source to /tmp/.bugtraq

34
Finishing Attack

• Backdoor on UDP port 2002 for providing
• Direct communication with another infected
  machine
• Relating data packets to another infected machine
• Broadcasting data packets to all infected
  machines
• Run command line on the machine
• Initiate a distributed denial of service (DDOS)
  attack using UDP/TCP/DNS?RAW
• Download a binary from remote machine via HTTP
  and executing it
• Send mail
• Send hacked machine information to master node

35
Peer to Peer Communication

• Misc. facts/features
• 2002 socket prevents running multiple worms at
  the same time
• Parent sends a periodically updated list of hosts
  and their addresses on malicious network to child
  nodes
• Peer to peer network on top of UDP provide
  checksums, sequence numbers, acknowledge packets

36
Slapper-A Worm

• Severity and Remedy

37
Severity

• F-Secure engineers added their own machine to the
  worms network
• Sunday September 15th, 2002 at 1700 GMT (less
  than 40 hours after release)
• 5987 machines in worm network
• Monday September 16th, 2002 at 1445 GMT
• 11249 machines in worm network
• Monday September 16th, 2002 at 1600 GMT
• 13892

38
Prevention

• Current updates and patches
• Maintain knowledge of immediate threats
• Firewalls not accepting communication without ACK
  packets
• Watch for NoP sleds and shell code transfer
• Before encrypted data transfer is established

39
Remedy Once Infected

• Slapper-A may be removed by killing the worms
  processes and removing the following files
• /tmp/.uubugtraq
• /tmp/.buqtraq.c
• /tmp/.bugtraq
• Upgrade OpenSSL to fixed version .9.6e or above
  to avoid re-infection

40
Closing

• Closing points
• Very small time elapse from concept to
  implementation
• Large community of malicious developers
• Financial gain / challenge or hobby / quest for
  power / trend
• These attacks are complex
• Automated attacks are the most dangerous
• Script kiddies
• One click limited knowledge great damage
• One line of code can provide significant impact
• strcpy( ) vs. strncpy( )

41
Resources

• BullGaurd
• http//www.bullguard.com/antivirus/vit_slapper_a.a
  spx
• Virus List
• http//www.viruslist.com/en/viruses/encyclopedia?v
  irusid23874
• F-Secure
• http//www.f-secure.com/v-descs/slapper.shtml
• Sophos
• http//www.sophos.com/virusinfo/analyses/linuxslap
  pera.html
• Symantec
• http//securityresponse.symantec.com/avcenter/refe
  rence/analysis.slapper.worm.pdf
• OpenSSL
• http//www.openssl.org/news/secadv_20020730.txt