时间：2018年10月19日
最近出了一个libSSH认证绕过漏洞，刚开始时候看的感觉这洞可能挺厉害的，然后很快github上面就有PoC了，msf上很快也添加了exp，但是在使用的过程中发现无法getshell，对此，我进行了深入的分析研究。
前言
搞了0.7.5和0.7.6两个版本的源码：[1]
360发了一篇分析文章，有getshell的图：[2]
Python版本的PoC到Github上搜一下就有了：[3]
环境
libSSH-0.7.5源码下载地址: [4]
PS: 缺啥依赖自己装，没有当初的编译记录了，也懒得再来一遍
|
1 2 3 4 5 6 |
$ 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函数[5], 看到第1211行：
|
1 |
1121 r=cb->callbacks[type - cb->start](session,type,session->in_buffer,cb->user); |
然后追踪到callbacks数组等于default_packet_handlers[6]
正常情况下，发送SSH2_MSG_USERAUTH_REQUEST请求，进入的是ssh_packet_userauth_request函数，而该漏洞的利用点就是，发送SSH2_MSG_USERAUTH_SUCCESS请求，从而进入ssh_packet_userauth_success函数
PS: 我们可以进入该数组中的任意函数，但是看了下其他函数，也没法getshell
正常情况下的执行路径是：
|
1 2 3 4 5 6 7 |
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中进行了设置:
|
1 2 3 4 5 6 7 8 9 10 11 |
// 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函数，由服务端的编写者设置的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// 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; } |
认证成功后的路径：
|
1 2 3 4 |
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;
利用该漏洞绕过验证，服务端的流程：
|
1 2 3 4 5 6 |
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函数：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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的情况下，reutrn结束该函数。这就导致了我们无法getshell。
如果想getshell，有两种修改方式：
1.删除sdata.authenticated变量
|
1 2 3 |
533 while (sdata.channel == NULL) { ...... 544 } |
2.把channel添加回调函数的代码移到循环之前
|
1 2 3 4 5 6 |
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分支下所有的分支:
|
1 2 3 4 5 6 7 |
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 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/720/