ssh_login bugged on non-standard devices #9519

h00die · 2018-02-07T12:07:19Z

I had a few emails with @bcook-r7 about this, but at some point between #6731 and now, a bug was introduced into ssh_login. When going interactive on non-standard shell sessions, you get no feedback, and i doubt the inputs are being sent to the device, or other similar errors.

Working against OpenSSH Server

msf5 > use auxiliary/scanner/ssh/ssh_login
msf5 auxiliary(scanner/ssh/ssh_login) > set rhosts 192.168.2.75
rhosts => 192.168.2.75
msf5 auxiliary(scanner/ssh/ssh_login) > set username ubuntu
username => ubuntu
msf5 auxiliary(scanner/ssh/ssh_login) > set password ubuntu
password => ubuntu
msf5 auxiliary(scanner/ssh/ssh_login) > run

[+] 192.168.2.75:22 - Success: 'ubuntu:ubuntu' 'uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare) Linux ubuntu-desktop-14 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux '
[*] Command shell session 1 opened (192.168.2.117:46539 -> 192.168.2.75:22) at 2018-02-07 06:40:53 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -i 1
[*] Starting interaction with 1...

uname -a
Linux ubuntu-desktop-14 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Broken Juniper SSG5

This is the same device as in #6731

resource (juniper_ssg5.rc)> use auxiliary/scanner/ssh/ssh_login
resource (juniper_ssg5.rc)> set username netscreen
username => netscreen
resource (juniper_ssg5.rc)> set password netscreen
password => netscreen
resource (juniper_ssg5.rc)> set rhosts 192.168.1.1
rhosts => 192.168.1.1
resource (juniper_ssg5.rc)> exploit
[+] 192.168.1.1:22 - Success: 'netscreen:netscreen' ''
[*] Command shell session 1 opened (?? -> ??) at 2018-02-07 06:43:48 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -i 1
[*] Starting interaction with 1...

?
help
foobarbaz

I'll also note on this that the RECV light on the switch does not light up when the commands are sent (as it does each key press during a standard ssh client session). However, normal ssh works fine.

r@k:~# ssh netscreen@ssg5
netscreen@192.168.1.1's password: 
Remote Management Console
ssg5-serial-> ?
clear                clear dynamic system info
delete               delete persistent info in flash
exec                 exec system commands
exit                 exit command console
get                  get system information
mtrace               multicast traceroute from source to destination
ping                 ping other host
reset                reset system
save                 save command
set                  configure system parameters
telnet               Telnet other hostname
trace-route          trace route
unset                unconfigure system parameters
ssg5-serial-> 
ssg5-serial-> help
              ^------unknown keyword help
ssg5-serial-> foobarbaz
              ^-----------unknown keyword foobarbaz
ssg5-serial->

Broken Juniper SSG5 Emulator

The juniper ssh emulator is also not working any more (although it works against a standard ssh client). Id be more inclined to believe my python script was broken, but standard ssh client works fine.

r@k:/# ssh any@127.0.0.1
any@127.0.0.1's password: 
ssg5-serial->  ?
clear                clear dynamic system info
delete               delete persistent info in flash
exec                 exec system commands
exit                 exit command console
get                  get system information
mtrace               multicast traceroute from source to destination
ping                 ping other host
reset                reset system
save                 save command
set                  configure system parameters
telnet               Telnet other hostname
trace-route          trace route
unset                unconfigure system parameters

Connection to 127.0.0.1 closed.

vs

msf5 auxiliary(scanner/ssh/ssh_login) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf5 auxiliary(scanner/ssh/ssh_login) > set username any
username => any
msf5 auxiliary(scanner/ssh/ssh_login) > set password "<<< %s(un='%s') = %u"
password => <<< %s(un='%s') = %u
msf5 auxiliary(scanner/ssh/ssh_login) > run

[+] 127.0.0.1:22 - Success: 'any:<<< %s(un='%s') = %u' ''
[*] Command shell session 1 opened (127.0.0.1:44119 -> 127.0.0.1:22) at 2018-02-07 06:58:43 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -i 1
[*] Starting interaction with 1...

?

and the ssh side:

r@k:/MSF-Testing-Scripts# ./juniper_ssg5_ssh_emulator.py 
Read key: 60733844cb5186657fdedaa22b5a57d5
Listening for connection ...
Got a connection!
Successful login via Juniper backdoor CVE-2015-7755 <<< %s(un='%s') = %u
Authenticated!
*** Client never asked for a shell.

@bcook-r7 was able to confirm something similar but different against a Sun baseband controller

