add reverse_dns stager

[busterb]

This is a note that @eik00d has written a reverse_dns file dropper that would be interesting to take advantage of in crafting some reverse_dns stagers (and meterpreter transport support). HT @viss

https://github.com/eik00d/Reverse_DNS_Shellcode/blob/master/dns_download_exec_svchost.rb

[Viss]

amusingly, the first result in the search here was a youtube video with this guys PoC running and staging up meterp over dns. suuuuuper excited to even have this on the radar :D

[eik00d]

Hi all! This droper making no sense for merge since there is already a good TXT droper from Peter.

But on other hand we (with @max3raza) already have done transport support for meterpreter, and stager payload(x86 done, x64 in progress). It supports multiply clients sessions. Current tunnel is ipv6(stealth but slow). We are planning to add NULL/DNSSEC tunnel (less stealth, but much faster). We will release it in November (will present results at Zeronights conf) as a fully functional "beta" fork, but not sure how it can be merged into main Rapid7 tree correctly.. it will be a future problem. Project is open-source and if you want to help with merging or anything else, please feel free - curent dev forks are here https://github.com/defcon-russia/metasploit-payloads and https://github.com/defcon-russia/metasploit-framework (check stage0 branch)

[sempervictus]

@eik00d: Thank you! I took a peek over the master branches of those repos. The divergence is definitely no fun (you guys started this before recent changes in transport semantics), but i'm pretty sure its fixable. I went through something like that once recently converting the old names pipes implementation into the new one. It might be most sane to do that as a rebase with some changes int he middle once your version is working. The biggest concern seems to be the TLV crypto code and associated XOR changes. We can probably adable the handle struct in metsrv to deal with the DNS handle the same way it deals with the named pipe handles. @OJ: Could you take a peek at this? Its a hell of a lot further along than what i have atop dnscat's protocol.

[max3raza]

I have merged the latest changes from rapid7 to defcon-russia in try_merge branch. Also I have fixed compilation of metsrv after merge using a new transport implementation (but without handling pivoting). In the nearest time I am going to change dns server code for handling new packet structure and encryption scheme.

[sempervictus]

Hi Max, thank you. I went over the merge and it unfortunately undoes a ton of other critical work around transport crypto. We need to refactor a bit and implement a tlv crypt compatible session here. It doesn't have to handle encryption, but it does have to work compatibly.

I haven't dug into the meterp side as much yet, I need to walk your commits from the fork point to figure out how to neatly rebase. This is awesome work guys, the process of merging will be well worth it. Thanks again.

[sempervictus]

@eik00d @max3raza - i've gone through the stage0 branch and performed a rebase on what we have upstream. Could you guys review my branch and check for consistency and functionality? A couple of notes on the porting effort:

1. I cherry-picked commits from stage0 branch on top of 9a5d5eec2e6c (which was the original divergence point far as i could see)
2. I ignored commits which merged master into the branch, if work was done on the relevant code in those commits, it was lost
3. Once the cherry picks were completed, i rebased on top of current master
4. Merge conflicts were addressed in the rebase to the best of my understanding, but need review.
5. I left a couple of TODO notes around timeout related merge conflicts, but the timeouts need manual review. It looks like during the design process there was some safety buffered in for the high latency asynchronous transport, but these won't play all that well in all scenarios, so we'll need to audit them in order to have the higher values set when the transport in use requires them (all tunneled transports should do this anyway)
6. Completely separate from the code, we probably want to audit for "questionable language" in some of the strings here, since i'm probably not the only reviewer who knows Russian ;-).
7. This has had zero testing, i dont know if framework will even start on this codebase, nor would i make any assumptions about the safety of said code. Lets get some human eyes on this.

@busterb, @OJ: could you gents also review that branch to ensure i didnt cut out cryptotlv code or other relevant pieces as i went through it? We need a similar effort on Meterpreter repo, but before that happens we need to undo the sockets breakage nightmare (which i currently suspect lives in the select(...) call in the C code).

@defcon-russia folks: If you guys find that branch to be stable, could you fork from there and continue changes at that point? The original code cant be merged as is because there were merges into it which made changes to components we cant live without. I removed some debug print stuff, and ideally after another cleanup round or two, we would diff that branch as a single commit atop the stable code to reduce git churn on dropped lines.

[max3raza]

Hi @sempervictus , I have checked your branch and have found that in the file lib/msf/core/payload/transport_config.rb we have 2 occurences of def transport_config_reverse_dns(opts={}) . The first one is valid, the second one have to be removed. Other changes looks like ok. The tunneling is not working now - connection is closed after getting machine id. And it doesn't work on my merged branch as well. So I believe this issue is not linked with missed changes during merge.

[sempervictus]

