How to intercept traffic. The best pen tester tools: sniffers and working with packages

Nowadays they have also become very popular public networks Wi-Fi. They are found in restaurants, gyms, shopping malls, subways, hotels, private hospitals and clinics, apartments and condominiums - they can be found almost anywhere where quite a lot of people gather.

These networks have a peculiarity - they are often open Wi-Fi networks that do not require a password to connect to. Are there any additional security rules for working with such networks?

Yes, when used open Wi-Fi network you need to understand well that:

all data is transmitted by radio waves, that is, unlike a wire, which not everyone can access, radio waves can be intercepted by anyone who is within range
V open networks data is not encrypted

With the first point, I think everything is clear: if someone with a computer and a Wi-Fi card is close enough, then he can capture and save all traffic transmitted between wireless hotspot Access and all its clients.

As for the second point, we need to clarify about the encryption of transmitted data. For example, if you open a site that uses the HTTPS protocol (that is, a secure protocol), such as a site, then the data transmitted to and from that site to you is encrypted. If you open a website running over the HTTP protocol, then all transmitted data: which pages you visited, which comments you left, which cookies your web browser received - this data is transmitted in unencrypted form. So, if you are connected to Wi-Fi hotspot Access that requires entering a password, the transmitted traffic is encrypted again. That is, even if you open a site using the HTTPS protocol, the transmitted traffic is encrypted twice (the first time when transmitted from the web browser to the web server and in the opposite direction, the second time when transmitted from your device to the Access Point, as well as in the opposite direction). And if you open a site using the HTTP protocol, then the transmitted traffic is encrypted only once (only during transmission from your device to the Access Point and back).

But open access points do not encrypt traffic. It follows from this: if you use an open access point and open a site running on the HTTP protocol, then your data is transmitted in clear text and anyone near you can capture and save it. If you open a site using the HTTPS protocol, then this data is encrypted, however, you can still see which sites you opened (although you cannot see which pages and what you entered, for example, which comments you left).

So: you need to remember that open wireless networks susceptible to information interception.

Intercepting traffic in open Wi-Fi networks

For a successful attack you need a computer running Linux (for example, with Kali Linux or with BlackArch), as well as Wi-Fi card from .

Let's start by looking at the names of the wireless interfaces:

As you can see, I have several wireless interfaces, I will use wlp0s20f0u2.

We translate wireless interface to monitor mode:

Sudo ip link set INTERFACE down sudo iw INTERFACE set monitor control sudo ip link set INTERFACE up

In the previous commands, instead of INTERFACE you need to enter the name that the wireless interface has on your system. For example, for wlp0s20f0u2 the commands look like this:

Sudo ip link set wlp0s20f0u2 down sudo iw wlp0s20f0u2 set monitor control sudo ip link set wlp0s20f0u2 up

Open the captured data file in Wireshark.

To highlight different data, we will need Wireshark filters. Here I will show an example of using only some filters, it is recommended to study a large selection of useful Wireshark filters.

To evaluate the quality of capture, you can start with filters that output the results of analysis of the TCP protocol.

For example:

Tcp.analysis.duplicate_ack_num == 1

This filter displays information about frames with an ACK flag that are duplicates. A large number of such frames may indicate communication problems between the Client and the Access Point.

Filter for displaying frames for which the previous segment is not captured:

Tcp.analysis.ack_lost_segment

This is normal at the beginning of data capture - since the information is not captured from the very beginning. But if this error occurs frequently in the future, then you are too far from the Access Point or Clients and you are not capturing part of the data they transmit.

To show frames that are retransmitted (sent repeatedly):

Tcp.analysis.retransmission

A large number of such frames may indicate that between the Client and the AP bad connection and they often have to send the same data repeatedly.

Using a filter

You can see ARP traffic - with its help it is convenient to analyze how many devices there are in at the moment connected to local network, what IP addresses do they have and what MAC addresses. .

Using a filter

you can see all DNS queries sent.

Thanks to these queries, you can find out which sites users have visited (even if these sites use HTTPS!), as well as which online services requests have been made.

For example, in the screenshot you can see the addresses of the online cinema Netflix, Facebook, various services Google.

To filter HTTP traffic filter:

Here you can find out a lot of interesting information. For example, you can see requests to services and transmitted data, including API keys, device identifiers, etc.:

You can see visited URLs with all passed parameters:

Files downloaded and opened on the Internet are visible:

You can save any transferred file. To do this, select with your mouse the package that contains it (1), then in the middle panel, which contains detailed information, scroll to the very bottom to find the data field and right-click on it to bring up the context menu (2), in context menu select Export Selected Packet Bytes(3) - Export bytes of the selected package:

Enter a file name, choose a location, and save it.

Someone is updating Windows:

Also visible installed by the user Cookies or cookies transferred to them:

Using a filter

Http.cookie

can be seen HTTP requests, in which cookies were transmitted.

And using a filter

Http.set_cookie

you can see requests in which the server installed cookies in the user’s browser.

Neighbors download strange torrents:

Data transferred using the POST method is also visible:

To search for any transferred images:

Http.content_type contains "image"

To search for specific types of images:

Http.content_type contains "gif" http.content_type contains "jpeg" http.content_type contains "png"

To search for files of a specific type:

