Libnet example (9)

Libnet example (9)

Author: John (scz@nsfocus.com)
Home: http://www.nsfocus.com
Date: 2000-08-15

Next, we will take the IGMP attack as an example to introduce Libnet library programming. I have never used IGMP patch. For pwin98,
IGMP is useless. You can consider this method:

Use ultraedit to search for 6a 02 E8 and change it to 6a F2 E8. Here 02 corresponds to the IGMP protocol. After such processing,
F2 corresponds to IGMP. Therefore, generally, all attacks against the standard IGMP protocol are invalid. Of course, you do not have
The IGMP protocol is used normally. You can use other values instead of F2.

You may need to review the basic knowledge of IP protocol and IP sharding:

1) it is meaningless to specify only one bit and several bit at the same time. Whether it is allowed or
The receiver may encounter errors when processing such packets based on specific implementations.
2) IP fragmentation and complete IP packets have almost the same IP header, and the ID field is consistent for each shard.
In order to identify the parts of the same IP packet during the reorganization. Flags occupies up to 3 bits.
Left to right indicates from high to low, and the leftmost bit is retained. It should be set to zero. If it is non-zero, what are the consequences? Medium
Setting 1 between BITs indicates that the IP packet cannot be split. If the route must be split for MTU
When an IP packet cannot be sharded, the IP packet is discarded and ICMP is used to notify the source host of the reason for rejection, as shown in figure
If this is not a special requirement, 1 should not be set; if the rightmost bit is set to 1, the message is not the last IP segment.
3) the rightmost flags of the complete single-packet IP packet is zero, and the Fragment offset is zero. First IP segment
The rightmost bit of flags is 1, and the Fragment offset is zero. The rightmost flags of the last IP segment
The bit value is 0, and the Fragment Offset must not be zero. Fragment offset and flags share two bytes,
The former occupies 13 BITs. The offset given by Fragment offset is relative to the complete IP packet data zone.
In 8 bytes.
4) The reorganization takes place on the final target host, and the intermediate route does not perform sharding. Reorganization occurs when all shards arrive
Later. Generally, when the destination host receives an IP shard (not necessarily the first shard), it starts
Timer. If the time-out and the part is still not complete, all the reached parts with the same ID will be discarded.
If one part is lost, the complete IP packet is lost. At this time, the IP layer itself is not responsible for retransmission, and the upper layer is required.
The Protocol itself realizes that it needs to be re-transmitted.

As you can imagine, the target host always waits for the part to be consumed instead of all IP segments.
Use system resources. This is the principle of some slice storm attacks.

5) The total_len of the IP segment shows the total length of the IP segment, rather than the total length of the complete IP packet.
6) using UDP can easily cause IP sharding, but it is difficult to force TCP to send a packet that requires sharding.

In the early days, the operating system was not perfect enough to determine the IP shard boundary, and there was always such a problem.
The research, analysis, and confrontation of various DoS attacks in the year have become increasingly complete, and it is difficult to find the partition Boundary
Handle the vulnerability. Why do we need to review IP sharding? An IGMP attack described below involves IP sharding and is no longer used
I'm afraid some of my friends will see me dizzy.

Another unrelated problem is that raw_socket can send IP segments, but never receive IP segments,
Before the kernel is restructured, it will not partition raw_socket with an IP address. Remember this is important. Possible
Some friends may see the source code that uses raw_socket to send IP fragments, and mistakenly think that IP fragments are used for sending and receiving
Raw_socket is visible.

We do not intend to repeat the entire RFC of IGMP. The following describes several key points of the IGMP protocol:

1) The IGMP version is currently 1 and has only two types. 1 indicates the query sent by the multicast router and 2 indicates the host in the group.
Response. The Checksum is for 8-byte IGMP packets. Unused domains must be cleared.
2) Two Valid IGMP message examples

IGMP response (2)
TTL = 1
Group address
Destination IP = Group address
Source IP = Local IP

IGMP query (1)
TTL = 1
Group address = 0
Destination IP address = 224.0.0.1
Source IP = multicast router IP

