EAI Endorsed Transactions on _________________

06-07-2015 | Volume 1 | Issue __ | e_

EAI Endorsed Transactions on Wireshark – Network Protocol Analyzer Editorial

1 Wireshark

Wireshark – Network Protocol Analyzer

Abstract

The objective of this paper is to explore Wireshark an open source tool developed to capture live packets in a network,

analyze few sample packet captures and debug various communication protocols used in a network. The paper also

explores some security issues that can be observed through sample packet captures by monitoring the network. This tool is

used by various network engineers to analyze network packets and help them improve the performance of the network. It

is also used by Network security professionals for forensic purposes by debugging and tracing various attacks in the

network by caused by attackers like DDOS, ARP request attack, DNS poisoning etc.

1.0 Introduction A packet analyzer (also known as a network analyzer,

protocol analyzer or packet sniffer—or, for particular

types of networks, an Ethernet sniffer or wireless sniffer)

is a computer program that can intercept and log traffic

that passes over a digital network or part of a network. As

data streams flow across the network, the sniffer captures

each packet and, if needed, decodes the packet's raw data,

showing the values of various fields in the packet, and

analyzes its content according to the appropriate RFC.

Wireshark, formerly known as Ethereal is one such free

and open-source packet analyzer. Wireshark can be used

to examine the details of traffic at a variety of levels

ranging from connection-level information to the bits that

make up a single packet. Packet capture is the process of

intercepting and logging traffic, it can provide a network

administrator with information about individual packets

such as transmit time, source, destination, protocol type

and header data. This information can be useful for

evaluating security events and troubleshooting network

security device issues.

2.0 History Of Wire Shark

In late 1997 Gerald Combs needed a tool for tracking

down network problems and wanted to learn more about

networking so he started writing Ethereal (the original

name of the Wireshark project) as a way to solve both

problems.

Ethereal was initially released after several pauses in

development in July 1998 as version 0.2.0. Within days

patches, bug reports, and words of encouragement started

arriving and Ethereal was on its way to success. Not long

after that Gilbert Ramirez saw its potential and

contributed a low-level dissector to it. In October, 1998

Guy Harris was looking for something better than tcpview

so he started applying patches and contributing dissectors

to Ethereal.

In late 1998 Richard Sharpe, who was giving TCP/IP

courses, saw its potential on such courses and started

looking at it to see if it supported the protocols he needed.

While it didn’t at that point new protocols could be easily

added. So he started contributing dissectors and

contributing patches.

The list of people who have contributed to the project has

become very long since then, and almost all of them

started with a protocol that they needed that Wireshark or

did not already handle. So they copied an existing

dissector and contributed the code back to the team.

In 2006 the project moved house and re-emerged under a

new name: Wireshark. In 2008, after ten years of

development, Wireshark finally arrived at version 1.0.

This release was the first deemed complete, with the

minimum features implemented. Its release coincided

with the first Wireshark Developer and User Conference,

called Shark fest.

3.0 Modes of Operation in Windows

Wireshark can work in command line as well as in

graphical user interface mode in Windows.

Figure 1: Wireshark in Command line mode

Siddharth Coontoor

2

The Wireshark in command line mode supports a large

number of command line parameters. The command line

parameters can be explored using the command

"wireshark -h" in the command line. All the functions that

the tool supports in the graphical user interface can be

also executed using the command line. Figure 1 is a

screen shot of subset of the command line parameters.

In the graphical interface mode, the Wireshark tool makes

capturing and monitoring the packets very easy using a

different colour scheme for different communication

protocol. This feature makes it convenient for the security

professionals to identify the various protocol messages

and filter them using filtering rules or patterns so that they

can remove the unwanted packets and focus only on the

packets they are interested in from the packet capture.

Figure 2: Graphical interface of Wireshark

Figure 2 shows a sample screenshot of Wireshark

graphical interface. Wireshark will typically display

information in three panels. The top panel lists frames

individually with key data on a single line. Any single

frame selected in the top pane is further explained in the

tool's middle panel. In this section of the display,

Wireshark shows packet details, illustrating how various

aspects of the frame can be understood as belonging to the

data link layer, network layer, transport layer or

application layer. Finally, Wireshark's bottom pane