Http.content_type contains "text" http.content_type contains "xml" http.content_type contains "html" http.content_type contains "json" http.content_type contains "javascript" http.content_type contains "x-www-form-urlencode" http. content_type contains "compressed" http.content_type contains "application"

Search Wireshark for requests to obtain files of a certain type. For example, to search for transferred ZIP archives:

Http.request.uri contains "zip"

Instead of http.request.uri For greater accuracy, you can use filters http.request.uri.path or http.request.uri.query, for example, to search for download requests JPG files(links to pictures):

Http.request.uri.path contains "jpg"

Filter that shows only data transferred using the POST method:

Http.request.method == "POST"

A filter that shows only data transferred using the GET method:

Http.request.method == "GET"

Search for requests to a specific site (host):

Http.host == " "

Search for queries to a specific site by part of the name:

Http.host contains "partial.name here"

Conclusion

Now the number of applications and sites that do not use encryption is rapidly decreasing. Therefore, the danger of such interception decreases every year. Nevertheless, it is there.

Even sites that use HTTPS can unintentionally leak data. For example:

It can be seen that data from the user to booking.com is transmitted in unencrypted form, so this link can be intercepted.

The iPhone app is constantly downloading some (audio?) files without using a secure connection:

The popular (in some regions) qq.com either does not use encryption or uses its own algorithm:

Guaranteed protection against such interception is the use of a trusted VPN service. Reliable VPN service You can consider the one you configured yourself, or the VPN of your corporate network.

Methods for intercepting network traffic

Listening to the network using network analyzer programs is the first, most in a simple way data interception.

To protect against network eavesdropping, use special programs, for example, AntiSniff, which are capable of identifying computers on the network that are listening to network traffic.

To solve their problems, antisniffer programs use a special sign of the presence of listening devices on the network - the network card of the sniffer computer must be in a special listening mode. While in listening mode, network computers react in a special way to IP datagrams sent to the address of the host being tested. For example, listening hosts typically process all incoming traffic, not just datagrams sent to the host's address. There are other signs that indicate suspicious host behavior that AntiSniff can recognize.

Undoubtedly, eavesdropping is very useful from the point of view of an attacker, since it allows you to obtain many useful information– passwords transmitted over the network, addresses of network computers, confidential data, letters, etc. However, simple eavesdropping prevents a hacker from interfering with network communication between two hosts to modify and corrupt data. To solve such a problem, more complex technology is required.

Rice. 1 False ARP requests

Let's see how a hacker can use ARP to intercept network communications between hosts A and B.

To intercept network traffic between hosts A and B, the hacker imposes his IP address on these hosts, so that A and B use this falsified IP address when exchanging messages. To impose his IP address, the hacker performs the following operations.

The attacker determines the MAC addresses of hosts A and B, for example, using the nbtstat command from the W2RK package.
The attacker sends messages to the identified MAC addresses of hosts A and B, which are falsified ARP responses to requests to resolve host IP addresses to computer MAC addresses. Host A is informed that the IP address of host B corresponds to the MAC address of the attacker’s computer; host B is informed that the IP address of host A also corresponds to the MAC address of the attacker’s computer.
Hosts A and B enter the received MAC addresses into their ARP caches and then use them to send messages to each other. Since IP addresses A and B correspond to the MAC address of the attacker’s computer, hosts A and B, unsuspectingly, communicate through an intermediary who can do anything with their messages.

To protect against such attacks, network administrators must maintain a database with a table of correspondence between the MAC addresses and IP addresses of their network computers.

On UNIX networks, this type of spoofed ARP request attack can be implemented using system utilities monitoring and managing network traffic, for example, arpredirect. Unfortunately, in Windows networks such reliable utilities do not appear to be implemented. For example, on the NTsecurity website you can download the GrabitAII utility, presented as a tool for redirecting traffic between network hosts. However, a basic check of the functionality of the GrabitAII utility shows that complete success in implementing its functions is still far away.

To intercept network traffic, an attacker can spoof the real IP address of a network router with their own IP address, doing this, for example, using falsified ICMP Redirect messages. Host A must, according to RFC-1122, perceive the received Redirect message as a response to a datagram sent to another host, for example, B. Host A determines its actions on the Redirect message based on the contents of the received Redirect message, and if datagram redirection is specified in Redirect from A to B along a new route, this is exactly what host A will do.

Rice. 2 False routing

To perform false routing, the attacker must know some details about the organization of the local network in which host A is located, in particular, the IP address of the router through which traffic is sent from host A to B. Knowing this, the attacker will generate an IP datagram in which IP -the sender's address is defined as the router's IP address, and the recipient is host A. Also included in the datagram is an ICMP Redirect message with the new router's address field set to the IP address of the attacker's computer. Having received such a message, host A will send all messages to the IP address of the attacker's computer.

To protect against such an attack, you should disable (for example, using a firewall) the processing of ICMP Redirect messages on host A, and the IP address of the attacker’s computer can be identified tracert command(on Unix this is the tracerout command). These utilities are able to find an additional route that has appeared on the local network that was not provided for during installation, unless, of course, the network administrator is vigilant.

The above examples of interceptions (to which the capabilities of attackers are far from limited) convince of the need to protect data transmitted over the network if the data contains confidential information. The only method of protection against interceptions of network traffic is the use of programs that implement cryptographic algorithms and encryption protocols and prevent disclosure and substitution classified information. To solve such problems, cryptography provides the means to encrypt, sign, and verify the authenticity of messages transmitted over secure protocols.

