ARP poisoning is a method used for manipulating the flow of traffic between arbitrary hosts on a local area network: ARP messages contain the IP address of a network resource, such as the default gateway, or a DNS server, and replaces the MAC address for the corresponding network resource with its own MAC address. Network devices, by design, overwrite any existing ARP information in conjunction with the IP address, with the new, fake ARP information. The attacker then takes the role of man in the middle; any traffic destined for the legitimate resource is sent through the attacking system. This attack occurs on the lower levels of the stack and the end-user is oblivious to the attack happening.
ARP poisoning is also capable of executing Denial of Service (DoS) attacks. The attacking system, instead of posing as a gateway and performing a man in the middle attack, can simply drop the packets, causing the clients to be denied service to the attacked network resource.
ARP Poisoning is the most ignored, long-standing vulnerability
In an ARP MITM attack a MAC address is spoofed within a LAN in response to a victim's ARP request. If the MAC is successfully spoofed with the attacker's machine, then the victim will send traffic to the spoofed MAC address instead of the destination MAC address. The attack must be executed from within the victim's LAN and respond faster than the actual destination ARP response.
By flooding a network device with data packets, the translation table goes haywire and the connection between the ports and specific MAC addresses is destroyed. Any data that is intended for a single MAC address is now sent out on all ports associated with the network. This means that any type of data that was intended for a single address is received by multiple addresses.
Via MAC flooding an attacker can gain access to all sorts of data, including system passwords, protected files, and even email and instant messaging conversations. Because of the security risk that MAC flooding represents, many switches today can be configured to either provide extra security to specific MAC addresses, or to even shut down the network device in the event too much data floods into a given port.
IP is responsible for the transmission of packets between network end points. IP includes some features which provide basic measures of fault-tolerance (Time to Live, checksum), traffic prioritization (Type of Service) and support for the fragmentation of larger packets into multiple smaller packets (ID field, Fragment Offset). The support for fragmentation of larger packets provides a protocol allowing routers to fragment a packet into smaller packets when the original packet is too large for the supporting datalink frames.
IP fragmentation exploits (attacks) use the fragmentation protocol within IP as an attack vector.
The IPv4 Fragmentation and Reassembly can be used to trigger a Denial of Service Attack (DOS). The receiving device will attempt reassembly following receipt of a frame containing a Flag field set to
xx1, indicating more fragments are to follow. Receipt of such a frame causes the receiving device to allocate buffer resources for reassembly. If a device is flooded with separate frames, each with the Flag field set to
xx1, but each has the Identification Field set to a different value, the device would attempt to allocate resources to each separate fragment in preparation for reassembly and would quickly exhaust its available resources while waiting for buffer time-outs to occur. To defend against such DOS attempts, many network security features include specific rules implemented at the Firewall that change the time-out value for how long they will hold incoming fragments before discarding them.
Most routers come with the option to set the router to ignore or drop ICMP Redirects because they can be used to attack networks by confusing hosts as to where the correct default gateway is.
ICMP Redirects were also used to amplify smurf or fraggle attacks. A smurf attack spoofs the source address with the address of the victim, and then sends it out as a broadcast ping. Each system on the network will then respond, and flood the victim with echo replies. A fraggle attack sends a large amount of spoofed UDP traffic to a router’s broadcast address within a network but uses UDP traffic to achieve the same goal.
Routers do not pass broadcast packets. This was actually a change in rfc2644 released in 1999 in direct response to smurf attacks and the use of networks as smurf amplifiers. It is an update to rfc1812 which stated that a router must default to forwarding directed broadcasts. Routers today comply with this RFC, so smurf (and fraggle) attacks are limited to a broadcast domain. They will not go beyond a router.
ICMP Redirects can be used to set up Man-in-the-Middle without LAN access. An ICMP Redirect message is typically used to notify routers of a better route, and can be spoofed to reroute a victim's traffic through an attacker controlled router. Many routers have static routes or do not accept/process ICMP Redirect packets, but some still do.
The variable size of the ICMP packet data section has been exploited a lot. In the well-known Ping O' Death, large or fragmented ping packets are used for denial-of-service attacks. ICMP can also be used to create covert channels for communication (see the LOKI exploit).
When people talk about blocking ICMP they're really talking about
traceroute. The first can be used to determine if a host is alive, and Time Exceeded as part of traceroute, can be used to to map out network architectures, or void forbid, a Redirect(type 5 code 0) to change the default route of a host.
Reasons why we may not want to restrict ICMP as a whole:
Blocking ICMP in its entirety is probably not a good idea, picking and choosing what to block and to/from where, probably will get us what we want.
There is no limit on the time to wait after receiving the SYN in the three-way handshake. An attacker can initiate many connection requests with a spoofed source addresses. The victim machine maintains data related to the connection being attempted in its memory. The SYN+ACK segments the victim sends are not replied to. Once the implementation imposed limit of such half-open connections is reached, the victim machine refuses further connection establishment attempts from any host until a partially opened connection in the queue is completed or times out. This removes a host from the network for several seconds, making it useful at least as a stepping tool to other attacks, such as IP spoofing.
It is very easy to detect SYN attacks. The netstat command shows how many connections are currently in the half-open state. The half-open state is described as SYN_RECV. Another method for detecting SYN attacks is to print TCP statistics and look at the TCP parameters that count dropped connection requests. While under attack, the values of these parameters grow rapidly.
A number of SYN flooding countermeasures are listed in rfc4987.
Linux operating systems have a SYN cookies mechanism that can be enabled. SYN cookies protection is very useful when the system is under a SYN flood attack and source IP addresses of SYN packets are also faked (a SYN spoofing attack). This mechanism allows construction of a packet with the SYN and ACK flags set and which has a specially crafted Initial Sequence Number (ISN), called a cookie. The value of the cookie is the result of a hash function, generated from information like source IP, source port, destination IP, destination port plus some secret values. During a SYN attack the system generates a response by sending back a packet with a cookie, instead of rejecting the connection when the SYN queue is full. When a server receives the three-way handshake packet with the ACK flag set, it verifies the cookie. Only when the value is correct (it is a legitimate connection and the source IP address is not spoofed), it creates the connection, even with no corresponding entry in the SYN queue.
Starting the SYN cookie mechanism (this variable will return to default upon system reboot):
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
The IP layer trusts that the source address in an IP packet is valid. The IP protocol specifies no method for validating the authenticity of this address. Replacing the true IP address of the sender (or the destination) with a different address is known as IP spoofing. Because the IP layer normally adds these IP addresses to a data packet, a spoofer must circumvent the IP layer and talk directly to the network device.
An attacker can silence a host A from sending further packets to B by sending a spoofed packet announcing a window size of zero to A as though it originated from B.
The attacker’s machine cannot simply be assigned the IP address of another host T, using
ifconfig or a similar configuration tool. Other hosts, as well as T, will discover (through ARP) that there are two machines with the same IP address.
Detecting IP spoofing:
Preventing IP spoofing can be done with IP filtering rules, allowing only routing of packets from sources that could legitimately come from the interface the packet arrives on. Most routers now have options to turn off the ability to spoof IP source addresses by checking the source address of a packet against the routing table to ensure the return path of the packet is through the interface it was received on.
An attacker sitting in between host A and B is somehow able to monitor the packets between the two and floods host B with new requests causing to stop host B communicating with host A. Now, the attacker can predict the sequence number of the packet that host A is expecting from host B. The attacker sends a fake packet with the expected number to host A. Host A accepts it as coming from host B. The packet sent can be a packet terminating the connection (RST bit set), or asking host A to run some commands or scripts.
Timing differences or information from lower protocol layers could allow for detection of fake TCP packets, if the attacker cannot also fake that other information, making the receiving host near-immune to TCP sequence prediction attacks. Defenses are mentioned in rfc6528.
Once an attacker is able to hijack a TCP session, he or she can send packets with RST Flag ON to both A and B or any of the hosts, that will treat these packets normally and the connection between host A and host B is terminated.
Depending on environment, UDP's built-in checksum may or may not be reliable enough. UDP has a 16 bit checksum field starting at bit 40 of the packet header. This suffers from (at least) 2 weaknesses:
An even more realistic threat than data corruption along the transport is packet loss reordering: UDP makes no guarantees about all packets to (eventually) arrive at all and packets to arrive in the same sequence as sent.
UDP has no built-in mechanism to deal with payloads bigger than a single packet. It wasn't built for that. If we choose to use UDP, we need to build those parts that are integral to TCP but not to UDP into the application. This will most likely result in a (possibly) inferior reimplementation of TCP. Or not. These protocols may even be an improvement.
Some operating systems ship with SCTP support enabled. It not being as well known as TCP or UDP and overlooked in firewall and intrusion detection configurations (thereby permitting probing traffic), can be a good fingerprinting candidate.
rfc4960 and rfc5062 describe some of the attacks found since its launch: SCTP is not secured against redirection attacks, bombing attacks and towards verification-tag guessing attacks which lead to association-hijacking. RFC 5062 does not include any information about steganography-based attacks and methods of preventing them.
The SCTP’s multi-homing can be exploited to craft a form of denial of service attack. In effect, an illegitimate client connects to a server and steals or “holds up” a valid peer's address to prevent the legitimate peer from communicating with the server.
If an attacker guesses a valid verification tag that was sent to someone else's host, a connection from that host can be faked. The attacker can then use cryptanalysis for the server-selected secret function, inspect a series of valid cookies and then intelligently guess a new cookie. Guessing a verification tag requires 231 brute-force attempts. Assuming the attacker has exponentially high computational power, attacker can inspect a series of valid cookies and then intelligently guess a new cookie.
The attacker sends an INIT to the server using same IP address and port number as in the existing association. The server automatically responds with an INIT-ACK containing a state cookie. Inside the state cookie, the attacker can find both the verification tags (the locations of each tag in the cookie depend on the implementation which is not hard to guess). The attacker does not need to know the correct port number, the peer’s address, or even that the association exists.
An attacker sends packets using the victim's address as the source address containing an INIT chunk to the SCTP Server. The server then sends a packet containing an INIT-ACK chunk to the victim, which is most likely larger than the packet containing the INIT. Countermeasure: double check client before establishing a connection assures client is legitimate one if the connection is established.
Unauthenticated SOCKS proxies (TCP 1080) are a vulnerability. An attacker can browse the Internet, bouncing through these servers and remaining almost completely anonymous (especially if logging is turned off). A solution is to restrict the bindings of specific services.