Spurious data being inserted in field


M

Mike Myers

Hello

Periodically, some of the records in one table have one field updated to the
following value:

<!--<1586567094>-->

It is the most bizarre thing I have ever seen. We have checked all our
servers and stored procedures for any occurrence of this value in scripts or
ASP pages but none exist. We're fearing SQL injection or similar but in our
application this field is only updated from one place and it's tight against
hacking.

If it was a hack we would think the value might be something else, so we're
presuming some sort of corruption or similar. We're at a loss.

Does anyone have any suggestions?

Thanks and regards

Mike
 
Ad

Advertisements

D

Dan Guzman

If it was a hack we would think the value might be something else, so
we're presuming some sort of corruption or similar. We're at a loss.

This could very well be a hack. For example, the value 1586567094 might be
someone's SSN that the hacker was able to harvest and display on a web page.
I suggest run run a server side trace (not Profiler) continuously with a
filter to log the problem update when it occurs.

I don't know what steps you've taken to prevent SQL injection, but here is
my short list is:

- perform data access exclusively from stored procedures

- execute procedures from app code using command type stored procedure along
with parameter objects (never build and execute SQL Statement strings with
concatenation, especially form fields and URL data)

- grant no permissions on tables and leverage ownership chaining security

- use a minimally privileged account with only stored procedure execute
permissions

- no dynamic SQL in stored procedures

Separately, you can mitigate other security vulnerabilities (e.g. criss-site
scripting) with stringent input and output validation.

--
Hope this helps.

Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/
 
E

Eric Isaacs

It's hard to tell from here, but it has the signatures of a SQL
injection attack.

-Eric Isaacs
 
B

Bob Barrows

Mike said:
Hello

Periodically, some of the records in one table have one field updated
to the following value:

<!--<1586567094>-->

I might be wrong, but this appears to be harmless - it does not appear
to be encrypted script.
It is the most bizarre thing I have ever seen. We have checked all
our servers and stored procedures for any occurrence of this value in
scripts or ASP pages but none exist. We're fearing SQL injection or

With good reason ...
similar but in our application this field is only updated from one
place and it's tight against hacking.
The evidence suggests otherwise ... :)
Where does the application get the data it puts in this field?

If it was a hack we would think the value might be something else, so
we're presuming some sort of corruption or similar. We're at a loss.

Does anyone have any suggestions?

Conjecture A:
A hacker or hacking bot has figured out that your site is vulnerable to
sql injection and has been able to figure out the name of a single field
in a single table and is probably trying to figure out more of your
schema (probably by causing informative error messages to be returned
from your application). The data inserted into your table is probably a
byproduct of those attempts, rather than the actual payload, since the
string seems to be harmless. If there were more to it, or it is actually
encrypted script, then the hacker is counting on your application
sending that string to a client browser without html-encoding it.

Conjecture B:
No sql injection is involved: a user of your app is purposely entering
that string into an input element and submitting it
 
M

Mike Myers

Bob Barrows said:
I might be wrong, but this appears to be harmless - it does not appear
to be encrypted script.


With good reason ...

The evidence suggests otherwise ... :)
Where does the application get the data it puts in this field?



Conjecture A:
A hacker or hacking bot has figured out that your site is vulnerable to
sql injection and has been able to figure out the name of a single field
in a single table and is probably trying to figure out more of your
schema (probably by causing informative error messages to be returned
from your application). The data inserted into your table is probably a
byproduct of those attempts, rather than the actual payload, since the
string seems to be harmless. If there were more to it, or it is actually
encrypted script, then the hacker is counting on your application
sending that string to a client browser without html-encoding it.

Conjecture B:
No sql injection is involved: a user of your app is purposely entering
that string into an input element and submitting it

Thank you for your help everyone. I shall run a trace and see what that
yields. I understand the concerns of SQL injection but it is a simple HTML
form that records based on their primary key and the owner User ID as well.
Everything is escaped properly and all numbers/IDs converted/checked to be
numbers before they hit the database.

I was going to create a trigger to audit the setting of these values but as
the field is text (it's an old app, else we'd be using varChar(max)), they
can't be used.

Regards

Mike
 
Ad

Advertisements

M

Mike Myers

Dan Guzman said:
So you are not using parameterized queries? IMHO, that's an accident
waiting to happen (or already has).

--
Hope this helps.

Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/

Hi Dan

No, and I will now change this page to do so. I ran a trace for a while but
it yielded nothing.

Regards

Mike
 
B

Bwig Zomberi

Bob said:
Conjecture B:
No sql injection is involved: a user of your app is purposely entering
that string into an input element and submitting it

When the DB has become corrupted and the RDBMS tries to repair/restore
data something like this may happen. I have a vague recollection of this
happening a long time ago. Just open the data store in the latest
version of the DBMS and do an export to another data store in the latest
version of the DB. Then manually check all the data is fine. If okay,
use that data store.

This does not mean you should ignore possibilities that others have
pointed out.
 
E

Erland Sommarskog

Bwig said:
When the DB has become corrupted and the RDBMS tries to repair/restore
data something like this may happen.

No, if you get <!--<1586567094>--> inserted from nowhere, it is highly
unlikely that this is due to corruption. On the other hand if you had 7 in a
cell, and then the next day you have 2035 there, this is a very likely due
to corruption.

As for repairs, SQL Server would never tries to guess a value. Either it
repairs without data loss, or it throughs the data away. (And you have
explicitly to allow data loss for it to happen.)



--
Erland Sommarskog, SQL Server MVP, (e-mail address removed)

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
 
M

Mike Myers

Mike Myers said:
Hello

Periodically, some of the records in one table have one field updated to
the following value:

<!--<1586567094>-->

