Sockets and Services from a Security Point of View

Sockets and Services from a Security Point of View
Overview
In Chapter 3, you saw the first four layers of the OSI stack—those layers which transfer data,
irrespective of what that data is, from one computer to another over the Internet. This chapter
focuses on the security implications of the types of data exchanged between computers using these
lower level protocols. We'll talk about common protocols, such as HTTP and FTP, hidden or−
problematic ones, such as RPC and Finger, as well as obscure ones, like DHCP and SNMP.
A network intruder will look for security weaknesses at every point in your network architecture. If
you have adequately locked down the Physical, Data Link, Network, and Transport layers of your
network, the wily hacker will simply move up to those protocols and services your network does
expose to the Internet. These application specific protocols are actually much easier to exploit, so−
many hackers start there and drop down to the Network or Transport level when they need to
circumvent a protocol's security mechanisms.
In this chapter, we'll go over each of the most commonly used Internet services, briefly examining
each for their weaknesses and abuse potential. First, however, we'll discuss sockets and services in
general, identifying typical service vulnerabilities so you can identify potential problems when you
need to install services on your own network.
Evaluating Socket−Based Services
Which services are safe to allow through your firewall, which are not safe, and which ones do you
do need to keep an eye on? When a new service becomes popular, or when you want to give your
network clients a new Internet based tool, what do you look for when you evaluate the service?−
Later in this chapter, we will examine the most common protocols that use IP as a transport and are
passed through firewalls. For those protocols, and for any others you may want to support in your
network, you should ask the following questions:
• How complex is the service?
• How might the service be abused?
• What information does the service dispense?
• How much of a dialog does the service allow?
• How programmable or configurable is the service?
• What other services does the service rely on?
• What sort of authentication does the service use?

How Complex Is the Service?
Complex services are easier to exploit than simple services. The Echo service, for example, simply
transmits back to the client whatever the client sends to it. The Echo service is useful for debugging
and for network connectivity testing, but it is difficult to see how the Echo service could be exploited
to gain control of the computer running the service. Since the Echo service accepts data from the
client, however, it must be programmed to correctly handle being fed too much data at once.
77
The mail service, on the other hand, is a large, complex piece of software that accepts data (mail)
from and returns data to the client, as well as reads and stores data and configuration information
on the computer's hard drive. Many mail services (POP and IMAP, for example) require
authentication before the client can use the service. SMTP, on the other hand, allows any
connecting user to send mail as though it came from any user—even a non existent one. If the−
authentication mechanism can be subverted, the passwords hacked, or the service tricked into
sending out private data (such as your password file), the hacker can use the service to get enough
information to break into your computer through other means, such as FTP or Telnet.
Buffer Overruns and Denial of Service Floods− −
Buffer overruns, as described in Chapter 2, are a potential weakness of any service that receives
data from clients. Optimistic programmers expect network clients to play by the rules and only send
as much data as would be appropriate for the protocol. For example, the destination address portion
of an SMTP message should be somewhere between 4 and 200 characters. But what if the client
sends several mega bytes instead?−
A correctly written implementation of the protocol will simply discard the excess data and return an
error. An incorrectly written implementation, which does not check how much data is being received,
may overwrite its own program code and either crash or (if the sender of the data sent it maliciously)
begin executing the excess data as a program.
Early versions of Sendmail had exactly this kind of security hole, and the infamous Internet Worm
used this weakness to gain control of target computers and bring the whole Internet to its knees.
A related attack for computers that store data (such as mail) is to keep sending data until the
storage space on the server runs out. This is a denial of service attack that, although it does not− −
give the hacker control of the computer, renders the computer unusable by its intended clients.