Thanks Max, I can clean it up, or if you want to pull on my branch, please do. Far as breakage, 90% chance its from recent tlv changes for crypto and tunneling. It looks like you guys used indirection through wrap_aes here (l5), whereas upstream is using l7. Still working out the use of sockets here. One thing you may be able to use is the native DNS implementation I did a while back - an actual DNS server is included which can serve as a base handler. I'll be digging some more today, the c side is even more confusing :-). Thanks for staying with this, any luck and we'll have you prepped to merge by your presentation.

[max3raza]

@sempervictus I have fixed tunneling in my branch(migration still doesn't work - but it is other problem). The root cause was a typo when I added debug messages. But this typo doesn't exists on your branch. So I will figure out what is the difference. Btw, I and @eik00d have a concern about our dns server - it is standalone dns server that performs tunneling between metasploit framework (tcp transport) and meterpreter (dns transport). So it doesn't look well applied for the current framework concept.

[OJ]

I'll have a gander at this today! Cheers everyone for your efforts so far :)

On Sep 19, 2017 05:41, "Max" notifications@github.com wrote:

@sempervictus https://github.com/sempervictus I have fixed tunneling in my branch(migration still doesn't work - but it is other problem). The root cause was a typo when I added debug messages. But this typo doesn't exists on your branch. So I will figure out what is the difference. Btw, I and @eik00d https://github.com/eik00d have a concern about our dns server - it is standalone dns server that performs tunneling between metasploit framework (tcp transport) and meterpreter (dns transport). So it doesn't look well applied for the current framework concept.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rapid7/metasploit-framework/issues/8962#issuecomment-330333859, or mute the thread https://github.com/notifications/unsubscribe-auth/AABw4DDfEzsJMAhfK-DfzGUZeWlhz4X2ks5sjsdUgaJpZM4PXP-e .

[OJ]

The transport code should use the .merge(timeout_config(opts)) to include the timeouts in the same way the others do.

[OJ]

I assume the x64 version of DNS is on the todo list once the x86 version is solid?

[OJ]

I assume that LHOST refers to the domain name used to do the resolution, and NHOST is the nameserver? Am I right in thinking that leaving NHOST blank means to use the default internal resolvers on the target?

I'd prefer to see the URL for the DNS transport to encode more of the options, given that they're important to the transport. For example:

dns://<domainname>@<nsnameorip>:<port>/<serverid>

This would also remove the need to put anything extra on top of the standard options as far as custom config goes, and reduce the number of new TLVs that need to be passed around.

[OJ]

Will we be renaming windows/reverse_windns to windows/reverse_dns or is there a reason for the extra win in the name?

[OJ]

Thanks again to everyone for the work they've put in so far. Pardon the github spam and questions.

I assume we don't have any Meterpreter code ready yet, and hence someone needs to smash that out? Do we have any documentation on the "protocol" for data transmission in both directions other than the source code of this PR (which is one direction)?

Thanks!

[OJ]

The client_id appears to be hard-coded to '0', and doesn't appear to be used anywhere. Can someone please explain its purpose? I assume it has something to do with identifying the endpoint, but I would have assumed that the session GUID would be used for that instead?

[eik00d]

The transport code should use the .merge(timeout_config(opts)) to include the timeouts in the same way the others do.

Yes, will do that

I assume the x64 version of DNS is on the todo list once the x86 version is solid?

x86 is done, x64 in dev right now 8)

I assume that LHOST refers to the domain name used to do the resolution, and NHOST is the nameserver? Am I right in thinking that leaving NHOST blank means to use the default internal resolvers on the target?

I'd prefer to see the URL for the DNS transport to encode more of the options, given that they're important to the transport. For example:

dns://domainname>@<nsnameorip:/ This would also remove the need to put anything extra on top of the standard options as far as custom config goes, and reduce the number of new TLVs that need to be passed around.

This is good idea, just some re-factoring... will prioritize that after x64 will be done.

Will we be renaming windows/reverse_windns to windows/reverse_dns or is there a reason for the extra win in the name?

Do not remember a reason already 8) Will remove "win" part.

The client_id appears to be hard-coded to '0', and doesn't appear to be used anywhere. Can someone please explain its purpose? I assume it has something to do with identifying the endpoint, but I would have assumed that the session GUID would be used for that instead?

Yes client_id is needed to support multiclient sessions, by default it is '0', which telling DNS server that this is new client, and then DNS server will register that client and generate new client_id for him. GUID also was a plan, but problem with size. Bigger client-Id - less data you can put in DNS request from meterpreter. So we have deiced to use one-byte ID instead.

Thanks again to everyone for the work they've put in so far. Pardon the github spam and questions.

I assume we don't have any Meterpreter code ready yet, and hence someone needs to smash that out? Do we have any documentation on the "protocol" for data transmission in both directions other than the source code of this PR (which is one direction)?

Thanks!

No, thank you for your time and review! We will try to make it right 8)

Meterpreter code is 'very dirty' but ready and working: https://github.com/defcon-russia/metasploit-payloads/tree/stage0/c/meterpreter/source

