ПОМОГИТЕ! Производственная БД была ВНЕДРЕНА SQL!

Первое, что нужно сделать - не паниковать. Но я вижу, вы пропустили это и решили

Во-вторых, отключите сайт и убедитесь, что он недоступен извне, пока вы не выясните, что сломалось. Начните смотреть журналы доступа и попытайтесь выяснить, в чем основная проблема.

Третье, что нужно сделать, это проверить, регулярно ли вы делаете резервную копию своей БД и просто откатываете ее. Вы можете потерять некоторые данные, но вы будете в лучшем положении, чем сейчас

Четвертое, что нужно сделать, - НЕ выдавать URL-адрес, потому что он явно небезопасен.

Обязательно установите последнюю версию UrlScan - она ​​в значительной степени предназначена для защиты от подобных атак.

Если у вас есть журналы IIS, точка входа должна быть довольно очевидной - ищите ту, которую забили хакеры.

Еще один хороший способ поддержки, если это вообще возможно, - отказать в правах INSERT и UPDATE учетной записи веб-пользователя и вместо этого выполнить их через хранимые процедуры. Подобная поддержка спасла нас от аналогичной проблемы с аналогичным устаревшим приложением, когда это была атака нулевого дня.

Я думаю, вы также можете отменить право пользователя PUBLIC сканировать таблицы, что должно удерживать их от атак в стиле «таблицы foreach».

В качестве ориентира это работа атаки бота ASPRox SQL Injection. Кажется, что время от времени он сам всплывает, потому что становится довольно вирусным при обнаружении скомпрометированных систем. Вы можете поискать в Google по запросу "ASPRox bot" и получить дополнительные методы очистки и профилактические процедуры. Я только что нашел этот PDF файл, в котором есть хороший обзор его тактики и ссылки на некоторые варианты очистки.

Проблема в том, что модель вируса / инъекции, по сути, взяла каждое текстовое поле во ВСЕХ таблицах вашей базы данных и поместила небольшой фрагмент, который обращается к указанному URL-адресу, чтобы попытаться заразить любые другие веб-клиенты и попытаться сделать их зомби, которые посещают ваш сайт. .

Поэтому обязательно проверьте все базы данных на этом сервере, а не только на той, с которой задействована база данных, чтобы провести надлежащую очистку.

Похоже, что вы на правильном пути с предложениями здесь, но наличие некоторых «формальных» ссылок на имя вируса может помочь с дополнительными потребностями.

Во-первых, вы должны закрыть сайт, чтобы предотвратить дальнейшие инъекции.

Во-вторых, вам необходимо провести аудит безопасности, чтобы определить, какие журналы у вас есть, какая безопасность установлена ​​в системе, а также определить, как злоумышленники проникли внутрь.

В-третьих, вам необходимо обеспечить ведение журнала и безопасность, по крайней мере, для тех областей, где вы были скомпрометированы. Установите систему обнаружения вторжений, которая немедленно информирует вас (например, пейджер).

В-четвертых, проинформируйте руководство о том, что простои являются следствием игнорирования безопасности.

Проверьте свои журналы IIS, чтобы узнать, какую страницу они использовали для инъекции. Излишне говорить, что вам нужно быстро исправить или отключить эту страницу.

Оптимальный подход зависит от типа сайта. Если вообще возможно, убрать сайт пока вы не восстановите незапятнанную базу данных или не отмените изменения (для этого требуются подробные журналы). Затем вы можете снова перевести сайт в режим только для чтения, пока у вас не будет времени решить проблему (ы). Просто ограничьте учетную запись SQL только SELECT.

Даже когда вы объединяете строки запроса, вы можете быть в безопасности, не прилагая особых усилий. Поиск во всех файлах ASP по таким ключевым словам, как SELECT и UPDATE, выявит все запросы. Для начала окружите все свои параметры элементарными проверками работоспособности.

