Denial-of-Service
Contents
Description
- A denial-of-service(DoS) attack is one in which an attacker uses multiple techniques to deny legitimate users access to a system or resource. This Is generally done in one of two ways:
- Crashing the resource or a particular requirement for access to the resource
- Flooding the access so legitimate traffic is unable to reach it.
- DoS attacks are extremely common because they are so simple to carry out, and there is a wealth of ready-to-use tools available for script kiddies to download
Ping of Death
- The stereotypical “ping of death” is based on the fact that Internet Control Messaging Protocol (ICMP) echo messages are designed to be no larger than 65,535 bytes. Because most of the information of interest in ICMP echo packets is contained in the header, sometimes the data portion is unchecked. If an ICMP echo packet is sent that is too large, some operating systems (OSs) will crash.
- Whereas a packet larger than 65,535 bytes is illegal, this limitation can be worked around by using fragmentation packets that, when reassembled on the receiving end, overflows the buffer on some systems. so it s basically a buffer overflow exploit. Because of the ease and prevalence of this attack, most systems are no longer vulnerable.
Teardrop
- This attack is also dependent on fragmentation. Fragmented packets are sent but Instead of neatly lined-up fragmentation offsets, the offsets overlap.
- If the operating system does not have a plan in place for this eventuality, the system can crash, reboot, or lose stability.
- This is also an easy attack to learn; few systems are vulnerable anymore. It is named for the tool that exploits this vulnerability.
Ping Flooding
- Ping flooding is an attack specifically aimed at denial of network resource.
- Ping flooding uses up the bandwidth of the network so traffic from legitimate users can't get through.
- The general rule is that if the attacker has a greater bandwidth than the victim, the attacker will succeed in the DoS.
- This attack works as follows: the attacker send many large ping packets as quickly as possible to the victim. This exhausts the victims inbound bandwidth may be consumed as well.
Smurf Attacks
- A smurf attack is a specific variation on a ping flood attack. Instead of a ping to a single system, a smurf attack uses repeated spoofed broadcast ping messages to flood the system.
- All of these ping messages use the spoofed IP address of the intended victim as their source address. If the ping is actually broadcast to the network, most hosts on that IP network will accept the ICMP echo request and reply to it with an echo reply per recipient, which will have the effect of multiplying the traffic by the number of hosts responding.
- This attack is also named after the attack program created to exploit this vulnerability.
Amplification Attacks
- This type of DoS attack uses both spoofing and broadcast addressing to amplify a single stream of packets several hundredfold to flood the victim's bandwidth.
- To carry out this attack, the attacker needs to find a network that both allows communications to the network's broadcast address and has a good number of hosts active on the network.
- The attacker sends large ICMP echo request packets to the broadcast address of the amplifier network with a spoofed source address of the victim.
- The amplifier network then broadcasts these ICMP echo packets to all the hosts on that network, and each of these systems will then send corresponding ICMP echo replies to the spoofed source address of the victim, flooding their network bandwidth.
- This is also called a reflected attack. If the attack relies on ICMP packets, it's also called a smurf attack. If the attack relies on User Datagram Protocol (UDP) packets, it's called a fraggle attack.
SYN Flooding
- In SYN flooding, the attacker attempts to exhaust the space in the Transmission Control Protocol/Internet Protocol (TCP/IP) stack with spoofed and only partially complete connections, so legitimate users are unable to connect.
- TCP maintains the connections so it has to be able to track them and their state somewhere; that place is the TCP/IP stack. But only a finite number of connections can he tracked in the TCP/IP stack, and SYN flooding uses spoofing to exploit this.
- The attacker floods the system with many SYN packets that have spoofed nonexistent source addresses. These packets behave as if a system that has the spoofed IP address wishes to open a connection with the victim computer.
- Now the victim sends out a SYN/ACK package and waits for the connection handshake be returned in order to finalize or to complete the handshake process. In the meantime, the waiting connection goes into a backlog queue and will only be removed from the queue if either the SYN/ACK packet is received or the connection times out. The timeout can take quite a while, and the SYN packets continue to come in.
Distributed Denial of Service (DDoS)
- This is basically a DoS attack coming from more than a single location. To carry out a DDoS, the attacker will generally compromise other systems and install daemons on them for later use. The daemons are waiting for the attacker to determine which victim to attack. When a victim is chosen' the attacker uses a controlling program to tell the daemons to simultaneously attack the target.
- The fact that the DDoS attack is not coming from a single location has several impacts on its success:
- More volume can be generated.
- It's harder to filter or block multiple attacking systems.
Anatomy of an Exploit
- Ping of Death
- An attacker uses one of the ICMP ping tools available to construct an IP packet with a size larger than 65,535 bytes and sends it to the target choice. The header source IP is usually spoofed to help hide the source.
- Teardrop
- An attacker target a network that seems vulnerable and uses that Teardrop tool to set up the attack by sending several IP fragmentation packets that are structured so that when the receiving system attempts to reassemble them, they will overlap.
- Ping Flooding
- When an attacker thinks he has a vulnerable target, he tells his army of bots to begin sending ICMP echo requests to the target IP address as quickly as possible. The headers of the requests can be forged with random bogus IP source addresses to resist any attempts to filter the requests by source addresses.
- Smurf
- In a smurf attack, the attacker targets a vulnerable network and uses the Smurf tool to craft ICMP echo requests where it has forged the source IP address to match that of the target.
- SYN Flooding
- An attacker sends a continual series of TCP SYN packets to the target, each one with a different forged source IP address to exhaust the target's resources during this continual flooding.
Real –World Example WorldPay DDoS Attack
- At about 6 p.m. on Saturday, October 2, 2003, the payment processing division of the Royal Bank of Scotland, WorldPay (WorldPay Ltd.), was hit with a sustained DDoS attack.
- This attack, employing hundreds or Possibly thousands of “zombie” computers to issue repeated automated requests, was designed to clog and slow the bank's systems.
- This attack lasted for three days, in spite of the attempts to block out traffic and restore functionality to the bank's customers.
- In April 2004, WorldPay was again hit with a DDoS attack. There have some conjectures that this was a case of attempted cyber-extortion by organized crime ,but there never was full disclosure of the exact events surrounding either DDoS. These attacks, however, did of not reveal any of the data that WorldPay had stored.
Gibson Research Corporation DDoS Attack
- On the evening of May 1. 2001, GRC.COM appeared to drop off the Internet. The network activity was analyzed quickly, and it was discovered that both of their T1 connections were maxed out with incoming traffic at their 1.54 megabit rate, and there was almost no outbound traffic.
- Capturing and analyzing the arriving packets themselves showed that the attack was a brute force UDP DDoS attack that was designed to use up all available network bandwidth and thus deny access to legitimate users.
- GRC's firewalls and local routers easily recognized and discarded the bogus traffic but that meant the bandwidth to that point was still clogged. After 17 hr, filters were applied to the router that sat between the Internet and GRC's two Ti trunks to block out all UDP and ICMP traffic. From the type of packets generated, as well as other facts, it was determined that the attack was being carried out by 474 security-compromised Windows PCs. Because the attacks related to UDR the TCP-based senic° could continue even while the attack was still under way and the router was blocking all UDP and 1CMP traffic.
More attacks followed on the following schedule:
- May 4 — First attack took place;17 hr to filter traffic and return to service.
- May 13 — Second attack. Identical to the first, including the attacking Windows machines; 8 hr to reestablish the same filters used on May 4.
- May 14 — Attacked twice this day. The first attack Of the day was targeted at the IP of GRC's firewall, and GRC disappeared from the Internet again. This time the router filtering was changed t° add the firewall's IP to the filtering and then GRC was back.
- May 14 – only 2 hr later, the attack resumed, aimed at one of the T1 interfaces of GRC's Cisco router. This again flooded the Tls. And GRC was off the Net again, the decision was then made to shut down that Tl, which left one Tl to service GRC, but they were back on the Net again.
- May 15 — This attack took GRC off the Internet for 6.5 hr before stopping on its own. A decision was made to simply shut down at for the night because of some hugs in the routing software that made it possible to effectively filter this attack.
- May 16 — Comprehensive filtering was put in place after the previous day's attack so traffic would be kept away from the entire GRC site. Another attack occurred, but the new filtering was completely effective. An estimate of how many Packet were blocked by the filtering during this attack was 538,916'268.
- May 17 to May 20 — During this time the GRC was completely protected, but the number of packets filtered was estimated at 2,399,237,016.
Chat DoS Attack
- A chat DoS attack that I experienced was somewhat low-tech, but I've included it as an illustration of how sometimes these low-tech approaches can be very disrupting to legitimate users of a system.
- I was attending an online chat with a celebrity guest, and there were about 200 people in the online chat room. During the busy chat, two people who were logged in as anonymous guests began to repeat offensive messages as fast as they could paste the text and hit ''send.“ The speed at which these messages were being posted made the chat room completely unusable by legitimate customers.
- After a few minutes, an administrator booted the first of the attackers out, but before the second one could be booted as well, the first person (my own assumption) was back spamming again. This trade went on for about the next ten min before I gave up and left the room.
Test Techniques
- Testing for DoS attacks really has two major branches, and whether you use one or the other (or both) will depend on the product you are testing and what dependencies it has or services it offers to others.
Network DoS
- Most network DoS attacks boil down to one of two situations.
- Protocol Vulnerability
- In many cases, the DoS is caused by the fact that a network device or system is not able to deal with an exploit of a network protocol vulnerability. In these cases, fuzz testing is a good way to try to exercise the Protocols to determine the reaction of the system under test to protocol fuzzing. These are mostly network protocols and unless you are testing a system that deals directly with that low a level in the Open System Interconnection(OSI) model, you are a little bit helpless and dependent on your OS and network to handle these issues.
- Lack of Limits
- The other major factor is that limits on various types of transactions are either nonexistent or too high for the system to handle. In the latter case, it would pay if you can cause a DoS and then backtrack from it to question the limits that are in place to prevent DoS.
- There are several aspects of input that you can experiment with in trying to trigger a DoS:
- Quantity from a single source
- Quantity from multiple sources
- Size of individual items
Think Outside the Typical DoS Box
- In addition to the more standard DoS attack vectors, it pays to take a look at the more unusual attacks that might be able to be turned into DoS attacks.
- Circular References
- Is there any way you can cause a circular reference to occur in Your system? If you can, you might be able to cause a DoS. I had a recent experience with an e-mail system that treated notification messages not in the same way it treated regular e-mail messages: there were questions about whether or not a circular reference could be instigated with a combination of two different types of system notification messages. It turned out that it did not work, but it was an interesting experiment. Any service- or system-crashing issues may become a DoS. If you run across a mysterious crash of your test system or a service on the system' sometimes the tendency is to dismiss it as a fluke. Perhaps it is, but never just shrug it off. Always keep looking for what might have caused Ili because some of these crashing issues are very real vulnerabilities that may be exploitable as a DoS at some later date
External Links
Panel title
Percipit Mnesarchum
Molestie Phaedrum Luptatum
constituam Habeo adipisci Inani
zril Forensibus sea Habeo
adipisci Minimum corrumpit Regione
suscipit Has et partem Percipit
Mnesarchum Molestie Phaedrum
Luptatum constituam Habeo
adipisci Inani zril Vel
nisl albucius Habeo adipisci Minimum
corrumpit Regione suscipit Percipit
maiestatis Regione suscipit Percipit
maiestatis
Subtitle