The practical implementation of all cryptographic methods for protecting information exchange is provided by VPN networks (Virtual Private Networks).

TCP connection interception

The most sophisticated network traffic interception attack should be considered TCP connection capture (TCP hijacking), when a hacker interrupts the current communication session with the host by generating and sending TCP packets to the attacked host. Next, using the TCP protocol's ability to restore an interrupted TCP connection, the hacker intercepts the interrupted communication session and continues it instead of the disconnected client.

The TCP protocol (Transmission Control Protocol) is one of the basic OSI transport layer protocols that allows you to establish logical connections over virtual channel communications. Over this channel, packets are transmitted and received with their sequence recorded, the flow of packets is controlled, retransmission of distorted packets is organized, and at the end of the session the communication channel is broken. The TCP protocol is the only core protocol in the TCP/IP family that has an advanced message identification and connection system.

Overview of software packet sniffers

All software sniffers can be divided into two categories: sniffers that support launching from command line, and sniffers with a graphical interface. However, we note that there are sniffers that combine both of these capabilities. In addition, sniffers differ from each other in the protocols they support, the depth of analysis of intercepted packets, the ability to configure filters, and the possibility of compatibility with other programs.

Typically, the window of any sniffer with a graphical interface consists of three areas. The first of them displays the summary data of intercepted packets. Typically, this area displays a minimum of fields, namely: packet interception time; IP addresses of the packet sender and recipient; MAC addresses of the sender and recipient of the packet, source and destination port addresses; protocol type (network, transport or application layer); some summary information about the intercepted data. The second area displays statistical information about the individual selected package, and finally the third area displays the package in hexadecimal or ASCII character form.

Almost all packet sniffers allow you to analyze decoded packets (which is why packet sniffers are also called packet analyzers, or protocol analyzers). The sniffer distributes intercepted packets across layers and protocols. Some packet sniffers are capable of recognizing the protocol and displaying the captured information. This type of information is usually displayed in the second area of the sniffer window. For example, any sniffer can recognize the TCP protocol, and advanced sniffers can determine which application generated this traffic. Most protocol analyzers recognize over 500 different protocols and can describe and decode them by name. The more information a sniffer can decode and display on the screen, the less will have to be decoded manually.

One problem that packet sniffers may encounter is the inability to correctly identify a protocol using a port other than the default port. For example, to improve security, some well-known applications may be configured to use ports other than the default ports. So, instead of the traditional port 80 reserved for the web server, this server You can forcefully reconfigure it to port 8088 or any other. Some packet analyzers in similar situation are not able to correctly determine the protocol and display only information about the lower-level protocol (TCP or UDP).

There are software sniffers that come with software analytical modules as plugins or built-in modules that allow you to create reports with useful analytical information about intercepted traffic.

Another characteristic feature of most packet sniffer software is the ability to configure filters before and after traffic is captured. Filters select certain packets from the general traffic according to a given criterion, which allows you to get rid of unnecessary information when analyzing traffic.

Many users do not realize that by filling out a login and password when registering or logging in to a closed Internet resource and pressing ENTER, this data can easily be intercepted. Very often they are transmitted over the network in an unsecured form. Therefore, if the site you are trying to log in to uses the HTTP protocol, then it is very easy to capture this traffic and analyze it with using Wireshark and then, using special filters and programs, find and decrypt the password.

The best place to intercept passwords is the core of the network, where the traffic of all users goes to closed resources (for example, mail) or in front of the router to access the Internet, when registering on external resources. We set up a mirror and we are ready to feel like a hacker.

Step 1. Install and launch Wireshark to capture traffic

Sometimes, to do this, it is enough to select only the interface through which we plan to capture traffic and click the Start button. In our case, we are capturing over a wireless network.

Traffic capture has begun.

Step 2. Filtering captured POST traffic

We open the browser and try to log in to some resource using a username and password. Once the authorization process is complete and the site is opened, we stop capturing traffic in Wireshark. Next, open the protocol analyzer and see a large number of packets. It is at this point that most IT professionals give up because they don’t know what to do next. But we know and are interested in specific packages that contain POST data that is generated on our local machine when filling out a form on the screen and sent to a remote server when we click the “Login” or “Authorization” button in the browser.

We enter a special filter in the window to display captured packets: http.request.method == “POST"

And we see, instead of thousands of packages, only one with the data we are looking for.

Step 3. Find the user's login and password

Quick click right button mouse and select the item from the menu Follow TCP Steam

After this, text will appear in a new window that restores the contents of the page in code. Let's find the fields “password” and “user”, which correspond to the password and username. In some cases, both fields will be easily readable and not even encrypted, but if we are trying to capture traffic when accessing very well-known resources such as Mail.ru, Facebook, Vkontakte, etc., then the password will be encrypted:

HTTP/1.1 302 Found

Server: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie: password= ; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/

Location: loggedin.php

Content-Length: 0

Connection: close

Content-Type: text/html; charset=UTF-8

Thus, in our case:

Username: networkguru

Password:

Step 4. Determine the encoding type to decrypt the password