It is the most bizarre thing I have ever seen. We have checked all our
servers and stored procedures for any occurrence of this value in scripts
or ASP pages but none exist. We're fearing SQL injection or similar but
in our application this field is only updated from one place and it's
tight against hacking.

If it was a hack we would think the value might be something else, so
we're presuming some sort of corruption or similar. We're at a loss.

Does anyone have any suggestions?

Thanks and regards

Mike

Well thanks guys.

We have found one other record in this same table with a similar value,
similarly meaningless.

We did some analysis and it seems that only records created before the 12th
July were affected. This means the injection/corruption either happened on
this date or some other conic. 23124 records have been affected out of a
total of 45826, (some of which may have been updated back to a more
meaningful description so are no longer included in the erroneous count).

We've switched to using stored procedures for the updates to this table but
I am not convinced we've found the problem. The database is 85GB so playing
at restoring backups is a nightmare.

Regards

Mike
 
B

Bob Barrows

Mike said:
Well thanks guys.

We have found one other record in this same table with a similar
value, similarly meaningless.

We did some analysis and it seems that only records created before
the 12th July were affected. This means the injection/corruption
either happened on this date or some other conic. 23124 records have
been affected out of a total of 45826, (some of which may have been
updated back to a more meaningful description so are no longer
included in the erroneous count).
We've switched to using stored procedures for the updates to this
table but I am not convinced we've found the problem. The database
is 85GB so playing at restoring backups is a nightmare.

Regards

Mike

Switching to a parameterized stored procedure is certainly a good thing, but
it might not be enough. This hacker inserted html into your table, which
means that he is counting on you reading the data from the table and passing
it to a client browser without encoding. Think of the ramifications if he
had inserted something like <img src='webpage that downloads a keylogger'>
into your table instead of the innocuous comment he did insert. Again, the
fact that it was innocuous indicates to me that he was testing your
defenses, seeing if he could cause html to be passed back to his client
untouched.

So, you also need to verify that you are correctly handling data retrieved
from the database, using htmlencode when passing it to a client.
 
Ad

Advertisements

E

Erland Sommarskog

Mike said:
We've switched to using stored procedures for the updates to this table
but I am not convinced we've found the problem. The database is 85GB so
playing at restoring backups is a nightmare.

Beware that using stored procedures alone is not sufficient. You also need
to call them in the proper way. If you send EXEC statements to SQL Server
you are as exposed as ever.


--
Erland Sommarskog, SQL Server MVP, (e-mail address removed)

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
 
M

Mike Myers

Bob Barrows said:
Switching to a parameterized stored procedure is certainly a good thing,
but it might not be enough. This hacker inserted html into your table,
which means that he is counting on you reading the data from the table and
passing it to a client browser without encoding. Think of the
ramifications if he had inserted something like <img src='webpage that
downloads a keylogger'> into your table instead of the innocuous comment
he did insert. Again, the fact that it was innocuous indicates to me that
he was testing your defenses, seeing if he could cause html to be passed
back to his client untouched.

So, you also need to verify that you are correctly handling data retrieved
from the database, using htmlencode when passing it to a client.

Hi Bob

No, the value is shown on the Site as it appears in the database. We encode
all our output. Our end users brought this to our attention as they could
see the error value. If someone entered an image tag, that is what would
display, not the image. I was wondering if <!--< was some know server side
scripting tag. I've come across a few such as <!--# and <!--[ so wondered
if this was something along those lines - perhaps even trying to execute
code server side.

Thanks for your time on this.

Mike
 
B

Bob Barrows

Mike said:
Hi Bob

No, the value is shown on the Site as it appears in the database. We
encode all our output. Our end users brought this to our attention
as they could see the error value. If someone entered an image tag,
that is what would display, not the image.

And that explains why he (or it - it could've been a bot) gave up. Your
defenses were good. Well done.

I was wondering if <!--<
was some know server side scripting tag. I've come across a few such
as <!--# and <!--[ so wondered if this was something along those
lines - perhaps even trying to execute code server side.

I've never seen <!--[, where have you seen that? I've also never seen
<!--<
 
Ad

Advertisements

D

Dan

Mike Myers said:
Bob Barrows said:
Switching to a parameterized stored procedure is certainly a good thing,
but it might not be enough. This hacker inserted html into your table,
which means that he is counting on you reading the data from the table
and passing it to a client browser without encoding. Think of the
ramifications if he had inserted something like <img src='webpage that
downloads a keylogger'> into your table instead of the innocuous comment
he did insert. Again, the fact that it was innocuous indicates to me that
he was testing your defenses, seeing if he could cause html to be passed
back to his client untouched.

So, you also need to verify that you are correctly handling data
retrieved from the database, using htmlencode when passing it to a
client.

Hi Bob

No, the value is shown on the Site as it appears in the database. We
encode all our output. Our end users brought this to our attention as
they could see the error value. If someone entered an image tag, that is
what would display, not the image. I was wondering if <!--< was some know
server side scripting tag. I've come across a few such as <!--# and
<!--[ so wondered if this was something along those lines - perhaps even
trying to execute code server side.

Thanks for your time on this.

Mike

<!-- is simply a comment tag - normally values within the <!-- and --> tags
are not displayed in the browser. <!--# is a special case in that it
indicates a server side include (SSI) if the server application supports it,
for instance it is used a lot in ASP applications for including common
files. I've never seen <!--[, but that is again simply a comment tag if the
[ has no special meaning to the server application processing the fikes.

Given that these entries are comments, it would seem odd that they would be
the result of an attack as normally it's script tags that are injected in
order to try to install something on browsers that visit the site. Are you
sure someone hasn't been doing some testing on the database or server and
inadvertently updated all these rows? Do the numbers have any relation to
data in the row they are found in?

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top