3) when a process on the host is added to a group on a local interface
In this group, an IGMP response is sent. This opportunity maintains relevant information until all local processes exit this
Group.

When a process leaves a group, it does not send an IGMP response. When all processes on the machine exit from all groups
The caster router sends Query Packets without IGMP response.

The multicast router periodically sends a query. The Group address of the query packet is fixed to 0, and the target IP address is 224.0.0.1.

4) The Class D address of 224.0.0.0-239.255.255.255 belongs to the multicast address. However, 224.0.0.0 cannot be used.
Any group. 224.0.0.1 indicates all the hosts and routers with multicast capabilities in the LAN.
After the port is initialized, if it has the multicast capability, it is automatically added to the group, even if no local process is explicitly added to the group
Group. IGMP response is not sent because it is added to the group. The multicast address can appear as the target IP address, but cannot
As the source IP address.

If the multicast address between 224.0.0.0-224.0.0.255 appears on the target IP address, no matter how large the TTL is,
The multicast Router does not forward such packets. Such packets can only appear in the LAN. Obviously
224.0.0.1.

5) if the TTL is 0, the multicast packets cannot be sent to the host. If the TTL is 1, the multicast packets can only be transmitted over the LAN. For example
If you want to be forwarded by the multicast router, you must set a larger TTL.

The above description is the description of the 4.x BSD implementation by W. Richard. Steven S, which may change now. Version and type
Share one byte, and the version occupies 4 bits. Therefore, many header files define macros such as 0x11 and 0x12.
0x16, 0x17. The annotations are clear.

After a member host in the group receives an IGMP query, it will respond within a random period of time, because multicast causes other
All member hosts receive a response, not only the host that sends the query message, but other Member hosts do not respond,
This avoids the storm response. Non-group member hosts can send Query Packets, but they cannot receive the corresponding IGMP response.
Yes. Not only multicast routers can send IGMP queries, but the data of other IGMP Query Packets is different,
For example, the destination IP address is not necessarily 224.0.0.1. It can be another multicast address, and the Group IP address is not necessarily 0.
It is a fixed group address.

The Libnet Library has the following function prototype:

Int libnet_build_igmp (u_char type, u_char code, u_long IP,
Const u_char * payload, int payload_s,
U_char * BUF );

This function is used to construct IGMP packets, the type value is in/usr/include/Libnet/libnet-headers.h
Macro definition:

# Define igmp_membership_query 0x11/* Membership Query */
# Define igmp_v1_membership_report 0x12/* ver. 1 Membership report */
# Define igmp_v2_membership_report 0x16/* ver. 2 Membership report */
# Define igmp_leave_group 0x17/* Leave-group message */

Here 0x17 seems to indicate that an IGMP message should be sent to you to leave the group later. It is unclear. 0x16 is even more fascinating
Paste, since it is version 2, it should be 0x26, do not understand. We don't need them.

The code of the parameter should specify the unused domain, so it can only be zero. The parameter IP specifies the D-class multicast address, and payload is
Null, payload_s is zero. The shape parameter Buf needs to point to an allocated data zone, and the IGMP header is open from this pointer
Start.

Libnet_do_checksum (packet, ipproto_igmp, libnet_igmp_h) is used for verification and calculation.
Number. Of course, if the IGMP packet is abnormal, the parameter value needs to be adjusted with the load.

Unfortunately, the attack did not actually use the above functions, but only indicated by the upper-layer protocol domain of the IP header.
The load is an IGMP packet.

The IGMP attack program described below has many exceptions:

