Metasploit-framework: Exploits with single-host RHOSTS not interacting with sessions

[wvu-r7]

msf5 exploit(bsd/finger/morris_fingerd_bof) > run
[*] Exploiting target 127.0.0.1

[*] Started reverse TCP handler on 192.168.1.2:4444
[*] 127.0.0.1:7979 - Connecting to fingerd
[*] 127.0.0.1:7979 - Sending 533-byte buffer
[*] Command shell session 1 opened (192.168.1.2:4444 -> 192.168.1.2:65190) at 2018-10-05 01:32:42 -0500
[*] Session 1 created in the background.
msf5 exploit(bsd/finger/morris_fingerd_bof) > sessions -1
[*] Starting interaction with 1...

/usr/ucb/whoami
nobody

This is pretty annoying having to interact with the session manually. Only background jobs or multiple hosts should do this, IMHO. @Green-m? @busterb?

And why is there an extra newline after the first message?

9246, #10720

[Green-m]

My terrible fault, I misunderstood the code of @busterb, I would fix it right now.

About the newline issue, I am not sure what is the reason.

[wvu-r7]

It's okay, @Green-m. It's just code. :)

I'm not strictly opposed to this behavior, since one might want to use other modules before interacting with the session - though maybe single-host RHOSTS should be treated specially in certain cases. See the fallout in #10229, for example.

I'd definitely want to fix that weird whitespacing, though. I think a print statement is just out of place.

[wvu-r7]

Maybe -i can be cmd_exploit's "interact immediately" option. :)

[Green-m]

Thanks for your kindness. :)

I agree with you, the single host exploit should interact with the session once created, as it was before. And the multiple hosts exploit should not do the same behavior because the process may keep running for a while.

As for this issue, I did not test it for all scenarios, a mistake about the if judge.

[Green-m]

Maybe -i can be cmd_exploit's "interact immediately" option. :)

Maybe for multiple hosts? For now, it would not interact with a session during the multiple hosts exploit.

[wvu-r7]

It is tricky, but if we decide to keep backgrounding all RHOSTS jobs, -i when it's a single host would be nice. I haven't figured out the weird print yet.

[timwr]

I suspect the extra newline has always been there, it's just that [*] Exploiting target 127.0.0.1 is now printed before it happens.

[wvu-r7]

@timwr: That is my thought, but I cannot find the blank line yet!

[wvu-r7]

The line appears to be queued up. It's printing only once when I manually run exploit_simple.

[timwr]

https://github.com/rapid7/metasploit-framework/blob/master/lib/rex/ui/subscriber.rb
print_blank_line if user_output.prompting?
?

[wvu-r7]

Good find! That's it. Specifically print_warning for me because I'm testing loopback.

[wvu-r7]

Oh, shame. I was working in that file just a couple days ago, but it was in the input section at gets. 😅

[wvu-r7]

@Green-m: I'm afraid there's no easy fix here. We either leave it or remove it. (:

[wvu-r7]

I'd argue that the message is a little redundant right after you've configured the target(s). But that's just me.

[wvu-r7]

msf5 exploit(linux/http/axis_srv_parhand_rce) > grep RHOSTS options
   RHOSTS   127.0.0.0/24     yes       The target address range or CIDR identifier
msf5 exploit(linux/http/axis_srv_parhand_rce) > run
[*] Exploiting target 127.0.0.0

~Eh, remove it. :)~ Looks better continuing the run:

msf5 exploit(linux/http/axis_srv_parhand_rce) > run
[*] Exploiting target 127.0.0.0

[!] You are binding to a loopback address by setting LHOST to 127.0.0.1. Did you want ReverseListenerBindAddress?
[*] Started reverse TCP handler on 127.0.0.1:4444
[*] Using URL: http://0.0.0.0:8080/BjnzkPtoyCPmaIh
[*] Local IP: http://192.168.1.2:8080/BjnzkPtoyCPmaIh
^C[-] Exploit failed [user-interrupt]: Interrupt
[*] Server stopped.
[*] Stopping exploiting current target 127.0.0.0...
[*] Control-C again to force quit exploiting all targets.
[*] Exploiting target 127.0.0.1
[!] You are binding to a loopback address by setting LHOST to 127.0.0.1. Did you want ReverseListenerBindAddress?
[*] Started reverse TCP handler on 127.0.0.1:4444
[*] Using URL: http://0.0.0.0:8080/Owl1QCn0ygdvE
[*] Local IP: http://192.168.1.2:8080/Owl1QCn0ygdvE
[*] Command Stager progress - 100.00% done (150/150 bytes)
^C[*] Server stopped.
[*] Exploiting target 127.0.0.2
[!] You are binding to a loopback address by setting LHOST to 127.0.0.1. Did you want ReverseListenerBindAddress?
[*] Started reverse TCP handler on 127.0.0.1:4444
[*] Using URL: http://0.0.0.0:8080/jdcSVxT4PJDw
[*] Local IP: http://192.168.1.2:8080/jdcSVxT4PJDw
^C[-] Exploit failed [user-interrupt]: Interrupt
[*] Server stopped.
[*] Stopping exploiting current target 127.0.0.2...
[*] Control-C again to force quit exploiting all targets.
^C[-] run: Interrupted
msf5 exploit(linux/http/axis_srv_parhand_rce) >

[Green-m]

@wvu-r7
See #10751

[Green-m]

msf5 exploit(linux/http/axis_srv_parhand_rce) > run
[*] Exploiting target 127.0.0.0

Eh, remove it. :)

I add this prompt in #10720 because I think it's maybe more readable when multiple hosts, especially want to stop some targets manually. Not sure it's a good approach.

[wvu-r7]

@Green-m: It looks a lot better with multiple hosts. I wouldn't want to remove something useful to work around a quirk in our console. We should attempt to fix the underlying behavior, not the symptom.

[wvu-r7]

Yes, I would absolutely keep it now that you've excepted single hosts from it. We'll sort out the console quirk later. Thank you!

[wvu-r7]

Thanks, everyone!!