作者：Hcamael@知道創宇404實驗室
時間：2018年10月19日
English version:http://www.bjnorthway.com/724/
最近出了一個libSSH認證繞過漏洞，剛開始時候看的感覺這洞可能挺厲害的，然后很快github上面就有PoC了，msf上很快也添加了exp，但是在使用的過程中發現無法getshell，對此，我進行了深入的分析研究。
前言
環境
PS: 缺啥依賴自己裝，沒有當初的編譯記錄了，也懶得再來一遍
$ tar -xf libssh-0.7.5.tar.xz
$ cd libssh-0.7.5
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ..
$ make主要用兩個，一個是SSH服務端Demo：examples/ssh_server_fork, 一個是SSH客戶端Demo：./examples/samplessh
服務端啟動命令：sudo examples/ssh_server_fork -p 22221 127.0.0.1 -v
客戶端使用命令：./examples/samplessh -p 22221 myuser@127.0.0.1
PS: 用戶那隨便填，我使用myuser，只是為了對比正常認證請求和bypass請求有啥區別，正常情況下SSH服務端是使用賬戶密碼認證，賬戶是: myuser, 密碼是: mypassword
修改../src/auth.c的ssh_userauth_xxxx函數，我修改的是ssh_userauth_password:
根據360的分析文章和我自己的研究結果，修改了上圖箭頭所示的三處地方，這樣./examples/samplessh就會成為了驗證該漏洞的PoC
PS: 修改完源碼后記得再執行一次make
漏洞分析
根據服務端輸出的調試信息，可以找到ssh_packet_process函數, 看到第1211行：
1121 r=cb->callbacks[type - cb->start](session,type,session->in_buffer,cb->user);然后追蹤到callbacks數組等于default_packet_handlers
正常情況下，發送SSH2_MSG_USERAUTH_REQUEST請求，進入的是ssh_packet_userauth_request函數，而該漏洞的利用點就是，發送SSH2_MSG_USERAUTH_SUCCESS請求，從而進入ssh_packet_userauth_success函數
PS: 我們可以進入該數組中的任意函數，但是看了下其他函數，也沒法getshell
正常情況下的執行路徑是：
ssh_packet_userauth_request ->
ssh_message_queue ->
ssh_execute_server_callbacks ->
ssh_execute_server_request ->
rc = session->server_callbacks->auth_password_function(session,
msg->auth_request.username, msg->auth_request.password,
session->server_callbacks->userdata);找找這個函數，發現在服務端Demo中進行了設置:
// examples/ssh_server_fork.c
......
514 struct ssh_server_callbacks_struct server_cb = {
515 .userdata = &sdata,
516 .auth_password_function = auth_password,
517 .channel_open_request_session_function = channel_open,
518 };
519 ssh_callbacks_init(&server_cb);
520 ssh_callbacks_init(&channel_cb);
521 ssh_set_server_callbacks(session, &server_cb);
......找到了auth_password函數，由服務端的編寫者設置的：
// examples/ssh_server_fork.c
static int auth_password(ssh_session session, const char *user,
const char *pass, void *userdata) {
struct session_data_struct *sdata = (struct session_data_struct *) userdata;
(void) session;
if (strcmp(user, USER) == 0 && strcmp(pass, PASS) == 0) {
sdata->authenticated = 1;
return SSH_AUTH_SUCCESS;
}
sdata->auth_attempts++;
return SSH_AUTH_DENIED;
}認證成功后的路徑：
ssh_message_auth_reply_success ->
ssh_auth_reply_success:
994 session->session_state = SSH_SESSION_STATE_AUTHENTICATED;
995 session->flags |= SSH_SESSION_FLAG_AUTHENTICATED;正常情況下，在SSH登錄成功后，libSSH給session設置了認證成功的狀態，SSH服務端編寫的人給自己定義的標志位設置為1: sdata->authenticated = 1;
利用該漏洞繞過驗證，服務端的流程：
ssh_packet_userauth_success:
SSH_LOG(SSH_LOG_DEBUG, "Authentication successful");
SSH_LOG(SSH_LOG_TRACE, "Received SSH_USERAUTH_SUCCESS");
session->auth_state=SSH_AUTH_STATE_SUCCESS;
session->session_state=SSH_SESSION_STATE_AUTHENTICATED;
session->flags |= SSH_SESSION_FLAG_AUTHENTICATED;可以成功的把libSSH的session設置為認證成功的狀態，但是卻不會進入auth_password函數，所以用戶定義的標志位sdata->authenticated仍然等于0
我們在網上看到別人PoC驗證成功的圖，就是由ssh_packet_userauth_success函數輸出的Authentication successful
研究不能getshell之謎
很多人復現該漏洞的時候肯定都發現了，服務端調試的信息都輸出了認證成功，但是在getshell的時候卻一直無法成功，根據上面的代碼，發現session已經被設置成認證成功了，但是為啥還無法獲取shell權限呢？對此，我又繼續深入研究。
根據服務端的調試信息，我發現都能成功打開channel，但是在下一步pty-req channel_request我服務端顯示的信息是被拒絕:
所以我繼續跟蹤代碼執行的流程，跟蹤到了ssh_execute_server_request函數：
166 case SSH_REQUEST_CHANNEL:
channel = msg->channel_request.channel;
if (msg->channel_request.type == SSH_CHANNEL_REQUEST_PTY &&
ssh_callbacks_exists(channel->callbacks, channel_pty_request_function)) {
rc = channel->callbacks->channel_pty_request_function(session, channel,
msg->channel_request.TERM,
msg->channel_request.width, msg->channel_request.height,
msg->channel_request.pxwidth, msg->channel_request.pxheight,
channel->callbacks->userdata);
if (rc == 0) {
ssh_message_channel_request_reply_success(msg);
} else {
ssh_message_reply_default(msg);
}
return SSH_OK;接著發現ssh_callbacks_exists(channel->callbacks, channel_pty_request_function)檢查失敗，所以沒有進入到該分支，導致請求被拒絕。
然后回溯channel->callbacks，回溯到了SSH服務端ssh_server_fork.c：
530 ssh_set_auth_methods(session, SSH_AUTH_METHOD_PASSWORD);
531 ssh_event_add_session(event, session);
532 n = 0;
533 while (sdata.authenticated == 0 || sdata.channel == NULL) {
534 /* If the user has used up all attempts, or if he hasn't been able to
535 * authenticate in 10 seconds (n * 100ms), disconnect. */
536 if (sdata.auth_attempts >= 3 || n >= 100) {
537 return;
538 }
539 if (ssh_event_dopoll(event, 100) == SSH_ERROR) {
540 fprintf(stderr, "%s\n", ssh_get_error(session));
541 return;
542 }
543 n++;
544 }
545 ssh_set_channel_callbacks(sdata.channel, &channel_cb);在libSSH中沒有任何設置channel的回調函數的代碼，只要在服務端中，由開發者手動設置，比如上面的545行的代碼
然后我們又看到了sdata.authenticated，該變量再之前說了，該漏洞繞過的認證，只能把session設置為認證狀態，卻無法修改SSH服務端開發者定義的sdata.authenticated變量，所以該循環將不會跳出，直到n = 100的情況下，return結束該函數。這就導致了我們無法getshell。
如果想getshell，有兩種修改方式：
1.刪除sdata.authenticated變量
533 while (sdata.channel == NULL) {
......
544 }2.把channel添加回調函數的代碼移到循環之前
530 ssh_set_auth_methods(session, SSH_AUTH_METHOD_PASSWORD);
531 ssh_event_add_session(event, session);
532 ssh_set_channel_callbacks(sdata.channel, &channel_cb);
533 n = 0;
534 while (sdata.authenticated == 0 || sdata.channel == NULL) {
......在修改了服務端代碼后，我也能成功getshell:
總結
之后我看了審計了一下ssh_execute_server_request函數的其他分支，發現SSH_REQUEST_CHANNEL分支下所有的分支:
SSH_CHANNEL_REQUEST_PTY
SSH_CHANNEL_REQUEST_SHELL
SSH_CHANNEL_REQUEST_X11
SSH_CHANNEL_REQUEST_WINDOW_CHANGE
SSH_CHANNEL_REQUEST_EXEC
SSH_CHANNEL_REQUEST_ENV
SSH_CHANNEL_REQUEST_SUBSYSTEM都是調用channel的回調函數，所以在回調函數未注冊的情況下，是無法成功getshell。
最后得出結論，CVE-2018-10933并沒有想象中的危害大，而且網上說的幾千個使用libssh的ssh目標，根據banner，我覺得都是libssh官方Demo中的ssh服務端，存在漏洞的版本的確可以繞過認證，但是卻無法getshell。
引用
- https://0x48.pw/libssh/
- https://www.anquanke.com/post/id/162225
- https://github.com/search?utf8=%E2%9C%93&q=CVE-2018-10933&type=
- https://www.libssh.org/files/0.7/libssh-0.7.5.tar.xz
- https://0x48.pw/libssh/libssh_0.7.6/src/packet.c.html#ssh_packet_process
- https://0x48.pw/libssh/libssh_0.7.5/src/packet.c.html#default_packet_handlers
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/720/
