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

This article shows you how to carry out OpenSSH user enumeration vulnerability CVE-2018-15473 analysis, the content is concise and easy to understand, can definitely make your eyes bright, through the detailed introduction of this article, I hope you can get something.

Introduction

This vulnerability does not generate a list of valid user names, but it allows an attacker to guess the user name. At present, the details of this OpenSSH user enumeration vulnerability (CVE-2018-15473) have been uploaded to GitHub, and students who are interested can check the [portal].

In this article, we will conduct an in-depth analysis of the vulnerability and provide some feasible mitigation solutions.

Technical details

This vulnerability exists in some authentication functions implemented by OpenSSH. First of all, let's take a look at the public key authentication vulnerability of Ubuntu OpenSSH.

By sending a malicious public key authentication message to an OpenSSH server, an attacker will be able to obtain specific user name information. If the user does not exist, the server will send an authentication failure message to the client. If the user exists, the message cannot be parsed and the communication is terminated, that is, the communication connection is disconnected without any message being returned. Exploit code for this vulnerability can be obtained from this Python PoC script: [portal].

This vulnerability exists because the user queries a user name that does not exist before the server fully parses the message. To fix this vulnerability, it is also easy to follow the attack logic in reverse: first fully parse the message, and then establish a communication connection.

One way to test vulnerabilities to exploit PoC is to open the OpenSSH server in debug mode:

Then run the PoC script with an existing valid user name:

The error message will be viewed on the server side:

Relevant error messages can also be found in / var/log/auth.log:

If the message cannot be parsed correctly, the communication between the client and the server will be interrupted, and the prompt message sent by the server will not be received when the message is interrupted:

Notice the last packet marked in pink (client packet), and there is no subsequent blue packet (server packet).

When the PoC script runs with a user name that does not exist:

The "imcomplete message" error message will not pop up:

Notice the blue server packet at the end of the communication data.

This is the whole process that this vulnerability (public key authentication vulnerability) exposes a valid user name.

Among them, the userauth_pubkey function is one of the functions implemented by the authentication function, which is specially used to complete authentication according to the public key. If authentication fails, "0" is returned, and "1" is returned for success. When the server receives the SSH2_MSG_USERAUTH_REQUEST request, the function is called, and the result is used to send back a SSH2_MSG_USERAUTH_FAILURE or SSH2_MSG_USERAUTH_SUCCESS message to the client.

The running logic of this function is:

1. If the user name does not exist: return "0"

two。 If the user name exists but the key is incorrect: return "0"

3. If the user name exists and the key is correct: return "1"

But someone found that we could actually stop the userauth_pubkey function between the first step and the second step. After the first step, the userauth_pubkey function gets the message string from the client, and if the fetch fails (caused by a malicious string), the whole process is terminated and the connection is closed without sending any postback messages.

The results of packet_get_string are as follows:

If the user name exists, the first step is done after the program has extracted the data from the message domain.

The first extracted data field is a Boolean (1 byte), and the corresponding function is packet_get_char (). If the authentication type is publickey, the return value is "1". This is followed by two strings: the algorithm and the key. In a SSH message, the string is encoded with a length-value key-value pair, with a string of 4 bytes.

The function packet_get_string, which extracts a string from a message and validates it, relies on another function: ssh_ssh_packet_get_string.

The ssh_packet_get_string function calls the sshpkt_get_string function, and if the value returned is not "0", it also calls the fatal function. The function fatal logs fatal error events and then terminates the generated OpenSSH process (no error messages are sent back).

Then the sshpkt_get_string function is executed and the sshbuf_get_string function is called:

Then the sshbuf_get_string function calls sshbuf_get_string_direct:

Then sshbuf_get_string_direct calls sshbuf_peek_string_direct:

Finally, sshbuf_peek_string_direct does string validation:

If the remaining data in the message is less than 4 bytes, or if the remaining data in the message is less than the string length, a SSH_ERR_MESSAGE_INCOMPLETE error message is returned. This is what our previous Python PoC script was going to trigger. First, it establishes an encrypted communication link with the OpenSSH server and then sends malicious SSH2_MSG_USERAUTH_REQUEST messages to it. By redefining the add_boolean function, the Boolean range in the message is ignored.

When the function userauth_pubkey parses the malicious message, it first reads the Boolean range, and since this field does not exist, it will read the next field (function packet_get_char): the 4-byte length value of the encryption algorithm string. Then call the next function, packet_get_string, to read the encryption algorithm string.

The following is the process of parsing legitimate messages:

The following is the process of parsing malicious messages:

As a result, the code parses a 1907-byte string (0x00000773 in hexadecimal), which is longer than the length of the entire message, which causes ssh_packet_get_string to call the fatal function and interrupt the OpenSSH process.

This is a very hidden vulnerability, it is not a buffer overflow vulnerability, nor is it a remote code execution vulnerability, let alone an incorrect input validation vulnerability. There is no buffer overflow problem here, and all inputs are validated before use. The problem is that input validation is done after some functional processing.

The solution to the problem is also relatively simple: change the calling order of the function, that is, first verify the input, and then deal with the function.

The above content is how to analyze OpenSSH user enumeration vulnerabilities CVE-2018-15473. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.