How Might the Service Be Abused?
Some services might be simple and innocuous in themselves, but can be turned to unexpected and
detrimental uses. Chargen, for example, is a simple Unix service that sends out ASCII characters
over and over. Chargen is a useful network programming and testing tool, because there are certain
classes of networking problems that become evident when you can look at a stream of data
spanning a whole range of binary representations. A communications channel that clears (or sets)
the top two bits of every data word, for example, becomes obvious because the pattern of
characters from Chargen will change as well.
An unscrupulous hacker, however, might exploit this protocol by forging a SYN packet (connection
request) that redirects the output of Chargen to another computer and port. This way the hacker can
flood the target computer with data that doesn't even originate from his own computer!
What Information Does the Service Dispense?
Some services may be simple, terse, and still dangerous to your network security. Finger, for
example, was designed to help Unix users contact each other. A Finger request will tell you whether
or not there is an account for an individual on a computer, what that account name is, when the user
last logged on, additional contact information for the user, and whatever else that user would like to
tell the world.
78
That information is certainly useful if you need to know a coworker's e mail address or phone−
extension. It is also incredibly useful for a hacker who wants to verify the existence of an account,
find a dormant one, or get clues to the identity and personality of an account holder. You won't find
many computers on the modern Internet that support the Finger protocol. The Whois service is
another one that you might not want to run on your network due to the amount of information it can
give to a network intruder.
Services such as Whois and Finger are excellent timesaving tools for use within an organization,
but you should never allow access to these services from beyond your internal network or your
intranet.
How Much of a Dialog Does the Service Allow?
A simple service with a regular interface is easier to secure than a complex service that uses an
extensive dialogue with the client to provide its functionality. HTTP, for example (disregarding CGI,

server applets, and Active Server Pages for the moment), is easy to secure because all the client
can do is ask for a resource, and the server does not maintain data about the state of the
connection between client requests (i.e. the protocol is stateless).
A stateful protocol is more difficult to secure, especially if the protocol requires client authentication
at the beginning of the session and allows for many requests, replies, and state changes after
authentication. A stateful protocol must be tested for security holes for every state the client may
place the server in. It is possible, for example, to hijack a Telnet session after an authorized client
has established the connection and provided correct credentials.
Also, the more dialog a service allows, the more dangerous the service is when compromised. If a
hacker arranges the Finger service to run at the wrong permissions level (such as root or
Administrator), the hacker would still just get account and contact information from it. An FTP
session at the supervisor level, however, could send the hacker any file in the computer. A root
Telnet session would allow the intruder to do anything at all, including running programs, shutting
down or starting services, replacing operating system code, as well as creating and deleting
accounts.
Service Separation
FTP sites, websites, and Telnet hosts perform vital functions in today's Internet connected−
networks. They create an Internet presence and facilitate communication within the organization as
well as with outside customers and the rest of the world. You can't just decide not to run these
services, but you can be careful about how you do it.
Because computers running these services are more vulnerable to being compromised, these
services should not be run on computers that also host other internal services (i.e. the file server or
a database server). Ideally, each Internet service would be run on its own server, but some services
work well together (FTP is often used to update web server content, for example).
Most common Unix utilities were developed before Internet security was a serious problem. New,
more secure utilities and services can replace nearly all common Unix utilities. You should seriously
consider replacing Telnet with SSH, FTP with SFTP, and POP with SPOP. These utilities are
basically the same except that they perform secure authentication and stream encryption rather
than sending passwords and data in the clear. If you don't have the option of changing non secure−
utilities, use a VPN.

79
How Programmable or Configurable is the Service?
The more configurable a service, the easier it is to get the configuration wrong. The more
programmable the service, the more likely bugs are to pop up, creating loopholes for network
intruders to jump through. So, Exchange Server (which has more configuration options than you can
shake a stick at) and Internet Information Server (or any other web server that allows you to run
arbitrary scripts to generate web pages) are more likely to contain security weaknesses than simpler
services, such as the POP service that comes with the NT 4 Resource Kit.
What Sort of Authentication Does the Service Use?
Any service that requires authentication from the client is a potential security risk for two reasons:
the authentication protocol may be weak, and users tend to use the same account names and
passwords across multiple services.
POP is one example of weak authentication. The username and password are sent from the client
to the server unencrypted, and the password is sent complete and unsalted. In POP, the server
asks for the username and password, and the client just sends them. Compare this to MAPI (used
by Microsoft Exchange), which uses a challenge and response protocol. With MAPI, the server− −
requests the username and password, but also sends a value for the client to salt (prepend to) the
password before the client hashes (scrambles) the password. The username and hashed password
are then sent to the server. The server can compare the hash to a known hashed password to
determine if the client should have access to the service. No eavesdropping computer can
determine what the password is from the hash, and the same hash cannot be used more than once
because the server changes the hash every time.
Another common problem with authentication is insufficiently long passwords. LAN Manager style−
passwords, which are used in Windows for Workgroups and Windows 95, are weak because
case sensitivity is ignored in the hash, and because the hash comprises two sections using the−
same seed that may be cracked in parallel. In addition, older Microsoft networking clients send the
s a m e p a s s w o r d h a s h e d w i t h b o t h t h e L A N M a n a g e r p r o t o c o l a n d t h e W i n d o w s N T
challenge and response protocol, seriously compromising the Windows NT hash.− −
Password hashing works by storing an encrypted version of a password rather than storing the
password itself. The encryption algorithm is similar to a public key protocol in that it can only be−

