1 / 164

Internet Attacks: The Gory Details Bill Cheswick

Internet Attacks: The Gory Details Bill Cheswick ches@lumeta.com 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

jacob
Download Presentation

Internet Attacks: The Gory Details Bill Cheswick

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

  5. “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

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

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

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

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

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

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

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

  13. Attacks Stack Smashing

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

  15. A Stack: before a procedure call Variables

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

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

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

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

  20. “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

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

  22. Attacks Portable Programs

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

  24. Program Kernel Where do Programs Run?

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

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

  27. 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”

  28. Attacks Sniffing attacks (“eavesdropping”)

  29. Host withTCP Services Client Server Attacker

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

  31. Wireless passwords

  32. Wireless passwords

  33. Attacks IP Spoofing a trusted host

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  48. Attacks TCP hijacking

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

More Related