For example, go to the website http://www.onlinehashcrack.com/hash-identification.php#res and enter our password in the identification window. I was given a list of encoding protocols in order of priority:

Step 5. Decrypting the user password

At this stage we can use the hashcat utility:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

At the output we received a decrypted password: simplepassword

Thus, with the help of Wireshark we can not only solve problems in the operation of applications and services, but also try ourselves as a hacker, intercepting passwords that users enter in web forms. You can also find out passwords for mailboxes users using simple filters to display:

The POP protocol and filter looks like this: pop.request.command == "USER" || pop.request.command == "PASS"
The IMAP protocol and filter will be: imap.request contains "login"
The protocol is SMTP and you will need to enter the following filter: smtp.req.command == "AUTH"

and more serious utilities for decrypting the encoding protocol.

Step 6: What if the traffic is encrypted and uses HTTPS?

There are several options to answer this question.

Option 1. Connect when the connection between the user and the server is broken and capture traffic at the moment the connection is established (SSL Handshake). When a connection is established, the session key can be intercepted.

Option 2: You can decrypt HTTPS traffic using the session key log file recorded by Firefox or Chrome. To do this, the browser must be configured to write these encryption keys to a log file (FireFox based example) and you should receive that log file. Essentially, you need to steal the session key file from hard drive another user (which is illegal). Well, then capture the traffic and use the resulting key to decrypt it.

Clarification. We're talking about the web browser of a person whose password they're trying to steal. If we mean decrypting our own HTTPS traffic and want to practice, then this strategy will work. If you are trying to decrypt the HTTPS traffic of other users without access to their computers, this will not work - that is both encryption and privacy.

After receiving the keys according to option 1 or 2, you need to register them in WireShark:

Go to the menu Edit - Preferences - Protocols - SSL.
Set the flag “Reassemble SSL records spanning multiple TCP segments”.
“RSA keys list” and click Edit.
Enter data in all fields and write the path in the file with the key

WireShark can decrypt packets that are encrypted using the RSA algorithm. If the DHE/ECDHE, FS, ECC algorithms are used, the sniffer will not help us.

Option 3. Gain access to the web server that the user is using and obtain the key. But this is an even more difficult task. IN corporate networks for the purpose of debugging applications or content filtering, this option is implemented on a legal basis, but not for the purpose of intercepting user passwords.

BONUS

VIDEO: Wireshark Packet Sniffing Usernames, Passwords, and Web Pages

This lesson describes network hacking technologies based on intercepting network packets. Hackers use such technologies to listen to network traffic in order to steal valuable information, to organize data interception for the purpose of a man-in-the-middle attack, to intercept TCP connections, allowing, say, data spoofing, and to perform other equally interesting actions. Unfortunately, most of these attacks are actually implemented only for Unix networks, for which hackers can use both special utilities, and Unix system tools. Windows networks, apparently, have been ignored by hackers, and we are forced to limit our description of data interception tools to sniffer programs designed for trivial listening of network packets. However, one should not neglect at least a theoretical description of such attacks, especially for anti-hackers, since knowledge of the hacking technologies used will help prevent many troubles.

Network sniffing

Typically used for sniffing Ethernet networks. network cards switched to listening mode. Listening Ethernet networks requires connecting a computer running a sniffer program to a network segment, after which all network traffic sent and received by computers in this network segment becomes available to the hacker. It is even easier to intercept traffic from radio networks that use wireless network intermediaries - in this case, you do not even need to look for a place to connect to the cable. Or an attacker can connect to the telephone line connecting the computer to the Internet server, finding a convenient place for this (telephone lines are usually laid in basements and other rarely visited places without any protection).

To demonstrate sniffing technology, we will use a very popular sniffer program SpyNet, which can be found on many Web sites. Official website of the program SpyNet located at http://members.xoom.com/layrentiu2/, where you can download a demo version of the program.

Program SpyNet consists of two components - CaptureNet And PipeNet. Program CaptureNet allows you to intercept packets transmitted over the Ethernet network at the network level, i.e. in the form of Ethernet frames. Program PipeNet allows you to assemble Ethernet frames into application layer packets, restoring, for example, messages email, HTTP protocol messages (exchange of information with the Web server) and perform other functions.

Unfortunately, in the demo version SpyNet possibilities PipeNet are limited to the HTTP package build demo, so we won't be able to demonstrate how it works SpyNet in full. However, we will demonstrate the capabilities of network sniffing SpyNet using our experimental network as an example, by passing text file from host Sword-2000 to host Alex-Z using regular Windows Explorer. Simultaneously on the computer A1ex-1 we will launch the program CaptureNet, which will intercept transmitted packets and allow the contents of the transmitted file to be read in Ethernet frames. In Fig. 1 shows the text of the secret message in the file secret.txt; we will try to find this text in the captured Ethernet frames.

Rice. 1. Text of the secret message in the Notepad window

To capture Ethernet frames, follow these steps:

On the computer Alex-Z run the program CaptureNet. In the displayed working window of the program, select the menu command Capture * Start(Capture * Start) and start the process of capturing network frames.

Using Windows Explorer, copy the security.txt file from your computer Sword-2000 on A1ex-3.

After transferring the secret.txt file, select the menu command Capture * Stop(Capture * Stop) and stop the capture process.

