Follow up --- RE: New and unique IIS log entries.

• Previous message: Schmehl, Paul L: "NetSDK vulnerable to SQL Slammer"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date:         Mon, 16 Jun 2003 14:27:53 -0700
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

First, I want to thank everyone who emailed with suggestions and who took
the time to review the logs after requesting copies. I was surprised at the
amount of interest this post generated and am appreciative for the informed
suggestions and explanations.

I will attempt to summarize all the input I have received in hopes that it
will help others as it has helped me.

Of the ~40 responses I received...

Possible explanations:

The vast majority suggested that this activity was due to a vulnerability
scanner and not due to a worm/virus. The best reason I heard for this
assumption is because most worms won't do as many vulnerability tests as we
see here (1700+) because that would imply the worm could exploit them all,
which would not be very likely.

Only one person saw patterns in their logs files close enough to my log
files to say within a reasonable doubt that the same tool was used against
their sites. A couple people suggested that this could be a commercial
vulnerability scanner, however, the majority of the people who requested and
reviewed the log files felt it was more likely to be a "super script" of
some sort made up of a bunch of smaller well known vulnerability testing
scripts. A couple thought that it could have originated from "zombie bot"
machines who had previously been infected with a trojan of some sort. This
is entirely possible.

All agreed that any well hardened fully patched IIS server would be
impervious to this particular attack because all of the attack vectors are
well known and patches have been available for these exploits for some time.

Suggestions:

As mentioned, a well hardened IIS server would not be affected by this
attack, so most suggestions were directed more towards eliminating the load
on the server and corresponding log file bloat caused by such attacks.

Most agreed that the best place to deal with these requests are at the
router.

If you have a Cisco router (except 1600 series), you can create a policy map
to mark and drop this traffic. This will keep it from hitting your IIS box
and your log files will be much cleaner. You can block and drop most folder
traversal, root.exe, and default.ida type stuff which is the vast majority
of what I saw in my logs. Here's a couple helpful links...

http://www.ccert.edu.cn/upload/1/35.pdf

http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-linux/2002-01/011
4.html

I'm sure other routers also have similar functionality.

There are also many other third-party firewalls and routers that would help,
but all are at an additional cost. If your budget is tight, it may be that
the best you can do is to implement URLScan and IISLockDown and spend the
time configuring them. There always seems to be a delicate tight-rope
balancing act between security and functionality with the network
administrators, security consultants and professionals being the ones on the
rope.

I have not seen any additional log entries since my previous post.

Again, thanks to all who took the time to reply.

Regards,
Ken

-----Original Message-----
From: Ken Goods
Sent: Thursday, June 12, 2003 10:15 AM
To: NTBUGTRAQ (E-mail)
Subject: New and unique IIS log entries.

Just a friendly heads up and am curious if anyone has experienced this or
knows anything about it.

During my normal morning log review a couple days ago I noticed something
out of the ordinary. I am used to seeing anywhere from 10 to 30 unique IP
addresses showing some form of code red (or blue), Nimda, etc., and these
I'm sure will continue. But on 6/9 I noticed some log entries that were
unique in, (1) the volume of attempts and, (2) the sheer number of different
vulnerabilities attempted. There were two unique requesting IP addresses and
both seemed to try the same exploits in the same order. The first address
(61.54.101.x) made 1773 attempts in 2 minutes 28 seconds for an average of
~12 attempts per second. The second (217.136.76.x) made 1849 attempts in 1
minute 46 seconds averaging ~17.5 attempts per second. I have not had a
chance to look at each and every log entry but from what I have seen, it
looks like most are trying to exploit known vulnerabilities. However, I have
not seen nor heard of any automated (obviously) tool that operates this way
nor have I seen log entries similar to these before. And I have never seen
one that tries so many different vulnerabilities against so many different
folders.

My curiosity is up and I'm wondering if this is a vulnerability scanner or a
new virus/worm of some sort. Has anyone else noticed these types of log
entries? If anyone else is curious and wants to see the log entries I would
be happy to get them to you.

Regards,
Ken
Ken Goods
Network Administrator
MIS Dept.
AIA Insurance, Inc.

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by TruSecure
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Free 14-day trial of New Threat & Vulnerability Notification Service

TruSecure's new IntelliShield(tm) web-based threat and vulnerability
service isn't your typical alert service. Supported by TruSecure's vast
intelligence resources - including the ICSA Labs - IntelliShield's early
warning, analysis, decision support, and threat management tools provide
organizations with unmatched intelligence to better protect critical
information assets. Experience it for yourself - just click below to begin
your free, no obligation 14-day trial today!

http://www.trusecure.com/offer/s0074/

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

• Previous message: Schmehl, Paul L: "NetSDK vulnerable to SQL Slammer"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]