Problem getting hacked with this new SQL injection Tool. Adword71 and direct84

[Lance Wynn]

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

[Bob Barrows [MVP]]

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]

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]" <te*****@dnartr eb.noraawrote in message
news:uM******** ******@TK2MSFTN GP03.phx.gbl...

>[1] There are no quotes in this querystring:
id=1234;DECLAR E%20@S%20NVARCH AR(4000);SET%20 @S=CAST(0x4400. ..7200%20AS%20N VARCHAR(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("i d"), "'", "''") & "';"

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]

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]" <re******@NOyah oo.SPAMcomwrote in message
news:%2******** *******@TK2MSFT NGP05.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.

[Evertjan.]

Bob Barrows [MVP] wrote on 15 mei 2008 in
microsoft.publi c.inetserver.as p.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)

[Bob Barrows [MVP]]

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.

[Bob Barrows [MVP]]

Evertjan. wrote:

Bob Barrows [MVP] wrote on 15 mei 2008 in
microsoft.publi c.inetserver.as p.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 help 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 helping 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.

[Dave Anderson]

"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.

[Lance Wynn]

Thanks to all for the help 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" <La********@com munity.nospamwr ote in message
news:%2******** ********@TK2MSF TNGP05.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

[Aaron Bertrand [SQL Server MVP]]

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