Metasploit-framework: android/meterpreter/reverse_tcp not working on Nougat

[Kitt3120]

Steps to reproduce

How'd you do it?

1. Create the payload apk file and uploaded it to my fileserver
2. Started the handler in background (All settings like payload and port are right)
3. Loaded the apk file onto my phone
4. Started it
5. The Meterpreter tries to handle the session but then fails (Reason: Died)

Everything is set up correctly. When I try it on my girlfriends phone (S4) with Lollipop then everything works fine. It's because my phone (S6 Edge) runs on Nougat I think. It could also be an app that blocks the connection, like my antivirus. But I disabled everything. And also, before updating to Nougat (so on Marshmallow) everything worked with my phone too.

Expected behavior

The handler should handle the incoming connection and create a meterpreter session

Current behavior

What happens instead?

The Meterpreter dies. After some seconds it also gives me an error that the session has been closed because the payload was not valid.

System stuff

Metasploit version

Framework & Console are version: 4.14.1-dev

I installed Metasploit with:

• [x] Kali package via apt
• [ ] Omnibus installer (nightly)
• [ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• [ ] Source install (please specify ruby version)
• [x] Other ? -> Katoolin... So it should be Kali's apt, right ?

OS

What OS are you running Metasploit on?

Linux Ubuntu, installed tools with katoolin (I somehow managed it without breaking my system, yay)

[timwr]

Strange, is this reverse_tcp or reverse_http? Can you reproduce with both?

[Kitt3120]

It was reverse_tcp. I will try Http, hopefully this will work. I will try at as soon as possible :)

[timwr]

I can confirm this. So confused :/

[busterb]

is it a stager incompatibility? I've never looked closely at how these work, but I wonder if it's something to do with aarch64

[timwr]

I can reproduce on armv7 and aarch64. The socket is being killed (not sure why yet) before the first command completes, but after staging has completed.

[timwr]

For some reason reverting this: https://github.com/rapid7/metasploit-framework/pull/7993/files fixes it ¯\_(ツ)_/¯

[busterb]

Hmm, that seems to have been the same commit that made port forwarding with Windows meterpreter over reverse_tcp show packets out of order. This is weird.

[timwr]

I'm still baffled by this. Why Android 7.0 only?
@pbarry-r7 any ideas?

[pbarry-r7]

Oof, not off the top of my head, @timwr. :/ I tried to keep that commit simple/focused on just changing the packet-timeout logic to account for arriving, individual frames as proof that the connection is still valid and working. But there could always be a bug, I'll review the code today.

[busterb]

Theory, we don't actually process packets strictly in the order in which they are received. Also, apparently the handler might not always be associated with a packet right away, in which case they get requeued for a second go-round:

+            #
 +            # Also, don't bother saving incomplete packets if we have no handler.
 +            if (!pkt.in_progress and ::Time.now.to_i - pkt.packet.created_at.to_i < PACKET_TIMEOUT)
                incomplete << pkt
              end

I think the change above modifies timing by creating some new objects to manage queued packets, which causes an already fragile system to fall down a bit more.

[pbarry-r7]

Good point, I do recall the recent discussion w.r.t. packet ordering. I'm very open to discussion on approaches to fix (e.g. sequence each packet by number, dispatch packets 'up' by order of first-arrived-frame instead of first-completely received, other ideas...) :)

[Kitt3120]

Hey! Sorry for not answering for the past days. I will be online more often at the weekend again.

[timwr]

@Kitt3120 don't worry about it, thanks for reporting.
I'm still confused as to why this only affects Nougat (and only Android).

Also (stupid question perhaps) shouldn't tcp ensure the packets arrive in the correct order?

[Kitt3120]

I think that's one thing tcp should do. Hopefully it does. I will test the bind_tcp later.

[pbarry-r7]

Y'all are right about TCP, @timwr and @Kitt3120. My expectation is that TCP is "doing the right thing" for us w.r.t. managing missing and out-of-order frames when they happen on the connection between Meterpreter and MSF. I believe the issue is (and @bcook-r7 can correct me if I'm off here) above the transport layer, that MSF's code for receiving packets has an opportunity to "dispatch" completely-received TLV packets in a mis-ordered fashion to the registered consumers. And that my recent changes may have exacerbated that "chance of out-of-order" condition.

[netship01]

Same here on Android 7.1.1 meterpreter shell died just after shell created.

[busterb]

I reverted the bits in #8250. Seems that how packets are queued on the network affects whether this triggers or not.

[adithyan-ak]

Issue close and hw the fck can i cmnt?

[sameerphad72]

Security Patched in Android 7.0

[adithyan-ak]

@Sameer, But my mobile is Arch64 and Android 7.0 and meterpreter works fine with my device... I guess, getting meterpreter depends on Architecture!

[mmaae]

why meterpreter not working with Android nougat Android 7.0 - Linux 3.18.35+ (aarch64) ?
plz help me about this
any android run fine
but android 7 & 8 not work ( only help command and sysinfo )