I'll also note it does seem to detect a valid login on the ssg5:

msf5 auxiliary(scanner/ssh/ssh_login) > run

[+] 192.168.1.1:22 - Success: 'netscreen:netscreen' ''
[*] Command shell session 2 opened (?? -> ??) at 2018-02-07 07:05:01 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > set password bad
password => bad
msf5 auxiliary(scanner/ssh/ssh_login) > run

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

The text was updated successfully, but these errors were encountered:

busterb · 2018-02-07T12:20:01Z

Nice! By the way, I did figure out how to access a few local Juniper and other targets (d'oh, they were just powered off), so we will be able do some local testing here as well.

busterb · 2018-02-08T05:22:59Z

I want to say the most substantial thing we did here was switch from a local fork of net-ssh to upstream https://github.com/net-ssh/net-ssh. net-ssh can also be used outside of Metasploit, so we can tell if this is an upstream issue, or something to do with how Metasploit is using it.

busterb · 2018-02-08T06:16:08Z

I think a common thread with these is the targets don't have real shells, but just implement a raw command dispatcher. Seems similar to ansible/ansible#30224

Currently reading the https://net-ssh.github.io/net-ssh/Net/SSH/Connection/Session.html#method-i-open_channel docs to see how to setup a raw session. I think @wvu needed this for an exploit module as well.

busterb · 2018-02-08T06:28:28Z

It looks like as long as we don't call the exec method on a session after we connect, this is sufficient for testing authentication. Net::SSH::CommandStream isn't going to work on these devices because it assumes you can invoke a shell.

busterb · 2018-02-08T06:59:02Z

Since the remote hosts here do not support the 'exec' channel type, we need to send_channel_request("shell", ...) to get a raw shell instead. There aren't wrappers in net-ssh for this, so CommandStream needs to do it directly I think.

busterb · 2018-02-08T07:01:53Z

This is the kind of thing we're looking for: https://github.com/mitchellh/net-ssh-shell/blob/master/lib/net/ssh/shell.rb#L153

busterb · 2018-02-08T08:33:53Z

@h00die I fixed this for my local targets in the above PR. Would you mind verifying locally?

@wvu this might address some issues you may have run into in the past as well.

wvu · 2018-02-21T02:17:45Z

#6612 (comment)

For the record (apologies for repeating myself), sending a shell channel request did not work for me with Fortinet. I received an "unknown admin user" error. I will give #9524 a test as soon as I'm able. Hopefully my code was just wrong.

Thanks!

h00die · 2018-02-23T02:26:54Z

@busterb you mentioned you found a screenOS. What hardware and screen os version? My SSG5 is still not working after patch.

msf5 auxiliary(scanner/ssh/ssh_login) > set rhosts 192.168.1.1
rhosts => 192.168.1.1
msf5 auxiliary(scanner/ssh/ssh_login) > set username netscreen
username => netscreen
msf5 auxiliary(scanner/ssh/ssh_login) > set password netscreen
password => netscreen
msf5 auxiliary(scanner/ssh/ssh_login) > run

[+] 192.168.1.1:22 - Success: 'netscreen:netscreen' ''
[*] Command shell session 1 opened (?? -> ??) at 2018-02-22 21:23:56 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/ssh/ssh_login) > sessions -i 1
[*] Starting interaction with 1...

?
ls
hello

busterb · 2018-02-23T02:44:59Z

SSG-520M-SH running 6.0.0r4.0

h00die added the bug label Feb 7, 2018

busterb mentioned this issue Feb 8, 2018

prefer 'shell' channels over 'exec' channels for ssh CommandStream #9524

Merged

9 tasks

busterb closed this as completed in #9524 Feb 21, 2018

h00die mentioned this issue Feb 23, 2018

Juniper post enum module #9614

Merged

6 tasks

wvu mentioned this issue May 30, 2019

SSH Exec Calls are not Universally Compatible #11905

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ssh_login bugged on non-standard devices #9519

ssh_login bugged on non-standard devices #9519

h00die commented Feb 7, 2018

busterb commented Feb 7, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

wvu commented Feb 21, 2018

h00die commented Feb 23, 2018

busterb commented Feb 23, 2018

ssh_login bugged on non-standard devices #9519

ssh_login bugged on non-standard devices #9519

Comments

h00die commented Feb 7, 2018

Working against OpenSSH Server

Broken Juniper SSG5

Broken Juniper SSG5 Emulator

busterb commented Feb 7, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

busterb commented Feb 8, 2018

wvu commented Feb 21, 2018

h00die commented Feb 23, 2018

busterb commented Feb 23, 2018