How to Break-in to an Internet Server

Warren Toomey
wkt@cs.adfa.edu.au

School of Computer Science
Australian Defence Force Academy

Abstract

To break into an Internet server, you can exploit weaknesses in the server's applications with tools such as SATAN and Strobe. Alternatively, you can use home-grown packets to `spoof' the IP and TCP protocols.

This presentation looks at these forms of attack, and describes daemon programs and kernel modifications which monitor and log these sorts of activities.

A summary and review of the last six months of log information will be given for the FTP and WWW server minnie.cs.adfa.edu.au.

This document is a verbatim copy of the slides presented in my seminar - Warren.

Introduction

The growth of the Internet brings with it a higher risk of
network attack by hackers.

System vulnerability tools are useful for both sysadmins and would-be hackers.

Hackers are also using sophisticated protocol `spoofing'
methods to penetrate systems.

Many attacks are based on implied trust of a client's domain name or IP address.

Server vulnerabilities due to assumptions made about:

• Format of data from client machines, and
• Authenticity of data from client machines.

Introduction

I will look at the following attacks:

• Strobing of a server's network ports,
• Strobing using half-open TCP connections,
• Attacks on vulnerable network applications,
• Domain name corruption attacks,
• The TCP sequence number attack,
• Packet redirections, and
• IP fragmentation.

As well, I will examine measures to help prevent some of these attacks.

Strobing Network Ports

An Internet server has 65,536 TCP and 65,536 UDP ports.
Not all have attached services.

In general, a specific service always uses the same port:

• FTP on port 21, Mail on port 25, WWW on port 80.

A hacker can find out what services you run by connecting to all of your network ports. If the connection succeeds, you run that service.

The hacker uses this list of services to look for potential
vulnerabilities.

The service might also provide version information on
connection. This helps determine specific vulnerabilities.

Catching Port Strobing

Programs like TCP_Wrappers restrict connections to services on a per-machine/per-subnet basis.

Any unauthorised connection is established, but immediately dropped:

Connections to unused ports not logged. Rulesets use IP
addresses and machine names. More later.

Half-open Connections

Strobe connections will be logged by TCP_Wrappers.

Sending only the first packet of a handshake is enough to tell if a service is running.

As connection not fully established, TCP_Wrappers does not see it, and nothing is logged.

This event frequently occurs on the Internet. Possible strobes come from the same client and to different server ports.

Vulnerable Network Applications

On Internet servers, many network services run with full
privileges. Programming defects make these services
vulnerable to attack.

Recent Unix vulnerabilities found are:

• Ftpd: bad installation allows unauthorised exec.
• Telnetd: environment variables can subvert security.
• Named: corruption/infection of name/address lookups.
• Syslog library: buffer overflow allows root login.
• Sendmail: several vulnerabilities which allow root execs.

Sysadmins can only play `catch up' in this area. Read the CERT advisories. Get newer versions. Use SATAN and ISS.

Domain Name Corruption Attacks

If a server places trust in a client's domain name, this trust can be subverted.

The Domain Name servers map domain names to IP addresses and back. Each domain has a single authority, and several secondaries/caches. There are forward and reverse mappings.

Both mapping are not necessarily done by the same Name server.

This means that a pair of forward/reverse lookups may not give the original answer.

Domain Name Corruption Attacks

If a hacker can alter these mappings, he can masquerade as a trusted client.

This is especially true for reverse lookups, as humans prefer to set up trust rules based on machine names:

1. Rlogin connection from bad.guy.com (10.10.10.10) arrives.
2. Server does reverse lookup on 10.10.10.10.
3. Hacker runs Name server for domain 10.10.10.X.
4. Hacker's Name server gives bogus answer nice.guy.com.
5. Server allows rlogin connections from nice.guy.com.

Hackers also try to insert bogus DNS information into legitimate Name servers. Upgrade to BIND 4.9.3.

TCP Sequence Number Attacks

If TCP sequence numbers are predictable, a hacker can forge a connection from another machine.

The hacker doesn't need to see the packets from the server; the server believes the hacker is the trusted client.

TCP Sequence Number Attacks

Most versions of Unix set next seqno S = last seqno S + K1, with a periodic increment of K2.

Thus the server's sequence number is very predictable.

The hacker must build his own packets, and `gag' the trusted client, so as to keep the connection alive.

This is easily done on any Internet machine where the hacker has full privileges: Macs, Windows etc.

This attack was successfully used by Kevin Mitnick to break-in to several Internet machines 14 months ago.

Read the book Takedown by Tsuomo Shimomura, one of the victims.

Packet Redirection

A hacker can redirect packets for a machine by using ICMP Redirects or IP Source Routing.

The hacker can then return these packets back to the redirected machine, and sniff for plaintext passwords etc.

Packet Redirection

The packet redirections and the sequence number attack depend on forged packets from the 'inside' coming from the 'outside'.

Routers can detect packet redirections and `inside from outside' packets.

