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

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 • 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