ie_unsafe_scripting.rb exploit module

[natron at invisibledenizen.org (natron)]

Sure, my first thought when I decided to write this module was to
build an aux module that would:

1) Hook the browser via a remote javascript include (e.g. XSS anywhere
on the web) or a regular HTTP GET
2) Perform intranet scanning for XSS
3) Setup a page to bounce to the XSS vuln linked to the
ie_unsafe_scripting exploit module, then direct the browser to it

The code to hook could be taken from any of the various AJAX libraries
and/or XSS exploit tools.  For XSS testing my plan was to take the
fingerprints out of Nikto, modify them to do a remote call upon js
execution so we know we found an XSS hole, and then use invisible
iframes to start launching XSS tests.  The problem is how to identify
the hosts you want to scan.

The main reason to look for intranet XSS holes is to try to leverage
the elevated trust given by IE to servers in the Intranet zone (be it
for ie_unsafe_scripting or any other future module that could do
something in Intranet but not Internet).  For a web server to get
classified there, you can't use IP addresses, so that method is out.

So you have to know the server name.  What are our options?

1) Just scan localhost for default apps running on default ports and
ignore external servers.  (Think workstation management apps, virus
scan consoles, stuff like that.)
2) Discover through unknown external methods (like identifying their
naming scheme through some webserver information disclosure, then
generating a list of permutations... or a compromised DNS server) and
have the mod import a file.
3) Pre-populate a list of guessed naming schemes.

How do you propose we do 3)?  That doesn't sound easy or very
successful.  In most environments I see, the naming schemes are all
over the map.


n

On Wed, Dec 17, 2008 at 12:12 AM, H D Moore <hdm at metasploit.com> wrote:
> Looks good, need to remove the SEH include and tweak some of the fields
> (Version to be $Revision:$), but would be happy to add it. A friend of
> mine had some suggestions for making the HTTP download more reliable as
> well (use up to four different objects).
>
> What are your thoughts on writing another module (or extending this one)
> to auto-exploit XSS in the intranet zone? Take a long, long list of
> hostnames and XSS methods and iterate through them all, hoping one or
> another hits. A really nice/easy vector could be printer administration
> interfaces -- there are XSS bugs in nearly all of the
> JetDirect/Ricoh/Xerox products and printers tend to have generic names (as
> do switches, backup NAS devices, etc).
>
> -HD
>
> On Tuesday 16 December 2008, natron wrote:
> > I've recently come across environments that have the "Initialize and
> > script ActiveX controls not marked safe for scripting" configured to
> > run without prompt for the 'Intranet' or 'Trusted Sites' zones.  This
> > grants access to WScript.Shell, so my first thought was to add a
> > little code to ie_createobject, but I discovered that the unsafe
> > scripting settings doesn't grant access to the MSXML.XMLHTTP, so a
> > warning dialog still popped.
>
>
> _______________________________________________
> http://spool.metasploit.com/mailman/listinfo/framework