No documentation, only source code. The reason why code is so dirty and no documentation - because this project is chaotic and we did a lot of changes in protocol and logic during development (because it was not clear before, and we had to test different ideas). Right now it is more or less clear - how we want to do tunnel and sessions, and we will document it when beta will be ready.

[eik00d]

@sempervictus , for DNS in ruby still many questions. We wanted to use your code, but have decided to do Python DNS Proxy server, since anyway it's run separate from MSF, which is probably not a best design, but at least it is a normal use-case scenario for pen-tests. Thank you for you review and help with merging issues!

[max3raza]

@sempervictus I have created PR for small cleanup and removing duplicated method definition that was mentioned above. By the way, all works identically for as we have before merge( and migration as well) - for metsrv used "try_merge" branch of defcon-russia repo.

[eik00d]

@sempervictus @max3raza are you sure that you took code from stage0? I see my old bugs, for example with timeout: https://github.com/sempervictus/metasploit-framework/blob/rebase-defcon_ru-dns_transport/lib/msf/base/sessions/command_shell.rb#L96 and in stage0 it is different(right): https://github.com/defcon-russia/metasploit-framework/blob/stage0/lib/msf/base/sessions/command_shell.rb#L96

I think this is one of the reasons why everything works strange...

[eik00d]

Ah i see..

I ignored commits which merged master into the branch, if work was done on the relevant code in those commits, it was lost

[eik00d]

Dunno where to ask, but while merging we have issues with spawn threads (for MeterpreterReciever). Sometimes, after migration, when bind handler trying to spawn new MeterpreterReciever it's failed. No thread spawned at all. This is happens 1 time from 10... or something. Not sure where is a bug, maybe you have seen this before...

Other than this code almost migrated, few features and "todos". I think we need more of your help... if possible

[fsacer]

what's the state of DNS staging support in metasploit?

[eik00d]

@fsacer Hi, to be honest: not sure. The latest "almost stable" release was in our repo one year ago (https://github.com/defcon-russia/metasploit-payloads and https://github.com/defcon-russia/metasploit-framework, howto and demo: http://asintsov.blogspot.com/2017/12/data-exfiltration-in-metasploit.html )

But i was not able to merge it into Rapid7 easily, since... to be honest, i am very bad at Ruby at Metasploit internals 8)) We need help of community .. as I remember @sempervictus was tried to help us, but not sure what is a current situation. From my side: I will try to update our repo, fix few bugs and make our fork updated to current version.. but if there too many internal changes, then it will be not very fast. So that is how i request help from the MSF community if this module still valuable, of course 8)

[sempervictus]

My work on this has been stalled for a while too, but I do have the low level protocol decoders and async header/data segment pipeline pieces. I probably need a solid 8h to wire them into an updated async packet handler implementation for a semi-functional pure ruby mechanism. As Alex said, the code works as these guys wrote it with the python bridge. It doesn't look like grampas txt record streams on NIDS either, so a useful proof of function on engagement.

[dogasantos]

@eik00d

if this module still valuable

It IS valuable. More than that, it is remarkable. More and more we see servers with no outbound direct internet communication (not a single port, nor http/s). If we can create a DNS tunnel and pass all meterpreter commuincation through that tunnel, this would be amazing. This means freedom and it's probably the "safe card" we'll have in hands for worst case scenarios. So if you ask me, your work has a special place in the main repo. I'm just waiting ancious for that, and I remember your project everytime I see a situation like described (as I am now).

[eik00d]

Thx for moral support 8) We have updated our fork with all commits from Rapid7 master. So it is updated... but it is still not clear how to move this into main fork of Rapid7.

[fsacer]

it would probably best get the commits that changed stuff and apply those on seperate fork and make pr

[sempervictus]

I recently spoke with OJ about some of the complexity in session/transport wiring for framework around having a C2 transport which is not only async, but requires header/data processing mechanisms that arent semantically equivalent to the synchronous stuff plumbed into HTTP encoding for instance. The current train of thought is that i finish jury-rigging the packet parsers atop logic internal to the transport handler instead of a generic/framework-wide fix for the problem, and we revisit it down the line once we have something working. I have some time blocked off this weekend to address the http proxy and meterp ssl PRs, will add another push on this front to that list (lets see if i can get something PR-able).

[jeffmcjunkin]

Poking quite an old threat -- what's the state of DNS communications for Metasploit? At this point does it make sense to go for stageless DNS payloads first?

[Viss]

hi, checking in four years later. i dont suppose there's been any news or updates with regards to adding dns c2 to meterp?

[sempervictus]

There's an implementation by the defconrussia folks, but relies on an external piece of middleware. I've been out of the game for quite a while in terms of serious msf development... but did get the initial packet handling for that working natively in Msf/Rex somewhere. There's a bigger discussion about this in the issues section debating how to handle third-party session types.

[jeffmcjunkin]

At this point it might make more sense to tie in explicit support for https://github.com/FSecureLABS/C3, so that DNS and other transports can be supported outside the MSF repo, and Rapid7 stays responsible for a sane transport plugin. Just my outsider opinion.