One of my server has been compromised from this virus, and I can't seem to
block it out! I have shut down the infected server, but I need to figure
out how to check for this, and stop it.

The site is running iis5 on Windows2000, the backend DB is SQLServer 2000

Can anyone point me to some good resources for this? This is urgent!

Thanks alot
Lance


--
Support Fairtax Legislation
www.fairtax.org

"A government big enough to give you everything you want, is strong enough
to take everything you have."
-Thomas Jefferson

Well, do your ASP pages use ad hoc SQL? Do you validate input? Are you
using an over-privileged account to connect to the database from ASP? You
should read up on SQL injection, and determine what you are doing now that
allows it, and fix it.

I don't think anyone has given explicit instructions on how to check for it
and stop it, because there aren't enough details available about the actual
exploit. But most of the articles talk about SQL injection, so that is a
pretty good place to start.



"Lance Wynn" <Lance_Wynn@community.nospam> wrote in message
news:%23Wpq8fotIHA.2588@TK2MSFTNGP05.phx.gbl...
> One of my server has been compromised from this virus, and I can't seem to
> block it out! I have shut down the infected server, but I need to figure
> out how to check for this, and stop it.
>
> The site is running iis5 on Windows2000, the backend DB is SQLServer 2000
>
> Can anyone point me to some good resources for this? This is urgent!
>
> Thanks alot
> Lance

Hi, thanks for responding so quickly, there are adhoc queries, and I do
validate input. I must just be missing something... I watched the logs last
night, and saw many failed attempts come in, and then this morning, it found
a way in, and I'm not sure how...


Lance


--
Support Fairtax Legislation
www.fairtax.org

"A government big enough to give you everything you want, is strong enough
to take everything you have."
-Thomas Jefferson

"Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:u6gI5kotIHA.4876@TK2MSFTNGP02.phx.gbl...
> Well, do your ASP pages use ad hoc SQL? Do you validate input? Are you
> using an over-privileged account to connect to the database from ASP? You
> should read up on SQL injection, and determine what you are doing now that
> allows it, and fix it.
>
> I don't think anyone has given explicit instructions on how to check for
> it and stop it, because there aren't enough details available about the
> actual exploit. But most of the articles talk about SQL injection, so
> that is a pretty good place to start.
>
>
>
> "Lance Wynn" <Lance_Wynn@community.nospam> wrote in message
> news:%23Wpq8fotIHA.2588@TK2MSFTNGP05.phx.gbl...
>> One of my server has been compromised from this virus, and I can't seem
>> to block it out! I have shut down the infected server, but I need to
>> figure out how to check for this, and stop it.
>>
>> The site is running iis5 on Windows2000, the backend DB is SQLServer 2000
>>
>> Can anyone point me to some good resources for this? This is urgent!
>>
>> Thanks alot
>> Lance
>
>

