2.Phys & Link

Course 3: Network Security, Section 2 Pascal Meunier, Ph.D., M.Sc., CISSP May 2004; updated July 30, 2004 Developed thanks to the support of Symantec Corporation, NSF SFS Capacity Building Program (Award Number 0113725) and the Purdue e-Enterprise Center Copyright (2004) Purdue Research Foundation. All rights reserved.

Course 3 Learning Plan Architecture Physical and link layer Network layer Transport layer Application layer: DNS, RPC, NFS Application layer: Routing Wireless networks More secure protocols: DNSSEC, IPSEC, IPv6

Learning objectives Be able to identify the design objectives and vulnerabilities in the designs of ARP, TCP/IP v.4 and important network services, for each level For each of the vulnerabilities (where possible): Be able to justify limitations on availability (e.g., forwarding between network segments) or disabling the functionality Be able to identify mitigating factors Know of a tool that would detect relevant policy violations

Physical Layer Risks Disconnection Cut cable Barrier to radio waves Availability Eavesdropping Tap in cable Confidentiality Interference and Jamming e.g., provide 120 V AC in cable to cause damage Selective jamming Availability

Risks (cont). Interception Splice in cable, with attacker in-between a.k.a "man-in-the-middle" Can also work on wireless networks (see later) Can selectively remove or modify messages Integrity Physical integrity difficult to guarantee Pressurized pipes, etc... Integrity of radio waves (?!)

Effect of Network Topologies Types Bus Star Ring Tree Level Physical Actual connection Logical Programmed behavior

Bus All stations are connected to a single cable winding its way between them Any break in the bus splits the segment in two Unterminated bus becomes noisy as signals bounce All traffic is accessible by any station Station needs to be located in-between victims of man-in-the-middle attacks Signal terminator Signal terminator

Star Central point is single point of failure A single cut cable affects only one station Malicious stations can't intercept (man-in-the middle) Central point may perform filtering, routing Eavesdropping, jamming more difficult

Ring Messages are retransmitted by each station Highly vulnerable to interception attacks Logical May be using star physical implementation Faulty workstations can be bypassed Physical Resists one cut Good for fiber optics

Tree A mix of the above configurations (including linking star sections)

Link Layer Vulnerabilities Media Access Control Logical Link Control

Media Access Control (MAC) Control which station should access the data Access control often performed by self (e.g., bus) Conflict of interest "Promiscuous mode" listens to everything Control which station transmits Access control performed by self e.g., token passing networks Stations are supposed to remain silent unless in possession of a virtual token "Access control" misnomer "Media access contention resolution" more accurate

Media Contention On a shared medium, how do you know if it's "your turn" to talk? What if two stations send messages at the same time? Collision Approaches to Manage Contention CSMA/CD Carrier Sense Multiple Access with Collision Detection CSMA/CA Carrier Sense Multiple Access with Collision Avoidance Token Passing OFDM Orthogonal Frequency Division Multiplexing

CSMA/CD Ethernet Carrier Sensing: Do not transmit while another station is transmitting Obvious brute force attack: transmit continuously Attacker is also unable to receive replies Not subtle

Collision Detection Two stations trying to transmit at about the same time create a collision If a station detects a collision, it waits a random amount of time before trying again If there's another collision, it waits twice as long as the previous time (loop) Exponential back-off Vulnerability: a specific station can be knocked off the network by any other one Attacker only has to create collisions After the second collision, timing is known so the network can be accessible to other stations except the attacked one Data is eventually discarded

Power of Collision Attacks Other attacks such as TCP session hijacking need to silence one of the correspondents in the exchange See later but remember this

Token Passing vs CSMA/CD Token passing networks: Never have collisions because no station can transmit without a token, and there's only one token Token ring networks perform linearly with the amount of data to be transmitted, almost up to the theoretical maximum Ethernet transmission rates plateau well before the theoretical maximum when several stations want to transmit, due to collisions Have latencies proportional to the number of stations Each station has to retransmit the token

CSMA/CA Does carrier sensing as in CSMA/CD Carrier Sense Multiple Access with Collision Avoidance When collision detection is not possible (e.g., wireless) Algorithm: Sender waits for clear air, waits random time, then sends data Receiver sends explicit ACK when data arrives intact Also, RTS/CTS handshake messages RTS: Request to send Other stations keep quiet to avoid collisions CTS: Clear to send

Attacking CSMA/CA Sending RTS at intervals makes the other stations keep quiet As it was designed to do Keep sending them, and nobody can transmit Essentially the 802.11 vulnerability that was "discovered" at Queensland University of Technology AusCERT Reference #: AA-2004.02 Intrinsic property of wireless model of a shared communications channel AusCERT "recommend(s) that the application of wireless technology should be precluded from use in safety, critical infrastructure and/or other environments where availability is a primary requirement."

Comparison CSMA/CA and CSMA/CD CSMA/CA Doesn't know if there was a collision until the wait for acknowledgment times outs Is less efficient than CSMA/CD So 802.11 always slower than equivalent 802.3