used to encrypt the password, not to decrypt it. Retrieving a stored password then doesn't reveal
the password because the hash cannot be reversed.
Challenge response protocols are used to ensure that a hacker can't use a password hash. In a−
challenge response protocol, a random number is transmitted by the server to the client. The client−
then encrypts the random number using the password hash and transmits the result back to the
server, which uses its copy of the hash to decrypt the random number. If the decrypted random
number matches the original random number, then the client has proven that it knows the hash and
the server can trust it. On the wire, only a random number and permuted random number have
been transmitted, both of which are worthless and cannot be reused.
The purpose of a challenge response protocol is to keep the hacker from intercepting the−
passwords as they travel from the client to the server. If the hacker can't intercept the password, he
may just try to guess it. This is another area in which many protocols fail. A properly implemented
protocol will detect an unusual number (three or greater) of failed password attempts, after which it
80
will not allow any more logon attempts to that username or from that client. A weak protocol will
allow as many attempts as the hacker can perform, and a clever hacker can write a program to
perform hundreds of attempts per second, determining the true password by brute force. Windows
will by default lock out any account but the Administrator account when there are too many failed
password attempts.
Warning
Initially, VNC, the popular open source remote control software, did not lock out−
intruders and would respond rapidly to attempts. The protocol could be
brute forced in just a few hours. This problem was fixed in 3.3.3r7, so be certain−
you stay up to date.
It is easier to remember one password than a half dozen, so many computer users use exactly the−
same password for all of their computer accounts. This means that if a network intruder penetrates
one computer and captures the password list for that computer, one or more passwords and
usernames from that computer are very likely to also work in another computer that is otherwise
secure. Your password protected service gives the hacker a double resource—if the hacker can−
find a password that works on that service, she'll try it elsewhere, and if she can find a password

elsewhere, she'll try it on that service as well.
One Key Fits All
For convenience's sake, some services use the operating system username and password instead
of recording a separate username and password pair for the service. While this feature makes life
easier for the user, it also makes life easier for the hacker. When the hacker has obtained access to
the service, it means that he has also obtained access to the underlying operating system. Internet
Information Server (for password protected web pages) works this way, as do the POP and SMTP−
services that can be installed with it.
Your Network Profile
One thing that you should realize as you consider which services you will expose to the Internet is
that the more services you choose to expose, the less secure your network will be. Each protocol
you decide to allow may have a low probability of being compromised, but those probabilities are
additive and it only takes one hole to negate all your security efforts. So remember, less is more—in
this case, fewer services exposed is more security for your network.
In addition, hackers use the services you expose to profile your servers and they use that
information to select which attacks to run in an attempt to penetrate your network. If you expose all
of the ports that a default Windows server exposes, then the hacker is much more likely to pull out
his Windows hacking scripts rather than his Linux hacking scripts, for example.
DNS, The Essential Service
One of the most important higher level services in the Internet Protocol Suite is the Domain Name−
Service, and it deserves a bit more explanation than the rest of the protocols because it is so
intimately tied with the operation of the Internet. The lower level Internet protocols all use IP−
addresses to identify source and destination computers, but people have a hard time remembering
numbers. So, the architects of the Internet developed a service that would translate human friendly−
Internet addresses like and into their corresponding
computer friendly IP addresses.−
81
Dot Com and All That
In the beginning, people just kept a list of the human friendly Internet addresses and their−
corresponding IP addresses (the host file is a remnant of this), but as the Internet grew these files