displays the raw frame, with a hexadecimal rendition on

the left and the corresponding ASCII values on the right.

It is easy to observe that the green coloured packets are

TCP and packets marked in blue are DNS etc.

4.0 Analyzing Packets in a capture Wireshark is not an intrusion detection system. It will not

warn the user when someone does strange things on the

network that he/she is not allowed to do. However, if

strange things happen, Wireshark would help to figure out

what is really going on. Wireshark will not manipulate

things on the network, it will only "measure" things from

it. Wireshark does not send packets on the network or do

other active operations. It would first do a packet capture

by capturing all the packets in the network. This activity

is sometimes called as sniffing and an attacker could also

do this for reconnaissance. Network engineers would

perform packet captures to monitor the network and

debug the network for performance issues whereas

Security professionals would use these captures to

identify and debug malwares and other threats to the

network.

To perform a packet capture of the network in Windows

operating system, the user would have to download the

WinPcap driver (called NPF) which is also provided by

Wireshark. This requires administrator privileges. Once

the driver is loaded, every local user can capture from it

until it's stopped again. While capturing packet from a

network the NIC card would have to be enabled in

promiscuous mode. This is a mode for a wired network

interface controller (NIC) or wireless network interface

controller (WNIC) that causes the controller to pass all

traffic it receives to the central processing unit (CPU)

rather than passing only the frames that the controller is

intended to receive.

The NIC would start to capture all the packets in the

network in formats like .cap, .libcap, .pcap etc. The act of

capturing packets in a network without the consent of the

owner of the network could be considered malicious and

the user could face legal actions, therefore it is best to

perform these actions by consulting a lawyer.

As seen in Figure 2, we observe in the second panel of the

tool that different packets are represented by different

colours. This is a feature in the tool that makes it easy for

the user to identify the protocols when viewing a packet

capture. The colour codes for every protocol is completely

customizable. Figure 3 illustrates the customizable screen

and the currently assigned colour rules set for the packets.

Figure 3: Colouring Rules for packets

Another useful feature in the tool is the filter. The filter

allows the user to search for particular strings in packets

and also create labels using pattern expressions and

saving them for later use. This helps security and network

Wireshark – Network Protocol Analyzer

3

professionals to zero down on what they are looking for in

thousands on packets that they are looking at.

5.0 Network Monitoring and Identifying Threats Using Wireshark

This section introduces scenarios that demonstrates how

Wireshark can be used to effectively to monitor network

and understand the protocols using Scenarios 1 and 2.

Also explores how the tool can be used by security

professionals to investigate and analyze network threats

like detecting port scanning, ARP cache poisoning and

malware downloaded through websites. These techniques

are used widely for forensic purposes and used to

understand, document and publish the threats to the

security community and help design a solution to avoid

further exploits.

5.1 Scenario 1: Http packet request and response capture and analysis Wireshark supports capture and analysis of HTTP packets

and allows the administrator to view the process of

connection establishment in detail. This section explores

how to analyze a simple HTTP connection using a packet

capture. A detailed HTTP connection process flow

diagram and TCP handshake process can be referenced

while tracing the packets for clarity as presented in the

Appendix A.1.

In this scenario, the packet capture shows a client

representing IP 145.254.160.237 establishing a

connection with server 65.208.228.223.

Snapshot 1

Initially, there is a TCP handshake between the client and

server. This can be seen by looking at the frames 1, 2, 3

(snapshot 1) and observing the ACK and SYN flags. Also

observe that the sequence and acknowledgment numbers

that indicates that the connection is as per the flow

diagram in Appendix A.1.

Snapshot 2

As soon as the initial TCP handshake is established, we

can say that the client has successfully connected to the

server. Next, the client sends a HTTP GET request seen in

frame 4 (snapshot 2). Also observe in the TCP level, the

ports communicating between the client and the server are

3372 and 80(HTTP) respectively as shown in the snapshot

3.

Snapshot 3

In the same packet at the HTTP level we can see exactly

what the client is requesting from the server in the HTTP

format. We see the client sending details to the server

about the User Agent , the formats it would accept and

languages it supports etc. as shown in the below snapshot

4. In addition Wireshark also mentions the response to

this request is present at frame 38 making it easy to follow