Set up your routers to reject these packets.

Hackers can fragment redirection (and other) packets to fool some routers.

Routers should detect/reject packets once they are
reassembled, not beforehand.

This router vulnerability is slowly being fixed. Hassle your router vendor.

Warren's Server

I run minnie.cs.adfa.edu.au, a FreeBSD server with these services:

• Anon ftp to 500M of files, with WU-FTP 2.4.
• Web service to 100M of files, using Apache 0.8.8.
• Email using a wrapped Sendmail 8.6.10.
• NTP using Xntpd 3.3g.
• Telnet service with Berkeley telnetd.
• Rsh service using Berkeley rshd.
• Domain Name service using Berkeley named 4.9.3.

There are no other services. Some services are restricted by TCP_Wrappers. All services pass through TCP_Wrappers for logging.

Kernel Modifications

It is simple to add code to the kernel to log suspicious network behaviour. Any modifications to the kernel must be well scrutinised. The FreeBSD kernel was modified to perform:

• Logging of connection on unused ports.
• Logging of half-open connections.
• Randomisation of the TCP sequence number.
• Log & ignore packets with ICMP redirects.
• Log & ignore packets with IP source routes.
• Logging of programs run by root.

This provides information about suspicious events. The TCP sequence number attack and redirection attack is defeated.

TCP Attempts for June - December 1995

Port Service Jun Jul Aug Sep Oct Nov Dec Sum

113 ident 309 469 513 509 391 973 875 4039

119 nntp 17 16 14 22 9 111 13 202

70 gopher 13 4 5 3 6 17 4 52

8001 alt-www 4 2 12 1 19

87 ttylink 1 3 4 2 2 12

2000 callbook 1 1 8 10

8080 alt-www 4 1 2 3 10

513 rlogin 2 1 1 1 1 6

2012 ttyinfo 1 4 1 6

131 cisco-tna 3 2 5

2016 bootserver 3 3

1993 snmp-tcp-port 1 1

Attempts to connect to Ident are legitimate.

Attempts to connect to NNTP, Gopher, Prospero, talk,
alternate WWW ports are probably mistakes.

Most of the remaining TCP attempts are suspicious. The
attempts on bootserver and cisco-tna are.

UDP Attempts for June - December 1995

Port Service Jun Jul Aug Sep Oct Nov Dec Sum

512 biff 9 18 9 8 8 88 48 188

1525 prospero 2 3 22 10 37

518 ntalk 6 2 8

517 talk 7 7

161 snmp 3 3

8305 2 2

525 timed 1 1

1874 1 1

62001 1 1

62010 1 1

62015 1 1

Data from the Computer Science subnet has been omitted to remove `noise'. Attempts to connect to SNMP are suspicious.

Minnie does not attract much attention. Results from
archie.au would be much more interesting.

There were no TFTP, NFS, X11, rexec or Sun RPC attempts.

Packet Suckers

It makes sense to record packets to sensitive ports.

I've written port logging programs which can be used on in-use or
unused ports.

Example packet logs are given below:

• An attempt to TFTP my /etc/passwd file:

  Jan 25 12:15:10 Pkt from some.where.com port 1062 to tftp
   0- 00012f65 74632f70 61737377 64006e65     ../etc/passwd.ne
  16- 74617363 696900                         tascii.

• A root rlogin attempt:

  Jan 25 13:35:03 Data from some.where.com port 1016 to login
   0- 00776b74 00726f6f 74007874 65726d2f     .wkt.root.xterm/
  16- 39363030 00                             9600.

Logging Sun RPC Requests

I've also written a portmopper program to `fake' and log RPC requests.

This is harder as the services don't listen on the same port each time.

• An attempt to mount Minnie's root filesystem:

  Feb 16 12:32:34 bad getport(nfs)    from henry.cs.adfa.edu.au
  Feb 16 12:32:34 bad getport(mountd) from henry.cs.adfa.edu.au
  Feb 16 12:32:35 fake connect from henry.cs.adfa.edu.au to mountd
   0- 322031d2 00000000 00000002 000186a5     2 1.............
  16- 00000001 00000001 00000001 00000030     ...............0
  32- 3123dd3a 00000013 68656e72 792e6373     1#.:....henry.cs
  48- 2e616466 612e6f7a 2e617500 00000000     .adfa.edu.au.....
  64- 00000000 00000002 00000000 00000000     ................
  80- 00000000 00000000 00000001 2f000000     ............/...

Conclusion

There is a ongoing `arms race' between intruders and
sysadmins.

Many current systems do not log suspicious network events. TCP_Wrappers performs useful work but is not enough.

Results to date show some suspicious behaviour, but not much.

Packet loggers can give more detail about break-in attempts. Many other suspicious network events can also be logged and ignored.

Automated tools are needed to summarise the logged data. The summary must be useful to the sysadmin, and
understandable.

Data from many systems might help find hacker trends.