got unwieldy and a more flexible method was needed. The Internet architects came up with a new
scheme that allowed an organization (or a person) to request an Internet address from a central
authority and then expand on that name using their own authority. Thus was born the Internet
Domain Name Registration system.
Human readable Internet addresses, like IP addresses, contain dots. But Internet addresses can−
have as few as one dot or many more than four (although it is a rare address that will have more
than a half dozen). The dots function as separators, and the last portion of the address is called the−
top level domain. Common top level domains include .com, .org, .net, .mil, .gov, .edu, and− −
two character country codes such as .uk, .us, .cz, .au, and .oz.−
W h e n y o u r e q u e s t a d o m a i n n a m e s u c h a s m e m e t e c h . c o m , l i t v a u l t . o r g , o r
robinsoncrusoefamily.org, you are staking out space on the Internet in a similar manner to when you
obtain a range of IP addresses. It is up to you to further subdivide the name space. When you
request the name, you provide the top level service with the IP address of two servers that will−
h a n d l e n a m e r e q u e s t s f r o m y o u r n a m e s p a c e . W h e n a c o m p u t e r w a n t s t o c o n t a c t
www.memetech.com, for example, it is up to the domain name servers that you specify to perform
the translation from www.memetech.com to the actual IP address. Your servers can put any
c o m p u t e r n a m e y o u w a n t b e f o r e m e m e t e c h . c o m , i n c l u d i n g
this.is.a.very.long.domain.name.memetech.com.
A large organization or a service may further subdivide the name space. BigCorp, for example,
might have separate domain name servers for each of its divisions in Asia, Europe, the US, and
A f r i c a . I n t h i s s c e n a r i o , o n e d o m a i n n a m e s e r v e r w o u l d h a n d l e r e q u e s t s s u c h a s
h t t p : / / w w w . a s i a . b i g c o r p . c o m / a n d a d i f f e r e n t o n e w o u l d h a n d l e r e q u e s t s s u c h a s
allowing each division to configure their networks independently but
maintain overall BigCorp control of the bigcorp.com domain.
DNS Queries
When you type into your web browser, your computer needs to know
what IP address corresponds to that Internet address. Microsoft's DNS (Domain Name System)
server is the computer that contains that information. How does that information get from the
Microsoft DNS server into your computer?
Your computer has the IP addresses of one or two DNS servers that it can ask about domain

names (and unless you work in Redmond, neither one is likely to be the Microsoft DNS server that
has the resolution you need). Your DNS servers most likely contain only Internet address to IP− −
address mappings for your local network and for a few frequently accessed external locations.
When your local DNS server cannot satisfy a DNS mapping request, it will either redirect your
computer to another DNS server or query that DNS server itself and pass the results back to your
computer.
If the mapping query is for an address in a domain foreign to the DNS server, the DNS server
redirects the query up the chain of servers toward (or to) a root server (such as the server for the
.com, .edu, or .gov domains). A server that has recorded and delegated name service for a domain
will redirect the query down to the DNS server that has responsibility for the domain. See Figure 4.1
for an example.
82
Figure 4.1: The DNS system distributes control of Internet domain names.
DNS Messages
Your computer makes a DNS request by sending a UDP packet in the DNS message format to port
53 of the DNS server. DNS uses UDP rather than TCP because it has one short message that will
fit in a UDP packet to send to the server, and the connection establishment overhead of TCP is not
necessary for DNS. The message has a fixed 12 byte header and 4 variable length fields, as− −
shown in Figure 4.2.
83
Figure 4.2: A single DNS message may contain multiple address resolution queries or responses in
the Question RR and Answer RR fields of the DNS UDP packet.
The DNS message fields are as follows:
• Identification This is set by the client, so that it can identify the DNS server response.
• Flags This field classifies the message as follows (See Figure 4.2):
♦ QR 0 for query or 1 for response.
♦ Opcode 0 for Standard Query, 1 for Inverse Query, or 2 for Server Status Request
♦ AA Authoritative Answer (True/False)
♦ TC Truncated (True/False)
♦ RD Recursion Desired (True/False)

♦ RA Recursion Available (True/False)
♦ Zero These three bits are zero.
♦ Rcode 0 for No Error, or 3 for Name Error
• Number of Questions 1 or more for query, 0 for reply
• Number of Answer RRs 0 for query, 1 or more for reply
• Number of Authority RRs 0 for query, 1 or more for reply
• Number of Additional RRs 0 for query, 1 or more for reply
• Questions Each question is composed of a string containing the Internet address being
queried, a query type, and a query class (which is 1 for Internet addresses). Common types
are as follows:
♦
1 A
2 NS
The IP Address
The Name Server for the domain
5 CNAME The Canonical Name (if a computer responds to more than one name,
this is the main one)
12 PTR The Pointer Record (looks up the name corresponding to an IP
address)
13 HINFO Host Information (computer details)
15 MX The Mail Exchange Record (which host handles mail for this Internet
Address)
84