Поскольку вы, вероятно, торопитесь, можете взглянуть на некоторые действительно мой старый код ASP VBScript. Существует множество функций SafeSqlWhatever, которые помогут вам создавать безопасные операторы SQL. Никаких гарантий, это никогда не предназначалось для публикации. Однако замена всех входных переменных на SqlVar (someValue) функция должна помочь вам начать работу. Вам необходимо удалить одинарные кавычки из остальной части строки запроса, поскольку SqlVar добавляет их за вас. В качестве альтернативы используйте функции, специфичные для ожидаемого типа значения:

Перед:

Conn.Execute("UPDATE posts SET Subject='" & subject & "' WHERE ID=" & id)

После:

Conn.Execute("UPDATE posts SET Subject=" & SafeSqlString(subject) & " WHERE ID=" & SafeSqlNumber(id))

PS: нет, так не должно быть, но наверное как можно быстрее вернуть вещи в рабочее состояние с того места, где вы сейчас находитесь.

Пытаясь ответить на исходный вопрос об отслеживании запроса, я думал о том, чтобы сделать это с другой стороны, если сервер не был сброшен, вытащить все запросы из кеша запросов, чтобы я показывал, какой запрос был запущен - при условии, что это все еще в кеше.

SELECT  ( SUBSTRING(s2.text, (statement_start_offset / 2) + 1, ((CASE WHEN statement_end_offset = -1 THEN (LEN(CONVERT(nvarchar(max),s2.text)) * 2) ELSE statement_end_offset END)- statement_start_offset)/2)) AS sql_statement
    ,execution_count
    ,(total_worker_time / 1000) as total_worker_time_milli_s
    ,(last_worker_time / 1000) as last_worker_time_milli_s
    ,((total_worker_time / execution_count) / 1000) as average_worker_time_milli_s
    ,min_worker_time
    ,max_worker_time
    ,last_execution_time
    ,qp.query_plan
FROM 
    sys.dm_exec_query_stats qs 
    CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
    CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) as qp
WHERE
    s2.objectid is null
ORDER BY
    total_worker_time desc

IIS может иметь несколько журналов, которые могут дать вам некоторые подсказки о том, к каким страницам был осуществлен доступ, если у вас включено ведение журнала. Вы можете проверить конфигурацию сайта.

Сначала я хотел бы убедиться, что пользователь sql для приложения по умолчанию имеет доступ только для чтения. Добавьте доступ вставки / обновления / удаления только к тем таблицам, где это необходимо.

Вам нужно удалить ссылки .js из базы данных? Некоторое время назад мы использовали этот сценарий, чтобы удалить все ссылки .js для всех наших таблиц. Это глобальный поиск / замена базы данных. Введите ссылку .js, где вы увидите это: PLACE BAD JAVA SCRIPT CODE HERE

DECLARE @T varchar(255),@C varchar(4000)   
DECLARE Table_Cursor1 CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)   
OPEN Table_Cursor1
FETCH NEXT FROM Table_Cursor1 INTO @T,@C WHILE(@@FETCH_STATUS=0)    
BEGIN exec('SELECT [' + @C + '] FROM [' + @T + '] WHERE [' + @C  + '] LIKE ''%.js%'' ')
FETCH NEXT FROM Table_Cursor1 INTO @T,@C END   
CLOSE Table_Cursor1 DEALLOCATE Table_Cursor1    