the communication in the last line.

Snapshot 4

The frame 38 is a packet sent from the server to the client

which contains the HTTP response and the page requested

in by the client. The details can be seen in the HTTP

response header in the frame 38 in the snapshot 5 below.

Snapshot 5

Lastly, once the HTTP request/response phase is

completed, the client and server would want to end the

connection in a graceful manner, this can be seen in the

below snapshot 6 where the client and server send FIN

flag enabled TCP packets to close the connection

gracefully.

Siddharth Coontoor

4

Snapshot 6

5.2 Scenario 2: SSL Handshake and encrypted payload capture and analysis SSL (Secure Sockets Layer) is the standard security

technology for establishing an encrypted link between a

web server and a browser. This section explores a packet

capture of an SSL handshake between a server and a

browser and also views the encrypted payload and

methods that Wireshark provides to decrypted the payload

using the encryption key. This can be used by security

professionals for forensic analysis to gather information

and evidence of communications between two parties.

In this packet capture, the client and server are different

ports of the same machine 127.0.0.1 communicating

through ports 38713 and 443(default port for SSL). The

SSL handshake protocol can be referenced from the

Appendix A.2.

This packet capture includes a SSL handshake in which a

RSA key exchange algorithm is being used. Initially, a

TCP three way handshake takes place that establishes

connection between the client and the server as shown in

snapshot 7.

Snapshot 7

Once connection established, the client would send a

“CLIENT HELLO” to the server which contains SSL

protocol version, Session ID, a list of cipher suits client

supports which the server would need to securely

communicate with the client. This is seen in snapshot 8.

Snapshot 8

Now the server would send a “SERVER HELLO”

encapsulating information that a client would need to

securely communicate with the server. This is seen in

frame 6 as shown in the snapshot 9.

Snapshot 9

The “SERVER HELLO” contains SSL version, session

specific data, cipher selected for secure communication

and the server’s certificate that contains the public key.

The above cipher suite has been selected by the server

which indicates that SSL version 3 TLS is used for secure

communication, RSA is used for key exchange and 256

bit AES in CBC mode would be used for symmetric

encryption and SHA algorithm for integrity of the

messages exchanged.

The client would now first validate the validate the

server’s certificate and use the public key specified in the

certificate to encrypt a pre master secret and sends it to

the server. The pre master secret is created by the client

based on the cipher suite selected by the server. This

client key exchange is seen in frame 8 in the screenshot

10.

Snapshot 10

Now, the server uses its private key to decrypt the pre

master secret and generate the master key with the agreed

cipher. Using this master secret they generate the

Wireshark – Network Protocol Analyzer

5

symmetric session key which would be used from now to

encrypt and decrypt messages exchanged between them.

The client and server therefore use asymmetric keys to

establish a symmetric key that will be used throughout the

session. The encrypted payload can be seen sent from the

client to server in snapshot 11.

Snapshot 11

Additionally, Wireshark also provides the functionality of

decrypting the encrypted payload provided one has the

session key. The below snapshot 12 shows the method of

decrypting the payload by inserting the key into the

packet capture.

Snapshot 12

Snapshot 12, shows that after providing details of the IP

address and port of the server, the underlying protocol

used and the session key used to encrypt the application

payload, the tool would decrypt the payload and allow the

security professionals to gain information about the

messages exchanged.

Snapshot 13

Snapshot 13 shows packet capture after the decryption of

the communication marked in green by the tool.

5.3 Scenario 3: NMAP OS Fingerprinting Scan OS fingerprinting is the process of determining the

operating system used by a host on a network. This

technique can be used by attackers to understand and gain

more information about the systems in the target network.

If an attacker can identify the operating systems that run

on specific target machine, they can then learn which

exact vulnerabilities to exploit. Each and every OS in

deployment has unique bugs and vulnerabilities. When an

exact OS is determined, it is really easy to research what

they are. That is even often true when bug reports have

not been sent to vendors already, and the corresponding

patches have yet to be developed. So, hardening against

OS fingerprinting can, in some cases, prevent zero-day

attacks.

Nmap ("Network Mapper") is a free and open source

utility for network discovery and security auditing. Many

systems and network administrators also find it useful for

tasks such as network inventory, managing service

