CSW Lab Manual -2-42
CSW Lab Manual -2-42
Aim: Basic Packet Inspection: Capture network traffic using Wire shark and
analyze basic protocols like HTTP, DNS, and SMTP to understand how data is
transmitted and received.
a. Open Wireshark.
b. The following screen showing a list of all the network connections is
displayed. Select one or more of the network interfaces using shift+left-click
or by clicking on the tab All Interfaces Shown
c. Once the network interface is selected, start the capture, and there are several
ways to do that.
i. Click the first button on the toolbar, titled “Start capturing packets.
OR
d. During the capture process, Wireshark will show the following screen
e. Once all required packets are captured, use the same buttons or menu options
Wireshark shows three different panes for inspecting packet data. The Packet List, the
Wireshark filters
Capture filters limit the captured packets by the chosen filter. If the packets don’t
a. host IP-address: This filter limits the captured traffic to and from the IP
address
e. port not 53 and not arp: Capture all traffic except DNS and ARP traffic
Wireshark display filters change the view of the capture during analysis.
from one computer (ip.src) to another (ip.dst). You can also use ip.addr to
ii) tcp.port eq 25: This filter will show you all traffic on port 25, which is
iii) icmp: This filter will show you only ICMP traffic in the capture, most
iv) ip.addr != IP_address: This filter shows you all traffic except the traffic to
The Hypertext Transfer Application Layer Protocol (HTTP) utilizes the internet to
establish protocols whenever the HTTP client/server transmits/receives HTTPrequests.
Start a Wireshark capture -> Open a web browser -> Navigate to any HTTPS-based
website -> Stop the Wireshark capture.
Input ' ssl' in the filter box to monitor only HTTPS traffic -> Observe the first TLS
packet -> The destination IP would be the target IP (server).
A standard port scan takes advantage of the TCP three-way handshake. The attacker
sends the SYN packet to the target port. The port is considered open when he gets
SYN+ACK as a response, whereas the arrival of RST shows the port is closed. After
receiving SYN+ACK, the hacker would send an ACK packet to establish a TCP
connection.
Input ‘tcp.port == 80’ to see only TCP traffic connected to the web server connection.
Observe the TCP [SYN] packet. Expand Ethernet and observe the destination address
that is the default gateway address; whereas, the source is your own MAC address.
To check the IP details, observe Internet Protocol Version 4; in our case, the
destination IP is Googles' web server IP, and the source IP is the local IP address.
To view TCP details, observe Transmission Control Protocol, like port numbers.
Monitor the flag values. SYN, which is enabled, shows the initial section of the TCP
three-way handshake.
Take a look at the TCP [SYN, ACK] packet. Expand Ethernet and observe the
destination address now would be your own MAC address; whereas the source is the
default gateway address.
Monitor the acknowledgement code. It's worth noting that the number is one relative
ACK number. The real acknowledgement value is one higher than the previous
segment's identifier. Monitor the flag values. [SYN, ACK], which is enabled, shows
the second section of the TCP three-way handshake.
Analyze SYN flood attack
SYN flood occurs when an attacker delivers a substantial amount of SYN packets to a
server using fake IPs, causing the server to respond with an SYN+ACK and keep its
ports partially open, expecting a response from an invisible client.
By overwhelming a victim with SYN packets, an attacker can effectively overrun the
victim's resources. In this state, the victim fights with traffic, which causes processor
and memory usage to rise, eventually exhausting the victim's resources.
Use the hping3 tool to flood the victim IP. Simultaneously, start capturing the traffic
on Wireshark. Input 'tcp.flags.syn == 1' in the filter box to view SYN packets flood.
Let’s simulate a Denial of Service (DoS) attack to analyze it via Wireshark. Use
macof tool, the component of the Dsniff suit toolkit, and flood a surrounding device's
switch with MAC addresses.
The image below shows IP address is generating requests to another device with the
same data size repeatedly. This sort of traffic shows a standard network DoS attack.
For a DDoS attack, use the macof tool again to generate traffic. Observe the fake
source and destination IP addresses are sending many packets with similar data sizes.
Experiment-3
tls.handshake.type eq 1
Since this traffic is encrypted we will be decrypting with the decryption key we were
provided with on GitHub.
Now, filter the HTTP traffic and the TLS handshake, along with excluding SSDP:
Here is an interesting GET request where it looks like it was reaching for a .dll file.
If we follow this through a HTTP stream, we can see that it has already been
downloaded. The running in DOS mode means the rest of the content is the dll.
Save this file, and use a website like virus total to see what kind of malware it is.
We can also find an very weird POST request for this .php file:
After the system has been infected it tries to connect to a control server. Following
with TLS stream we can see it does indeed try and connect to the control server.
Experiment No:4
Step 1: Open Wireshark tool start capturing the network. Here we are capturing
wireless fidelity.
Step:2 After starting the packet capturing we will go to the website and login the
credential on that website.
Step-3: Now after completing the login credential we will go and capture the
password in Wireshark. For that we have to use some filter that helps to find the login
credential through the packet capturing.
Step 4: Wireshark has captured some packets but we are specifically looking for
HTTP packets. so in the display filter bar we use some command to find all the
captured HTTP packets.
Step 5: So there are some HTTP packets that are captured but we are specifically
looking for form data that the user submitted to the website. For that, we have a
separate filter .
As we know that there are two main methods used for submitting form data from web
pages like login forms to the server. the methods are-
GET
POST
Step 6: So firstly for knowing the credential we use the first method and apply the
filter for the GET methods.
As we can see in the image there are two packets where the login page was requested
with a GET request as well, but there is no form data submitted with a GET request.
Step 7: Now after checking the GET method if we didn’t find the form data, then we
will try the POST method for that we will apply the filter on Wireshark as you can
see.
As we can see we have a packet with form data click on the packet with user info and
the application URL encoded. and click on the down-
HTML form URL Encoded where the login credential is found. login credential as it is
the same that we filed on the website in step 2.
Experiment No:5
Aim: ARP Poisoning Attack: Set up an ARP poisoning attack using tools like
Ettercap. Analyze the captured packets to understand how the attack can lead to
a Man-in-the-Middle scenario.
1. Open Ettercap.
2. Go to the pull-down menu that says "Sniff" and click on "Unified Sniffing".
4. Click on the "Hosts" tab and there is a menu that includes "Scan for Hosts".
Click on it and ettercap will begin scanning the network for hosts.
5.
6. Now, using that same "Hosts" tab, click on "Hosts List". This will display all
the hosts that ettercap has discovered on your network as seen in the
screenshot below.
7. Now, select one of the hosts that will be the target of this attack in the window
by clicking on it and then click on "Add to Target 1" at the bottom of the
window. When we do so, ettercap will add that host as the first target in our
MiTM attack as seen in the screenshot below. Next, select the second host in
this attack and then click "Add to Target 2".
8. Finally, go to the menu above and click on MITM tab and the drop down
menu will have a selection called "ARP Poisoning" as seen in the screenshot
below.
9. Select it and it will open a pop window like below. Select "Sniff remote
connections".When we press OK, ettercap will begin ARP poisoning and we
see ettercap respond in its main windows with the message below.
Now, we have successfully placed ourselves between the two targets systems and all
their traffic must flow through us.
SQL Injection: Use DVWA to practice SQL injection attacks. Demonstrate how
an attacker can manipulate input fields to extract, modify, or delete database
information.
➢ Extract the DVWA files into the htdocs directory of our web server (e.g., C:
\xampp\htdocs\dvwa).
➢ Navigate to the "DVWA Security" page and set the security level to "Low".
➢ In the input field (e.g., "User ID"), enter a simple SQL injection payload: ' OR
'1'='1
➢ Expected Output: The application will display all user information because
the query always returns true.
127.0.0.1/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit#
Now in above URL we will try to unbalance sql query by placing a ‘ after 1 like this,
127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’&Submit=Submit#
And Web page is supposed to throw an error. If it doses then we can say that it is
vulnerable. Like this,
Step 7: — Now we find out how many columns does it contains by using “order by”
keyword.
Step 8: — Now that we have figured it out that we have 2 vulnerable columns we use
UNION SELECT statement over here to find out database name and its version. Like
this,
Step 9: — Now we extract out all the table names from this database by firing
following query.
Step 11: — Now we want user name and password and we can see in above picture
that it contains column name “user” and “password”. So, now we get all user name
and password by firing this simple query.
➢ Use an SQL injection payload to update data in the database. For example, to
change the password of the first user:
3. Deleting Data:
➢ Use an SQL injection payload to delete data from the database. For example,
to delete the first user:
Log in to DVWA using either the default credentials “admin” and “password,” or the
credentials, set up. We begin by testing the low-security level, then move on to the
medium level, and finally, the high-security level.
Click on “DVWA Security,” then choose the “Low” security level and proceed by
clicking the “Submit” button.
Navigate to “XSS (Stored)” and input a name of your choice into the designated field.
For the message field, insert the payload below before clicking the “Sign Guestbook”
option.
<script>alert('stored XSS');</script>
Upon submission, an alert box appeared, confirming the vulnerability of the site to
stored XSS attacks.
Click on “DVWA Security,” then choose the “medium” security level and proceed by
clicking the “Submit” button as shown below.
Upon re-entering the previous inputs, it becomes evident that no pop-up is triggered,
even though the XSS payload is correct. This could be attributed to various reasons,
such as input sanitization being implemented in the source code, which may include
processes like removing special characters or employing other security measures. It’s
important to note that without access to the source code, we can only speculate on the
specific mechanisms in place.
<script>alert('stored XSS');</script>
Also, it was observed that the tags <script> and </script> were removed. As a result,
payloads utilizing these tags cannot be effectively employed. To bypass this restriction
and inject a payload into the name field, we can utilize a payload that does not include
the <script> tag.
We attempted to input the payload into the name field, but encountered client-side
restrictions that limit users to entering a maximum of 10 characters, as shown below.
To bypass this limitation, right-click on the name input field, select “Inspect,” and
then modify the `maxlength=”10"` attribute to a different value, such as `”90"`. After
making this adjustment, press Enter to apply the changes, as illustrated below.
Now, we input the payload into the name field and enter any text in the message field.
Afterward, click on the submit button.
After clicking the “Sign Guestbook” button to inject the payload, we received a pop-
up alert, which confirms the successful exploitation of this vulnerability at the
medium security level.
Experiment-8
Cross-Site Request Forgery (CSRF) is a type of attack that tricks a user into
performing actions on a web application without their consent. It exploits the trust that
a web application has in an authenticated user by using their credentials to perform
unauthorized actions. This can lead to actions like changing account details,
transferring funds, or any other action that the user is authorized to perform.
Performing a CSRF Attack
Step 1: Navigate to CSRF Page:
Go to the "CSRF" section in the DVWA menu.
Step 2: Understanding the CSRF Vulnerability:
Observe the form that allows changing the user password. This form is vulnerable
to CSRF.
Step 3: Create a Malicious Web Page:
Create an HTML file (csrf_attack.html) with the following content:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>CSRF Attack</title>
</head>
<body>
<h1>CSRF Attack Demonstration</h1>
<form action="http://localhost/dvwa/vulnerabilities/csrf/" method="POST">
<input type="hidden" name="password_new" value="newpassword">
<input type="hidden" name="password_conf" value="newpassword">
<input type="hidden" name="Change" value="Change">
<input type="submit" value="Click me to change your password">
</form>
<script> document.forms[0].submit();
</script>
</body>
</html>
It is an attack that allows an attacker to include a file on the web server through a php
script. This vulnerability arises when a web application lets the client submit input
into files or upload files to the server. A file include vulnerability is distinct from a
generic Directory Traversal Attack, in that directory traversal is a way of gaining
unauthorized file system access, and a file inclusion vulnerability subverts how an
application loads code for execution. Successful exploitation of a file include
vulnerability will result in remote code execution on the web server that runs the
affected web application.
Login to DVWA, then go to DVWA security tab and change the difficulty level to low.
Go to file inclusion tab and change the URL from incude.php to ?page=../../../../../../
etc/passwd.
change the URL from?page=../../../../../../etc/passwd to ?page=../../../../../../proc/
version.
Difficulty: MEDIUM
Now, go on and try the exploits we used in low difficulty. We notice that we can’t read
files like before using the directory traversal method. So, as we can see in the below
snapshot of source page, the server is more secure and is filtering the ‘../’ or ‘..
\’pattern. Let’s try to access the file without ‘../’ or ‘..\’.
Difficulty: HIGH
Change the difficulty to HIGH and try all exploits from medium difficulty, and you’ll
notice none of them will works because the target is more secure, as it is only
accepting “include.php” or inputs starting with the word “file”. If you try anything
else, it will show “File not Found”.
In this level of security, we can still gather sensitive info using the “File” URI scheme.
(because it starts with the word “file”)
We get the data of /etc/passwd file. This is how we can exploit file inclusion
vulnerability using local files on the webserver.
Experiment-10
Brute-Force and Dictionary Attacks: Use DVWA to simulate login pages and
demonstrate brute-force and dictionary attacks against weak passwords.
Emphasize the importance of strong password policies.
Modern brute force attacks can now easily crack 8-characters alphanumeric password
in just a mere 2 hours, while more advanced encryption hashes can be cracked in a
few months. This can be achieved by performing exhaustive key search, in which the
computer will try every possible combination of every single possible character in
order to find the right combination of characters as the password. For the purpose of
this demonstration, I will be setting up the Damn Vulnerable Web Application
(DVWA) to simulate a brute force attack.
The attack will utilize Hydra as a parallelized login cracker and the ‘rockyou.txt’
wordlist that will be demonstrated on the login form below.
Initially, barely any information was disclosed. However, a wild guess would be to use
one of the most popular usernames on any web application, which is “admin”. Before
proceeding with the attack, we must first collect more information. Open a Burp Suite
browser and direct it to the DVWA page, which will look exactly like the one on a
regular browser. Now, try logging in using a random password. For this attempt, the
username “admin” and password “admin123” was used. For Burp Suite to scan the
web application, turn on the Intercept mode right before clicking on the “Login”
button.
As expected, the credentials entered were wrong, displaying an error message saying,
“Username and/or password incorrect”. Now, head back to Burp Suite and view the
raw data of the connection request.
Through this, we have gathered several more information that may be useful (e.g.,
session cookies, parameters of the request). The following table includes all the
gathered information:
The next step is to use Hydra to crack the account password. There is no fixed format
to Hydra’s command as it will depend on the elements and/or information known to
the pentester (e.g., username, hostname, URL service, and cookies). Considering the
list of disclosed information and available parameters obtained during the
vulnerability assessment step utilizing Burp Suite, the command used for this
demonstration will be:
The result of the attack reveals the password to be “password”, which will show that
the login is successful, hence concluding the demonstration.