You can clone with
No one assigned
I noticed some interesting behavior when testing some IE exploits on a variety of hosts (XP with IE8, WIn7 with IE8, Win7 with IE9).
Clients are configured to use a proxy, capable of doing SSL inspection (mitm).
When SSL is enabled for the exploit, the proxy will intercept and sends a slightly diffferent user agent to the msfconsole webserver... different enough to make msf bail out and tell it's not a supported platform.
What I have discovered is that the browser version is wrong, but the windows version is correct:
Actual version What metasploit sees
XP SP3 with IE7 MSIE7 / NT 5.1
XP SP3 with IE8 MSIE7 / NT 5.1
Win7 with IE8 MSIE7 / NT 6.1
Win7 with IE9 MSIE7 / NT 6.1
If the IE8 target (which usually is based on a msvcrt.dll ROP chain) works on IE7 too, then the exploit can be successful in an increased number of cases, if the IE8 payload is used for MSIE7 / NT 5.1 at all times
For the non-existing combination of MSIE7 / NT 6.1, it would be good enough to send the IE9 payload. It's somewhat slower, but at least it will give a shell and not a crash.
For non SSL sessions, the UA is correct.
Do you have a record of the actual user-agent strings and what generated them? That'd be nice to have.
Is this User-Agent mutation proxy product specific, or something that IE is doing for some reason?
Opened this as a Redmine bug https://dev.metasploit.com/redmine/issues/7244
I wanna know if that's proxy specific, too. Maybe every proxy product behaves a little differently.
is this the ie compatibility mode?http://blogs.msdn.com/b/askie/archive/2009/03/23/understanding-compatibility-modes-in-internet-explorer-8.aspx
Emulate IE7 mode causes IE8 to do three things:
1) Use IE 7 Standards mode for standards mode document
2) Send the IE7 User agent string
3) Sets the right internal parameters to process conditional comments as IE 7 would.
As you can see, it does more than just setting the HTML document’s compatibility-mode.
yeah, it's proxy specific - so it might be different for other products, but at least the Windows version component was accurate. It's definitely not compatibility mode (although the behavior looks similar, and the proposed technique might actually work too in case of compatibility mode)
User agents :
XP SP3 with IE8 :
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Win7 with IE8 and IE9 (same output)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)
I'm tracking the issue in here instead:http://dev.metasploit.com/redmine/issues/7244
Closing this out in favor of RM7244