Sockets and Services

1
Sockets and Services

• CS-480b
• Dick Steflik

2
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?

3
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

4
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 users connection
• redirecting
• rerouting a users 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 didnt
  request

5
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

6
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

7
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

8
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
• HTTPs base 64 encoding of passwords isnt
  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