Insertion
An IDS can accept a packet that an end-system rejects. An IDS that does this makes the mistake of believing that the end-system has accepted and processed the packet when it actually hasn’t.
We call this an “insertion” attack, An attacker can use insertion attacks to defeat signature analysis, allowing her to slip attacks past an IDS.
“signature analysis” uses pattern-matching algorithms to detect a certain string within a stream of data. For instance, an IDS that tries to detect a PHF attack will look for the string “phf” within an HTTP “GET” request, which is itself a longer string that might look something like "GET /cgi-bin/phf?“.
The IDS can easily detect the string “phf” in that HTTP request using a single substring search. However, the problem is much more difficult, to solve when the attacker can send the same request to a web server, but force the IDS to see different string, such as “GET /cgi bin/pleasedontdetecttthisforme?”.
The attacker has used an insertion attack to add “lcasedontdetectt”, “is”, and
‘orme” to the original stream. The IDS can no longer pick out the string “phf”
from the stream of data it observes.
For Example
Attacker can insert data into the packet with bad checksum value the end host may reject this packet and the IDS may accept it, as a result the end host gets the 'ATTACK' and the IDS misses detecting it.
A “denial of service” (DOS) attack is one that is intended to compromise the availability of a computing resource. Common DOS attacks include ping floods and mail bombs both intended to consume disproportionate amounts of re-sources, starving legitimate processes. Other attacks are targeted at bugs in software, and are intended to crash the system.
One IP header field that is easy to neglect is the checksum. It, may seem unnecessary for an IDS to verify the accuracy of the checksum on each captured packet; however, a datagram with bad checksum will not be processed by most IP implementations. An IDS that does not reject packets with bad checksums is thus vulnerable to a very simple insertion attack.
TTL
A harder problem to solve is the TTL field. The TTL (time to live) field of an IP packet dictates how many “hops” a packet can traverse on it’s way to it‘s destination. Every time a router forwards a packet, it decrement,s the TTL. When the TTL runs out, the packet is dropped. If the IDS is not on the same network segment as the systems it watches, it, is possible to send packets that only the IDS will see by setting the TTL just long enough for the packet, to reach the IDS, but too short for the packet to actually arrive at it’s destination.
Don't Fragment
“Don’t Fragmentt” (DF) flag in the IP header. The DF flag tells forwarding devices not to split a packet, into fragments when the packet is too large to be forwarded, but instead to simply drop the packet. If the maximum packet size of the nework the IDS is on is larger than that of the systems it watches, an attacker can insert packet by making them too large for the destination nework and setting the DF bit.
Most end-systems will drop a packet that is “strict source routed” when the host’s own address is not in the specified source route. It is reasonable for an IDS to drop such packet, avoiding an insertion attack. However, many operating systems can be configured to automatically reject source routed packets. Unless the IDS knows whether a source-routed packet’s destination rejects such packets, the correct action to take is ambiguous.
Timestamp
“timestamp” option requests that, certain recipients of the datagram place a timestamp within the packet. The code that processes the timestamp option can he forced to discard the packet (if the option is malformed). If the sniffer does not validate the timestamp option in the same manner as the end systems it watches, the inconsistency can he exploited.
An attacker on the same LAN as a
network monitor can direct link-layer frames to the IDS, without ever allowing
the host specified as the IP destination to see the packet.
Even if the attacker doesn’t know the link-layer address of the network monitor: she can exploit the fact that the network monitor is operating in promiscuous mode by addressing the frame to a fake address. Again, unless the IDS verifies the destination address in the IP header against the correct link-layer address (and can do so reliably), it can be fooled by falsely-addressed link-layer frames.
IP Fragmentation
IP packets can be broken into smaller packets, and reassembled at the destination.
This is termed “fragmentation”: and is an integral part of the IP protocol.
IP fragmentation allows the same information to travel over different types of
network media (which may have different packet, size limits) without limiting
the entire protocol to an arbitrary small maximum packet size. Because end-systems will reassemble a stream of IP fragments, it is important
that a network monitor correctly reassemble fragments as well. An IDS
that does not correctly reassemble fragments can be attacked simply by ensuring
that all data is exchanged between machines using artificially fragmented
packets.
Out-Of-Order Fragments
If IDS doesn't know the order of the fragmented packets and how to handle out-of-order fragments is vulnerable to attack.
Flood By Fragment
Another significant problem is the fact that received fragments must, be stored until the stream of fragments can be reassembled. by doing so IDS can be attacked by flooding the network with partial, fragmented datagrams which will never be completed.
Systems drop fragments based on their TTL, to avoid running out of memory due to over-full fragment queues. An IDS that eventually drops old, incomplete fragment streams must do so in a manner consistent with the machines it’s watching, or it will be vulnerable to insertion (due to accepting fragment streams that end-systems have dropped already) or evasion (due to dropping fragments that some systems have not yet discarded) attacks.
Overlapping
Overlapping occurs when fragments of differing sizes arrive out of order and in overlapping positions. If a fragment, arriving at an end-station contains data that has already arrived in a different fragment, it is possible that, the newly arrived data may overwrite some of the old data. And may reassemble a completely different packet than an end system in receipt of the same fragments.
IP Options in Fragment Streams
RFC791dictates that certain IP options are to be present in every fragment of a datagram (for example, the “security” option), and others must appear only in the first fragment.
A strict implementation of IP could discard fragments that incorrectly prevent options. Many implementations do not,. If the IDS doesn’t behave exactly like the machines it’s watching in this respect, it will be vulnerable to insertion and evasion attacks.
Resource Exhaustion
There are many different types of denial of service attacks that are valid against ID systems. The attacks we’ll discuss here all involve resource exhaustion the attacker identifies some point of network processing that requires the allocation of some sort of resource, and causes a condition to occur that consumes all of the resource. Resources that can be exhausted by an attacker include CPU cycles, memory, disk space, and network bandwith.
The CPU processing capabilities of an IDS can be exhausted because the IDS spends CPU cycles reading packets, determining what they are, and matching than to some location in saved network state (for example, an IP fragment, needs to be matched to the other fragments of the datagram it represents). An attacker can determine what the most computationally expensive network processing operations are, and force the IDS to spend all its time doing useless work.
Exhausting Memory
An attacker trying to exhaust memory on an IDS examines the system, trying to determine the points at which the system allocates memory. The attacker attempts to isolate network processing events that, cause the system to allocate memory for a long duration of time; the attacker then induces this processing by sending packets that the IDS will be forced to process in that manner. After being flooded with such packets for some time, the IDS will run out of memory to process the incoming packets.
Exhausting Network Bandwidth
Perhaps the simplest way to starve an IDS of resources is simply to creatc too much raw network traffic for the system’s low-level network interface to keep up with. As each packet arrives, the interface must copy the packet off the wire and into a buffer, interrupt the system, and cause the system to copy the packet into the kernel. The interface is capable of handling only a limited amount of traffic before it is overwhelmed by the load and starts dropping incoming packets.
Creating False Positives
Attacker simply creates and blindly sends forged packets, and the IDS is fooled into believing that the attack is coming from somewhere that it isn’t. Good examples of this include ICMP ping floods, SYN floods, “death” packets (such as the ping-of-death attack involving large ICMP echo requests), and UDP packet storms.
An IDS can accept a packet that an end-system rejects. An IDS that does this makes the mistake of believing that the end-system has accepted and processed the packet when it actually hasn’t.
We call this an “insertion” attack, An attacker can use insertion attacks to defeat signature analysis, allowing her to slip attacks past an IDS.
“signature analysis” uses pattern-matching algorithms to detect a certain string within a stream of data. For instance, an IDS that tries to detect a PHF attack will look for the string “phf” within an HTTP “GET” request, which is itself a longer string that might look something like "GET /cgi-bin/phf?“.
The IDS can easily detect the string “phf” in that HTTP request using a single substring search. However, the problem is much more difficult, to solve when the attacker can send the same request to a web server, but force the IDS to see different string, such as “GET /cgi bin/pleasedontdetecttthisforme?”.
The attacker has used an insertion attack to add “lcasedontdetectt”, “is”, and
‘orme” to the original stream. The IDS can no longer pick out the string “phf”
from the stream of data it observes.
For Example
Attacker can insert data into the packet with bad checksum value the end host may reject this packet and the IDS may accept it, as a result the end host gets the 'ATTACK' and the IDS misses detecting it.
Following image gives a simple example of the same attack.
It doest not matter if attacker sends packets out of order but both the IDS & End Host will assemble them according to the sequence numbers.
Here if IDS has signature of 'ATTACK' in it's database it will prevent that, but with that badsum packet 'X' attacker can bypass signature based detection.
It doest not matter if attacker sends packets out of order but both the IDS & End Host will assemble them according to the sequence numbers.
Here if IDS has signature of 'ATTACK' in it's database it will prevent that, but with that badsum packet 'X' attacker can bypass signature based detection.
Denial of Service
“ping of death” and “teardrop” attacks are examples of these.
Header Manipulation
A harder problem to solve is the TTL field. The TTL (time to live) field of an IP packet dictates how many “hops” a packet can traverse on it’s way to it‘s destination. Every time a router forwards a packet, it decrement,s the TTL. When the TTL runs out, the packet is dropped. If the IDS is not on the same network segment as the systems it watches, it, is possible to send packets that only the IDS will see by setting the TTL just long enough for the packet, to reach the IDS, but too short for the packet to actually arrive at it’s destination.Don't Fragment
“Don’t Fragmentt” (DF) flag in the IP header. The DF flag tells forwarding devices not to split a packet, into fragments when the packet is too large to be forwarded, but instead to simply drop the packet. If the maximum packet size of the nework the IDS is on is larger than that of the systems it watches, an attacker can insert packet by making them too large for the destination nework and setting the DF bit.
Source Routing
Most end-systems will drop a packet that is “strict source routed” when the host’s own address is not in the specified source route. It is reasonable for an IDS to drop such packet, avoiding an insertion attack. However, many operating systems can be configured to automatically reject source routed packets. Unless the IDS knows whether a source-routed packet’s destination rejects such packets, the correct action to take is ambiguous.Timestamp
“timestamp” option requests that, certain recipients of the datagram place a timestamp within the packet. The code that processes the timestamp option can he forced to discard the packet (if the option is malformed). If the sniffer does not validate the timestamp option in the same manner as the end systems it watches, the inconsistency can he exploited.
MAC Addresses
An attacker on the same LAN as a
network monitor can direct link-layer frames to the IDS, without ever allowing
the host specified as the IP destination to see the packet.Even if the attacker doesn’t know the link-layer address of the network monitor: she can exploit the fact that the network monitor is operating in promiscuous mode by addressing the frame to a fake address. Again, unless the IDS verifies the destination address in the IP header against the correct link-layer address (and can do so reliably), it can be fooled by falsely-addressed link-layer frames.
IP Fragmentation
IP packets can be broken into smaller packets, and reassembled at the destination.
This is termed “fragmentation”: and is an integral part of the IP protocol.
IP fragmentation allows the same information to travel over different types of
network media (which may have different packet, size limits) without limiting
the entire protocol to an arbitrary small maximum packet size. Because end-systems will reassemble a stream of IP fragments, it is important
that a network monitor correctly reassemble fragments as well. An IDS
that does not correctly reassemble fragments can be attacked simply by ensuring
that all data is exchanged between machines using artificially fragmented
packets.Out-Of-Order Fragments
If IDS doesn't know the order of the fragmented packets and how to handle out-of-order fragments is vulnerable to attack.
Flood By Fragment
Another significant problem is the fact that received fragments must, be stored until the stream of fragments can be reassembled. by doing so IDS can be attacked by flooding the network with partial, fragmented datagrams which will never be completed.
Systems drop fragments based on their TTL, to avoid running out of memory due to over-full fragment queues. An IDS that eventually drops old, incomplete fragment streams must do so in a manner consistent with the machines it’s watching, or it will be vulnerable to insertion (due to accepting fragment streams that end-systems have dropped already) or evasion (due to dropping fragments that some systems have not yet discarded) attacks.
Overlapping
Overlapping occurs when fragments of differing sizes arrive out of order and in overlapping positions. If a fragment, arriving at an end-station contains data that has already arrived in a different fragment, it is possible that, the newly arrived data may overwrite some of the old data. And may reassemble a completely different packet than an end system in receipt of the same fragments.
IP Options in Fragment Streams
RFC791dictates that certain IP options are to be present in every fragment of a datagram (for example, the “security” option), and others must appear only in the first fragment.
A strict implementation of IP could discard fragments that incorrectly prevent options. Many implementations do not,. If the IDS doesn’t behave exactly like the machines it’s watching in this respect, it will be vulnerable to insertion and evasion attacks.
Resource Exhaustion
There are many different types of denial of service attacks that are valid against ID systems. The attacks we’ll discuss here all involve resource exhaustion the attacker identifies some point of network processing that requires the allocation of some sort of resource, and causes a condition to occur that consumes all of the resource. Resources that can be exhausted by an attacker include CPU cycles, memory, disk space, and network bandwith.
The CPU processing capabilities of an IDS can be exhausted because the IDS spends CPU cycles reading packets, determining what they are, and matching than to some location in saved network state (for example, an IP fragment, needs to be matched to the other fragments of the datagram it represents). An attacker can determine what the most computationally expensive network processing operations are, and force the IDS to spend all its time doing useless work.
Exhausting Memory
An attacker trying to exhaust memory on an IDS examines the system, trying to determine the points at which the system allocates memory. The attacker attempts to isolate network processing events that, cause the system to allocate memory for a long duration of time; the attacker then induces this processing by sending packets that the IDS will be forced to process in that manner. After being flooded with such packets for some time, the IDS will run out of memory to process the incoming packets.
Exhausting Network Bandwidth
Perhaps the simplest way to starve an IDS of resources is simply to creatc too much raw network traffic for the system’s low-level network interface to keep up with. As each packet arrives, the interface must copy the packet off the wire and into a buffer, interrupt the system, and cause the system to copy the packet into the kernel. The interface is capable of handling only a limited amount of traffic before it is overwhelmed by the load and starts dropping incoming packets.
Creating False Positives
Attacker simply creates and blindly sends forged packets, and the IDS is fooled into believing that the attack is coming from somewhere that it isn’t. Good examples of this include ICMP ping floods, SYN floods, “death” packets (such as the ping-of-death attack involving large ICMP echo requests), and UDP packet storms.
Obfuscation
Obfuscation (in the context of software) is a technique that makes binary and textual data unreadable and/or hard to understand. Its implementation can be as simple as a few bit manipulations and advanced as cryptographic standards (i.e. DES, AES, etc).
Session Splicing
It exploits how some IDSs do not reconstruct sessions before performing pattern matching on the data, The idea behind session splicing is to split data between several packers, making sure that no single packet matches any patterns within an IDS signature.
If attackers know what IDS system is in use, they could add delays between packets to bypass reassembly checking. Many IDS reassemble communication streams, so if a packet is not received within a reasonable amount of time, many IDS stop reassembling and handling that stream.
If the application under attacks keeps a session active longer than an IDS will spend on reassembling it, the IDS will stop. As a result, any session after the IDS stops reassembling the session will be susceptible to malicious data theft by the attacker.
Polymorphic Shellcode
In computer terminology, polymorphic code is code that uses a polymorphic engine to mutate while keeping the original algorithm intact. That is, the code changes itself each time it runs, but the function of the code (its semantics) will not change at all. For example, 1+3 and 6-2 both achieve the same result while using different values and operations. This technique is sometimes used by computer viruses, shellcodes and computer worms to hide their presence.
Encryption is the most common method to hide code. With encryption, the main body of the code (also called its payload) is encrypted and will appear meaningless. For the code to function as before, a decryption function is added to the code. When the code is executed this function reads the payload and decrypts it before executing it in turn.
Obfuscation (in the context of software) is a technique that makes binary and textual data unreadable and/or hard to understand. Its implementation can be as simple as a few bit manipulations and advanced as cryptographic standards (i.e. DES, AES, etc).
Session Splicing
It exploits how some IDSs do not reconstruct sessions before performing pattern matching on the data, The idea behind session splicing is to split data between several packers, making sure that no single packet matches any patterns within an IDS signature.
If attackers know what IDS system is in use, they could add delays between packets to bypass reassembly checking. Many IDS reassemble communication streams, so if a packet is not received within a reasonable amount of time, many IDS stop reassembling and handling that stream.
If the application under attacks keeps a session active longer than an IDS will spend on reassembling it, the IDS will stop. As a result, any session after the IDS stops reassembling the session will be susceptible to malicious data theft by the attacker.
Polymorphic Shellcode
In computer terminology, polymorphic code is code that uses a polymorphic engine to mutate while keeping the original algorithm intact. That is, the code changes itself each time it runs, but the function of the code (its semantics) will not change at all. For example, 1+3 and 6-2 both achieve the same result while using different values and operations. This technique is sometimes used by computer viruses, shellcodes and computer worms to hide their presence.
Encryption is the most common method to hide code. With encryption, the main body of the code (also called its payload) is encrypted and will appear meaningless. For the code to function as before, a decryption function is added to the code. When the code is executed this function reads the payload and decrypts it before executing it in turn.
Tools :
• Nmap
• Metasploit
• Nmap
• Metasploit
• Fragtest
• Evader
• Libemu
• Fragrouter
• InTrace
• SniffJoke
• Wireshark
• HxD (hex editor/viewer)
• Inundator
• Evader
• Libemu
• Fragrouter
• InTrace
• SniffJoke
• Wireshark
• HxD (hex editor/viewer)
• Inundator
• Traffic IQ Professional
No comments:
Post a Comment