MAC Addresses MAC addresses are used to identify stations Most network interface cards can be reprogrammed to have any MAC address Driver dependent

Special MAC Addresses 00:00:00:00:00:00 is reserved FF:FF:FF:FF:FF:FF is the broadcast address More on this and amplification attacks later Multicast addresses 01:00:5E:00:00:00 Last bit of first byte is the "multicast bit" Several destinations at once Unicast addresses (remainder) uniquely identify stations

Tools to Change MAC Addresses Windows SMAC: http://www.klcconsulting.net/smac/ UNIX/LINUX ifconfig ip link

Mini-Lab Use " ifconfig " to change the MAC address of your computer's NIC (see following slides) Bring down the interface Change the hardware address Bring it back up See that it worked

Shutting Down the Interface So you can change the hardware address has side effects, such as losing route information Record the current route information by doing route -n See the current status of the interface (and current hardware address with ifconfig eth0 Bring the interface down (deactivate) with ifconfig eth0 down

Changing the Hardware Address Type ifconfig eth0 hw ether 22:22:22:22:22:22 Verify with ifconfig eth0

Reactivating the Interface Type ifconfig eth0 up Add the original default route with: route add default gw <address> Verify that it worked ifconfig eth0 route -n Use a web browser or ping the gateway to test connectivity

Mini-Lab Question What do you think of network security features that restrict network access based on a list of "good" MAC addresses? Examples 802.11 access points Cisco routers

ARP: The Address Resolution Protocol Problem statement: You have a message for a given IP address. The hardware (link layer NIC) understands MAC addresses only. How do you find out the MAC address of a host with that IP address? ARP provides a solution RFC 826 (== STD0037) http://www.ietf.org/rfc/rfc826.txt Send an ARP request, and you should get the answer in an ARP reply

ARP Request Analogy Pick up a megaphone in New York (i.e., send a broadcast packet) Yell “I am the Queen of England, and I have a dollar for John Malkovich!” Wait and see who says that they are John Malkovich That’s the ARP request

If you get an ARP Request Whenever someone asks for John Malkovich: You may say that you are him (see ARP reply) In any case, write down who they say they are (e.g., the Queen), and where you met them (the MAC address). Overwrite any previous entry for that name.

ARP Reply Whenever someone tells you who they are (e.g., John), write it down, no matter whether or not you asked for it. If you never asked for it, its known as a "Gratuitous ARP", a.k.a. "GARP" Overwrite any previous entry for that name. That’s the ARP reply

ARP Poisoning Attack If the Queen wasn’t listening, then by sending a single ARP request pretending to be her, I am going to get all of her packets, without her knowing. If the Queen is listening, then instead of picking up a megaphone (broadcast), I will tell people one on one (unicast ARP replies) that I am her.

Basic Attack: Black Hole Poison the ARP cache of every computer on the network to point an IP to a non-existant MAC address All frames are lost at the link layer because no computer is listening for packets sent to that MAC address The computer whose IP address was "black holed" won't receive its frames

Example: Man-in-the-middle Attack (MIM) Malory asks Alice “I’m Bob, are you Alice?” Alice records Malory as Bob. Malory asks Bob “I’m Alice, are you Bob?” Bob records Malory as Alice. Malory is now in the middle of traffic between Bob and Alice. All he has to do is forward the traffic between them to keep up the appearance of normal functionality.

Implementation of MIM (exploit) " arprelay " Forward IP packets between two machines that have each been told that the MAC address of the other is some random spoofed MAC address You tell arprelay the IP and MAC addresses of Alice and Bob (the two machines whose communication you want to proxy) and the MAC address you spoofed on both machines.

ARP Attack Tools Attack Tools: Arpspoof will send frames to poison the ARP tables of other computers Arp-sk can perform several kinds of attacks "swiss army knife" Defense: ARPWatch: Lawrence Berkeley National Laboratory http://www-nrg.ee.lbl.gov/ WinARPWatch http://jota.sm.luth.se/~andver-8/warp/

Defenses Arpwatch can detect attacks (does not prevent) May miss unicast attacks on other computers if medium is not a bus Static entries in a file prevent attacks on that computer or using that computer Other computers can still have their ARP cache manipulated e.g., they can still "black hole" the computer with static entries

ARP Server Computer responds to ARP requests even if the request is not for itself As above, but file entries marked " pub " The server may foil some attacks on other computers if the requests are broadcast Not guaranteed Require attacker to be more active Conflicts could be detected by an intrusion detection system arpwatch is the start of an IDS IDS should generate alerts when other computers are generating conflicting ARP data

ARP-Related Vulnerabilities CVE-2001-0895 Multiple Cisco networking products allow remote attackers to cause a denial of service on the local network via a series of ARP packets sent to the router's interface that contains a different MAC address for the router, which eventually causes the router to overwrite the MAC address in its ARP table. CAN-2002-0438 (under review) ZyXEL ZyWALL 10 before 3.50 allows remote attackers to cause a denial of service via an ARP packet with the firewall's IP address and an incorrect MAC address, which causes the firewall to disable the LAN interface. Present in many home products (e.g., NetGear) CVE-1999-0763 NetBSD on a multi-homed host allows ARP packets on one network to modify ARP entries on another connected network.

ARP-Related Vulnerabilities CAN-1999-0444 (under review) Remote attackers can perform a denial of service in Windows machines using malicious ARP packets, forcing a message box display for each packet or filling up log files. CAN-2000-0612 (under review) Windows 95 and Windows 98 do not properly process spoofed ARP packets, which allows remote attackers to overwrite static entries in the cache table. CVE-1999-0764 NetBSD allows ARP packets to overwrite static ARP entries. and more

Network Junctions Hub Repeater, simplest possible device Works at the physical layer with electrical signals Connects cables as if they were the same segment Bridge Works at the link layer Connects segments Sends data to other segments based on MAC addresses Switch Switches track which MAC addresses exist on each segment, and forward traffic accordingly Essentially a multi-port bridge

Sniffing A bridge won't forward frames to the red segment unless the destination is there Mallory, on the red segment, is prevented from sniffing traffic on the blue segment Router Bridge Mallory Blue segment

Switches vs Hubs Hubs broadcast frames to all stations on a star network Switches filter and send packets based on MAC addresses Do switches provide security against eavesdropping? Do switches prevent ARP poisoning attacks? Problem: do the switches fail "functional" or safe?

Switches Switches only keep track of on which connector (and network segment) are which MAC addresses, and forward traffic accordingly Eavesdropping (a.k.a. sniffing) Segregation of traffic by switches can be defeated. Some switches fail “open” (like hubs) under bad conditions. The firmware is designed to protect functionality instead of security. Attack tool: " macof " in /usr/bin/tcp-tools/ ARP Poisoning Broadcast packets are sent everywhere anyway! Replies can be broadcast (gratuitous replies) Switches afford no protection against ARP poisoning

Animated Slides Show how attacks work Slides courtesy of Craig Ozancin Separate download

Mini-Lab In this lab, you will launch " arpwatch " and use it to monitor changes in your computer's ARP cache Pair up with someone else "A" should try to poison "B"'s ARP cache, using "arpspoof" (on your Knoppix CD) Try a man-in-the-middle attack against the NAT firewall for the class See if you can detect it Create an ARP file with static ARP entries Contain lines of " hostname ether_addr " Make ARP read it ( arp -f filename ) Can you still be attacked?

Conclusion ARP vulnerabilities are a design problem. There is nothing you can do from the implementation standpoint to avoid them This applies to both wireless and wired networks. You can defend stations by: Generating an alert when the protocol is abused Welcome to the world of intrusion detection! Using static IP-MAC pairs (in effect disabling ARP) Configuring the network to put sensitive, important or trusted hosts and servers on a different subnet than other hosts ARP is not used or relayed between subnets This may include hosts used by privileged users

Logical Link Control Abstraction mechanism for multiple protocol networks and MAC layers Send data to several different protocol stacks Easier to deal with multiple or complex types of MAC layers e.g., manage 802.11 networks transparently from TCP/IP Not used in Ethernet II, present in 802.3 Ethernet Defined in 802.2 Has option for reliable transmission properties Attacker can send frames to affect this mechanism

802.2 Reliable Transmissions Attacker can send retransmission requests Asymmetric attack with amplification One small packet from attacker triggers retransmission of possibly several large frames Little power needed for mobile wireless attackers Establishment of a connection Perhaps the attacker can tear down connections at will Frames are unauthenticated Initiate phony connections without finishing them to consume resources (crash) Similar idea to SYN flood TCP attack (more on this later)

Logical Link Control Attacks Attacks against 802.2 are rare, undocumented, but possible No script kiddie tools available

Wireless 802.11 Frames Spoofed management frames in 802.11 wireless networks are easy, common Many automated tools available to disrupt wireless networks at the link layer De-authenticate stations, etc... Wireless networks are a more attractive target due to the lack of a well-defined physical boundary Harder to secure the link layer More on this later in the section on wireless networks

About These Slides You are free to copy, distribute, display, and perform the work; and to make derivative works, under the following conditions. You must give the original author and other contributors credit The work will be used for personal or non-commercial educational uses only, and not for commercial activities and purposes For any reuse or distribution, you must make clear to others the terms of use for this work Derivative works must retain and be subject to the same conditions, and contain a note identifying the new contributor(s) and date of modification For other uses please contact the Purdue Office of Technology Commercialization. Developed thanks to the support of Symantec Corporation

Pascal Meunier [email_address] Contributors: Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez-Rivera

2.Phys & Link

More Related Content

What's hot

Similar to 2.Phys & Link

More from phanleson

Recently uploaded

2.Phys & Link