DECLARE @T varchar(255),@C varchar(4000)    
DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)    
OPEN Table_Cursor    
FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0)    
BEGIN exec('update ['+@T+'] set ['+@C+']=replace(['+@C+'],''PLACE BAD JAVA SCRIPT CODE HERE'','''')')     
FETCH NEXT FROM Table_Cursor INTO @T,@C END      
CLOSE Table_Cursor DEALLOCATE Table_Cursor

Обычно случается, что хакер (который часто является ботом) выполняет поиск в Google того, что выглядит как возможные точки входа для SQL-инъекции (ищет строки запроса, выполняя поиск, скажем, «inurl: .aspx?» Или «inurl :? id = "). а затем автоматически проверяет уязвимость инъекций. Если вы хотите найти точку входа, неплохо было бы отправить похожие запросы в Google и посмотреть, какие из ваших сайтов со строками запросов он проиндексировал.

Двигаясь дальше, эти сценарии обычно надеются, что выполняющийся сценарий имеет доступ к sysobjects, и в этом случае он может перебирать все таблицы в базе данных и внедрять себя в каждый столбец. Если это произошло (что, как я полагаю, в противном случае можно было бы просто предположить, что уязвимость внедрения находится там, где находится внедренный код), я однажды написал сценарий, который делает то же самое, для поиска по всей базе данных для данного значения. Это можно найти здесь:

http://pastebay.com/28400

Если у вас нет резервных копий (что я предполагаю по вашему несколько отчаянному тону), этот скрипт можно использовать для поиска всех введенных столбцов, а с небольшой модификацией его также можно использовать для удаления этих инъекций.

Вот вам и восстановление окружающей среды. После этого стоит задача убедиться, что это больше не повторится. Ты не в который очень спешите, тот, кто вводил вам инъекцию, вероятно, ударит вас случайным образом и вряд ли попробует это снова в ближайшее время, но извлеките урок из этого и сделайте это в любом случае приоритетной задачей.

Что касается защиты сайта, ну, я уже упоминал способ Google получить подсказку о том, где находятся уязвимости, но на самом деле пришло время вам столкнуться с задачей перемещения ваших sql-запросов один за другим в хранимые процедуры. , или OR / M, или что-то в этом роде. как только вы закончите с этим, вы довольно далеко продвинетесь в наведении порядка в своем грязном источнике.

Если вы знаете, что есть уязвимости, вам обязательно стоит подумать об использовании Брандмауэр веб-приложений который представляет собой фильтр, работающий перед вашим веб-сервером, который пытается предотвратить проникновение злонамеренного ввода и известных атак в ваше приложение / базу данных. Таким образом, вы можете улучшить свою безопасность без необходимости переписывать и проверять устаревшее приложение.

Это не идеальное решение, но в данной ситуации это был бы быстрый способ сразу исправить большее количество уязвимостей безопасности.

1. не паникуйте.
2. поставить сайт на обслуживание.
3. отменить примененную инъекцию sql.
4. исправить ошибку.
5. верните сайт в онлайн.

Не знаю, возможно это или нет, но вы не предоставили подробностей, которые могут понадобиться знающим людям.

• Какой у вас движок базы данных? (включая номера версий)
• Какой у вас веб-сервер? (предположительно IIS, но какая версия?)
• Какой твой любимый ... nvm

Но определенные приложения и номера версий вашего стека превратят это в вопрос, на который кто-то сможет ответить.

В стандартном SQL нет ничего, что могло бы предоставить вам эту информацию, поэтому вам нужны расширения или инструменты администрирования для конкретных поставщиков.

Это сложный вопрос. Чтобы выяснить, что это была за атака и что она могла сделать, я бы посмотрел на ваши журналы IIS, а не на SQL. В зависимости от атаки журнал IIS может точно отображать, что было за sql-инъекцию.

Если нет, я бы немедленно включил ведение журнала IIS (и ведение журнала SQL и любое другое ведение журнала) как можно выше. Возможно, злоумышленник все еще копается, и вы хотите отследить, что он делает, и как можно скорее начать отключать его точки доступа.

Удачи!

Загрузите свой сайт и начните работать над всем снова. После взлома войти в вашу систему будет проще простого.

Любые решения на неполный рабочий день только ухудшат ситуацию в будущем.

Вы также должны предположить, что у этого хакера теперь есть копия всех данных в вашей БД. Если это включает личную информацию, вы должны уведомить соответствующих людей.