Local Network Attacks John Kristoff jtk@depaul.edu +1 312 362-5878 - - PowerPoint PPT Presentation

local network attacks
SMART_READER_LITE
LIVE PREVIEW

Local Network Attacks John Kristoff jtk@depaul.edu +1 312 362-5878 - - PowerPoint PPT Presentation

Local Network Attacks John Kristoff jtk@depaul.edu +1 312 362-5878 DePaul University Chicago, IL 60604 FIRST TC 2002 John Kristoff - DePaul University 1 Agenda Overview Theoretical and example attacks How to


slide-1
SLIDE 1

FIRST TC 2002 John Kristoff - DePaul University 1

Local Network Attacks

John Kristoff jtk@depaul.edu +1 312 362-5878 DePaul University Chicago, IL 60604

slide-2
SLIDE 2

FIRST TC 2002 John Kristoff - DePaul University 2

Agenda

  • Overview
  • Theoretical and example attacks

How to resist (if possible) local network attacks

  • References
  • Tools
slide-3
SLIDE 3

FIRST TC 2002 John Kristoff - DePaul University 3

Overview

  • Local network attacks target an internal network
  • Some attacks can be launched remotely
  • Most do not monitor or guard against local attacks
  • Ultimately everything is a physical security problem
slide-4
SLIDE 4

FIRST TC 2002 John Kristoff - DePaul University 4

Theoretical and Example Attacks

  • ARP
  • LAN Bridge/Switch
  • Routing
  • DHCP
  • Multicast
  • Other
slide-5
SLIDE 5

FIRST TC 2002 John Kristoff - DePaul University 5

ARP-based Attacks

  • ARP request spoofing

Responders to a request cache the sender's info

As do others who already have the sender's info

  • ARP update spoofing (gratutious ARP)
  • Thinking out loud:

Is UNARP widely used? Can we attack with it?

Can we poison ARP entries to = group address?

slide-6
SLIDE 6

FIRST TC 2002 John Kristoff - DePaul University 6

Preventing ARP-based Attacks

  • Use LAN switches with one port per end host
  • Enable port security to limit source MAC addresses
  • Use 802.1x port authentication
  • Enable (get) knobs on end hosts to validate ARPs

How to best do this?

  • Monitor LAN bridge/switch address tables
  • Monitor router ARP tables
  • Keep history of address/ARP tables
  • FYI... vendors must support knobs (at line rate)
slide-7
SLIDE 7

FIRST TC 2002 John Kristoff - DePaul University 7

LAN Bridge/Switch Attacks

  • Overflow MAC address tables to cause flooding

Typical gear can hold a few thousand addresses

MAC addresses = 48 bits or >> a few thousand

  • Spoof spanning tree BPDU messages

Take over as root/designated bridge

Cause continuous topology recomputations

  • Forge VLAN, priority or aggregation tags
  • Spoof PAUSE (flow control) frames (gig only)
slide-8
SLIDE 8

FIRST TC 2002 John Kristoff - DePaul University 8

Preventing LAN Bridge Attacks

  • Monitor MAC address tables
  • Manually set root bridge and monitor
  • Use knobs like Cisco's BPDU and Root Guard
  • Manually set and prune trunked switch ports
  • Use 802.1x port authentication
slide-9
SLIDE 9

FIRST TC 2002 John Kristoff - DePaul University 9

Routing Attacks

  • Route injection
  • Route monitoring
  • Route redirection
  • Route process DDoS attack
  • Note, other types of local attacks may target routers
slide-10
SLIDE 10

FIRST TC 2002 John Kristoff - DePaul University 10

Preventing Routing Attacks

  • Strongly authenticate all routing updates/packets
  • Listen/send routing packets where there are routers
  • Protect processes and access (ports, IPs, physical)
  • Monitor routing

Table size (especially changes over time)

Checksum values and LSA counts in OSPF

Flaps, deaggreation, traffic patterns

  • Build baseline network map (ala Ches's netmapper)
slide-11
SLIDE 11

FIRST TC 2002 John Kristoff - DePaul University 11

DHCP Attacks

  • Spoof DHCP requests
  • Spoof DHCP replies (or be a rogue DHCP server)
  • Thinking out loud:

Can we spoof DHCP releases?

slide-12
SLIDE 12

FIRST TC 2002 John Kristoff - DePaul University 12

Preventing DHCP Attacks

  • Monitor DHCP discover/lease activity
  • Monitor DHCP discovers, requests and offers

Clients broadcast request, contains server IP

Can monitor DHCP packets and contents at:

  • DHCP servers
  • Router edges
  • Use intra-VLAN knobs (e.g. Cisco's intra-VACL)
slide-13
SLIDE 13

FIRST TC 2002 John Kristoff - DePaul University 13

Multicast Attacks

  • Spoof IGMP queries and take over as Querier
  • Spoof IGMP reports (joins)

There are 224.0.0.0/4 IP multicast groups

  • Spoof or simply generate group traffic
  • Thinking out load:

Can a default querier(s) be configured on hosts?

  • Ala DHCP option or just set to default gw

How to better authenticate group participation?

Will we see intentional multicast based attacks?

slide-14
SLIDE 14

FIRST TC 2002 John Kristoff - DePaul University 14

Preventing Multicast Attacks

  • Monitor IGMP querier on router edges
  • Monitor IP multicast group usage on edges
  • Monitor IP multicate routing state changes
  • Heavily filter IP multicast group state, allow just:

224.0.0.0/8

225.0.0.0/8

239.192.0.0/14 (internal only if used)

233.xx.yy.0/8 (GLOP space)

Then filter out bogus groups in above ranges

slide-15
SLIDE 15

FIRST TC 2002 John Kristoff - DePaul University 15

Other Attacks

  • HSRP/VRRP - use MD5 auth and/or IPSEC
  • Wireless - better authentication needed!

See my first-teams post about finding APs

  • ICMP redirect, SQ, router adv. - easily fixed
  • Time sync - who is getting time from who?
  • IPv6 - potential problems with discovery/autoconf?
slide-16
SLIDE 16

FIRST TC 2002 John Kristoff - DePaul University 16

References

  • Layer 2 Attacks and Their Mitigation, Cisco

Networkers 2002 presentation or Hacking Layer 2: Fun with Ethernet Switches, Blackhat 2002

  • Directed IGMP Report vulnerability:

http://www.cs.ucsb.edu/~krishna/igmp_dos/

  • Making Multicast Hard (How to ward off DOS &
  • ther threats), Marshall Eubanks, IETF 51
  • Gigabit Ethernet and The Switch Book, both by

Rich Seifert

slide-17
SLIDE 17

FIRST TC 2002 John Kristoff - DePaul University 17

Tools

  • http://www.monkey.org/~dugsong/dsniff/
  • Cammer from Tobias Oetiker (MRTG/RRDTool)
  • At http://cosi-nms.sourceforge.net:

ARPTrack

cislog

RouteCheck

I hope to do more (particularly multicast related)

  • We also have an unreleased AP MAC/IP tracker