upgrade schedules, and monitoring host or service uptime.

This tool is often used by attackers in OS fingerprinting

systems of the target network. It is therefore important to

detect and harden against OS fingerprinting.

This section demonstrates a packet capture of an active

NMAP OS fingerprinting scan. Active fingerprinting

works by sending packets to a target and analyzing the

packets that are sent back. In this capture we observe the

various packets sent by an attacker to the network.

When Nmap scan is executed on a remote machine, it

sends a number of TCP, UDP, and ICMP probes to the

target machine. Nmap sent probes to lots of different

TCP/IP ports, and analyzes what returned.

Specific OSes and network service applications leave

different types of data in their TCP, UDP, and ICMP

packets. Nmap utilizes scripting that analyzes that data to

print out results that are useful for OS fingerprinting.

In the following packet capture, a host at IP 172.1.16.150

is a target of a NMAP OS fingerprint scan by IP

172.16.16.128 (attacker). The packet capture reveals a

variety of packets sent by 172.16.16.128 that include

TCP, UDP and ICMP echo. The packet capture includes

frames in which the attacker tries to send these packets to

port 135 and make the target host reply to these requests.

Siddharth Coontoor

6

Snapshot 14

The snapshot 14 shows 26 frames with respect to the

relative times and several different types of packets have

been sent by IP 172.16.16.128 to the host at IP

172.1.16.150 and port 135. Frames 1-12 show IP

172.16.16.128 create half open connections using TCP

SYN/ACK and gathering the responses from the host

machine. Also, the attacker at IP 172.16.16.128 uses

different ports (53936-53941 and 53948-53952) to initiate

the half open TCP connections, so as to bypass any

firewall restrictions. In frame 13-16 we see ICMP ping

requests from the attacker and the subsequent replies from

the host. Frame 17,26 shows a UDP packet sent from

attacker to the host to check if port 42283 is open, since

the host doesn’t reply with a ICMP destination

unreachable error code it is most likely that the UDP port

is open. Frames 18-25 show TCP requests and responses

to attacker with various flags like URG, CWR, ECN, FIN

that seem to indicate a OS fingerprinting scan from IP

172.16.16.128.

5.4 Scenario 4: ARP cache poisoning at packet level Address Resolution Protocol (ARP) is a protocol for

mapping an Internet Protocol address (IP address) to a

physical machine address that is recognized in the local

network. The physical machine address is also known as a

Media Access Control (MAC). A table, usually called the

ARP cache, is used to maintain a correlation between

each MAC address and its corresponding IP address.

Every machine in a local network maintains its own copy

of the ARP cache. ARP provides the protocol rules for

making this correlation and providing address conversion

in both directions.

When an incoming packet destined for a host machine on

a particular local area network arrives at a gateway, the

gateway asks the ARP program to find a physical host or

MAC address that matches the IP address. The ARP

program looks in the ARP cache and, if it finds the

address, provides it so that the packet can be converted to

the right packet length and format and sent to the

machine. If no entry is found for the IP address, ARP

broadcasts a request packet in a special format to all the

machines on the LAN to see if one machine knows that it

has that IP address associated with it. A machine that

recognizes the IP address as its own returns a reply so

indicating. ARP updates the ARP cache for future

reference and then sends the packet to the MAC address

that replied.

This section explores ARP Poisoning that takes advantage

of the overly trusting ARP system. By sending forged

ARP packets, an attacker can cause a victim to send

traffic to any nodes on the local network or perform a

man-in-the-middle attack or also potentially cause a

denial of service by broadcasting a bogus MAC address

for the default gateway.

There are two primary types of ARP messages:

1. ARP Request: This is a message broadcasted to IP

addresses essentially asking "who has this IP address?"

2. ARP Reply: The machine with the IP address responds

to the request with its MAC address. All machines that

hear the reply cache the MAC address.

Snapshot 15

In this packet capture as seen in snapshot 15, filtering to

only "arp" packets and observing frame 54 which appears

to be an arp request asking "who has 172.16.0.107? Tell

172.16.0.1". This packet sent by the attacker manages to

poison the ARP cache of machine with IP address

172.16.0.107. The injected packet at frame 54 exploits the

ARP protocol since ARP assumes that when a machine

