Internet Attacks: The Gory Details Bill Cheswick

1. Internet Attacks: The Gory DetailsBill Cheswick ches@lumeta.com

3. The Internet • Ad hoc collection of TCP/IP interconnections • No real central authority • No central knowledge of connections • maybe flows, but not yet • No per-packet billing, in most places • Core equipment too busy to help law enforcement • Large perimeters are impossible to control

4. Attacks can be laundered through many hosts around the world brief attacks are hard to track down the average defender is clueless Remote Attacks, and anonymity, are easy

5. clueless ISPs ignorant law enforcement treaties with foreign countries may not be against the local law attacker may cease attack before traceback is completed Traceback can be very hard

6. “Monoculture” • Small set of target types and versions • Microsoft OS and applications • Apache • Samba • DNS • Cisco IOS • Like planting Kansas with a single strain of wheat, or vineyards with a single root stock

7. Attacking scripts are published and shared • Loners develop attack software for the rest of us • Hacking FAQs are common • Software tools are easily available • look up “rootkit” • “Script kiddies” are a major source of current Internet attacks

8. Useful Poorly written Poor auditing Found in most hosts Safer services and protocols are rare Vendors sell flawed software Users don’t fix holes Host-based security is usually broken Security requires discipline: not found in market leaders And often not found in open source software either Unsafe Services

9. Unchecked user input submitted to the shell or Perl wildcard and escape characters take over the process CGI scripts Secret options, commands, or back doors DEBUG and others in sendmail Input string length is not checked string buffer overrun corrupts stack strcpy, gets, sprintf caller supplies assembly code, and jumps to it finger (Morris worm) early Netscape statd (latest) Unsafe ServicesSome Typical Errors

10. Unsafe Services: Privileged programs are much too large • Sendmail is tens of thousands of lines of complex code, running as root. • Netscape browser/communicator is huge • Operating systems are huge • Windows • Unix • Features are never retired, only added • A short, simple program is hard to get right

11. Unsafe Protocols • Passwords transmitted in the clear • Challenge/response is better, though subject to dictionary attacks • EKE can hide this • Machine generated passwords are better, but require devices or printouts • Address-based authentication • Can be OK in controlled environments • DNS and routing attacks can fool these

12. Vulnerabilities are common in network services One break-in compromises the rest of the host the host’s net (via sniffers) trusting hosts “non-vital” targets may be vital Weakest Link Compromisesmany targets

13. How Do They Find Dangerous Ports? • Port scanners • Easy to write • Half-open (SYN-only) scanners often don’t show up in logs • Harder to scan for UDP services, but not by much • “Firewalking” can scan through a firewall • Uses packets that a firewall often admits, such as ICMP or TCP SYN/ACK

14. Attacks Stack Smashing

15. Programs don’t check their input • Routines like gets, strcpy, and sprintf, which are inherently dangerous • If input length is too long, it can overwrite memory in C, overwriting variables and subroutine return addresses. • Every piece of external data must be checked before it is used. • It doesn’t hurt to check internal stuff, too • assert.h • CPU time is cheap

16. A Stack: before a procedure call Variables

17. A Stack: while a procedure is running Other stuff Return addr Local vars. String buffer Local vars Where to go after the procedure is finished

18. A Stack: while a procedure is running Other stuff Return addr Local vars. String buffer Local vars Input line goes in here

19. A Stack: while a procedure is running Other stuff Return addr Local vars. String buffer Local vars Input line goes in here

20. “Stack smashing” attack Other stuff Return addr Local vars. String buffer Local vars New return address, points to...

21. “Stack smashing” attack Other stuff Return addr Local vars. String buffer Local vars …new code loaded in some space on the stack The code runs with the privileges of the attacked program, usually root

22. Fingerd (Morris worm) sendmail syslogd rstatd early Netscape browsers file names in attachments to mail sshd IIS web server Some former victims of stack-smashing attacks

23. Attacks Portable Programs

24. Dangerous services:portable programs • JAVA • ActiveX^H^H^H^H^H^H^HCOMX^H^H^H^HSOAP • Viruses: • PC • Word • Excel

25. Program Kernel Where do Programs Run?

26. Program Kernel Where do Programs Run? This model is wrong!

27. Applets run in an incompletely-defined environment Kernel Program

28. Is incompletely defined Can be different for each vendor Often optimized for speed, not security Allows “native methods”, which can break the security model ActiveX like Java, but no sandbox at all Java’s “sandbox”

29. Attacks Sniffing attacks (“eavesdropping”)

30. Host withTCP Services Client Server Attacker

31. Was never secure from eavesdropping “Sniffing” tools are common grab host name, user name, and password check any hacker collection Credit card numbers are easy Over 1,000,000 captured in 1994 It doesn’t matter how good your password is if it can be sniffed! Still in wide use - even for root! Ethernet and Passwords

32. Wireless passwords

33. Wireless passwords

34. Attacks IP Spoofing a trusted host

35. IP Spoofing • Defeats address-based authentication • i.e. rlogin, rsh, tcp wrappers • Common tools available to the hackers • they don’t have to be TCP/IP experts • This was used to crack Tsutomu Shimomura’s machines in “Takedown.” • Robert Morris Jr. wrote a paper on this in 1984 • Steve Bellovin republished it in 1989 • First known use in 1994

36. Normal TCP connection,initial SYN packet Client Server SYN,SEQ0

37. Response to Open, connection is “half open” Client Server SYN,SEQ0 SYN,ACK, SEQ0+1,SEQ0

38. Client completes handshake, TCP connection is now open Client Server SYN,SEQ0 SYN,ACK, SEQ0+1,SEQ0 ACK, SEQ0+1,SEQ0+1

39. IP Spoof of a Trusted Client Determine Likely SEQ0 Client Server Attacker

40. IP Spoof of a Trusted ClientSuppress the Trusted Client Client Server killer packet or SYN attack Attacker

41. IP Spoof of a Trusted ClientSuppress the Trusted Client Client Server Attacker

42. Attacker opens connection “from” trusted client Client Server SYN,SEQ0 Attacker

43. Open seems to come fromtrusted client Client Server SYN,SEQ0 Attacker

44. IP Spoof of a Trusted ClientServer responds to dead client Client Server SYN,ACK, SEQ0+1,SEQ0 Attacker

45. IP Spoof of a Trusted ClientSpoof final open message Client Server ACK, SEQ0+1,SEQ0+1 Attacker

46. IP Spoof of a Trusted Client“Open” is complete Client Server Attacker

47. IP Spoof of a Trusted ClientOpen Server to outside access Client Server “evil trusted command” Attacker

48. Preventing IP spoofing • Spoofing can be stopped at the perimeter • “No internal addresses accepted from the outside” • Helps to have a coherent address space • A firewall can prevent access also • Address-based authentication is a BAD IDEA.

49. Attacks TCP hijacking

50. Attacker is watching an existing connection, perhaps through the strong authentication stage Client Server Attacker