Hackers use it to redirect traffic. Methods of hacker attacks
The next type of attack aims to direct traffic from the attacked computer to a false address, which can be the address of either an attacker or a third party. An attacker can dispose of the data stream that a user sends, for example, to his corporate server or a bank server in two ways. The first is that the attacker disguises himself as the recipient’s server, transmitting to the client the “picture” and the messages that he expects. Thus, an attacker can simulate a logical login procedure for a victim user, thereby obtaining the user ID and password. This data can later be used for unauthorized access to the server of an enterprise or bank, which is the main target of the attack. The second method is to organize traffic transit. Each intercepted packet is remembered and/or analyzed on the attacking node, and then forwarded to the “real” server. Thus, all traffic between the client and server is passed through the attacker’s computer.
Let's look at some of the techniques used now (or in the recent past) to carry out attacks of this type. Countermeasures have already been developed for most of them, and the descriptions of attacks given here are mainly of an educational nature.
The simplest option for redirecting traffic on a local network can be done by sending a false ARP-omeema to the network. (Let us leave aside the question of how often such a situation may arise when an attacker is interested in intercepting traffic from his own local network.) In this case, the scheme is obvious: having received a broadcast ARP request regarding a certain IP address, the attacker sends a false ARP response in which it is reported that this IP address corresponds to its own MAC address.
The ICMP protocol can theoretically also be used to intercept and redirect traffic on a local network. Under this protocol, the default router sends an ICMP route redirection message to a host on the directly attached LAN when that route fails or when it detects that the host is using an inappropriate route for some destination address. In Fig. 1, and the default router R1, having received a packet from host H1 addressed to host H2, determines that the best route to host H2 runs through another router on this local network, namely through router R2. Router R1 discards the received packet and places its header in the JMR route redirection message that it sends to host H1. The message contains the IP address of the alternate router R2, which the host should now use when sending data to host H2. Host H1 makes changes to its routing table and from now on sends packets to host H2 along the new adjusted route. To intercept traffic sent by host H1 to host H2, the attacker must generate and send to host HI a packet masquerading as a JMR route redirection message (Fig. 1, b). This message requests that the routing table of host H1 be adjusted so that in all packets with IP address H2, the next router address becomes IPha. which is the address of the malicious host NA. In order for the host to “believe” this message, the address of router R1, which is the default router, must be placed in the sender IP address field. When packets transmitted by the deceived host begin to arrive at the attacker’s node, it can either capture and not forward these packets further, imitating the application for which these packets were intended to maintain a dialogue, or organize transit data transmission to the specified destination IPn2-Reading all traffic between nodes H1 and H2, the attacker receives all the necessary information for unauthorized access to the H2 server.
Another way to intercept traffic is to use false DNS-omeemoe (Fig. 2). The attacker's goal is to gain access to the corporate server. To do this, he needs to take possession of the name and password of an authorized user of the corporate network. He decides to obtain this information by forking the stream of data that the corporate client sends to the corporate server. The attacker knows that the client is accessing the server by specifying its symbolic DNS name www.example.com. He also knows that before sending a packet to the server, the software on the client machine queries the DNS server to find out which IP address corresponds to that name.
The attacker's goal is to get ahead of the DNS server's response and impose on the client his own version of the answer, in which instead of the IP address of the corporate server (193.25.34.125 in the example), the attacker indicates the IP address of the attacking host (203.13.1.123). There are several serious obstacles to the implementation of this plan.
Rice. 1. Route redirection using the YMR protocol: a - a message about a more rational route to host H2 is sent by router H1, which is used by default;
b - the message about route redirection is sent to itself by the attacking host NA
Rice. 2. Traffic redirection scheme using false DNS responses
First of all, it is necessary to delay the response of the DNS server; for this, the server, for example, can be subjected to a DoS attack. Another problem is determining the DNS client port number that must be included in the packet header for the data to reach the application. And if the server part of the DNS has the so-called “well-known” number 53 permanently assigned to it, then the client part of the DNS protocol receives the port number dynamically at startup, and the operating system selects it from a fairly wide range.
Note that the DNS protocol can use either UDP or TCP to transmit its messages, depending on how it is configured by the administrator. Since the TCP protocol establishes a logical connection by tracking the numbers of bytes sent and received, it is much more difficult to “break in” into the dialogue between the client and the server in this case than in the case when the UDP datagram protocol is used.
However, even in the latter case, the problem of determining the UDP port number of the DNS client remains. The attacker solves this problem by directly enumerating all possible numbers. Also, by enumerating possible values, the attacker overcomes the problem of determining DNS message identifiers. These identifiers are sent in DNS messages and serve so that the DNS client can match incoming responses to sent requests. So, the attacker bombards the client machine with false DNS responses, trying out all the possible values of the identifying fields so that the client eventually accepts one of them as a true DNS response. As soon as this happens, the attacker’s goal can be considered achieved - packets from the client are sent to the address of the attacking host, the attacker receives the name and password of the legal user, and with them access to the corporate server.
Listening to Switched Networks
Study of modern methods
Many modern attacks are carried out by so-called "script kiddies". These are users who find exploit scripts on the Internet and launch them against every system they can find. These simple attack methods do not require special knowledge or instructions.
However, there are other methods based on a deeper understanding of the operation of computers, networks and the systems being attacked. In this section we will get acquainted with such methods - listening (sniffing) of switched networks and simulating an IP address (IP-spoofing).
Eavesdropping, or sniffing, is used by hackers/crackers after a system has been compromised to collect passwords and other system information. To do this, the sniffer sets the network interface card to promiscuous mode, i.e. the network adapter will intercept all packets moving across the network, and not just packets addressed to this adapter or system. Sniffers of this type work well in networks with shared bandwidth with network concentrators - hubs.
As network switches are now used more, sniffing efficiency has begun to decline. In a switched environment, broadcast mode is not used; instead, packets are sent directly to the receiving system. However, switches are not security devices. These are ordinary network devices, so the security they provide is more a by-product of their network purpose than a design element. Therefore, it is quite possible that a sniffer will appear that can work in a switched environment. And this has already happened. A sniffer specifically designed for the dial-up environment can be found at http://ettercap.sourceforge.net/.
To eavesdrop on traffic in a dial-up environment, a hacker must meet one of the following conditions:
- "convince" the switch that traffic of interest should be directed to the sniffer;
- force the switch to send all traffic to all ports.
If one of the conditions is met, the sniffer will be able to read the traffic of interest and, thus, provide the hacker with the information he is looking for.
The switch directs traffic to ports based on the Media Access Control (MAC) address for the frame transmitted over the Ethernet network. Each network interface card has a unique MAC address, and the switch "knows" which addresses are assigned to which port. Therefore, when a frame is transmitted with a specific destination MAC address, the switch forwards the frame to the port to which that MAC address is assigned.
The following are methods by which you can force the switch to forward network traffic to the sniffer:
- ARP spoofing;
- duplication of MAC addresses;
- imitation of a domain name.
ARP spoofing(ARP-spoofing). ARP is an Address Resolution Protocol used to obtain the MAC address associated with a specific IP address. When transmitting traffic, the sending system sends an ARP request to the recipient's IP address. The receiving system responds to this request by transmitting its MAC address, which will be used by the sending system to forward the traffic directly.
If the sniffer captures traffic of interest to it, it will respond to the ARP request instead of the actual recipient system and provide its own MAC address. As a result, the sending system will send traffic to the sniffer.
To ensure this process is effective, all traffic must be forwarded to the sniffer instead of the actual destination. If this is not done, there is a possibility that network access will be denied.
Note
ARP spoofing only works on local subnets because ARP messages are sent only within the local subnet. The sniffer must be located on the same local network segment as the sending and receiving systems.
Duplicate MAC addresses. Duplicating the destination system's MAC address is another way to "convince" the switch to send traffic to the sniffer. To do this, the hacker needs to change the MAC address on the sniffer and locate himself on a system that is located in the same local network segment.
Note
It is believed that it is impossible to change MAC addresses. However, this is not the case at all. This can be done on a Unix system using the ipconfig command. Similar utilities are available in Windows.
To perform ARP spoofing, the sniffer must be located on the same local subnet as both systems (sender and recipient) to be able to duplicate MAC addresses.
Imitation of a domain name. There is a third way to force the switch to send all traffic to the sniffer: you need to “trick” the sending system into using the real MAC address of the sniffer to transmit data. This is done by spoofing a domain name.
In this attack, the sniffer intercepts DNS requests from the sending system and responds to them. Instead of the IP address of the systems to which the request was sent, the sending system receives the IP address of the sniffer and sends all traffic to it. Next, the sniffer must redirect this traffic to the real recipient. We see that in this case the domain name spoofing attack turns into an hijacking attack.
To ensure the success of this attack, the sniffer needs to look at all DNS queries and respond to them before the actual recipient does. Therefore, the sniffer must be located on the route of traffic from the sending system to the DNS server, and even better - in the same local subnet as the sender.
Note
A sniffer could look at requests sent over the Internet, but the further away it is from the sending system, the more difficult it is to ensure that it responds first.
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, no less interesting actions. Unfortunately, most of these attacks in practice are 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
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, email messages, HTTP messages (exchange of information with a 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, transferring a text file from the 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.
Methods for intercepting network traffic
Network listening 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 later 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 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.
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.
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, 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 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 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 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 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. A brief overview of cryptographic security principles and techniques can be found in Appendix E, and a detailed description of the cryptographic security features provided by the application is provided in Appendix E. PGP Desktop Security (http://www.pgp.com).
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, 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 the source code of the well-known TCP connection interception utility Hunt from Pavel Krauz).
Despite the lack of practical tools, we cannot ignore such an interesting topic as intercepting TCP connections, and we will dwell on 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 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 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 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 to obtain 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 must be clearly understood 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 if 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.
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 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).
In this article we will look at attacks like Man-in-the-Middle, or rather the method
redirecting SSH and HTTP traffic using the Man in the Middle attack. Let's not pull the cat by the tail, but let's get down to business.
Man in the Middle (in short MitM, from Russian simply - “attack of the middleman” or “man
in the middle") is a type of attack based on redirecting traffic between two machines to intercept information - further study, destroy or modify it. So, the first thing we need is the dsniff package (you will see a link to the package at the end of the article). Why Yes, because this package contains all the necessary utilities, including sshmitm (redirecting SSH traffic) and httpmitm (redirecting HTTP traffic), which can bypass the following security scheme: as far as you know, protocols with data encryption are quite -they are "secure" (encryption helps :)) and do not allow attacks to be carried out "on top" of the network layer. The encryption key is unknown to the hacker - it is impossible to decrypt the data and insert a command too. Everything seems fine, but here's how
Since the MitM attack programs (sshmitm and httpmitm) from the dsniff package are able to bypass this security system (almost everything can be bypassed). This is all done according to the following principle:
the intermediate host receives the request from the client, "telling" it that it is the server, then connecting to the real server.
The second thing we need is straight arms, the fourth thing - the most important thing - is desire, and, of course, a victim, that is, the computer that we will attack.
Redirecting SSH traffic
After preparing the tools, you understood what was what and why :). Get sshmitm - now we will redirect SSH traffic (everything that you didn’t understand with the theoretical part - read above)
using it, taking advantage of the shortcomings of today's PKI (public key infrastructure - a key management scheme based on
methods of asymmetric cryptography). Let's look at the syntax
sshmitm:
sshmitm [-d] [-I] [-p port] host
D
allow debug output (i.e. more advanced mode)
I
session hijacking
P port
listening port
host
address of the remote host whose sessions will be intercepted
port
port on the remote host
Everything seems simple and tasteful - there is nothing complicated :). Let's start implementing the attack!
# sshmitm server.target.gov // specify your SSH server
sshmitm: relaying to server server.target.gov
Since we do not have a real SSH key, the command interpreter of the attacked
will display a request to check the host key, it will all look something like this:
clientmachine$ server.target.gov
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Please contact your system administrator.
And then the user will decide whether to connect or not. If yes, then we will have full control over the SSH session.
BUT! If the user has never connected to that car, the following message may be displayed:
The authenticity of host "server.target.gov" can"t be established
RSA key fingerprint is
bla:bla:bla;bla;bla........
Are you sure you want to continue connecting (yes/no)?
Here the user also has two choices - to connect or not. If yes, then we intercepted the session, if not, then alas... :(.
In general, the attack was successful if the user connected, and sshmitm, in turn, recorded all passes and logins, and in a very readable manner :)
Naturally, this is not the only SSH session interceptor, but once you become familiar with this, you can easily master another one :)
Redirecting HTTP Traffic
Now we will redirect HTTP traffic. Again, we will need a previously selected tool: httpmitm, which listens to ports 80 (HTTP -) and 443 (HTTPS -), intercepts WEB requests, then connects to the server and forwards the requests to the client computer. The program also generates SSL keys and SSL certificates using OpenSSL. Then, after trying
connects to the site (target.gov), the browser will check the SSL certificate. Since the certificates will not match, the user’s browser will warn about
incorrect SSL certificate. From the attacker's perspective it will look something like this:
#webmitm -d
webmitm: relaying transparently
webmitm: new connection from
GET [link]/uzerz.php?user=hellknights&password=neskaju1qwerty HTTP/[version]
Connection: [type]
Host: www.target.gov
User-Agent: [system, browser information]
[etc, etc, etc]
Cookie: [cookies]
This is how it all looks from the outside -
the SSL connection is intercepted, capturing unencrypted data.
Conclusion
In this article, we looked at the redirection of SSH and HTTP traffic using the Man in the Middle attack - clearly, in detail, briefly. Other HTTP and SSH redirectors
You will master traffic using MitM quickly if you have mastered these too :)). If something was unclear, then...
In this article we will look at proxying the traffic of iOS applications that use native web sockets to interact with the server. The article will be useful to those pentesters who in their work are faced with the interception of confidential information sent by iOS applications in non-standard ways. These methods are relevant because using the default proxy server settings on the device to intercept traffic from some applications may not be sufficient.
Recently, during another pentest, I came across an application that sent information to port 20xx of a web server. The traffic of this application could not be intercepted by changing the default settings (Settings -> Wi-Fi -> HTTP Proxy -> Manual) and redirecting the traffic to the proxy. One of the reasons why this method does not work is that native websockets are used to communicate with the server instead of the UIWebView class. More details about how web sockets are configured can be found in this article.
However, there is a workaround to solve this problem. We can implement DNS spoofing and redirect all HTTP traffic from all ports through a proxy like Burp. This article consists of parts:
- Sniffing traffic using Wireshark to find the server's IP address and port.
- DNS spoofing and forwarding all traffic to the machine where the proxy is installed.
- Intercepting traffic using a proxy server after DNS spoofing.
Below is a step-by-step diagram for implementing traffic interception for iOS applications using Native Web Socket.
1. Create a wireless access point and connect the device to it. [Note: The machine must be connected to Ethernet or otherwise connected to the Internet, since the Wi-Fi interface will be used for the access point. This article talks about how to set up an access point on a Windows machine]
2. Launch a network sniffer (for example, Wireshark) and look for traffic passing through non-standard ports.
a. We filter traffic, leaving only that which goes to the IP address we need (ip.dst== ip.ip.ip.ip)
b. Find the port number to which traffic is sent.
Figure 1: Finding a non-standard port to which the application sends traffic
3. Launch the Metasploit console for DNS spoofing and enter the following commands:
c. set SRVHOST = (IP of wireless access point)
d. set SRVPORT = 53, set TARGETACTION = BYPASS, set TARGETDOMAIN = www.apple.com (Note: by setting TARGETDOMAIN= www.apple.com, we will intercept all traffic except that coming from apple.com).
e. set targethost = (IP of wireless access point)
Figure 2: Setting up a DNS server using the fakedns module (inMetasploit)
4. Configure Burp to listen to incoming device traffic on certain ports and redirect it to the previously found port.
a. Go to Proxy->Options->Add; set the “bind port” to the port to which the application should forward traffic (note: this is one of those non-standard TCP ports that was found using Wireshark).
b. We listen to all interfaces.
c. In the Request Handling tab, set the server domain (Redirect to host field).
d. In the same tab, set the corresponding port number (Redirect to port field).
e. If traffic is sent via https, we force the use of SSL.
f. Click ok and repeat all the above operations for all ports to which the application sends traffic. In other words, each port needs a separately configured Proxy listener.
Figure 3: Configuring listening and redirecting traffic
5. Configure the proxy settings on the device:
a. Go to the Wi-Fi->DHCP section and set DNS = IP address of the access point.
b. In the HTTP proxy settings, set the IP address of the access point and the corresponding port to which burp is configured (these settings are used to proxy standard HTTP traffic).
Figure 4: IP Configuration andDNS forwardingon the device
6. Enter “exploit” in the Metasploit console and you will see all intercepted traffic from non-standard ports.
The described method can be used to bypass problems with intercepting traffic from iOS applications that transmit it in non-standard ways.