The captured Ethernet frames will be displayed on the right side of the program working window CaptureNet(Figure 2), with each row in the top list representing an Ethernet frame, and below the list the contents of the selected frame.

Rice. 2. Ethernet frame contains secret message text

Having looked through the list of intercepted frames, we can easily find the one that contains the text we transmitted This is a very big secret (This is a very big secret).

We emphasize that this is the simplest example, when all intercepted network traffic was recorded. Program CaptureNet allows you to intercept packets sent over certain protocols and to certain host ports, select messages with specific content and accumulate the intercepted data in a file. The technique for performing such actions is simple, and can be mastered using the program’s help system SpyNet.

In addition to primitive network eavesdropping, hackers have access to more sophisticated means of data interception. Below is a brief overview of such methods, albeit from a theoretical aspect. The reason is that for Windows networks, the practical implementation of data interception attacks is extremely limited, and the set of reliable utilities for interception attacks is quite poor.

Methods for intercepting network traffic

Listen to the network using network analyzer programs like the one above CaptureNet, is the first, simplest way to intercept data. Except SpyNet For network sniffing, many tools are used, initially developed for the purposes of analyzing network activity, diagnosing networks, selecting traffic according to specified criteria, and other network administration tasks. An example of such a program is tcpdump (http://www.tcpdump.org), which allows you to record network traffic in a special log for subsequent analysis.

To protect against network eavesdropping, special programs are used, for example, AntiSniff (http://www.securitysoftwaretech.com/antisniff), which are capable of identifying computers on the network that are listening to network traffic. To solve their problems, antisniffer programs use a special sign of the presence of listening devices on the network - the network card of the sniffer computer must be in a special listening mode. While in listening mode, network computers react in a special way to IP datagrams sent to the host being tested. For example, listening hosts typically process all incoming traffic, not just datagrams sent to the host's address. There are other signs indicating suspicious host behavior that the program can recognize AntiSniff.

Undoubtedly, eavesdropping is very useful from the point of view of an attacker, since it allows one to obtain a lot of useful information - passwords transmitted over the network, addresses of network computers, confidential data, letters, etc. However, simple eavesdropping prevents a hacker from interfering with network communication between two hosts to modify and corrupt data. To solve such a problem, more complex technology is required.

False ARP requests

To intercept and take over the process of network interaction between two hosts A and B, an attacker can replace the IP addresses of interacting hosts with his own IP address by sending falsified ARP (Address Resolution Protocol) messages to hosts A and B. You can get acquainted with the ARP protocol in Appendix D, which describes the procedure for resolving (converting) the host's IP address to the machine address (MAC address) hardcoded into the host's network card. Let's see how a hacker can use ARP to intercept network communications between hosts A and B.

The attacker determines the MAC addresses of hosts A and B, for example, using the command nbtstat from the package W2RK.

The attacker sends messages to the identified MAC addresses of hosts A and B, which are falsified ARP responses to requests to resolve host IP addresses to computer MAC addresses. Host A is informed that the IP address of host B corresponds to the MAC address of the attacker’s computer; host B is informed that the IP address of host A also corresponds to the MAC address of the attacker’s computer.

Hosts A and B store the received MAC addresses in their ARP caches and then use them to send messages to each other. Since IP addresses A and B correspond to the MAC address of the attacker’s computer, hosts A and B, unsuspectingly, communicate through an intermediary who can do anything with their messages.

To protect against such attacks, network administrators must maintain a database with a table of correspondence between the MAC addresses and IP addresses of their network computers. Next, using a special software, for example, utilities arpwatch (ftp://ftp.ee.lbl.gov/arpwatch-2.lab.tar.gz) you can periodically survey the network and identify inconsistencies.

On UNIX networks, this type of spoofed ARP request attack can be implemented using system utilities for monitoring and managing network traffic, for example, arpredirect. Unfortunately, such reliable utilities do not seem to be implemented on Windows 2000/XP networks. For example, on the NTsecurity website ( http://www.ntsecurity.nu) you can download the utility GrabitAII, presented as a means to redirect traffic between network hosts. However, a basic check of the functionality of the utility GrabitAII shows that complete success in implementing its functions is still far away.

False routing

To protect against such an attack, you should disable (for example, using a firewall) the processing of ICMP Redirect messages on host A, and the command can reveal the IP address of the attacker’s computer tracert(on Unix this is the tracerout command). These utilities are able to find an additional route that has appeared on the local network that was not provided for during installation, unless, of course, the network administrator is vigilant.

The above examples of interceptions (to which the capabilities of attackers are far from limited) convince of the need to protect data transmitted over the network if the data contains confidential information. The only method of protection against interceptions of network traffic is the use of programs that implement cryptographic algorithms and encryption protocols and prevent the disclosure and substitution of secret information. To solve such problems, cryptography provides tools for encrypting, signing and verifying the authenticity of messages transmitted over secure protocols

The practical implementation of all the cryptographic methods for protecting information exchange described in Chapter 4 is provided by VPN (Virtual Private Network) networks. Brief overview principles and methods of cryptographic security can be found in Appendix E, and in detailed description cryptographic protection provided by the application PGP Desktop Security (http://www.pgp.com).

TCP connection interception

Several effective utilities have been created to perform TCP connection hijacking attacks, but all of them are implemented for the Unix platform, and on Web sites these utilities are presented only in source code form. Thus, as convinced practitioners of the noble cause of hacking, attacks using the TCP connection interception method are not of much use to us. (Lovers of understanding other people's program code can refer to the site http://www.cri.cz/~kra/index.html where you can download source code well-known TCP connection interception utility Hunt from Pavel Krauz).

Despite the lack of practical tools, we cannot ignore this interesting topic, like intercepting TCP connections, and let's look at some aspects of such attacks. Some information about the structure of a TCP packet and the procedure for establishing TCP connections is given in Appendix D of this book, but here we will focus on the question of what exactly allows hackers to carry out TCP connection interception attacks? Let us consider this topic in more detail, relying mainly on the discussion in and.

The TCP protocol (Transmission Control Protocol) is one of the basic OSI transport layer protocols that allows you to establish logical connections over a virtual communication channel. Over this channel, packets are transmitted and received with their sequence recorded, the flow of packets is controlled, retransmission of distorted packets is organized, and at the end of the session the communication channel is broken. The TCP protocol is the only core protocol in the TCP/IP family that has an advanced message identification and connection system.

To identify a TCP packet, there are two 32-bit identifiers in the TCP header, which also act as packet counters, called sequence number and acknowledgment number. We will also be interested in one more field of the TCP packet, called control bits. This 6-bit field includes the following control bits (in order from left to right):

URG - urgency flag;

ACK - confirmation flag;

PSH - carry flag;

RST - connection re-establishment flag;

SYN - synchronization flag;

FIN - connection termination flag.

Let's look at the procedure for creating a TCP connection.

1. If host A needs to create a TCP connection with host B, then host A sends the following message to host B:

A -> B: SYN, ISSa

This means that the message sent by host A has the SYN flag (Synchronize sequence number) set, and the sequence number field is set to the initial 32-bit value ISSa (Initial Sequence Number).

2. In response to the request received from host A, host B responds with a message in which the SYN bit is set and the ACK bit is set. In the sequence number field, host B sets its initial counter value - ISSb; the acknowledgment number field will then contain the ISSa value received in the first packet from host A, increased by one. So host B responds with this message:

B -> A: SYN, ACK, ISSb, ACK(ISSa+1)

3. Finally, host A sends a message to host B in which: the bit is set ASK; the sequence number field contains the value ISSa + 1; The confirmation number field contains the value ISSb + 1. After this TCP connection between hosts A And IN is considered established:

A -> B: ACK, ISSa+1, ACK(ISSb+1)

4. Now the host A can send data packets to the host IN over the newly created virtual TCP channel:

A -> B: ACK, ISSa+1, ACK(ISSb+1); DATA

Here DATA stands for data.

From the algorithm for creating a TCP connection discussed above, it can be seen that the only identifiers of TCP subscribers and a TCP connection are two 32-bit parameters of the sequence number and acknowledgment number - ISSa And ISSb. Therefore, if a hacker manages to find out the current field values ISSa And ISSb, then nothing will prevent it from generating a falsified TCP packet. This means that a hacker only needs to select the current parameter values ISSa And ISSb TCP packet for a given TCP connection, send the packet from any Internet host on behalf of the client of this TCP connection, and this packet will be accepted as valid!

The danger of such TCP packet spoofing is also important because the high-level FTP and TELNET protocols are implemented based on the TCP protocol, and the identification of FTP and TELNET packet clients is entirely based on the TCP protocol.

In addition, since the FTP and TELNET protocols do not check the IP addresses of message senders, after receiving a falsified packet, the FTP or TELNET servers will send a response message to the IP address of the hacker host specified in the false packet. After this, the hacker host will start working with the FTP or TELNET server from its IP address, but with the rights of a legally connected user, who, in turn, will lose contact with the server due to mismatch of counters.

Thus, to carry out the attack described above, a necessary and sufficient condition is knowledge of the two current 32-bit parameters ISSa And ISSb, identifying the TCP connection. Let's consider possible ways receiving them. In the case when the hacker host is connected to the attacked network segment, the task of obtaining the values ISSa And ISSb is trivial and can be solved by analyzing network traffic. Therefore, it is necessary to clearly understand that the TCP protocol allows, in principle, to protect a connection only if it is impossible for an attacker to intercept messages transmitted over this connection, that is, only in the case when the hacker host is connected to a network segment different from the subscriber segment of the TCP connection.

Therefore, intersegment attacks are of greatest interest to a hacker, when the attacker and his target are in different network segments. In this case, the task of obtaining values ISSa And ISSb is not trivial. To solve this problem, only two methods have now been invented.

Mathematical prediction of the initial value of TCP connection parameters by extrapolation of previous values ISSa And ISSb.

Exploiting vulnerabilities in identifying TCP connection subscribers on Unix rsh servers.

The first task is solved through in-depth studies of the implementation of the TCP protocol in various operating systems and now has a purely theoretical significance. The second problem is solved using vulnerabilities Unix systems by identifying trusted hosts. (Trusted by this host A called network host IN whose user can connect to the host A without authentication using host r-service A). By manipulating the parameters of TCP packets, a hacker can try to impersonate a trusted host and intercept a TCP connection with the attacked host.

All this is very interesting, but the practical results of this kind of research are not yet visible. Therefore, we advise everyone who wants to delve deeper into this topic to turn to the book, from where the information presented above was mainly taken.

Conclusion

Intercepting network data is the most effective method of network hacking, allowing a hacker to obtain almost all the information circulating on the network. The greatest practical development has been achieved by sniffing tools, i.e. listening to networks; However, we cannot ignore the methods of intercepting network data, which are performed by interfering with the normal functioning of the network in order to redirect traffic to the hacker host, especially methods of intercepting TCP connections. However, in practice, the last mentioned methods have not yet received sufficient development and need to be improved.

An anti-hacker should know that the only salvation from data interception is its encryption, i.e. cryptographic protection methods. When sending a message over the network, you should assume in advance that cable system The network is absolutely vulnerable, and any hacker connected to the network will be able to catch all transmitted secret messages from it. There are two technologies for solving this problem - creating a VPN network and encrypting the messages themselves. All these tasks are very easy to solve using a software package PGP Desktop Security(its description can be found, for example, in).

Original: Network sniffing
Author: Paul Cobbaut
Published date: March 12, 2015
Translation: A. Panin
Transfer date: April 1, 2015

Chapter 23. Intercepting network traffic

A network administrator should be able to use a sniffer such as wireshark or tcpdump to diagnose network problems.

The student will also often have to resort to using a sniffer in order to understand the principles of network functioning. This chapter describes appropriate techniques for intercepting network traffic.

23.1. wireshark app

23.1.1. Installing wireshark

IN in this example Here's a command to install the wireshark application on distributions that use software packages with the .deb extension (including Debian, Mint, Xubuntu, and other distributions).

Root@debian8:~# Read package lists Done Build dependency tree Read status information Done... (output shortened)

Distributions that use .rpm software packages, such as CentOS, RHEL, and Fedora, can use the yum utility to install the wireshark application.

# yum install wireshark Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile ... (output shortened)

23.1.2. Selecting a network interface

When you launch the wireshark application for the first time, you will have to select the network interface. You will see a dialog that looks similar to the illustration below.

It is likely that there will simply be no available network interfaces, because in some distributions network traffic can be intercepted exclusively by the root user. In this case, you will have to run the wireshark application as root using the sudo wireshark command.

Or you can follow the general recommendations and use the tcpdump utility or some other tool to intercept the traffic and write the data to a file. Any intercepted data can be analyzed later using the wireshark application.

23.1.3. Traffic minimization

During the process of intercepting network traffic, thousands of packets can be generated over very short periods of time. Obviously, such a volume of data will complicate traffic analysis. Try to get out of this situation by isolating your sniffer within the network. The preferred option is to intercept traffic passing through the network interface of an isolated virtual network, under your complete control.

If you're looking into tools to intercept network traffic at home, it may be helpful to shut down any network applications running on your computer and disconnect your computer from other computers and devices such as smartphones and tablets to minimize traffic.

However, a more important tool for minimizing traffic is filters, which will be discussed in the next section.

23.1.4. Intercepting traffic generated by the ping utility

I ran the sniffer and captured all the packets sent over the network as a result of three ping commands (it makes no sense to run these commands as root):

Root@debian7:~# ping -c2 ns1.paul.local PING ns1.paul.local (10.104.33.30) 56(84) bytes of data. 64 bytes from 10.104.33.30: icmp_req=1 ttl=64 time=0.010 ms 64 bytes from 10.104.33.30: icmp_req=2 ttl=64 time=0.023 ms --- ns1.paul.local ping statistics --- 2 packets transmitted , 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.010/0.016/0.023/0.007 ms root@debian7:~# ping -c3 linux-training.be PING linux-training.be (188.93.155.87) 56(84) bytes of data. 64 bytes from antares.ginsys.net (188.93.155.87): icmp_req=1 ttl=56 time=15.6 ms 64 bytes from antares.ginsys.net (188.93.155.87): icmp_req=2 ttl=56 time=17.8 ms 64 bytes from antares.ginsys.net (188.93.155.87): icmp_req=3 ttl=56 time=14.7 ms --- linux-training.be ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 14.756/16.110/17.881/1.309 ms root@debian7:~# ping -c1 centos7.paul.local PING centos7.paul.local (10.104.33.31) 56(84) bytes of data. 64 bytes from 10.104.33.31: icmp_req=1 ttl=64 time=0.590 ms --- centos7.paul.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max /mdev = 0.590/0.590/0.590/0.000 ms

In total, more than 200 packets were captured from the network. Everything will become much more obvious if you enter the icmp string in the filter field and click the “Apply” button.

23.1.5. Intercepting traffic generated by the ping utility and the dns client

Working with the same data capture session, we can apply a different filter. We want to monitor traffic related to both the dns protocol and the icmp protocol, so we will have to enter the names of the two mentioned protocols in the filter field.

To capture data related to the two protocols in question, the string "dns or icmp" must be entered in the filter field. If you enter the line "dns and icmp", no information about any packets will be displayed, since there are no packets related to both mentioned protocols.

Looking at the illustration above, you will notice that packets 25 and 26 have source and destination IP addresses of 10.104.33.30. This is because the DNS client runs on the same computer as the DNS server.

A similar situation is observed in the case of packets 31 and 32, because the ping utility is used to send packets to the working system on which this utility is running.

23.1.6. Specific IP address

In this case, packets related to the DNS protocol and containing a specific IP address are filtered. The string "ip.addr==10.104.33.30 and dns" is used as a filter. The and directive tells the application to print information about each packet that matches two conditions.

Packet 93 contains a DNS query aimed at obtaining the type A record of the linux-training.be domain. Package 98 contains the response from DNS server. What do you think happened after packet 93 was sent and before packet 98 was received? Try to answer this question before reading the next section (if working with various systems It is always useful to try to predict upcoming events and check the correctness of your predictions).

23.1.7. Frame-based filtering

The correct term used to refer to an intercepted packet is the term frame (due to the fact that we do packet interception at Layer 2 of the OSI network model). Thus, to display information about packets with specific numbers, you should use the frame.number directive in the filter field.

23.1.8. Investigation of package contents

The middle panel of the sniffer window can be expanded. When you select a line within this panel, you can see the corresponding byte values in the field of the lower panel.

The illustration below shows the middle panel of the sniffer window with the selected address of my laptop.

Note that the technique described above works great when intercepting traffic sent through a single network interface. If you capture traffic, for example, using the tcpdump -i any command, you will encounter the "Linux cooked capture" packet capture method.

23.1.9. Other filter examples

You can combine two protocol descriptions using the directive logical operation or ("OR") located between them. The illustration below shows how to capture only packets related to the ARP and BOOTP (or DHCP) protocols.

And the following illustration shows a method for intercepting packets related to the DNS protocol and containing a specific IP address.

23.2. tcpdump utility

If working with the system command line interface, packet interception can be carried out using the tcpdump utility. Below are some examples of its use.

Using the tcpdump host $ip command will display information about all traffic related to a specific host (in this case, IP address 192.168.1.38).

Root@ubuntu910:~# tcpdump host 192.168.1.38 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

Interception of traffic related exclusively to the ssh protocol (TCP protocol, port 22) can be carried out using the tcpdump tcp port $port command. The length of output lines has been trimmed to 76 characters for easier reading.

Root@deb503:~# tcpdump tcp port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 14:22:20.716313 IP deb503. local.37973 > rhel53.local.ssh: P 666050963:66605 14:22:20.719936 IP rhel53.local.ssh > deb503.local.37973: P 1:49(48) ack 48 14:22:20.720922 IP rhel53.local .ssh > deb503.local.37973: P 49:113(64) ack 14:22:20.721321 IP rhel53.local.ssh > deb503.local.37973: P 113:161(48) ack 14:22:20.721820 IP deb503 .local.37973 > rhel53.local.ssh: . ack 161 win 200 14:22:20.722492 IP rhel53.local.ssh > deb503.local.37973: P 161:225(64) ack 14:22:20.760602 IP deb503.local.37973 > rhel53.local.ssh: . ack 225 win 200 14:22:23.108106 IP deb503.local.54424 > ubuntu910.local.ssh: P 467252637:46 14:22:23.116804 IP ubuntu910.local.ssh > deb503.local.54424: P 1:81 (80 ) ack 14:22:23.116844 IP deb503.local.54424 > ubuntu910.local.ssh: . ack 81 win 2 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

The same operation, but writing the captured data to a file, can be done using the tcpdump -w $filename command.

Root@ubuntu910:~# tcpdump -w sshdump.tcpdump tcp port 22 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes ^C 17 packets captured 17 packets received by filter 0 packets dropped by kernel

The tcpdump -r $filename command can print the contents of the file created in the previous example.

Root@ubuntu910:~# tcpdump -r sshdump.tcpdump

Many other examples of using the utility in question can be found in the tcpdump man page.

23.3. Practical task: intercepting network traffic

23.4. The correct procedure for completing a practical task: intercepting network traffic

1. Install the wireshark application on your system (not running in a virtual machine).

On Debain/Ubuntu distributions: aptitude install wireshark

On Red Hat/Mandriva/Fedora distributions: yum install wireshark

2. Use the ping utility to generate traffic between your computer and some other computer.

Ping $ip_address

3. Start intercepting network traffic.

(sudo)wireshark

Select the network interface (probably eth0)

4. Using the filter, display information only about those packets that contain responses to requests from the ping utility.

Enter "icmp" (without quotes) in the filter field and click the "Apply" button.

5. Now pass the ping utility a domain name (such as www.linux-training.be) and try to capture DNS request and response packets. What DNS server was used? Was TCP or UDP used to transmit the request and response?

First of all, launch the sniffer.

Enter "dns" in the filter field and click the "Apply" button.

Root@ubuntu910:~# ping www.linux-training.be PING www.linux-training.be (88.151.243.8) 56(84) bytes of data. 64 bytes from fosfor.openminds.be (88.151.243.8): icmp_seq=1 ttl=58 time=14.9 ms 64 bytes from fosfor.openminds.be (88.151.243.8): icmp_seq=2 ttl=58 time=16.0 ms ^C --- www.linux-training.be ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 14.984/15.539/16.095/0.569 ms

The wireshark application window should look similar.

Based on the information from the wireshark application window, we can conclude that the DNS request was transmitted using a UDP packet, after which it is easy to answer the questions posed.

6. Find a private website that has a password request form. Try to log in using the username "paul" and password "hunter2" while the sniffer is running. Now try to find the entered username and password in the data captured by the sniffer.