DoS with Hping3

Denial of service (DoS) attack is a type of network attack by exhausting the network resource of the target in order to overwhelming the network service of the target. In result, the target may have unavailable service to the user. The common target are usually those who give service to public, for example bank service, delivery service, etc.

But, how does could happen? DoS can be conducted with many techniques, however the intention are still the same which is to flood the network of the target until it is exhausted and cannot give any service for proper user. The simple way of flooding the network target is sending the target with huge amount of packet in a short amount of time.

This time, I will try to show what I have learnt to conduct a simple DoS attack to one of my virtual machine. The attack that I used is an ICMP packet flooding with spoofed IP address. In order to do this, I should use an application that has the function to create a packet (packet crafting). This time I will use Hping3 on Kali Linux.  The command to execute the flooding is below:

# hping3 –c 100 –icmp –flood –rand-source target_IP

        

Notes:                                                                      

·      -c 100 actually specifies the number of packet sent, however, since we set the –flood mode, the packets that will be sent are over 100, therefore you could ignore the –c 100 options.

·    --icmp means the packets that will be sent are in form of ICMP packets.

·      --flood allow the rapid send of packets in a short time.

·      --rand-source will spoof the source of the IP address of the source packet.

The screen below is the execution of the command:

The result of the command shows that  there are 1770552 packets sent to the target. Noe, the question is host about the target. The target IP address is 192.168.28.145 on Ubuntu virtual machine. During the test, I ran wireshark and system monitor. Now lets see a cut scene from the wireshark packet that had been captured.

The sequence number of the packets reached 160490 packets of ICMP ping reply and request just in 7-8 seconds. Look at some of the lines here, it shows that the machine on 192.168.28.145 gave the ICMP reply to many spoofed IPs on the destination. This shows how the spoofed IP on Hping3 works. Basically hping3 sends many ICMP packets with spoofed IPs, the target then responds to the ICMP request with ICMP reply. However, since the packets flow are huge and in short amount of time, it may exhaust the network resource. This way if there is a legitimate user trying to contact the machine while an attack is occurring, it may received a delay on the service. That basically how the DoS works.

Here is the system monitor output of the machine:

On the network history part, we can see a huge increase in received and sent network packet. This is when the attack was occurring. Now, we know what and how DoS work. The actual attack would definitely much more complex and harder to solve directly. But with simple knowledge like this, we can gain more experience in the future.

Reference:
http://www.hping.org/manpage.html

 

Unicornscan - TCP and UDP Scan

Unicornscan is one of the port scanning tool found in Kali Linux. Since this is the 1st time I heard of Unicornscan, I browsed a bit about it. Many sources tell that Unicorn scan performs asynchronous scan, meaning that it sends unorganized packets to the target and wait for the responds.

This time I will observe about how Unicorn scan performs the TCP and UDP port scan. Before we started, I use Windows XP SP2 for the target on address 131.107.1.222 while the Kali Linux has address of 131.107.1.101. 

TCP SCAN

Now, lets look at basic TCP scan command in Unicornscan:

unicornscan –msf –I 131.107.1.222

-msf is the command for SYN TCP scan, while –I means immediate where the result of the scan is immediately shown.

 

From the scan result, we know that there are two open TCP port on port 139 and 445. The other information that can be gathered is the ttl value of the host target. The ttl value is 128 indicates the target runs on Windows OS. But, using this results is not enough, therefore during the scan I ran the wireshark to capture the packets that are sent during the scanning process.

Here is the wireshark capture. The scan is performed by sending TCP packet from random port of the host to random port of the target. The host, sent SYN packet to the target. If the port is closed, there is no answer. However, I got a SYN ACK replied from port 445 (line 13) from SYN packet from line 3 and the next packet that follows this reply is an RST flagged packet from the host to the target(line 14). 

The same thing also happened for port 139. The SYN packet to port 139 was replied by a SYN ACK packet, the the host sent the  RST packet.

 

 

Now, we may assume how unicornscan determined the state of the port. Then, something interestinng happened after 1 seconds since the RST packet sent, the host machine sent an ACK packet to the open port. The open port then replied the ACK packet with 2 RST packet. In the image below we see that the Windows machine sent 2 RST packet to the port that sent the initial ACK, between these 2 RST packet there are NetBIOS Session Service with continuation message.

 

UDP SCAN

After we see how TCP SYN scan works, I tried the UDP port scan. The command for this scan is:

unicornscan –mU –I 131.107.1.222

 

-mU is the command for UDP scan. 

The result from the scan is straightforward as it indicates that the open UDP port is at port 137. Same as before, I ran wireshark while the scan is on progress. The wireshark capture below shows that most of the packets sent are UDP packets with target to random port from random port also. However, I cannot specifically see that packet that stated the open port on 137.

 

But there is one unique ICMP packet with code 3 and type 3 (destination unreachable and port unreachable type). Interested with this packet, I see the detail of the ICMP packet. This ICMP unreachable port come from port 137 of the target machine. Since the open port result is 137 and this is the only ICMP packet, I assumed that the unicornscan determine the open UDP port if there is port ureachable ICMP message.

 

However, still unsure about this, I performed UDP scan for specific port with this command:

 unicornscan –mU –I 131.107.1.222:137

The result from the wireshark show the ICMP port unreachable message. Now I’m pretty sure that the port unreachable is the indicator of open UDP port.

 

The conclusion from my little founding are open TCP port is indicated by the SYN, ACK reply from the port and the open UDP port is surprisingly determined from the port unreachable ICMP packet. 

Reference:

•  http://kalilinuxtutorials.com/unicornscan/