This lesson describes network hacking technologies based on interception 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.
To sniff Ethernet networks, network cards set to listening mode are usually used. Listening to an Ethernet network requires connecting a computer running a sniffer program to a network segment, after which all network traffic sent and received by computers on that 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's 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.
Network listening using network analyzer programs like the one above CaptureNet, is the first, the most in a simple way data interception. 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 later analysis.
To protect against network eavesdropping, use special programs, 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 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 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 does not allow a hacker to interfere with network communication between two hosts in order to modify and corrupt data. To solve such a problem, more complex technology is required.
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.
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 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 for resolving the hosts' IP addresses to the MAC addresses of computers. 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. Further, using special software, for example, the utility 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, in Windows networks 2000/XP does not seem to implement such reliable utilities. 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.
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.
To perform false routing, the attacker must know some details about the organization 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 the sender’s IP address is defined as the router’s IP address, and the recipient is specified 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 command can reveal the IP address of the attacker’s computer tracert(on Unix this is the tracerout command). These utilities are capable of finding 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 us 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 cryptographic methods for protecting information exchange described in Chapter 4 is provided by VPN networks(Virtual Private Network - Virtual private networks). Short review 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).
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.
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. (Those who like to understand other people's program code can refer to the site http://www.cri.cz/~kra/index.html where you can download source 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 - 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 transport protocols. OSI level, allowing 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 host B the following message:
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 Current Package will be perceived as true!
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 problem is solved through in-depth studies of the implementation of the TCP protocol in various operating systems and is now of purely theoretical significance. The second problem is solved by using Unix system vulnerabilities to identify 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.
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 methods of intercepting network data, performed by interfering with the normal functioning of the network in order to redirect traffic to a 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 the network's cable system 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).
The idea of writing this material was born, as it happened in most cases, thanks to questions from readers and other acquaintances regarding technologies for intercepting and analyzing network traffic. These questions are conditionally divided into 3 categories: is it possible, in principle, to intercept and decode data moving over the network, how and with the help of what software this can be done. The third group of questions reflects some confusion in terminology, in particular the following options are possible: a person knows the essence of the technology, but does not know what it is called. Therefore, when it comes to, say, a sniffer, he, looking down, answers that he does not know what it is. Isn't it time to dot the i's on this extremely important issue for both beginners and advanced networkers? Let's get started...theory
First, let's understand a little terminology.
The word sniffer (literally from English this can be translated as “sniffer” or “sniffer”) in the most general sense is a kind of listening device embedded in a network to intercept data transmitted over it. In a narrower sense, a sniffer is software that interacts with (often said, “sitting” came from a registered trademark of the company Network Associates, referring to the product “Sniffer(r) Network Analyzer”, but the word later suffered the same fate as the PC , xerox, kleenex - sniffer is becoming a common noun, denoting the entire class of similar products.
In some literature and documentation, as well as in electronic dictionaries such as Lingvo, the term sniffer (network sniffer) is identified with such concepts as “network traffic analyzer”, “packet analyzer”, “protocol analyzer”, “network analyzer”. However, let me slightly disagree with this approach.
Still, it would be more logical to say that sniffing is a set of measures to intercept traffic. Within the framework of a specific product, the following things can be implemented: packet capturing. At this stage, we receive a kind of raw (machine readable) data dump, usually divided into pieces along frame (packet) boundaries. And what we are going to do with him is our problem. But usually, since we have started the sniffer to work for some reason, we are interested in getting some result in a human readable format, for which we use packet decoding or protocol analysis;
Actually, this is the process of “raking up” our dump. For example, we had such raw material.
As you may have noticed, this case consists of three columns: the offset of each line, the data in hexadecimal format and their ASCII equivalent. This packet contains a 14-byte Ethernet header, a 20-byte IP header, a 20-byte TCP header, an HTTP header ending with two consecutive CRLFs (0D 0A 0D 0A), and then the actual application layer data, in our case - web traffic.
Sometimes this representation is enough to obtain the necessary information, but it is still more convenient for the packet to be decoded and analyzed at all levels of the protocol stack. It’s really nice to get a picture like this, isn’t it?
ETHER: Destination address: 0000BA5EBA11 ETHER: Source address: 00A0C9B05EBD ETHER: Frame Length: 1514 (0x05EA) ETHER: Ethernet Type: 0x0800 (IP) IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Precedence = Routine IP:...0.... = Normal Delay IP:....0... = Normal Throughput IP:.....0.. = Normal Reliability IP: Total Length = 1500 (0x5DC) IP: Identification = 7652 (0x1DE4) IP: Flags Summary = 2 (0x2) IP:.......0 = Last fragment in datagram IP:......1 . = Cannot fragment datagram IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 127 (0x7F) IP: Protocol = TCP - Transmission Control IP: Checksum = 0xC26D IP: Source Address = 10.0.0.2 IP: Destination Address = 10.0.1.201 TCP: Source Port = Hypertext Transfer Protocol TCP: Destination Port = 0x0775 TCP: Sequence Number = 97517760 (0x5D000C0) TCP: Acknowledgment Number = 78544373 (0x4AE7DF5) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 ( 0x0000) TCP: Flags = 0x10:.A.... TCP:..0..... = No urgent data TCP:...1.... = Acknowledgment field significant TCP:....0. .. = No Push function TCP:.....0.. = No Reset TCP:......0. = No Synchronize TCP:.......0 = No Fin TCP: Window = 28793 (0x7079) TCP: Checksum = 0x8F27 TCP: Urgent Pointer = 0 (0x0) HTTP: Response (to client using port 1909) HTTP: Protocol Version = HTTP/1.1 HTTP: Status Code = OK HTTP: Reason = OK ....In addition to the above, other “features” can be implemented, such as viewing passing packets in real time, filtering according to a given scenario, various types of traffic statistics - the number of errors, intensity, etc.
Types of sniffers and sniffing
Everything that will be described in this paragraph, naturally, has some shade of convention, since no one has yet fully described the official “Sniffing Theory”. We'll have to come up with a classification on the fly;)
So, according to “location” (if this term is applicable here), the sniffer can work:
On the router (gateway)
In this situation, you can intercept traffic passing through the interfaces of this gateway. For example, from your local network to another network and in the opposite direction. Accordingly, if we install a sniffer on the router of an Internet provider, we can monitor the traffic of its users, and so on...
At the end node of the network
With regard to Ethernet, we will have two main possible options for wiretapping. Classic, non-switched Ethernet assumes that each network interface, in principle, “hears” the traffic of its segment. However, in normal operation of the network card, after reading the first 48 bits of the frame header, the station compares its MAC address with the recipient address specified in the frame. If the address is someone else’s, the station “shamefully closes its ears,” that is, stops reading someone else’s frame. Thus, in normal mode, you can only intercept and analyze your own traffic. To intercept packets from all stations on a segment, you need to transfer your network card into a mode called promiscuous mode so that it “shamelessly” continues to read packets that are not intended for it. Almost all sniffer implementations allow the card to switch to promiscuous mode.
Note: using switched Ethernet creates a situation where even switching the card to promiscuous mode makes listening to traffic not intended for your station almost impossible. However, there is a technology for organizing such eavesdropping through so-called ARP spoofing. The bottom line is this: the switch creates a so-called “broadcast domain”, and a host with an installed sniffer can pretend to be, for example, a border router using ARP message forgery (by constantly sending out ARP messages, where the network address of the router corresponds to the MAC address of the listening station). Thus, the neighbors' traffic will be forcibly turned towards the "spien".
Otherwise, sniffers may differ from each other mainly in functionality, such as:
Supported physical interfaces and link layer protocols;
Decoding quality and number of “recognizable” protocols;
User interface and ease of display;
Additional features: statistics, real-time viewing, generating or modifying packets and more...
When choosing a sniffer (as, indeed, any other software), it makes sense to be guided by the following considerations: from what exists for your OS, choose either something that exactly matches your tasks (it makes sense if you are planning either a one-time event or either constantly performing the same operation) or the most sophisticated solution, in case you feel that the sniffer will be useful to you, but do not yet know in what situation :) And situations are different...
Why do we need a sniffer?
Traditionally, the idea of sniffing lived as if in two forms: legal and illegal use. Tellingly, the word "sniffer" is more often used in the illegal sphere, and "network analyzer" - in the legal one. Let's start with legal use;)
Troubleshooting (detection of problems and network bottlenecks). In advanced mode, when the sniffer operates in a non-switched segment or on a gateway, we can get an almost complete picture of events occurring in our network: traffic intensity by time, by workstation, by protocol, number of errors different types. In addition, in both modes, we can "rake" more specific problems, when, say, a particular station fails to organize some interaction over the network, and this despite the fact that the network looks quite functional from the outside. A sniffer is especially useful in cases where network software is poorly documented or uses its own closed (undocumented), often suspicious technologies (protocols).
For example: ICQ, Europe Online. Suspicious technologies/software should be understood as situations where you suspect that a program contains a tab or other undocumented functionality. For example, there were rumors that the client part of the famous cDc Back Orifice is also a Trojan horse and sends some information to the owners - the authors of the software. Setting the BO Client "to listen" showed that the rumors were not true.
A sniffer is no less useful for debugging your own software. I will never forget the moment when the proxy server refused to establish a connection if the GET request ended with \n\n instead of the required \r\n\r\n. Only examining the packets sent by the "legitimate" browser and comparing them to the packets sent by my "upstart" script pointed me to an unfortunate error. Very, very often in my daily admin practice, I also have to deal with analysis at the TCP / UDP level.
Education. You can get half swooning by memorizing various protocol packet header formats and interaction methods (say, 3-way TCP handshake, DNS, traceroute plan application methods), but this knowledge is dead until you try to "touch it with your hands" - having written once program or... by looking into the sniffer! After reading the documentation for an unknown or poorly understood protocol, try to simulate interaction, intercept packets and analyze them - I assure you, everything will become extremely clear and moreover, this knowledge is more realistic and will be deposited in your head for a long time. In the case of closed technologies, a sniffer may be almost the only means for studying them.
Network traffic logging. There can be a lot of discussion about the legality and ethics of logging user traffic by an administrator for further review, but the fact remains that many organizations include this technology in their security policy. My personal opinion is that the owner is a gentleman, that is, if the company provides its employees with equipment, connection to local and global networks, it has the right to demand the proper use of these resources. Second important reason for traffic logging - detection of unauthorized access attempts and other malware - DoS attacks for example. Having such logs, the administrator can know with 100% accuracy what is happening in his network properties.
Now let's talk about the illegal side of sniffing. Well, first of all, it's banal
Eavesdropping. By correctly installing a sniffer, you can spy on your close and distant ones - enemies, friends, spouses;) You may be interested in the following questions: why does a person use the network, what web resources does he visit, what data does he transmit, with whom and what does he communicate? Forgive me the state security authorities, but the notorious SORM, the legitimacy of which in the form of total traffic logging is a big question, I still refer to this section, although it could also be in the last paragraph of "legal sniffing";)
More mercantile eavesdropping. However, a significant part of the “hacker” community does not exchange their talents for spying on unfaithful spouses and other everyday matters. Most often, an attacker is interested in some material that can be used to advance the difficult task of breaking into other people's systems and networks. As you might have guessed, we're talking about, mainly about intercepting usernames and passwords passing through the network in unencrypted (plain text) form. In particular, this applies to passwords for telnet, POP, IMAP, NNTP, IRC, for web applications that do not use encryption, SNMP v1 community-strings, etc.
Implementations
Now, having more or less understood the theoretical part, let’s return to the sinful earth - let’s talk about specific implementations of sniffers for various platforms. In fact, there is a lot of such software, the range is functionality and the price tag (especially the latter) is colossal. The author of the "Sniffing (network wiretap, sniffer) FAQ" Robert Graham recommends trying the following products:
WinNT Server
Microsoft's WinNT Server comes with a built-in program called "Network Monitor". Go to the network control panel, select "Services", click "Add..." and select "Network Monitor Tools and Agent". After installation, the program will be available in start menu in the "Administrative Tools" section.
BlackICE is actually an Intrusion Detection System (IDS), but one of its functions is to write raw packet dumps in a form acceptable for decryption by protocol analyzers. One thing: the program only looks at traffic passing through the local interfaces of the host on which it works, that is, it is non-promiscuous. You can download the program on the website
This program, on the contrary, can only analyze packets recorded by a sniffer like BlackICE Pro.
Free protocol analyzer.
Naturally, this list is far from complete; you can climb any search engine or to the download software collection and find something suitable on the left side menu. Moreover, the review does not mention the most, in my opinion, the most outstanding product of this kind for Win32 - NetXRay, now renamed Sniffer Basic. We'll talk about it a little later.
Snort
A libpcap-based sniffer with advanced filtering capabilities.
Again, the list is far from perfect, you can look elsewhere. Another thing is that in the *NIX community it is not particularly customary to “spray” - there are time-tested, constantly improving leading products, and the majority prefer them, without even trying to look for an alternative. The absolute leaders here are tcpdump and sniffit.
Tcpdump & WinDump
(by Ghost//Necrosoft)
As mentioned above, TcpDump is the most commonly used sniffer for *nix systems. You can find it in any of the latest distributions of the operating system you use. The best way to describe tcpdump is to simply list all its options. command line- this way you get a list of its capabilities and a direct guide to action - “in one bottle”.
WinDump is a port of TcpDump from *nix systems, performs the same functions and has the same syntax as TcpDump, but has a couple of additional command line options, which will be discussed below.
A short note on using TcpDump under various systems. Under SunOS using nit or bpf devices: To run tcpdump you must have read access to /dev/nit or /dev/bpf*. Under Solaris with dlpi, you should be able to access pseudo-network adapters such as /dev/le. Under HP-UX with dlpi: you must be root or uid must be set to root on tcpdump. Under IRIX with snoop and Linux: requirements similar to HP-UX. Under Ultrix and Digital UNIX: only the superuser has access to promiscuous-mode operations , using pfconfig(8) you can get permission to run tcpdump Under BSD: you must have access to /dev/bpf* Under Win32: you must install the NDIS packet capture driver.
Now let's look at the command line options in detail.
TcpDump [ -adeflnNOpqStvx ] [ -c count ] [ -F file ] [ -i interface ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ expression ]. Windump specific options [-D] [-B size].
-a allows network and broadcast addresses to be converted to names.
-c exit after processing count packets.
-d prints the contents of the package in human-readable form.
-dd prints the contents of the package as a C program fragment.
-ddd prints the contents of the packet in decimal format.
-e Prints link-layer headers on each new line.
-f prints remote and local host addresses without converting to names.
-F use file with a description of the filtering parameters (additional expressions on the command line are ignored).
-i use interface for tracing. If not defined, tcpdump finds the lowest numbered active network interface (excluding loopback). In Windows interface - name network adapter or its number (you can find out by running WinDump -D).
-l uses buffered output to stdout. A construct like "tcpdump -l | tee dat" or "tcpdump -l > dat & tail -f dat" may be useful.
-n do not convert addresses (i.e. host address, port number, etc.) into names.
-N do not print Domain name in the hostname. Those. if this flag is used, tcpdump will print "nic" instead of "nic.ddn.mil".
-O do not run the package optimizer. This option is useful if you rake the packages yourself.
-p do not put the network interface into "promiscuous mode".
-q abbreviated output. Displays information in abbreviated form.
-r reads packages from file (those created with the -w option). If you want to use the console as input, then file is "-"".
-s produces a snaplen byte of each packet (in SunOS's NIT the minimum is 96). 68 bytes is enough for IP, ICMP, TCP and UDP protocols, but cuts off information from higher levels, say, DNS and NFS packets.
-T force interpretation of packets by type corresponding to the "expression" mask. On this moment The following types are known: rpc (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), vat (Visual Audio Tool), and wb (distributed White Board).
-S Prints the absolute number of the TCP packet.
-t does not print the time on each line.
-tt prints the unformatted time on each line.
-v verbose output. For example, packet lifetime and service type.
-vv verbose output. For example, displaying additional fields of NFS reply packets.
-w writes raw packets to file, which you can later decrypt using the -r option. If you want to use the console as output, then file is "-"".
-x outputs each packet in hexadecimal (without header). Snaplen bytes will be sent to the output.
Additional options WinDump:
-B sets the driver buffer size to size in kilobytes. The default buffer size is 1 megabyte. If some packets are not displayed during operation, try increasing the buffer size. If you have a PPP connection or 10 Mbit Ethernet, then the buffer size can be halved or tripled.
-D lists the network devices that are present on your system. The list looks like: number - number network device in the system, name is its name, followed by a description of the device. Subsequently, you will be able to use this data to work with all the existing network interfaces of your system that are currently available. And you can select the device using the -I option - "WinDump -i name" or "WinDump -i number".
expression - actually, an expression that specifies the packet filtering criterion. If the expression field is missing, then all packets are displayed. Otherwise, only those packets that match the expression mask are printed.
expression can consist of one or more primitives. Primitives often consist of an id (name or number) qualifier. There are three key types of qualifiers:
type is a qualifier that specifies the general policy. Possible types are host, net and port. Those. "host foo", "net 128.3", "port 20". If type is not specified, then host is used by default.
dir is a qualifier indicating the direction of packet transmission. Possible options src, dst, src or dst and src and dst. That is, "src foo", "dst net 128.3", "src or dst port ftp-data". If dir is not specified, then src or dst is used by default. For "null" connections (ppp or slip) the inbound and outbound qualifiers are used to indicate the desired direction.
proto - the qualifier allows you to filter packets by a specific protocol. Possible protocols: ether, fddi, ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcp and udp. Those. "ether src foo", "arp net 128.3", "tcp port 21". If there is no qualifier, then no packets are filtered. ("fddi" is actually an alias for "ether" because in most cases FDDI packets contain the source and destination Ethernet address and often contain Ethernet packet types. FDDI headers also contain other fields that are not in the filter list .)
In addition to the above, some special primitives do not have templates: gateway, broadcast, less, greater, and arithmetic expressions. About this a little further.
Many compound filter expressions use the words and, or, and not to combine primitives. For example "host foo and not port ftp and not port ftp-data". To simplify entry, some qualifiers may be omitted. For example, "tcp dst port ftp or ftp-data or domain" is the same as "tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain".
The following expressions are allowed:
dst host host is true if the IP destination field of the packet is host, which can be an address or hostname.
src host host is true if the IP source field of the packet is host.
host host is true if the source or destination of the packet is host. Prefixes can also be used: ip, arp, or rarp as: ip host host which is equivalent to ether proto \ip and hosthost. If host is a name with multiple IP addresses, each address is checked for a match.
ether dst ehost True if the destination Ethernet address is ehost. Ehost - any of the /etc/ethers names or numbers (see ethers(3N).
ether src ehost is true if the sender's Ethernet address is ehost.
ether host ehost is true if the recipient or sender Ethernet addresses are ehost.
gateway host is true if host is gateway. Those. The sender's or receiver's Ethernet address is host, but neither the sender's nor the recipient's IP is host. Host can be a name, and can also be located in /etc/hosts and /etc/ethers. (Which is equivalent to ether host ehost and not host host, which can be used with any name or number for host/ehost.)
dst net net is true if the recipient's IP address is net. Net - any entry from /etc/networks or network address.
src net net is true if the sender's IP address is net.
net net True if the recipient or sender IP has a network address - net.
net net mask mask True if the IP address matches net with the corresponding netmask. Can be specified in conjunction with src or dst.
net net/len is true if the IP is net and the subnet mask is len in bit form (CIDR format). Can be specified in conjunction with src or dst.
dst port port is true if the packet is ip/tcp or ip/udp and has a destination port of port. port can be a number or present in /etc/services (see tcp(4P) and udp(4P)). If a name is used for two or more ports, then both port numbers and protocols are checked. If an invalid port number or name is used, then only the port numbers are checked (ie, dst port 513 outputs tcp/login and udp/who traffic, and port domain outputs tcp/domain and udp/domain).
src port port is true if the source port is port.
port port is true if the source or destination port is port. Some expressions can be combined, for example: tcp src port port - only Tcp packets whose port is -port.
less length is true if the length of the packet is less than or equal to length, which is the same as len<= length.
greater length is true if the length of the packet is greater than or equal to length, which is equivalent to len >= length.
ip proto protocol is true if the packet is an IP protocol protocol packet. Protocol can be numbered or one of the names icmp, igrp, udp, nd, or tcp.
ether broadcast is true if the packet is an Ethernet broadcast packet. The ether expression is optional.
ip broadcast is true if the packet is an IP broadcast packet.
ether multicast is true if the packet is an Ethernet multicast packet. The ether expression is optional. This is shorthand for "ether & 1!= 0".
ip multicast is true if the packet is an IP multicast packet.
ether proto protocol is true if the packet is of Ethernet type. Protocol can be a number or a name: ip, arp, or rarp.
decnet src host is true if the destination DECNET address is host, which can be an address like "10.123" or a DECNET hostname (DECNET hostname is only supported on Ultrix systems).
decnet dst host True if the recipient's DECNET address is host.
decnet host host True if the DECNET address of the recipient or sender is host.
proto[expr:size]
Proto is one of the following protocols ether, fddi, ip, arp, rarp, tcp, udp, or icmp, and indicates the protocol level for this operation. Byte offset for this level protocol is taken from expr. Size - optional, shows the number of bytes of interest at a given offset, can be 1,2 or 4, default is 1.
Examples of using tcpdump
Dumping all incoming and outgoing packets from sundown: tcpdump host sundown
Sending traffic between helios and one of two hot or ace: tcpdump host helios and \(hot or ace \)
Issuing all packets between ace and other hosts, excluding helios: tcpdump ip host ace and not helios
Sending traffic between the local machine and the machine located in Berkeley: tcpdump net ucb-ether
Issuing ftp traffic through the snup gateway: tcpdump "gateway snup and (port ftp or ftp-data)"
Issuing traffic that does not belong to machines on the local network (if your machine is a gateway to another network, tcpdump will not be able to output traffic from your local network). tcpdump ip and not net localnet
Issuing old and stop packets (SYN and FIN packets) that do not belong to the local network. tcpdump "tcp & 3!= 0 and not src and dst net localnet"
Issuing IP packets longer than 576 bytes transmitted through the snup gateway: tcpdump "gateway snup and ip > 576"
Issuing IP broadcast or multicast packets that are not sent via Ethernet broadcast or multicast: tcpdump "ether & 1 = 0 and ip >= 224"
Dumping all ICMP packets that are not echo requests/responses (i.e., not ping packets): tcpdump "icmp!= 8 and icmp!= 0"
NetXRay
By Alice D. Saemon
The one I love...
Long long time ago... NetXRay was the first sniffer that came to my attention. Then, in 1997, this English program made a splash in the circles of windows-oriented networkers. Years have passed, but the old version of NetXRay (3.0.1) is still in service, in daily use on my workstation. To date, the product has been renamed to Sniffer Basic, some new features have been added, but, from a larger point of view, the main functionality has remained unchanged since 3.0.1. This is the first reason why NetXRay 3.0.1 will be described in the newspaper. The second reason... (looking at the anti-piracy police) - the product is very expensive (1643 pounds sterling), and the trial restrictions are very serious. So, let's get started.
The package consists of a set of different functions and can really be called a network analyzer rather than a sniffer. All capabilities (modules) are grouped in the “Tools” menu, where various settings are also located. Let's start with them. You can select the adapter for which the current test is being carried out (probe). The adapter must support the NDIS 3.0/3.1 standard.
Attention, bug! If you “set” NetXRay on the “wrong” adapter in its opinion or capture packets that it cannot decode at the link-network level (for example, exploit traffic that sends crookedly fragmented packets) - at the decoding stage (protocol analysis) the program freezes dead .
You can simultaneously test on several interfaces, for which multiple versions of the program (probes) are created. You can copy all the settings of any existing probe to a new probe.
In options you can configure the following things: appearance desktop, standard port numbers for various protocols (3 options - very useful in cases where network applications operate on non-standard ports), response to the occurrence of some event, threshold values for various types of statistics, etc.
Well, now let's move on to the functional modules of the package.
capture (packet capture)
The heart of NetXRay, in fact, is what in the popular understanding is a sniffer. Therefore, I will allow myself to describe it in as much detail as possible.
When this module is activated, a small window appears in front of us with " dashboard" and a couple of buttons. All actions that we can perform in this window are duplicated in the Capture menu. And we can do this: start capturing packets, stop, stop + view the contents of the buffer and simply view the contents of the buffer, provided that the capture was stopped. There we can carry out fine tuning filters:
By addresses of the sender and recipient. To facilitate this task, there is an address book and a certain set of preset addresses, for example “Any”.
According to templates. If you need to catch packets containing some specific data anywhere in the packet, you can write a clever template. Moreover, what is especially nice is that you can construct templates in any representation convenient for you: binary, hexadecimal, ASCII and EBCDIC.
According to protocols known to the program. This:
Network: AppleTalk, AppleTalk ARP, APOLLO, DECNET, IP, IP ARP, IPX, LAT, NetBEUI, OSI, SNA, VINES, VINES Loopback, VINES Echo, XNS
Higher in the IP stack: transport, service and routing - ICMP, IGMP, GGP, EGP, IGP, ISO-TP4, HELLO, IP-VINES, IGRP, OSPF, TCP, UDP; application level - FTP, REXEC, RLOGIN, RSH, PRINTER, SMTP, TELNET, DNS(TCP), GOPHER, HTTP, POP, SUNRPC(TCP), NNTP, NETBIOS, X-WINDOW, DNS(UDP), BOOTP, TFTP, SUNRPC(UDP), SNMP, SNMPTRAP, BIFF, WHO, SYSLOG, RIP, GDP, NFS.
Higher in the IPX stack: NCP, SAP, NRIP, NBIOS, DIAGNOSTIC, SERIALIZATION, NMPI, NLSP, NSNMP, NSNMPTRAP, SPX.
As you can see, it’s not so little, I would say - even excessive for real life.
Attention! The protocol filter has a slightly strange interface: it is assumed that if all checkboxes within the boundaries of one level are not marked, all protocol packets of this level and everything higher (lower, if you look at user interface;). Thus, if you haven’t placed a single “bird”, absolutely everything is caught. Naturally, unknown protocols of application levels in this case are also caught, but are not decoded into a readable form, which is natural, since they are unknown :))
In addition, you can adjust the buffer size or specify the file where to send the packet capture results.
Filter settings can be recorded in a so-called profile, assigned a name and subsequently selected from the list.
After working out the capture of the required number of packets, when viewing is activated, we fall out into the so-called "results window", which by default has the names XRay1, XRay2 and so on according to the number of current buffers. You can see such a window on the screenshot: above - a list of packages with a brief "annotation", in the middle - decoded data (well, I could decode;) and below - a raw package. It is curious that when you click on the field of interest in the decoded section, the corresponding place in the raw packet is highlighted - you can check the quality of the protocol analyzer;)
The user interface of the "results window" has along with the advantages (the ability to apply any of the filters discussed above to the displayed buffer, the ability to send any packet or buffer to the network with one mouse click or copy a number of packets to a separate buffer, a very beautiful display of decoded data, even with some nesting for fields of little interest to the average user) as well as obvious disadvantages (you cannot delete a couple of packages from the buffer, there is no clipboard operability, that is, the results cannot, for example, be copied and saved in text format).
In addition to accumulating packets in a buffer or file for subsequent decoding, there is also the possibility of viewing traffic in real time.
True a) visually it looks terrible b) this option is enabled in such an illogical place that even such an old NetXRay user like me forgets where this "bird" is. The bird is installed in the Tools | Options... General tab, Realtime Display checkbox, and not in the Capture settings, where it would be logical to look for it;-/
In addition, the "results window" contains bookmarks for statistical data on the capture session, but we will not dwell on them.
packet generator
This is really a wonderful thing: you can "sketch" from scratch and send absolutely any packet to the network. The interface consists of the main window and the so-called package designer, divided into two sections - Configure and Decode.
In the first one, we have a portrait of a standard dump (see the theoretical part of the article), filled with zeros. We begin to enter hexadecimal numbers there - in the decoding section, which looks exactly like the decrypted packet in the "results window" of Capture, an analysis of our packet appears.
But in this case, we can not only look at the decoded packet, but also make changes by clicking on the desired field. True, changing the values in any case is carried out only in hexadecimal form, and the input fields are striking in their inconvenience: (There are several options for generating and sending packets: send the current packet, send the current buffer, write a packet from scratch or send an edited packet from what you collected .
Interface note: if the “send current packet” option is called from the Capture “result window”, the packet is sent immediately without calling the packet constructor, although it remains in the current “send buffer”, and can be adjusted there later.
If "send current packet" is called from the Packet Generator window, the package designer is automatically called. Be careful!
In the package designer in the Decode section, the program will give you some hints, in particular, it will calculate a new checksum when modifying the package (it would also make the appropriate changes itself, lazy creation;). However, AI differs from the human mind in that it cannot think properly. So when, for example, you change the recipient's IP address, think about whether you should also change its MAC address? ;)
Packets can be sent to different modes: one click - one packet, a specified number of packets, or in a loop. This way you can generate traffic. In general, you can find a lot of options for using the package generator, it’s up to your imagination and ingenuity.
All sorts of things
In addition to the above, the program contains a lot of other useful and not so (depending on whom;) bells and whistles. Briefly about them:
Dashboard Network load statistics, more precisely that one the part of it that is visible to you. Number of packets, bytes, errors of all types, utilization calculation. This feature has always confused me, because I have never seen error messages in my life - well, it can’t be that there aren’t any!;)
Host Table. Captures various information about hosts visible to the sniffer and their activities (without full packet capture and analysis)
Matrix. Almost the same as Host Table, but presented in a slightly different format.
History. Draws graphs and diagrams of network behavior over a certain period of time.
Protocol Distribution. As the name suggests, it keeps statistics on the use of various protocols.
Statistics. Statistics on utilization and frame sizes.
Alarm log. A log of events you define.
Well, that's all in a nutshell. (wow “it turned out in short %-()) Download and test for health - for your joy and to spite your enemies :)
Conclusion
Well, the tale of sniffers is over for today. Those who listened (read to the end) - well done, I hope you got answers to most of your questions. For the sake of fairness, I note: not ALL issues were considered within the framework of this article. At least two big topics were left out: the internal structure of sniffers, including methods and approaches to writing such software, as well as ways to counter sniffing.
As for the first, here’s what I think: the topic is interesting, requiring separate material, but it will be intended mainly for programmers. We'll figure something out about this. As for the second question, the answer to it is basically the same: encryption, encryption and encryption again, which is obvious. There are, of course, methods for recognizing the presence of a sniffer on a network and even countering it, but they are quite private and not very effective.
Interceptor is a multifunctional network tool that allows you to obtain data from traffic (passwords, instant messenger messages, correspondence, etc.) and implement various MiTM attacks.
Intercepter program interface
Main functionality
Ressurection Mode– recovery of useful data from traffic, from protocols that transmit traffic in clear text. When the victim views files, pages, data, they can be partially or completely intercepted. Additionally, you can specify the size of the files so as not to download the program in small parts. This information can be used for analysis.
Password Mode– mode for working with cookies. In this way, it is possible to gain access to the victim's visited files.
Scan mode– main mode for testing. To start scanning, you need to right-click Smart Scan. After scanning, all network participants will be displayed in the window, their operating system and other parameters.
Additionally, in this mode you can scan ports. You must use the Scan Ports function. Of course, there are much more functional utilities for this, but the presence of this function is an important point.
If we are interested in a targeted attack on the network, then after scanning we need to add the target IP to Nat using the command (Add to Nat). In another window it will be possible to carry out other attacks.
Nat Mode. The main mode, which allows you to carry out a number of attacks via ARP. This is the main window that allows targeted attacks.
DHCP mode. This is a mode that allows you to raise your DHCP server to implement DHCP attacks in the middle.
Some types of attacks that can be carried out
Site spoofing
To spoof the victim’s website, you need to go to Target, after which you need to specify the site and its substitution. This way you can replace quite a lot of sites. It all depends on how high-quality the fake is.
Site spoofing
Example for VK.com
Selecting MiTM attack
Changing the injection rule
As a result, the victim opens a fake website when requesting vk.com. And in password mode there should be the victim’s login and password:
To carry out a targeted attack, you need to select a victim from the list and add it to the target. This can be done using the right mouse button.
Adding MiTm attacks
Now you can use Ressurection Mode to recover various data from traffic.
Victim files and information via MiTm attack
Traffic spoofing
Specifying Settings
After this, the victim’s request will change from “trust” to “loser”.
Additionally, you can kill cookies so that the victim logs out of all accounts and logs in again. This will allow you to intercept logins and passwords.
Destroying cookies
How to see a potential sniffer on the network using Intercepter?
Using the Promisc Detection option, you can detect a device that is scanning on the local network. After scanning, the status column will show “Sniffer”. This is the first way to detect scanning on a local network.
Sniffer Detection
SDR HackRF Device
HackRF is a full SDR device for $300. The author of the project, Michael Ossman, is developing successful devices in this direction. The Ubertooth Bluetooth sniffer was previously developed and successfully implemented. HackRF is a successful project that has raised more than 600 thousand on Kickstarter. 500 of these devices have already been sold for beta testing.
HackRF operates in the frequency range from 30 MHz to 6 GHz. The sampling frequency is 20 MHz, which allows you to intercept Wi-Fi signals and LTE networks.
How to protect yourself at the local level?
First, let's use SoftPerfect WiFi Guard software. There is a portable version that takes no more than 4 MB. It allows you to scan your network and display what devices are displayed on it. It has settings that allow you to select the network card and the maximum number of devices to be scanned. Additionally, you can set the scanning interval.
Conclusion
Thus, we have considered in practice how to use software to intercept data within the network. We looked at several specific attacks that allow you to obtain login data, as well as other information. Additionally, we looked at SoftPerfect WiFi Guard, which allows you to protect your local network from eavesdropping traffic at a primitive level.
Many users do not realize that by filling out a login and password when registering or authorizing on 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 into uses the HTTP protocol, then it is very easy to capture this traffic, analyze it using Wireshark, and then use special filters and programs to 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.
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.
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 packages. This is where 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.
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:
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:
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:
and more serious utilities for decrypting the encoding protocol.
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:
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.
VIDEO: Wireshark Packet Sniffing Usernames, Passwords, and Web Pages
Methods for intercepting network traffic
Listening to the network using network analyzer programs is the first and easiest way to intercept data.
To protect against network eavesdropping, special programs are used, 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 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 one to obtain a lot of useful information - passwords transmitted over the network, addresses of network computers, confidential data, letters, etc. However, simple eavesdropping does not allow a hacker to interfere with network communication between two hosts in order to modify and corrupt data. To solve such a problem, more complex technology is required.
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.
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.
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 for monitoring and managing network traffic, for example, arpredirect. Unfortunately, such reliable utilities do not seem to be implemented on Windows networks. 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 address is defined as the IP address of the router, and the recipient is host A. Also included in the datagram is an ICMP Redirect message with the address field of the new router 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 tracert command (in Unix this is the tracerout command) can reveal the IP address of the attacker’s computer. These utilities are capable of finding 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 us 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 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.
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, TCP connection hijacking attacks are of little use.
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.
Overview of software packet sniffers
All software sniffers can be divided into two categories: sniffers that support launch from the command line, and sniffers that have a graphical interface. At the same time, we note that there are sniffers that combine both of these features. 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 capture 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 this 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 software packet analyzers 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.
