Shulou(Shulou.com)05/31 Report--

How Zeek provides the perception of encrypted communication, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Overview

Encrypted communication is now ubiquitous, but to some extent, encryption not only ensures the confidentiality of information, but also does not hinder the analysis of traffic. Some protocols, such as SSH and TLS, ensure that traffic analysis tools cannot read content directly, but analysis of the size and order of transmitted data can be helpful. This article outlines some of the work that Zeek uses to provide visibility into SSH connections.

Anyone who has observed network traffic on exposed IP can see a variety of connections in the Internet. Unlicensed connections from Internet scanners, crawlers, worms and reflexes are all common. Service providers like Shodan, Greynoise and Censys have created Internet-wide scan data, providing historical data sets for forensics and intelligence investigations. Although these services are benign, you can submit a request to the provider to exclude scanning. But not all scans are benign, such as variants of Mirai. The botnet scans the SSH and Telnet services and attempts to log in using the default password list.

SSH brute force detection of Zeek

Detecting SSH brute force cracking against the host is one of the "out-of-the-box" capabilities provided by Zeek. When a policy script for SSH brute force cracking is enabled, Zeek can detect SSH brute force cracking by tracking successful and failed SSH connection attempts on each host. This script detects SSH brute force cracking attempts, and if it is credential theft, it is called Credential Stuffing.

The logic of this script is to use the SumStats framework to count the number of ssh_auth_successful and ssh_auth_failed events. The counter is incremented each time a ssh_auth_failed event occurs. If the counter exceeds the configured threshold (password_guesses_limit), an alarm is issued. If you successfully log in to the server through password guessing, the script will also issue an alarm. If you see the ssh_auth_successful event after the ssh_auth_failed event and the host that initiates and responds is the same, Zeek infers that the login has been successfully cracked by brute force. A further understanding of the SSH protocol is necessary to understand what causes ssh_auth_successful events and ssh_auth_failed events.

SSH protocol

RFC 4251 description of SSH: the SSH protocol is a protocol for secure remote login and other network services over insecure networks. The protocol consists of three subprotocols with different message types to exchange information between the control side and the client. These three subprotocols are responsible for different tasks, including:

Transport layer protocol, used to establish encryption and improve the other two subprotocols

Authentication protocol, used to verify the endpoint of the SSH connection

Connection protocol to provide interactive sessions, command execution, X11 Forwarding, or port connections

The following figure depicts the process of exchanging information on a typical SSH connection. When an TCP connection is initially established, both endpoints send their version identification strings, similar to User-Agent in the HTTP protocol, but each side needs to provide one in SSH. The initial key exchange occurs after the exchange, which helps to create a symmetric key encryption tunnel. The cipher suite, compression method, and other configuration options to be used should be explicitly negotiated before encryption begins. The box at the top of the figure shows this exchange, labeled In the clear. It is worth noting that the information exchanged in plaintext is also used by fingerprint techniques such as HASSH.

Although the SSH protocol does not dictate what must be done after encryption starts. However, most clients send a service request message of type ssh-userauth to the server (the first message marked "Encrypted" in the green box below) indicating that the client wants to initiate authentication to the server. The server responds to the client's service request by accepting the message SSH_MSG_SERVICE_ACCEPT or disconnecting the message SSH_MSG_DISCONNECT, which terminates the TCP connection. If the TCP connection is not terminated, the server can be considered to have sent an accept message to the client. Measuring the size of messages accepted by the server is also an example of information disclosure. This is the key to how Zeek infers successful SSH authentication to generate ssh_auth_successful events.

After authentication is complete, the client initiates another service request to the server. Unlike the first service request of type ssh-authuser, the second service request is of type ssh-connection. Similarly, if the server accepts a service request from the client, a service acceptance message will be sent instead of a disconnect message. Swap connection protocols as shown in the purple box in the figure above. These messages are used to make specific requests, such as a PTY session for interactive login, an X11 session for X11 Forwarding, or a session for SFTP. Measuring the packet size in the SSH protocol can also be used to infer the type of session established between the client and the server, such as having an easily identifiable packet size when detecting file uploads.

SSH related events in Zeek

By understanding the different states of the SSH protocol and packet size, you can understand when Zeek generates ssh_auth_successful and ssh_auth_failed events. The code also shows the logic generated by events that start with generate_ssh_auth_ in the SSH parser.

Looking at previous code submission records reveals the source of inspiration, and the history of the SSH.cc file shows that the current code logic was added four years ago. The logic in the ProcessEncrypted function can be summarized as follows:

1. Determine the size of the server's SSH_MSG_SERVICE_REQUEST packet, marked as Auth service accept

2. Determine whether the unauthenticated state of the client (marked as Optional auth request (none) in the figure) causes the server to issue a response of SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE. Successful authentication will be 16 bytes smaller than the packet in step 1. There will be differences in the size of failed packages.

3. Before the success message is sent to the client in step 2a, determine whether the server has sent the optional Banner marked Optional banner in the figure.

4. Check the response packet size of the server to the second authentication attempt of the client marked Auth request (publickey) in the figure a. Successful authentication will be 16 bytes smaller than the packet in step 1. The size of the failed packet is the same as that of step 2b

This shows how Zeek inferred that authentication was successful, but not yet how to infer that authentication failed. Ssh_auth_failed events are never triggered by SSH protocol parsers, but by Zeek scriptland. This code shows that the ssh_auth_failed event is triggered once the SSH connection is about to expire in Zeek Core. Any SSH connection that completes without triggering a ssh_auth_successful event may trigger the ssh_auth_failed event. Recall that in the previous section, the ssh_auth_failed event was used to count between the requesting host and the responding host, comparing it to a set threshold.

Back to brute force cracking

Recently, Corelight Labs analyzed a set of details about SSH packets collected from a medium-sized network. The dataset includes the host numbers, port numbers, timestamps, and packet sizes of anonymous remote hosts and local hosts. In the process of our analysis, we soon found that we only need to check the size and ordering of packets to maliciously infer the connection behavior, even encrypted traffic.

To describe this discovery, we first divide the dataset into different sessions, and then represent the session as a graph. These graphical representations are conceptually similar to the SPLT analysis used by 喜悦.

The following figure is an example of an authentication attempt. The X axis is the time, red indicates the packet size sent by the local host, and blue indicates the packet size sent by the remote host. This example is an attempt by remote host 1 to violently crack local host 66. The local host 66 may be configured to respond to a delay before the client authentication attempt fails, as evidenced by the gap between small packet exchanges. The big data package at the beginning of the session may reflect the initial key exchange, that is, the kex_algorithms in the figure above.

The following figure is an example of a successfully connected SSH session where the local host has been successfully authenticated by the remote host and begins to transfer data to the remote host. The size of the PDU generated by the local host may be larger than the MTU of Ethernet, and the packet size in the figure is always close to 1500. Assuming that all this is successful, the remote host 78 belongs to the infrastructure of GitHub, and this SSH session may be used to transfer some small files.

The following two pictures are graphical representations of a large amount of data transferred over a long period of time after successful authentication. The first figure shows an example of a SSH session in which the client transfers a large amount of data, and the second shows an example of a SSH session in which the server transmits a large amount of data.

This is one of the many ways that Zeek provides visibility into encrypted communications. Simply encrypting the transmitted content does not prevent all analysis methods. Many of the concepts discussed in this article can also be used in TLS, and some studies have also focused on HTTP. In addition, other studies have shown that packet analysis can be used to identify the size of SSH_MSG_CHANNEL_REQUEST packets that contain requests for Shell or pty access.

This is the answer to the question about how Zeek provides the perception of encrypted communications. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.