Lance Wynn wrote:
> One of my server has been compromised from this virus, and I can't
> seem to block it out! I have shut down the infected server, but I
> need to figure out how to check for this, and stop it.
>
> The site is running iis5 on Windows2000, the backend DB is SQLServer
> 2000
>
> Can anyone point me to some good resources for this? This is urgent!
>
> Thanks alot
> Lance
>
>
The simplest, and most effective, way to stop sql injection is to stop
using dynamic (ad hoc0 sql ... anywhere. Use parameters instead. For
situations where dynamic sql must be used (for example, where object
names - columns, tables, etc. - need to be dynamic), then you need to
validate all user input that will be going into that sql statement. Do
not allow any string that has not been validated to be concatenated with
another string to form a sql statement. Here are some of my canned
replies on the subject:

http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.nextgenss.com/papers/adva..._injection.pdf
http://www.nextgenss.com/papers/more..._injection.pdf
http://www.spidynamics.com/papers/SQ...WhitePaper.pdf

See here for a better, more secure way to execute your queries by using
parameter markers (tokens):
http://groups-beta.google.com/group/...e36562fee7804e

Personally, I prefer using stored procedures, or saved parameter queries
as they are known in Access:

Access:
http://www.google.com/groups?hl=en&l...TNGP12.phx.gbl

http://groups.google.com/groups?hl=e...tngp13.phx.gbl

SQL Server:
http://groups.google.com/group/micro...09dc1701?hl=en


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Lance Wynn wrote:
> Hi, thanks for responding so quickly, there are adhoc queries, and I
> do validate input. I must just be missing something... I watched the
> logs last night, and saw many failed attempts come in, and then this
> morning, it found a way in, and I'm not sure how...
>
>

There is an exploit that some have termed "secondary sql injection",
that involves causing malicious code to be inserted into a database
table. The developer, not considering values he retrieves from the
database to be user input, fails to validate them before using them in a
dynamic sql statement, and ... the hacker is in.

Read through all the articles I posted in my previous reply, and take to
heart my advice to stop using dynamic sql.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

"Lance Wynn" wrote:
> Hi, thanks for responding so quickly, there are adhoc queries,
> and I do validate input. I must just be missing something... I
> watched the logs last night, and saw many failed attempts come
> in, and then this morning, it found a way in, and I'm not sure
> how...

You say you validate, but does that include your free-text [Search] fields?
If not, this is a possible point of vulnerability. Here's one common avenue:

Your form includes this field:
<input type="text" name="SearchTerm" />

Your ASP script assembles a SQL statement using that submitted value:

MySQLSearchString = "SELECT ... WHERE Description LIKE '%" +
Request.Form("SearchTerm").Item + "%'"
RS = CN.Execute(MySQLSearchString)

You have a vulnerability if your connection uses credentials with INSERT or
UPDATE privileges in the database. The user submits input values that turn
MySQLSearchString into a series of SQL statements, rather than just one
SELECT.

This is made easier for him if you send detailed error messages, since those
messages tell him what he is guessing wrong about your database, and as the
messages change, they also tell him what he is guessing correctly.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Thanks all, I typically do use parameterized queries, especially in.NET, but
This is a pretty old asp app (over 10 years) I think or close to it. I have
found a couple queries that look something like this:

"Select Fieldlist from table where id=" & ID

I am almost positive these are the holes. As a short term fix, will the
following work?

Select FieldList from table where id='" & replace(ID,"'","''") & "'"

This seems pretty straight foward as it will escape any single quotes in the
variable, and place two outside to catch the rest, or is there still a hole
in there?

thanks
Lance


--
Support Fairtax Legislation
www.fairtax.org

"A government big enough to give you everything you want, is strong enough
to take everything you have."
-Thomas Jefferson

"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:OA9eBwotIHA.4476@TK2MSFTNGP06.phx.gbl...
> Lance Wynn wrote:
>> One of my server has been compromised from this virus, and I can't
>> seem to block it out! I have shut down the infected server, but I
>> need to figure out how to check for this, and stop it.
>>
>> The site is running iis5 on Windows2000, the backend DB is SQLServer
>> 2000
>>
>> Can anyone point me to some good resources for this? This is urgent!
>>
>> Thanks alot
>> Lance
>>
>>
> The simplest, and most effective, way to stop sql injection is to stop
> using dynamic (ad hoc0 sql ... anywhere. Use parameters instead. For
> situations where dynamic sql must be used (for example, where object
> names - columns, tables, etc. - need to be dynamic), then you need to
> validate all user input that will be going into that sql statement. Do
> not allow any string that has not been validated to be concatenated with
> another string to form a sql statement. Here are some of my canned
> replies on the subject:
>
> http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
> http://www.nextgenss.com/papers/adva..._injection.pdf
> http://www.nextgenss.com/papers/more..._injection.pdf
> http://www.spidynamics.com/papers/SQ...WhitePaper.pdf
>
> See here for a better, more secure way to execute your queries by using
> parameter markers (tokens):
> http://groups-beta.google.com/group/...e36562fee7804e
>
> Personally, I prefer using stored procedures, or saved parameter queries
> as they are known in Access:
>
> Access:
> http://www.google.com/groups?hl=en&l...TNGP12.phx.gbl
>
> http://groups.google.com/groups?hl=e...tngp13.phx.gbl
>
> SQL Server:
> http://groups.google.com/group/micro...09dc1701?hl=en
>
>
> --
> Microsoft MVP -- ASP/ASP.NET
> Please reply to the newsgroup. The email account listed in my From
> header is my spam trap, so I don't check it very often. You will get a
> quicker response by posting to the newsgroup.
>
>

"Lance Wynn" wrote:
> I am almost positive these are the holes. As a short term fix, will the
> following work?
>
> Select FieldList from table where id='" & replace(ID,"'","''") & "'"
>
> This seems pretty straight foward as it will escape any single quotes in
> the variable, and place two outside to catch the rest, or is there still a
> hole in there?

The most recent round of SQL injection attacks typically did not involve
quotes[1], so adding them will . But in the absence of using parameters,
why are you continuing to use credentials with INSERT/UPDATE privileges?



[1] There are no quotes in this querystring:
id=1234;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAS T(0x4400...7200%20AS%20NVARCHAR(4000));EXEC(@S);

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

> [1] There are no quotes in this querystring:
> id=1234;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAS T(0x4400...7200%20AS%20NVARCHAR(4000));EXEC(@S);

I agree with your other points (less privileges, use parameters, etc.). But
if the "id" value is passed into a statement like:

sql = "SELECT * FROM table WHERE id = '" &
REPLACE(Request.QueryString("id"), "'", "''") & "';"

I don't see how the querystring above could be executed, since you don't
have a way of terminating the SELECT and starting a new statement. Now, if
the expected value was numeric, I agree, this exploit is possible... unless
you first try to convert the querystring value to a numeric.

So, in the case of strings/dates, preventing string termination is a good
first step (since it is not easy to change large web apps to stored
procedures / parameterized statements at the snap of your fingers). And
likewise, ensuring that you can convert an incoming value to the expected
type before blindly passing it to statements.

But in the long run, definitely, stop using sa / dbo, use parameterized
statements, and validate input.

Lance Wynn wrote:
> Thanks all, I typically do use parameterized queries, especially
> in.NET, but This is a pretty old asp app (over 10 years) I think or
> close to it. I have found a couple queries that look something like
> this:
>
> "Select Fieldlist from table where id=" & ID
>
> I am almost positive these are the holes. As a short term fix, will
> the following work?
>
> Select FieldList from table where id='" & replace(ID,"'","''") & "'"
>
> This seems pretty straight foward as it will escape any single quotes
> in the variable, and place two outside to catch the rest, or is there
> still a hole in there?
>

This will stop most ordinary hackers, but more complicated explots are
available to determined, experienced hackers, especially if you fail to
trap errors or continue to return over-informative error messages.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

This happened to me too, and it's some new SQL injection -- see
http://cyberinsecure.com/phishing-bo...und-in-google/

"Lance Wynn" wrote:

> One of my server has been compromised from this virus, and I can't seem to
> block it out! I have shut down the infected server, but I need to figure
> out how to check for this, and stop it.
>
> The site is running iis5 on Windows2000, the backend DB is SQLServer 2000
>
> Can anyone point me to some good resources for this? This is urgent!
>
> Thanks alot
> Lance
>
>
> --
> Support Fairtax Legislation
> www.fairtax.org
>
> "A government big enough to give you everything you want, is strong enough
> to take everything you have."
> -Thomas Jefferson
>
>
>

Thank you

Fortunately, this is not a huge database, or site, and so changing the
queries and inspecting the values should be easily implemented as a short
term fix. Going forward, we are looking to rewrite it all, but that is not
an option in the short term. I am going to setup a much more restricted
user for most of the site, but there is still a backend where users can add
their own content that could pose some issues.

I read through Bob's links and got a ton of great information there, so I'll
see if I can't implement these changes today and see how it does.

Lance


--
Support Fairtax Legislation
www.fairtax.org

"A government big enough to give you everything you want, is strong enough
to take everything you have."
-Thomas Jefferson

"Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:uMAuphqtIHA.1772@TK2MSFTNGP03.phx.gbl...
>> [1] There are no quotes in this querystring:
>> id=1234;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAS T(0x4400...7200%20AS%20NVARCHAR(4000));EXEC(@S);
>
> I agree with your other points (less privileges, use parameters, etc.).
> But if the "id" value is passed into a statement like:
>
> sql = "SELECT * FROM table WHERE id = '" &
> REPLACE(Request.QueryString("id"), "'", "''") & "';"
>
> I don't see how the querystring above could be executed, since you don't
> have a way of terminating the SELECT and starting a new statement. Now,
> if the expected value was numeric, I agree, this exploit is possible...
> unless you first try to convert the querystring value to a numeric.
>
> So, in the case of strings/dates, preventing string termination is a good
> first step (since it is not easy to change large web apps to stored
> procedures / parameterized statements at the snap of your fingers). And
> likewise, ensuring that you can convert an incoming value to the expected
> type before blindly passing it to statements.
>
> But in the long run, definitely, stop using sa / dbo, use parameterized
> statements, and validate input.
>

Can I remove access to the SysObjects table for the restricted user, or does
there need to be access to that table to run queries?



--
Support Fairtax Legislation
www.fairtax.org

"A government big enough to give you everything you want, is strong enough
to take everything you have."
-Thomas Jefferson

"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:%23bHXB2qtIHA.576@TK2MSFTNGP05.phx.gbl...
> Lance Wynn wrote:
>> Thanks all, I typically do use parameterized queries, especially
>> in.NET, but This is a pretty old asp app (over 10 years) I think or
>> close to it. I have found a couple queries that look something like
>> this:
>>
>> "Select Fieldlist from table where id=" & ID
>>
>> I am almost positive these are the holes. As a short term fix, will
>> the following work?
>>
>> Select FieldList from table where id='" & replace(ID,"'","''") & "'"
>>
>> This seems pretty straight foward as it will escape any single quotes
>> in the variable, and place two outside to catch the rest, or is there
>> still a hole in there?
>>
>
> This will stop most ordinary hackers, but more complicated explots are
> available to determined, experienced hackers, especially if you fail to
> trap errors or continue to return over-informative error messages.
>
> --
> Microsoft MVP -- ASP/ASP.NET
> Please reply to the newsgroup. The email account listed in my From
> header is my spam trap, so I don't check it very often. You will get a
> quicker response by posting to the newsgroup.
>
>

Bob Barrows [MVP] wrote on 15 mei 2008 in
microsoft.public.inetserver.asp.general:

> This will stop most ordinary hackers, but more complicated explots are
> available to determined, experienced hackers, especially if you fail to
> trap errors or continue to return over-informative error messages.

How would you trap such execute errors in asp-vbs, Bob?

I suppose you keep the error messages appearing using your own ip?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Lance Wynn wrote:
> Can I remove access to the SysObjects table for the restricted user,
> or does there need to be access to that table to run queries?
>
>

There should be no need for access to that table. You should restrict
access to only the tables, procedures and views required by the
application.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Evertjan. wrote:
> Bob Barrows [MVP] wrote on 15 mei 2008 in
> microsoft.public.inetserver.asp.general:
>
>> This will stop most ordinary hackers, but more complicated explots
>> are available to determined, experienced hackers, especially if you
>> fail to trap errors or continue to return over-informative error
>> messages.
>
> How would you trap such execute errors in asp-vbs, Bob?
>
> I suppose you keep the error messages appearing using your own ip?
>
For expected errors, I either discard or log the actual error message,
depending on what it is and return a friendly message to the user
explaining that an error occurred, what probably caused it, and how to
avoid it.

For unexpected errors, I will typically log vbscript error messages in a
text file*, redirecting the user to an error page displaying a generic
message such as:

An error I did not plan for occurred and has been logged on the server.
In the textbox below, would you mind providing some details regarding
the steps that led to the error to me figure out what went wrong?
Thank you.

Of course, a hacker will probably type in some rude message, but
legitimate users should have some interest in ing discover the cause
of the error.

* in a rare case, I used CDO to email them to myself - definitely
overkill for most applications

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

"Aaron Bertrand [SQL Server MVP]"
> I don't see how the querystring above could be executed, since
> you don't have a way of terminating the SELECT and starting a
> new statement. Now, if the expected value was numeric, I agree,
> this exploit is possible...

That is precisely the condition this exploit targeted -- unquoted INT
parameters.

> ...unless you first try to convert the querystring value to a
> numeric.

Yes. A parameter would have done it implicitly, but in the act of string
concatenation, this seems not to happen often enough.



> So, in the case of strings/dates, preventing string termination
> is a good first step (since it is not easy to change large web
> apps to stored procedures / parameterized statements at the snap
> of your fingers). And likewise, ensuring that you can convert an
> incoming value to the expected type before blindly passing it to
> statements.

We are in agreement.


> But in the long run, definitely, stop using sa / dbo, use
> parameterized statements, and validate input.

Allow me to make a couple of points. I believe you mean to say that people
should stop using logins with sysadmin or db_owner roles (I assume you don't
argue against the use of the dbo schema). To which I add: "Don't use
db_datawriter unless you absolutely must."

Personally, I almost always grant the login *no* roles, preferring to assign
permissions on an object-by-object basis.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Thanks to all for the with this. I implemented most of the advice, and
it seems to have worked a treat. I can see attempts being made in the logs,
but none have been successful. I also implemented data type checks on all
fields in any of the dynamic queries, so non-numeric values in a numeric
field get rejected.

Additionally, the error messages are now generic, and give no clue as to the
root cause.

Thanks much to all who participated in this thread, I really appreciate your
assistance.
Lance


--
Support Fairtax Legislation
www.fairtax.org

"A government big enough to give you everything you want, is strong enough
to take everything you have."
-Thomas Jefferson

"Lance Wynn" <Lance_Wynn@community.nospam> wrote in message
news:%23Wpq8fotIHA.2588@TK2MSFTNGP05.phx.gbl...
> One of my server has been compromised from this virus, and I can't seem to
> block it out! I have shut down the infected server, but I need to figure
> out how to check for this, and stop it.
>
> The site is running iis5 on Windows2000, the backend DB is SQLServer 2000
>
> Can anyone point me to some good resources for this? This is urgent!
>
> Thanks alot
> Lance
>
>
> --
> Support Fairtax Legislation
> www.fairtax.org
>
> "A government big enough to give you everything you want, is strong enough
> to take everything you have."
> -Thomas Jefferson
>
>

> Allow me to make a couple of points. I believe you mean to say that people
> should stop using logins with sysadmin or db_owner roles (I assume you
> don't argue against the use of the dbo schema).

Yes, I hope that is broadly understood as what I meant.

A