Security Problems in the TCP/IP Protocol Suite

1. Security Problems in theTCP/IP Protocol Suite Presented by: Sandra Daniels, José Nieves, Debbie Rasnick, Gary Tusing

2. Article by: S. M. Bellovin AT&T Bell Laboratories April, 1989

3. TCP/IP Protocol Suite • Widely used • Developed under DOD • Serious security flaws

4. Topics to be Discussed • Problems and defenses • Handshake sequence numbers • Routing • Authentication • Service protocols • Comprehensive defenses • Conclusion

6. TCP Sequence Number TCP Handshake • C → S: SYN (ISNc) • S → C: SYN (ISNs), ACK (ISNc) • C → S: ACK (ISNs) • C → S: data And/or • S → C: data

7. Mechanism • ISNs variable incremented by constant (once per second) and by half that amount each time a connection is initiated. ISNs a number precisely the round-trip between the client and server • ISNs predictable, can be guessed by intruder • No authentication except IP address

8. Problem • ISNs not true random number • Easy to calculate or predict • Can be used to spoof trusted host • Easy and cheap for Intruder

9. Defenses • Don’t use netstat protocol • Generate ISNs some other way Randomization Use cryptographic algorithm with key • Randomize increments instead of basing them on predictable or measurable factor 1

10. Defenses (cont.) • USE DES to generate ISNs • Good Logging • Alerting mechanisms

12. ISSUES Routing mechanisms can be abused Denial of Service – confusing routing tables Source Routing Reverse the TCP route on a request (if one is used). The attacker may be able to identify an IP address and network in the source domain, the first step gaining control of a host POSSIBLE DEFENSES Hard to defend Possibilities: Local net rejects all external packets claiming to be from the local net (not practical and extreme) Analyze source route and accept it only if trusted gateways are listed (again, hardly practical) Routing

13. ISSUES RIP – Routing Information Protocol (widely used) Routing information received is often unchallenged Intruder can send bogus routing information and thus re-direct packets to a non-trusted entity, network, or host (impersonating) Hard to authenticate RIP packets Bogus routing information disseminates to other routers POSSIBLE DEFENSES Establishing a “paranoid” gateway One that filters packets based on source or destination address only, not on the route Would have to make RIP more skeptical of the routes that the router is willing to accept RIP Attacks

14. ISSUES Protocol for communications between core routers Impersonation of a real gateway when such is down is not hard with this routing protocol Broadcast a route directing others to an offline router, while impersonating that router POSSIBLE DEFENSES Always make exterior gateways be on the core network so that attacker has a harder time impersonating the offline router EGP

15. ISSUES The Internet Control Message Protocol is used for echo requests from remote hosts (connectivity) ICMP attacks are difficult because of ICMP packet’s simplicity Yet, ICMP packets can be used to: Redirect routes (such as with RIP) DoS attacks POSSIBLE DEFENSES Again, “paranoia” Restrict routing changes to specified connections, not in response to ICMP Redirect messages Check that an ICMP packet is tied up to a particular connection only ICMP

16. Authentication Server • Used instead of address-based authentication • Nothing more than a Trusted Host that will mediate our connections and establish trusted identities • Should not rely solely on TCP/IP for authentication; should use some other algorithm

18. Services Withinthe Suite • Finger • Email • POP • PCMAIL • DNS • FTP • SNMP • Remote Booting

19. Finger • Problem: Gives away too much information to hackers • Solution: Disable service

20. POP • Problem: Conventional passwords are vulnerable • Solution: One-time passwords using cryptographic key

21. PCMAIL • Problem: Same as POP, but also supports password-change command with unencrypted passwords • Solution?

22. DNS • Problem: Sequence number attack leading to spying on traffic/capturing passwords • Solution: Run domain servers on highly secure machines and use authentication on domain server responses

23. DNS cont… • Problem: Recursive zone transfer requests to download entire database • Solution: Employ “refused” error code for any requests from unidentified servers • Also, Kerberos tickets can be used to authenticate DNS queries

24. FTP • Problem: Use of simple passwords for authentication • Solution: One-time passwords • Problem: Anonymous FTP • Solution: Be careful with sensitive data (such as encrypted passwords)

25. SNMP • Problem: In the wrong hands, can divulge too much information • Solution: Protect this service (through authentication)

26. Remote Booting • Problem: Boot process can be subverted and new kernel with altered protection mechanism can be substituted • Solution: Ensure boot machine uses random number for UDP source port and use 4-byte transaction ID

27. Trivial Attacks • ARP • TFTP • Reserved Ports

29. Comprehensive Defenses • Authentication • Encryption • Trusted Systems

30. Authentication • One of the overall problems is TCP/IP reliance on IP source address for authentication • Too easy to spoof IP address • Needs some form of cryptographic authentication • Needham-Schroeder algorithm

31. Needham-Schroeder algorithm • Relies on each host sharing a key with an authentication server • Versions exists for both private-key and public-key cryptosystems • Host wanting to communicate request key from authentication server & passes a sealed version along to destination • At conclusion of dialog, each side has verified id of other

32. Needham-Schroeder algorithm • Allows pre-authenticated connections that are safe • DNS provides ideal base for authentication systems • Key distribution responses must be authenticated and/or encrypted

33. Encryption • Can defend against most problems • Disadvantages: • Expensive • Slow • Hard to administer • Uncommon in civilian sector

34. Encryption • Two types: • Link Level including • Multi-points link encryption • End-to-end encryption • Major benefits • Implied authentication they provide • Provide privacy

35. Link Level Encryption • Encrypting each packet as it leaves the host • Excellent to protect confidentiality • Works well against physical intrusion • Weaknesses: • Broadcast packets are difficult to secure • Implies trust of gateways

36. Blacker Front End(BFE) • A multi-point link encryption device for TCP/IP • Looks to host as an X.25 DDN interface • Sits between host and actual DDN line • Receives call with new destination, contacts Access Control Center for permission and Key Distribution Center for cryptographic keys

37. BFE • If local host is denied permission to talk to remote host, appropriate diagnostic code is returned • Special Emergency Mode when link to KDS or ACC is not working • Permission checking can protect against DNS attacks • Totally unauthorized host does not receive sensitive data

38. BFE • Also translates original “Red” IP address to encrypted “Black” address using a translation table supplied by ACC • Foils traffic analysis which are bane of all multi-point link encryption

39. End-to-end encryption • Above the TCP level • To secure conversations regardless of number of hops • Or quality of links • Appropriate for centralized network management applications • Key distribution/management greater problem (more pairs involved)

40. End-to-end encryption • Encryption and decryption done before initiation or after termination of TCP processing, host level software must handle translations resulting in extra overhead for each conversation • Vulnerable to denial of service attacks

41. Trusted Systems • Hosted and routers rated B2 or higher immune to attacks described here • C2 level systems are susceptible • B1 are vulnerable to some but not all attacks

42. Conclusions 1. Relying on IP source address for Authentication is dangerous 2. Second broad class of problems deals with sequence number attacks (unpredictable and unseen) 3. Hosts should not be giving away information gratuitously (finger and netstat) 4. Intelligent use of default routes 5. Use verifiable point-to-point routing protocols instead of broadcast-based routing 6. Network control mechanisms must be guarded