Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSH Exec Calls are not Universally Compatible #11905

Open
sempervictus opened this issue May 30, 2019 · 8 comments

Comments

@sempervictus
Copy link
Contributor

commented May 30, 2019

Steps to reproduce

How'd you do it?

  1. Run an ssh login scanner against a brocade ICX 6340
  2. Using proper creds, let it try to prove the attempt and start a session, get:
(2019-05-30)17:22 (S:0 J:0)msf  auxiliary(scanner/ssh/ssh_login) > exploit 

[+] [2019.05.30-17:35:35] 192.168.2.243:22 - Success: 'brocade:Brocade' 'Protocol error, doesn't start with scp! '
[!] [2019.05.30-17:35:35] No active DB -- Credential data will not be saved!
[*] Command shell session 1 opened (?? -> ??) at 2019-05-30 17:35:35 -0400
[*] [2019.05.30-17:35:35] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

This culprit code is in gather_proof method of lib/metasploit/framework/login_scanner/ssh.rb, returning empty as first line of the method fixes this problem and produces:

(2019-05-30)17:56 (S:3 J:0)msf  auxiliary(scanner/ssh/ssh_login) > exploit 

[+] [2019.05.30-17:56:53] 192.168.2.243:22 - Success: 'brocade:Brocade' ''
[!] [2019.05.30-17:56:53] No active DB -- Credential data will not be saved!
[*] Command shell session 4 opened (192.168.2.241:42971 -> 192.168.2.243:22) at 2019-05-30 17:56:53 -0400
[*] [2019.05.30-17:56:53] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

All ssh_session.exec calls in libraries or modules which do not explicitly, solely, target systems with full shells and SSH implementations, must be replaced with CommandStream implementations.

Tag @wvu-r7 @h00die

This section should also tell us any relevant information about the
environment; for example, if an exploit that used to work is failing,
tell us the victim operating system and service versions.

Expected behavior

What should happen?

Current behavior

What happens instead?

You might also want to check the last ~1k lines of
/opt/metasploit/apps/pro/engine/config/logs/framework.log or
~/.msf4/logs/framework.log for relevant stack traces

System stuff

Metasploit version

Get this with the version command in msfconsole (or git log -1 --pretty=oneline for a source install).

I installed Metasploit with:

OS

What OS are you running Metasploit on?

@wvu-r7

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

#9519 bites again.

@h00die h00die added the a2k19 label May 30, 2019
@sempervictus

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2019

@wvu-r7, are you pulling on this? I figure you'll wanna keep the offending code but move it elsewhere. Alternatively I can just clip the platform specific stuff from lib, but someone wrote this stuff.

@wvu-r7

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

I'll work on this today.

@wvu-r7 wvu-r7 self-assigned this May 31, 2019
@h00die h00die referenced this issue Jun 2, 2019
1 of 6 tasks complete
@wvu-r7

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

All ssh_session.exec calls in libraries or modules which do not explicitly, solely, target systems with full shells and SSH implementations, must be replaced with CommandStream implementations.

ssh_login does use CommandStream. The problem is LoginScanner::SSH tries to send exec channel requests to gather proof well before CommandStream sends its shell channel request. Brocade doesn't like this order of operations.

I don't think any LoginScanner should be executing hardcoded shell commands, especially before a session is created!

@wvu-r7

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

I'm hung up on deciding whether to refactor LoginScanner::SSH. Should we implement a way to defer such proof gathering? Should I remove that code altogether?

@h00die

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

At the very minimum, make it an advanced option to skip to so at least breaking things can be avoided?

@wvu-r7

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

Let me finish with #12021, and I'll go fix this.

@wvu-r7

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

I can't simply make it an option, since that's not how LoginScanner works. Proof gathering is currently opaque to the module. That is why I've been waffling on how to fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.