Virus Scripts in SQL Database
I'm not sure what happened but all of a sudden a few of the "text" database fields in our sql database have virus scripts appeneded to them. For example we have a notes field that had user typed in notes, and then at the bottom of that their are what I can only imagine are virus scripts with a link in them.
Obviously their was a security flaw somewhere along the line. Is there a way to determine how these are getting in there and what is the best way to remove them? I'd prefer not to clear out the existing user notes, but if that is a necessity I guess its my only choice. Any help would be appreciated. Thanks.
Obviously their was a security flaw somewhere along the line. Is there a way to determine how these are getting in there and what is the best way to remove them? I'd prefer not to clear out the existing user notes, but if that is a necessity I guess its my only choice. Any help would be appreciated. Thanks.
is that database accessable from a webserver?
if so I assume that your web application has a SQL Injection vulnerability
first check your server logfiles, if you identify malicious requests disconnect that server from internet until you fixed the vulnerability
then you need to check (penetration test or SCA) your application and fix all flaws in the source code, then check again
if so I assume that your web application has a SQL Injection vulnerability
first check your server logfiles, if you identify malicious requests disconnect that server from internet until you fixed the vulnerability
then you need to check (penetration test or SCA) your application and fix all flaws in the source code, then check again
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> .. and only accept alpha numeric text
42 union select table_name from information_schema where table_name between 0x61 and 0x7a
> .. and simple punctation
4 or 2=2 into outfile 'result.txt'
*neverever* use blacklists or sanatised input data, always use a whitlist and reject anything not matching the whitelist
42 union select table_name from information_schema where table_name between 0x61 and 0x7a
> .. and simple punctation
4 or 2=2 into outfile 'result.txt'
*neverever* use blacklists or sanatised input data, always use a whitlist and reject anything not matching the whitelist
Was thinking the log from the web and app tier may also captured some request log which may be close to the script injected at database side. Probably is to trace back who is the source and who has access or download it so far... Window of exposure has already widen since the gap is opened up due to vulnerable web code...I suspect
E.g http://blogs.technet.com/b/neilcar/archive/2008/03/14/anatomy-of-a-sql-injection-incident.aspx
There she be some detection by is or firewall online but seems like they are bypass..we application firewall can serve well to trace out the events leading to it. Log parser are avail for the analysis if is or apache log are available....
E.g http://blogs.technet.com/b/neilcar/archive/2008/03/14/anatomy-of-a-sql-injection-incident.aspx
There she be some detection by is or firewall online but seems like they are bypass..we application firewall can serve well to trace out the events leading to it. Log parser are avail for the analysis if is or apache log are available....
can someone please explain why the accepted comment is the answer?
ASKER
I don't know if there is a script i could run to remove all of the malicious scripts while preserving the orginal information. The other big issue is trying to determine where it came from.. any suggestions where to start looking... a particular log? etc..