How to Break-in to an Internet Server
School of Computer Science
Australian Defence Force Academy
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.
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:
I will look at the following attacks:
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:
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
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.
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.
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:
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:
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.
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.
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.
I run minnie.cs.adfa.edu.au, a FreeBSD server with these services:
There are no other services. Some services are restricted by TCP_Wrappers. All services pass through TCP_Wrappers for logging.
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:
TCP Attempts for June - December 1995
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
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.
It makes sense to record packets to sensitive ports.
I've written port logging programs which
can be used on in-use or
Example packet logs are given below:
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.
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.
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 ............/...
There is a ongoing `arms race' between intruders and
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
Data from many systems might help find hacker trends.