Marc Smeets KPMG IT Advisory
Information Security & Control October 24 2008
IT ADVISORY
Network (in)security: Attacking the network one layer at a time
1
l Unfortunately hard to demo without a full network
l Please ask your questions as soon as you have any!
2
Outline
l Isn’t network security covered by now?
l Basic theory
l Attack!
l How to improve?
3
Isn’t network security covered by now?
l Isn’t all focus on web applications and ‘new stuff’ like RFID passports?
l No!
- Cisco IOS exploits (1 year ago, and new stuff coming soon ;-) )
- DNS cache poisening (3 months ago)
- TCP/IP DoS (4 weeks ago)
- MS08-067, remote RPC attack, Sasser/Blaster all over again? (2 days ago)
l What makes it fun? Major impact! Oh, and many, many companies still struggle with it
4
Basic theory
l OSI OSI OSI !
l I assume you are all familiar with it
5
Basic theory
l Layer 1: RJ45, fibre, wifi
l Layer 2: Ethernet (CSMA/CD)
l Layer 3: IP protocol
l Layer 4: TCP / UDP protocol
l PC-application -> DNS-name -> TCP/IP stack -> route tabel -> IP adres in my own subnet?
- Yes: check MAC table for address, otherwise send ARP request
- No: packet needs to go to default gateway, address in MAC table?
-> send frame to the correct NIC, the NIC will handle the details
6
OSI layer history?
l OSI model is old, very old
l What is the disadvantage of old techniques in IT?
7
Attack layer 1
l Netwerk tap
l Span port
l This is what makes wireless vulnerable!!!
8
Attack layer 2
l Which protocols and accompanying attacks do you know?
9
Attack layer 2
l MAC attack
- CAM table flooding
- ARP spoofing
l VLAN’s
- Trunking: ISL, dot1Q
- Dynamic Trunking Protocol, VLAN Trunking Protocol
- Configuring VLAN interfaces
l Other
- Cisco Discovery Protocol, Spanning Tree
10
Layer 2 MAC attack
l CAM = Content Addressable Memory
l CAM table = Switch DB with information about MAC address, physical port and VLAN
l Limited by available memory
l After the attack de switch will become a HUB, but..
- Attack only applicable for new addresses in the DB
- In which year this attack was introduced?
11
Layer 2 ARP spoofing
l Gratious ARP
12
ARP spoofing tooling
l Dsniff is an UNIX tool and supports 30+ protocols
l Ettercap UNIX tool + SSL/SSH interception
l Cain & Abel
l And many more
l What can we do about it?
13
Layer 2 VLAN’s
l VLAN safe?
l VLAN hopping on the access poort is possible by performing VLAN labeling
l VLAN hopping possible by using double labeling. However, not in both directions.
14
Layer 2 trunks
l VLAN’s only for local switch
l Administration of many switches time consuming
l ISL vs Dot1q (802.1Q) | VTP vs DTP
l Trunks and trunk mngt prot. Give access to all vlan’s
l DTP modes:
- On, Off, desirable, auto (default!) non-negotiate
l VLAN’s safe?
15
Layer 2 CDP
l Cisco Discovery Protocol
16
Layer 2 STP
l What is the function of STP?
17
Layer 2 STP l Spanning Tree default enabled on switch access ports
l Attack could be beneficial, could be (switches remain intelligent devices not all packets will pass)
l DoS-danger: Could have major impact on the network
18
Layer 3 and up?
l Which protocols and accompanying attacks?
19
Layer 3 and up
l HSRP / VRRP
l DHCP
l DNS
l Routing protocols are fun! OSPF, RIP(v2), EIGRP, etc. No BGP
l Can we add IP/TCP stressing..?
20
Layer 3: HSRP / VRRP
l Router redundancy
l Priorities determine who is active
l Password protected come on… it’s 2008
21
Layer 3: HSRP / VRRP
22
How to improve?
l MAC flooding?
- Port security at switch level (restricting # of allowed MAC addresses)
l ARP poisoning?
- Static ARP gives strange results, administrative hell
- switches nowadays are equipped with ARP poisoning detection
23
How to improve?
l VLAN’s?
- Limit amount of VLAN’s on access ports
- Use separate native VLAN for trunks
- Don’t use VLAN 1
- On access ports don’t use DTP or other VLAN mngt protocols
- Disable unused ports and put them in an unused VLAN.
24
How to improve?
l CDP?
- CDP could be disabled on access ports
l STP?
- No STP enabled on access ports (BPDU root guard)
l HSRP?
- ACL’s, non-default password and non-clear text password
25
Questions
26
Marc Smeets KPMG IT Advisory ICT Security & control [email protected] 06 51366680