Sockets and Services CS480 b Dick Steflik Evaluating
Sockets and Services CS-480 b 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 • Day. Time 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 Do. S 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 – Do. S 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 – Do. S • 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, Active. X or Java) – if possible allow only localhost access
What sort of authentication does the service use ? • If authentication is done in the clear (POP 3, 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
- Slides: 8