Alert: Secured IIS Project
From: Russ (Russ.Cooper@RC.ON.CA)Date: 07/20/01
- Previous message: Bill Sobel: "Re: Remote DoS attack against SSH Secure Shell for Windows Servers Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-ID: <E9A01F52DC939448BBDE44ED2E1C468F167A12@muskie.rc.on.ca> Date: Thu, 19 Jul 2001 22:39:50 -0400 From: Russ <Russ.Cooper@RC.ON.CA> Subject: Alert: Secured IIS Project To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
-----BEGIN PGP SIGNED MESSAGE-----
I'm beginning a new effort, the goal of which is to try and get all
IIS boxes on the planet secured against the more important exploits.
There's an opportunity for you to contribute to this effort. I need
programming assistance and, more importantly, the contribution of
your logs. This certainly isn't an attempt to take away from the good
work done over at Dshield.org, however their efforts are intended to
look for different things, trends, script kiddies, etc...
1. Secured IIS Project
2. New information about the worm
3. A few words about Responsible Disclosure
1. Secured IIS Project
The "Friday the 13th" worm (because it was first seen on Friday the
13th) provides us with an opportunity to reach out to all of the
people who run IIS but don't patch their systems. Anyone who receives
a connection attempt from a box compromised by the worm, and is
patched, will have a record of the attempt in their IIS logs. Of
course those of you who employ IDS or any sort of packet sniffing can
catch attempts as well.
I certainly hope that you, the NTBugtraq subscribers, will be
patched. Therefore, you will be able to get log info about others,
infected IIS boxes, who are attacking your machines.
With IP addresses of attacking machines I will then proceed to try
and personally contact the owner of the machine. I realize its an
incredible effort, and its not likely going to be a quick one either,
but its the only way to ensure that boxes are patched and the worm is
stopped.
Those that I can contact will be told of their machine's activity.
We'll verify whether or not their machine is executing an attack, and
if it is we'll stop it and patch the box. If it isn't, we'll
determine if it was vulnerable and get it patched if it is.
We'll make an effort to verify any submitted attacking IP addresses
to eliminate fraudulent claims. We'll err on the side of the accused,
until we get 5 or more reports of the same address from different
sites.
If we're unable to contact the owner, or the owner refuses to correct
the actions of his/her machine, the address will go into a list of
attacking IP addresses that anyone can use to black hole. In general
the concept of black hole'ing addresses means the system is failing.
In this case, due to the ease with which the worm can spread, it
seems a necessary step in trying to prevent your networks from
receiving worm infection attempts. Further, there's no reason why a
more virulent or devastating worm might not arise.
I've got an idea for an IIS ISAPI filter that will just log. Done
right it will be the first thing to see any connection attempt and so
will log regardless of what hits the box. There'll be a parser to
filter the logs for only those entries that are of interest, and a
plain text rules file that allows you to see what the parsing is
based on. I don't want any of your privileged information, only the
IP address, date/time, and URL submitted.
After that information is parsed it'll be sent, via email, to a
repository. From there it will be analyzed, the owner of the IP
address identified, and so on.
We'll find some way to put up aggregate statistics on the web site so
others can see how effective this effort is, and how widespread the
problem is.
In summary, NTBugtraq is ineffective. Microsoft Security Bulletin
Notification service is ineffective. WindowsUpdate is ineffective.
CNet, IDG, ZDNet, MSNBC, Wired, are all ineffective.
Unfortunately there are some naive people around who think that
everyone thinks of security like they do. I'd argue that fewer than
5% of all people who run a server that has IIS on it actually think
about security at all. Its been this way for eons, and its the reason
its hard to convince Vendors to pay as much attention to security as
we security geeks think they should. If customers don't demand it,
aren't willing to pay for it, then its not as high a priority as we'd
like.
So its not rocket science to realize that even a month after a patch
has been made available, the majority of boxes that are vulnerable
aren't patched. The majority of boxes that are vulnerable will go
their entire life unpatched, unless some piece of new software
installed on the box patches it for them. I hope to see this project
extend into some way of ensuring that patches and configuration
changes get done on all boxes that need them, even for people who are
currently unaware or unconcerned about security.
2. New information about the worm
Remember, this worm cares not whether the box its attacking is an IIS
box or a router. Reports on SecurityFocus' Bugtraq mailing list
indicate that some routers are experiencing problems when sent the
worm attack string.
Further, reports I have received as well as some personal experience
with infected machines (not mine) suggests that the worm may not be
effective against IIS 4.0 boxes. Instead, when the URL is received
the web services stop. Its reasonable to assume that the very small
shellcode it uses might not work properly across all vulnerable
platforms. So if you are experiencing web services stopping
repeatedly, its likely because of the worm.
The most effective way of stopping the worm instantly is to remove
the mappings for .ida and rebooting the box. I'm working on a
scriptable way to remove the mappings (help would be appreciated).
MetaEdit isn't runnable from a command line, so some other method is
required to modify the Metabase.
Placing the C:\NOTWORM file (any file called NOTWORM should do) will
stop the worm processing, but this won't prevent your machine from
stopping the web services or being infected by other worm attacks.
Applying the MS01-033 patch is equally important because the .ida and
.idq mappings may be re-instated if you add or remove programs
associated with IIS.
If you think you have the patch applied, re-apply it and reboot at
the first opportunity, just to be sure. You can also double-check the
details of IDQ.DLL to ensure its 5.0.2195.3645 or above on W2K,
5.0.1781.3 on NT 4.0. Whatever you do don't rely on anything that
simply looks in the \WINNT directory for an uninstall directory or
the registry, neither of these methods provide complete assurance the
right version is in place.
3. A few words about Responsible Disclosure
Had this original issue been handled using the principles of
Responsible Disclosure, there would have been no discussion of the
"sticking points" and how to resolve them to do "anything useful with
this" overflow. The detailed explanation of how to get the overflow
to run code would have been omitted. eEye's claim that they did not
release any exploit code for the .ida vulnerability is false. Their
original analysis contained everything required to place code in an
executable position within IIS, as well as necessary information
about how to make that code properly execute.
Responsible Disclosure would have permitted the free exchange of
detailed information about the worm amongst "trustable" parties,
parties whom would have already agreed to handle the information in a
responsible fashion. So analysis of this, or any other exploit, could
take place as effectively as now. The key difference is what would
have been released for public consumption. This myth that we must
bare all information, information capable of damaging companies,
forcing increased costs for bandwidth, and consuming valuable cycles
of network administrators, to any and all so they can participate in
research is crap.
The public has shown that its incapable of controlling itself when
given a bomb, they'll set it off eventually. If I were to take a
stick of dynamite and give it to every U.S. citizen, and tell them
"now don't light that or it will blow something up", how many do you
think will go off? When sufficient information is provided, that's
the effect. Therefore, until we can figure out better how to protect
ourselves from the onslaught by the public, either by teaching them
that the malicious acts will go punished, or by developing systems
that can withstand any attack, more restrictive disclosure is a must
if we expect to keep using the Internet.
Whether or not the "underground" can, or would have, done an exploit
without eEye's information is irrelevant. eEye has stated, publicly,
their belief that a public attack is a pre-requisite to get systems
patched. They state that Full Disclosure facilitates that belief,
ergo the more people affected, the more widespread the attack, the
better it is for the Internet. Bull! When has this approach ever
worked? Let's give everyone a gun and bullets and see whether or not
armed crime goes down or up.
Yes, we need to get systems secured, no doubt about it. But when we
live in a time where a single person can send a URL to a publicly
accessible web server and begin a damaging worm, we need to think
more seriously about how widely we spread such information. If people
are going to participate in research, in effect be given sticks of
dynamite or guns, we need to ensure they're not going to use them
against us (or anyone). Computer security research information isn't
just "text", or thought, its tangible. Since the research result can
be a URL, when clicked it starts a worm eating at the entire
Internet, it has to be treated with greater care than its currently
being treated.
There are drugs you can buy over the counter, and those that require
a prescription. We license Doctors and Lawyers and other
professionals, hold them to some ethical standards, and provide
oversight when they abuse those privileges their granted due to their
professional standing. We have laws to protect consumers, people to
police them, and courts that understand the importance of the actions
they judge. In computer security we're letting anyone do brain
surgery, we're not overseeing them or their actions, and they don't
have sufficient ethics to understand the real ramifications of their
actions (or if they do, they're using the Internet to do things that
would otherwise be illegal or impossible). Our courts don't fully
appreciate the actions, and the media loves the miscreants and
results of their actions.
Meanwhile, the public says this is ridiculous. They don't care why
systems are insecure, or where to get patches, or how amazing the
research is. They simply want it to stop! They expect people on the
Internet to act the way they would in person, the way they can
understand. If the place keeps looking like an out-of-control frat
party we're going to lose the public. Lose the public and we'll have
no reason to be securing anything, or customers to sell security
products to.
Anyway, I've rambled long enough tonight. Give me a hand in making
all of the IIS Servers out there secure, for free, now.
Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2
iQCVAwUBO1eZ9RBh2Kw/l7p5AQFGigQAmqbMwblp3NpYJJkPBg8txUNJP3FcSPyN
NfwJVFjkvKOQXCPgqjJuGzVBb+vLJtUyEmzXom5ugqCBTkqrfmU4lseOfesYNGVx
OrsfLwJTDrw+vl9wofJQtPxr0UG3iHnkYpljP6FILhrQ7+2zvRaSlDoPTFyfsEZB
DgqU4b1JW0M=
=dcdE
-----END PGP SIGNATURE-----
----------------------------------------------------------------------------
Delivery co-sponsored by Trend Micro
============================================================================
TREND MICRO REAL-TIME VIRUS ALERTS
If you would like to know about a virus outbreak before CNN and ZDNet get
Trend Micro Virus Info Feed FREE. Simply copy and paste a small piece of
code to give your visitors a real-time top 10 list and the latest virus
advisories. Setup takes just 10 minutes and requires no server-side code on
your Web site. All content is updated automatically from Trend Micro's Web
site.
http://www.antivirus.com/banners/tracking.asp?si=8&bi=237&ul=/syndication/
vinfo/
----------------------------------------------------------------------------
- Previous message: Bill Sobel: "Re: Remote DoS attack against SSH Secure Shell for Windows Servers Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
