Sniffing and Spoofing are two key tools in the arsenal of both cybercriminals and ethical hackers. They are used to intercept traffic, analyze data, and spoof network devices.
A sniffing attack is a method of intercepting data transmitted over a network. It involves listening to network traffic in a specific segment without actively interfering with it. This method allows an attacker to obtain confidential information, such as logins, passwords, or service packets that are transmitted in clear text.
A spoofing attack involves impersonating a trusted source. The attacker impersonates a trusted system or user in order to gain access to confidential data or functions. This can involve spoofing an IP address, MAC address, or even an email address.
Data interception during a hacking attack sometimes occurs as part of a denial-of-service (DoS) attack. In this case, the hacker captures or modifies packets in the data stream, then either resends them or modifies the content before sending them. Sniffers act as tools for discreetly analyzing network traffic, especially in cases where disclosure or destructive influence is undesirable.
An interception attack can also be used to recover a passphrase, particularly in cases where an attacker has obtained the SSH private key. In such a situation, special software captures SSH packets containing encrypted versions of the user’s entered password. This data can then be decrypted offline using brute-force techniques.
The term “sniffing” is defined in RFC 2301 as: “Any act of capturing network traffic and replaying it, usually for espionage or sabotage purposes.”
This definition is imprecise for UNIX-based systems, as any traffic can be sniffed if an attacker has access to the network interface cards (NICs) or modifies packets that cannot be altered in transit. Sniffing can be accomplished by using a special program such as tcpdump, tcpflow, or LanMon, which is connected to a port through which packets can be inspected remotely.
Another sniffing attack, called ARP spoofing, involves sending spoofed Address Resolution Protocol (ARP) messages over the Ethernet data link layer. These messages are used to associate the victim computer’s IP address with a different MAC address, causing the target computer to send all of its traffic destined for the victim through a host controlled by the attacker.
This is used both to intercept sessions and to flood the network with a denial-of-service attack (see Smurf attack).
Each IP packet contains, in addition to its payload, two fields: an IP header and an encapsulating Ethernet header.
Those working with Internet communications often refer to the combination of these two headers as a “packet”. Thus, an attacker can view and modify the IP header of an IP packet without viewing its payload.
The Ethernet header contains information about the destination MAC address (the hardware address of the recipient’s computer), and the Ether Type field contains a value indicating what type of service is being requested (such as priority or flow control).
The Ether Type can be “0xFFFF”, indicating that no service fields were included for the Ethernet frame. This was used in the Cisco implementation prior to version 8.0.
Such interception methods pose a serious threat to network security and require constant monitoring and updating of protection tools.
There are several different methods that an attacker can use to perform ARP spoofing. These include:
The attacker has access to the ARP cache on his infected machine, which also contains the MAC addresses of other machines, but which do not have or use the same IP addresses as other machines with the same MAC addresses in their ARP caches.
The attacker does not know what method the other computers use to store the MAC address table, and therefore simply sets up a network with many duplicate entries.
The attacker sends spoofed ARP messages in an attempt to associate his infected machine with the MAC address of another machine.
There are several ways to prevent an attacker from using these methods, including:
ARP spoofing is not a very effective attack, except on poorly secured networks.
For an attacker to use this method as a form of cloaking, they must be able to send packets directly to the network (either through Wi-Fi access or by exploiting a security vulnerability). Because of this, the attacker’s IP address is likely to become known very quickly.
A sniffing attack is a form of attack in which an attacker attempts to access certain data over a network, and sniffing is used as an important task in capturing the data. The term “sniffing” comes from the act of sniffing or sniffing. The attacker obtains this information using special software called a “Network Analyzer”.
Sniffing during hacking: This is considered to be an intrusion into your computer system without permission, without your knowledge, and without legal authorization. This is called hacking, which can be done in several ways.
During the investigation, a Cross Site Scripting (XSS) vulnerability was discovered, but the normal payload was not executed due to the Content Security Policy (CSP) blocking the execution of external JavaScript code. Later, another XSS vulnerability was found in another endpoint, which was also restricted by CSP. Combining these two vectors allowed the security policy to be bypassed and XSS to be executed via MIME sniffing.
The following image shows an endpoint on the home page whose value is displayed in the body of the website.
Instead of setting a string value, it was decided to try using a simple HTML payload. The <h1>kleiton0x00</h1> construct was introduced with the expectation that this payload would be processed and displayed in the browser as full HTML content.
An HTML injection was detected, so the next step was to test its potential for XSS. The simplest possible payload was used: <script>alert(1)</script>. If a Web Application Firewall (WAF) does not filter or block this script, there is a high probability that the JavaScript code will successfully execute in the browser.
The payload was successfully injected into the website, but there is no pop-up? Looking at the source code of the page, we see that nothing was filtered or removed.
After looking at the developer tools in the browser (Console), I realized that the script was being blocked by Content-Security-Policy.
This means that Content Security Policy (CSP) is a security mechanism that acts as an additional layer of security for web applications. It is implemented using a special HTTP header, the task of which is to restrict from which sources scripts, styles, images and other resources can be loaded. The main goal is to prevent the execution of malicious code, in particular in cases of XSS attacks.
Typically, a properly configured CSP allows the execution of scripts only from the same domain as the site itself (i.e. self), blocking the loading of external JavaScript files.
Before trying to bypass or analyze CSP, it is necessary to clearly determine how it works on a specific resource – that is, from which sources scripts are allowed to be loaded, and what restrictions are imposed on other types of content.
After analyzing the HTTP headers, in particular the Content-Security-Policy directive, it became clear that the policy allows loading scripts only from the site itself, its subdomains and internal directories. This creates strict restrictions that make it impossible to insert third-party malicious JavaScript code.
In this regard, it became necessary to search for alternative attack vectors, in particular additional XSS vulnerabilities. While viewing the source code of the page, a fragment of PHP code with a dynamically processed parameter was noticed when scrolling – a potential vulnerability for further analysis.
Without further ado, we moved to the path /js/countdown.php. A simple string value was added to the end of the parameter to test the website’s response and further analyze its behavior in response to the input.
We can see our string (kleiton0x00) appearing in the source code. Great! We can start implementing our javascript code.
The decision was made not to simply enter characters, but to try to change the structure of the JavaScript code by breaking it. From the analysis, it became clear that the entered data is inserted immediately after the numeric value in the code.
To close the current expression, ); is added — the parenthesis ) completes the variable declaration, and the semicolon ; completes the current line of code. After that, it becomes possible to implement new JavaScript code — in this case, the alert(1); instruction is used.
However, the rest of the string — * 1000). getTime (); — can cause a syntax error. To avoid this, it is enough to comment out the rest of the line with //.
Thus, the final payload looks like this:
); alert (1); //
Great — based on the source code analysis, we were able to inject JavaScript code and fix the second XSS vulnerability.
The full URL for testing looks like this:
http://website.com/js/countdown.php?end=2534926825);alert(1);//
However, despite the correctness of the injection, XSS is not executed when clicking on this link. The reason for this is, again, the Content Security Policy (CSP) in effect, which blocks execution of even locally implemented scripts.
It’s time to combine the first XSS we found on the home page and the second XSS we found on countdown.php.
Let’s see how MIME Sniffing can cause an XSS vulnerability. For an attacker to be able to perform an XSS attack using MIME Sniffing, certain conditions must be met. Note that both of the preconditions are on the client side:
The attacker must be able to control the content in the server response to inject malicious JavaScript (the second XSS we found).
The attacker must be able to inject the execution context via HTML injection or Javascript injection (the first XSS we found).
The final XSS payload is formed by combining the first vulnerability found (which used the classic XSS payload <script>alert(1)</script>) with the vulnerable endpoint /js/countdown.php, which allows for malicious code to be embedded.
Instead of directly executing JavaScript in the first XSS, a URL payload is added to the code:
http://website.com/js/countdown.php?end=2534926825);alert(1);//
Thus, the combined final load takes the following form:
<script src=’http://website.com/js/countdown.php?end=2534926825);alert(1);//></script>
We bypassed CSP and successfully executed alert(1) using MIME Sniffing.
In cybersecurity, special utilities are often used to analyze traffic, identify vulnerabilities, and implement interception on local networks. Here are three popular tools that play an important role in testing system security:
Allows you to redirect packets on a local network by substituting ARP replies. With its help, you can make computers on the network start sending their packets not to the real addressee, but to a node controlled by an attacker or researcher.
It is a powerful multi-tool for network attacks, monitoring and data collection. It supports ARP spoofing, password interception, DNS query analysis, HTTPS filtering and many other functions. It is often used during pentests and OSINT research.
ZAP is one of the most well-known web application security testing tools. It allows you to automatically scan for vulnerabilities, launch attacks, monitor HTTP/HTTPS requests and responses, and act as a proxy for manual analysis.
This article has shown how, even with modern protection in the form of Content Security Policy (CSP), unconventional vectors for XSS attacks can be found. Although regular scripts are blocked, combining multiple vulnerable endpoints, clever use of HTML injection, and manipulation of MIME types allows you to bypass security restrictions. This approach illustrates the importance of deep inspection of each component of a web application, as even minor scripts can become critical entry points in a complex attack.
1179 
