Prev: bcp format file - error SQLState HY000, NativeError = 0,IO
Next: MSSQL$SQLEXPRESS
From: Bob Barrows on 28 Jul 2010 06:48
Mike Myers wrote:
> "Mike Myers" <bookham_measures(a)yahoo.com> wrote in message
> news:%23QyMGFPKLHA.1996(a)TK2MSFTNGP06.phx.gbl...
>> 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

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.


From: Erland Sommarskog on 28 Jul 2010 08:39
Mike Myers (bookham_measures(a)yahoo.com) writes:
> 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, esquel(a)sommarskog.se

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

From: Mike Myers on 28 Jul 2010 10:41

"Bob Barrows" <reb01501(a)yahoo.com> wrote in message
news:cWT3o.44213$f_3.34012(a)newsfe17.iad...
> Mike Myers wrote:
>> "Mike Myers" <bookham_measures(a)yahoo.com> wrote in message
>> news:%23QyMGFPKLHA.1996(a)TK2MSFTNGP06.phx.gbl...
>>> 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
>
> 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


From: Bob Barrows on 28 Jul 2010 11:09
Mike Myers wrote:
>> 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.

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
<!--<
--
HTH,
Bob Barrows


From: Dan on 28 Jul 2010 12:20

"Mike Myers" <bookham_measures(a)yahoo.com> wrote in message
news:e#utBMmLLHA.4084(a)TK2MSFTNGP05.phx.gbl...
>
> "Bob Barrows" <reb01501(a)yahoo.com> wrote in message
> news:cWT3o.44213$f_3.34012(a)newsfe17.iad...
>> Mike Myers wrote:
>>> "Mike Myers" <bookham_measures(a)yahoo.com> wrote in message
>>> news:%23QyMGFPKLHA.1996(a)TK2MSFTNGP06.phx.gbl...
>>>> 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
>>
>> 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

First  |  Prev  | 
Pages: 1 2 3
Prev: bcp format file - error SQLState HY000, NativeError = 0,IO
Next: MSSQL$SQLEXPRESS