receives an ARP Request, it trusts the MAC/IP pair of the

requester and thus the machine updates its ARP Table

with the senders MAC and IP pair. Here the MAC

(00:25:b3:bf:91:ee) as seen in the specially crafted packet

in the is of the attacker and the IP address(172.16.0.1) is

spoofed. The subsequent ARP responses in frame 55, 56

would be treated as unsolicit replies and ignored.

Wireshark – Network Protocol Analyzer

7

Snapshot 16

Furthermore as seen in snapshot 16, frame 165 shows a

broadcast ARP request packet that is sent to all machines

in the local network asking "who has 172.16.0.1? Tell

172.16.0.105". The result the attacker manages to poison

all cache table entries to IP 172.16.0.105 with his MAC

address (00:25:b3:bf:91:ee).

5.5 Scenario 5: Distributed Denial Of service By TCP SYN Flood attack TCP SYN flood is a type of Distributed Denial of Service

(DDoS) attack that exploits part of the normal TCP three-

way handshake to consume resources on the targeted

server and render it unresponsive.

Essentially, with SYN flood DDoS, the offender sends

TCP connection requests faster than the targeted machine

can process them, causing network saturation.

A normal TCP three way handshake can be seen in

Appendix A.1. In a SYN flood attack, the attacker sends

repeated SYN packets to every port on the targeted server,

often using a fake IP address. The server, unaware of the

attack, receives multiple, apparently legitimate requests to

establish communication. It responds to each attempt with

a SYN-ACK packet from each open port.

The malicious client either does not send the expected

ACK, or if the IP address is spoofed never receives the

SYN-ACK. Either way, the server under attack will wait

for acknowledgement of its SYN-ACK packet for some

time.

During this time, the server cannot close down the

connection by sending an RST packet, and the connection

stays open. Before the connection can time out, another

SYN packet will arrive. This leaves an increasingly large

number of connections half open. Eventually, as the

server’s connection overflow tables fill, service to

legitimate clients will be denied, and the server may even

malfunction or crash causing a denial of service to

legitimate clients.

Snapshot 17

Snapshot 17 shows a packet capture which demonstrates a

host at IP 192.168.0.1 being flooded with SYN TCP

packets from various IPs. These machines IP addresses

could be either spoofed IPs or could be botnets that the

attacker controllers to launch this attack. The tool clearly

captures these random clients sending SYN packets to the

host to create the half open connections and attempts to

create a denial of service for legitimate clients.

Siddharth Coontoor

8

Appendix A. Protocols and Flow Diagrams

This section provides protocols and its flow diagrams for

reference purposes as used in the scenarios.

A.1. HTTP connection and TCP handshake flow diagram:

HTTP connection between client and server flow diagram

TCP Handshake Flow diagram

A.2. SSL Handshake:

References

[1] https://en.wikipedia.org/wiki/Packet_analyzer

[2] https://en.wikipedia.org/wiki/Wireshark

[3] http://searchsecurity.techtarget.in/definition/Wireshark

[4] https://www.wireshark.org/docs/wsug_html_chunked/ChIn

troHistory.html

[5] http://malware-traffic-analysis.net/index.html

[6] http://www.netresec.com/?page=PcapFiles

[7] https://www.wireshark.org/docs/man-pages/

[8] https://en.wikipedia.org/wiki/Pcap

[9] https://en.wikipedia.org/wiki/Promiscuous_mode

[10] http://www.symantec.com/connect/blogs/trojanhydraq-

incident-analysis-aurora-0-day-exploit

[11] https://www.wireshark.org/docs/wsug_html_chunked/ChC

ustColorizationSection.html

[12] http://www.symantec.com/connect/blogs/how-does-ssl-

work-what-ssl-handshake

[13] http://resources.infosecinstitute.com/must-know-os-

fingerprinting/

[14] http://forensicswiki.org/wiki/OS_fingerprinting

[15] http://chrissanders.org/packet-captures/

[16] http://www.arppoisoning.com/demonstrating-an-arp-

poisoning-attack/

[17] http://searchnetworking.techtarget.com/definition/Address-

Resolution-Protocol-ARP

[18] http://searchsecurity.techtarget.com/definition/SYN-

flooding