Cryptography and Network Security doc

Sockets and Services
CS-480b
Dick Steflik

Evaluating Socket Based Services
•
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 ones
–
the more complex it is the more possible points there are that a
hacker can try to exploit
•
DayTime is as simple as a service can get
–
A connect is recognized by the server and the server responds and closes

the connection; no user input required.
–
About the only exploit would be DoS by flooding service with requests
•
POP is more complex
–
possible password theft (remember they are not encrypted)
•
theft of data
•
loss of privacy
–
could try buffer overflows on any command
•
possibly crash server
–
DoS attempt

How might the service be abused ?
•
Hackers are very creative and will abuse a service in any
variety of hard to imagine ways
–
hijacking
•
taking over a valid user’s connection
–
redirecting
•
rerouting a user’s connection to another host

–
DoS
•
flooding the service with requests for service
•
redirecting Chargen output to some unsuspecting computer
could flood it with data that it didn’t request

What information does the service dispense ?
•
Some services provide deliver extensive user information
–
Finger was originally created to allow UNIX users to locate one
another on a UNIX system; depending on configuration
parameters none, minimal or extensive user information can be
delivered
–
Whois is another service that dispenses user information
•
Consider blocking these services altogether
–
they make it too easy to identify users or make it to easy for a
hacker to validate the existence of a userid
–
at least block incoming requests,if incoming is required insist it be
used via VPN

How much of a dialog does the service allow?
•
The more complex the dialog presented by the service the

harder it is to secure
–
HTTP is a simple stateless protocol and is easy to secure
–
FTP is complex and hard to secure
•
stateful protocol
•
uses two ports (20, 21)
•
extensive command structure
•
user ids and passwords are often the same as system user ids and
passwords
•
A complex dialog presents many possible points of attack

How programmable or configurable is the service?
•
Many modern services have literally hundreds of
configuration parameters
–
abundant room for misconfiguration errors
–
poor testing and pressure to meet product release dates is
conducive to buggy code and/or development code to still be in
the code
•
SMNP, RIP and OSPF are used for remote configuration
of network devices

•
should never allow incoming requests for these protocols
•
Some services (HTTP, LDAP…) allow remote
administration via web interfaces (HTML, ActiveX or
Java)
–
if possible allow only localhost access

What sort of authentication does the service use ?
•
If authentication is done in the clear (POP3, telnet, Basic
HTTP…) it is easily intercepted by anyone using a
“sniffer” program
–
HTTP’s base 64 encoding of passwords isn’t really secure as it is
easily decoded or worse yet recorded and replayed
•
Authentication is best if credentials are encrypted
–
public key techniques
–
challenge/response protocols
•
Password guessers
–
should watch for and log multiple password failures
•
use reverse DNS to find domain