1

Тема: Взлом САНТИ

Есть множество аналогичных продуктов, в том числе реализованных в виде компонентов/модулей для различных CMS. Во многих продуктах при сканировании сохраняются CRC файлов, по которым проводится сравнение. Однако, если взломщик получает доступ к файловой системе, следовательно, он получает доступ и базе данных или файлу, в котором хранятся хеши. В этом случае достаточно записать шелл в файл, сделать новый хеш и записать его в базу данных. Тогда повторное сканирование не выявит изменений. Как решается эта проблема в САНТИ?

Re: Взлом САНТИ

SeBun пишет:

Есть множество аналогичных продуктов, в том числе реализованных в виде компонентов/модулей для различных CMS. Во многих продуктах при сканировании сохраняются CRC файлов, по которым проводится сравнение. Однако, если взломщик получает доступ к файловой системе, следовательно, он получает доступ и базе данных или файлу, в котором хранятся хеши. В этом случае достаточно записать шелл в файл, сделать новый хеш и записать его в базу данных. Тогда повторное сканирование не выявит изменений. Как решается эта проблема в САНТИ?

Помимо CRC мы ещё храним вес файла, дату изменения и его права. Это усложняет задачу и жизнь взломщику, понадобится переписать все значения.
Но гипотетически Ваш сценарий возможен, хоть и будет очень трудозатратным.
На будущее у нас есть план перенести хранение одного из показателей по файлам сайта на свои сервера (CRC, Вес, Дату).

3

Re: Взлом САНТИ

В последнее время я наблюдаю взломы сайтов имеено на уровне хостеров, в основном это те, кто предоставляет недорогой хостинг. Взлом делается автоматически, заражаются все сайты аккаунта. Для взломщика оказывается не проблемой сменить права на файл и произвести запись в него. Таким образом, зная алгоритм хранения данных, их легко подделать. Даже если вы выносите базу за пределы сайта, например на свои сервера (а в этом случае на их обслуживание нужен грамотный админ), остается нерешенным вопрос с динамическими данными. К примеру, это аватарки, кэш, добавление пользователями файлов или картинок к материалам и т.д. Единственное решение, которое вы сможете в этом случае принять - игнорировать каталоги динамических данных. Следовательно, если я, к примеру, размещаю в таком каталоге свои скрипты, они будут проигнорированы. Вы можете предложить различные пресеты настроек для каждого движка, но пользователи устанавливают различные, порой очень дырявые расширения, модули и т.д. Как вы решаете этот вопрос?

Re: Взлом САНТИ

SeBun пишет:

В последнее время я наблюдаю взломы сайтов имеено на уровне хостеров, в основном это те, кто предоставляет недорогой хостинг. Взлом делается автоматически, заражаются все сайты аккаунта. Для взломщика оказывается не проблемой сменить права на файл и произвести запись в него. Таким образом, зная алгоритм хранения данных, их легко подделать. Даже если вы выносите базу за пределы сайта, например на свои сервера (а в этом случае на их обслуживание нужен грамотный админ), остается нерешенным вопрос с динамическими данными. К примеру, это аватарки, кэш, добавление пользователями файлов или картинок к материалам и т.д. Единственное решение, которое вы сможете в этом случае принять - игнорировать каталоги динамических данных. Следовательно, если я, к примеру, размещаю в таком каталоге свои скрипты, они будут проигнорированы. Вы можете предложить различные пресеты настроек для каждого движка, но пользователи устанавливают различные, порой очень дырявые расширения, модули и т.д. Как вы решаете этот вопрос?

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

5

Re: Взлом САНТИ

Igor Mitrofanov пишет:

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

Я с вами соглашусь, за исключением одного - именно формат png может содержать в своем коде вредоносный php-код. Кроме того, кеш пишется в формат php (в основном). Получается, как ни крути, нужен какой то сканер, который по известным сигнатурам будет перебирать содержимое файлов. Но как раз это решение и будет ловушкой, т.к. придется постоянно следить за активностью хакеров и выявлять эти самые сигнатуры, что позволит реагировать только на старые приемы, а не на новые.

6

Re: Взлом САНТИ

Очень распространенный сценарий взлома: на CMS через дырявый компонент или функционал какой нибудь сторонней галереи, дырявую админку, повышением прав, загружают первым делом шелл с расширением jpg (или другим картиночным) и потом переименовывают. Я с этим часто встречаюсь. Поэтому jpg может и имеет смысл проверять.

7

Re: Взлом САНТИ

optimus пишет:

Поэтому jpg может и имеет смысл проверять.

Как вы себе представляете такую проверку? Например, у пользователя полмиллиона файлов картинок в галерее весом около 2 Гб. Сколько времени займет проверка и насколько она будет эффективна? Кроме того, если бы я ломал сайт, я бы, получив доступ к файловой системе и залив шелл, через него записал бы куда нибудь либо бэкдор, либо что то еще, а следы удалил. Причем, получив возможность на запись, я буквально контролирую всю систему и могу влиять на результаты проверки, например, запустив демона, который будет висеть в памяти и выполнять нужную работу. Тут другой подход нужен.

Re: Взлом САНТИ

optimus пишет:

Очень распространенный сценарий взлома: на CMS через дырявый компонент или функционал какой нибудь сторонней галереи, дырявую админку, повышением прав, загружают первым делом шелл с расширением jpg (или другим картиночным) и потом переименовывают. Я с этим часто встречаюсь. Поэтому jpg может и имеет смысл проверять.

ну так переименование будет в любом случае в исполняемый файл - php/pl и прочее. А его-то мы просканируем.

9

Re: Взлом САНТИ

SeBun пишет:
optimus пишет:

Поэтому jpg может и имеет смысл проверять.

Как вы себе представляете такую проверку? Например, у пользователя полмиллиона файлов картинок в галерее весом около 2 Гб. Сколько времени займет проверка и насколько она будет эффективна? Кроме того, если бы я ломал сайт, я бы, получив доступ к файловой системе и залив шелл, через него записал бы куда нибудь либо бэкдор, либо что то еще, а следы удалил. Причем, получив возможность на запись, я буквально контролирую всю систему и могу влиять на результаты проверки, например, запустив демона, который будет висеть в памяти и выполнять нужную работу. Тут другой подход нужен.

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

Может дело в том, что продукт больше рассчитан на небольшие сайты, тк php не совсем быстрая штука в работе с файлами. Сайты с миллионами картинок сканировать на изменения можно простым файлом на баше, имхо и только так.