1) The upper layer of the IP header Protocol specifies that IGMP messages appear in the IP data zone, but the destination address of the IP header is not a multicast location.
The address is the unicast address (also the target address of the attack), so can such packets be called IGMP packets?
Whether the message is processed as an IGMP message is questionable.
2) IGMP messages are 8 bytes in total, with no additional load. However, this attack program has other loads and has a large load,
Deliberately creates IP fragmentation. The attacker uses reverse order to send IP segments. The last segment is sent first.
Slice, and finally send the first slice. The raw_socket is used to manually create exception fragments, instead of making IP addresses
The protocol stack fragment itself. In fact, the sender has never seen a large and complete IP packet before the fragment.
3) The version, type, checksum, and group address of IGMP packets are all zero, which is obviously abnormal.
4) if a complete batch of IP segments are used as the unit, the original program sends them twice in a loop. Feeling during testing
It depends on the sending speed and the number of sent packets. It is used twice by default, not every attack is successful.
In this case, repeated attacks are not very effective. In the program, adjust the number of cycles to 200, and an attack is
It is obviously related to the attack speed and number of packets.

The source IP address is not required to be equal to the target IP address. It can be a source IP address forged at will. The target IP address is not a multicast address,
For a router that only sees the IP layer, it is a common unicast IP packet and does not realize that route 1
IGMP packets (if this packet can be called an IGMP packet ). Some friends said they could not
And some friends said that the remote attack was effective. According to my analysis, remote attacks
In some cases, it is not because the regular route does not forward multicast packets. As explained above
The unicast IP packet is lost due to the part loss. This attack program creates 11 shards each time, far
The attack cannot guarantee that 11 parts can arrive at the target IP address on time and then be reorganized. In this case, after the reorganization
Huge exception IGMP packets cause troubles.

Some people may ask what the DoS attack works, and some may ask what messages are sent,
I feel that the answer is just a representation. To really explain why the blue screen and why the machine crashed, we need to use SoftICE to track the object.
The processing process of the packets. A valid DoS packet does not indicate the problem.
The software captures packets and reads the source code analysis reports only to find out what types of packets will lead
DoS: Why does such a message cause DoS not to be answered by network data itself. The one from the past
Jot2.c, I can only know the type of message that may cause DoS, but why is it unclear, regardless
Analyze the implementation of these protocols in a specific operating system, and only view the network data. What is the answer?
Boots are itchy. I'm not very fond of others discussing this issue in this way. No.
You need to have a deep understanding of the real causes of this type of DOS, unless you have the ability to modify the system and repair the source like Linux.
Code.

This attack first causes the target blue screen. After the carriage return, the IP stack is basically deprecated and the target cannot be pinged remotely,
Restart recovery is required. But it does not cause a crash. You can also do other non-network work. If yes
SoftICE: the situation is not the same. I am not familiar with it and I will not describe it much.

5) The ID field of the IP header has never changed. How to partition the parts in the next round of loop and the parts in the previous round of loop?
Points, I can't tell the difference. What is the impact on the receiver's sharding?

I personally think this attack can be carried out remotely, and the source IP address is not required to be the same as the target IP address. This is a great opportunity. Command
Specifies the number of spoofed source IP addresses, attack target IP addresses, and IGMP packets on the line (in the unit of a batch of fragments ).

--------------------------------------------------------------------------
Void igmpsend (u_long srcip, u_long dstip)
{
U_short ipdatalen;
U_short frag;
U_short bit;

Bit = 0;
Ipdatalen = 200;/* 200 bytes of load, a total of 15000 bytes of load */
Frag = 1850;
Do
{
/* Construct an IP header */
Libnet_build_ip (ipdatalen,/* IP data zone length */
Iptos_lowdelay,/* IP ToS */
19774,/* ip id */
Frag | bit,/* frag stuff */
255,/* TTL */
Ipproto_igmp,/* upper-Layer Protocol */
Srcip,/* big-Endian Order */
Dstip,/* Target IP */
Null,/* no option */
0,/* Option Length 0 */
Packet);/* point to the IP header */
Libnet_write_ip (rawsocket, packet, libnet_ip_h + ipdatalen );
If (frag = 0)
{
Break;
}
Ipdatalen = ipdatalen;
Bit = 0x2000;/* Non-last part */
Frag-= 185;
} While (1);/* A total of 11 parts are sent out */
Return;
}/* End of igmpsend */