Для создателя был он прекрасен,
Сшитый из десятка кусков,
Франкенштейн до чего безобразен,
Но для всех ли он таков?
Сшитый из десятка кусков,
Франкенштейн до чего безобразен,
Но для всех ли он таков?
Дела давно минувших лет, предание старины глубокой...
И снова здравствуйте! Сегодня мое сарафанное радио, после продолжительной паузы, вновь выйдет на сцену для освещения очередного интересно продукта, попавшего на наш операционный стол.
Забавный стишок в начале, не правда ли? Но именно эта ассоциация возникла у меня в самый первый момент. Итак, давайте по-порядку.
Ифреймер "Северная Сказка" Оригинальный топ
Итак... много слов, но мало понятного смысла... Приступим к краткому изложению имеющегося материала.
Историческая справка:
В далекие годы бурной молодости я познакомился с таким человеком как Zer0. Тогда все было интересно и в диковинку. В один прекрасный момент у нас зашел спор на тему «Что написать, чтобы заработать копейку». Вероятно результатом того спора и стал текущий рассматриваемый продукт. Но давайте вспомним с чего все начиналось. На заре написания данного монстра все было прозаично просто. Zer0 писал фрэймер и чекер ftp. Даже сразу чисто чекер вроде бы. Но суть не в этом. Первые продукты имели консольное управление и были довольно примитивны. Хотя и довольно быстры. На тот момент продукт удовлетворял запросы большинства тех пользователей, которым попадался в руки. В один прекрасный момент таким пользователем стал и я. Мне было интересно познакомиться с конкретным коммерческим продуктом. Написано все было изначально на php. Помню мы даже многопоточность прикручивали к этому продукту. Весело было... Затем в жизни автора что-то поменялось и захотелось сделать более качественно. Продукт был полностью переписан на perl. Версия оказалась со своими заморочками. Но, кроме головняка, ничего не принесла, ибо не имела принципиального отличия. Удачным было решение сделать все самостоятельным процессом, что не накладывало лимитов на время исполнения и т. д. Знаю. Сейчас все это звучит смешно, но поверьте, тогда это было чем-то выдающимся, написанным моим другом, форумчанином, хорошим человеком. Но, возвращаясь к теме, не пошло с перлом. И был произведен откат на версию на php. Затем наступило затишье. Долгое затишье и о продукте и авторе я долгое время ничего не слышал. НО! Дело оказывается не стояло на месте. Автор нашел себе хорошую команду специалистов и замутил проект. Когда я его увидел в следующий раз — я ужаснулся. Это был монстр. Очень быстро растущий и набирающий обороты. Раза два я пытался писать обзоры данного софта. Но проблема была налицо. Не успевал я описать какую-нить функцию или провести очередной тест, как все в корне менялось. Помню, раза 4 тесты делал и на утро узнавал, что опоздал с описанием. В итоге для меня месяца два держали и оплачивали сервак, но каждый день заливали свежие версии и я просто заморозил все, т. к. смысла описывать то, чего завтра уже не будет нет. Сейчас у проекта уже воде как третий ребрендеринги его выкупил весьма известный человек под ником severa, и выпустил на рынок под новым названием в свою честь.
!Рис. old version: 2.0
!Рис. old version: 3.3
!Рис. old version: web-version
В далекие годы бурной молодости я познакомился с таким человеком как Zer0. Тогда все было интересно и в диковинку. В один прекрасный момент у нас зашел спор на тему «Что написать, чтобы заработать копейку». Вероятно результатом того спора и стал текущий рассматриваемый продукт. Но давайте вспомним с чего все начиналось. На заре написания данного монстра все было прозаично просто. Zer0 писал фрэймер и чекер ftp. Даже сразу чисто чекер вроде бы. Но суть не в этом. Первые продукты имели консольное управление и были довольно примитивны. Хотя и довольно быстры. На тот момент продукт удовлетворял запросы большинства тех пользователей, которым попадался в руки. В один прекрасный момент таким пользователем стал и я. Мне было интересно познакомиться с конкретным коммерческим продуктом. Написано все было изначально на php. Помню мы даже многопоточность прикручивали к этому продукту. Весело было... Затем в жизни автора что-то поменялось и захотелось сделать более качественно. Продукт был полностью переписан на perl. Версия оказалась со своими заморочками. Но, кроме головняка, ничего не принесла, ибо не имела принципиального отличия. Удачным было решение сделать все самостоятельным процессом, что не накладывало лимитов на время исполнения и т. д. Знаю. Сейчас все это звучит смешно, но поверьте, тогда это было чем-то выдающимся, написанным моим другом, форумчанином, хорошим человеком. Но, возвращаясь к теме, не пошло с перлом. И был произведен откат на версию на php. Затем наступило затишье. Долгое затишье и о продукте и авторе я долгое время ничего не слышал. НО! Дело оказывается не стояло на месте. Автор нашел себе хорошую команду специалистов и замутил проект. Когда я его увидел в следующий раз — я ужаснулся. Это был монстр. Очень быстро растущий и набирающий обороты. Раза два я пытался писать обзоры данного софта. Но проблема была налицо. Не успевал я описать какую-нить функцию или провести очередной тест, как все в корне менялось. Помню, раза 4 тесты делал и на утро узнавал, что опоздал с описанием. В итоге для меня месяца два держали и оплачивали сервак, но каждый день заливали свежие версии и я просто заморозил все, т. к. смысла описывать то, чего завтра уже не будет нет. Сейчас у проекта уже воде как третий ребрендеринги его выкупил весьма известный человек под ником severa, и выпустил на рынок под новым названием в свою честь.
!Рис. old version: 2.0
!Рис. old version: 3.3
!Рис. old version: web-version
BODY
В итоге перед вами результат третьей или четвертой попытки. Давайте же попытаемся понять, что же перед нами?
Перед нами комплексное решение по добыче трафика с имеющихся ftp/shell. Что умеет программа и как она работает я предварительно постараюсь вам написать.
Самая главная функция данного комплекса — это конечно же проверка ваших ftp/shell на валид (для тех кто в танке — проверка на возможность использования). Далее хочется рассказать о фрэймере. Но не все так просто. Это давно не фрэймер... Это своеобразный, живущий собственной жизнью комплекс программ, который определяет, что можно заразить на удаленном сервере, проверяет не подходит ли данный пароль от ftp к службе ssh, если подходит — то используется набор эксплоитов для повышения привилегий, вытягиваются все конфигурационные файлы с логинами и паролями от БД, просматриваются записи БД на наличие вкусняшек, так же на жертву заливается комплекс скриптов, позволяющий получить релей трафика\шелл и т.д Вы полагаете это все? Нет и нет. Далее, в зависимости от cms или имеющихся скриптов, происходит внедрение iframe в нужные участки файлов и в нужных местах, там же внедряется iframe в swf файлы. В общем … жертва берется в полный оборот. Весь трафик направляется на один или несколько полученных релеев. Система имеет комплексную TDS, которая работает напрямую с релеями и управляет трафиком на них прописывая необходимые правила. Если скрипт ифрэйма спалился — он автоматом обновляется на чистый, если домен релея спалился — трафик распределяется на оставшиеся релеи путем обновления внедренных ифрэймов. Трафик подсчитывается и направляется на ваших потребителей. А теперь вопрос. Вы считаете, что это происходит в ручном режиме? Нет. Все доведено до автоматизма.
Что же еще имеется в данном монстре. Ну, например, имеющиеся проксики юзаются сервером для чека следующих ftp/шелов. Напрямую ip сервера не учавствует ни в процессе заражения ни в процессе слива трафика. Все это просиходит только на ip жертв. Единственный момент где светится ip сервера — это первый старт, когда проксиков система еще не успела наделать. К тому же проксики можно юзать в личных целях... Забыл еще написать про проверки на паливо. В систему встроен мощный алгоритм слежения за источниками трафика. Предварительно — в моменты простоя сервер повторно проверяет всю базу гудов/бэдов. Затем софт анализирует не попала ли прокладка в блэк-лист. И в случае если попала, автоматом обновляет фреймы.
Ну и как апогей - имеется биллинговая панель клиента для оперативного пополнения баланса и контроля средств.
Теперь, когде стало более-менее понятно что перед нами, давайте выделим составные части:
1. чекер и анализатор аккаунтов
2. ифрэймер
3. ТДС
4. соксификатор\релей
5. система контроля чистоты трафика и его ресурсов.
Гы. Думаю стало понятней почему же я именно про франкенштейна вел беседу...
Давайте посмотрим на скринах на основные окна данного программного комплекса:
!Рис.1 - биллинг
!Рис.2 - Оплата
!Рис.3 - Главное окно с процессом анализа
!Рис.4 - Главное окно с процессом ифрэйма
!Рис.5 - Главное окно с процессом очистки
!Рис.6 - текущие релеи для трафика
!Рис.7 - поиск по аккаунтам
!Рис.8 - поиск по файлам на жертвах
!Рис.9 - соксы (и оставил для информации параметры сервака)
!Рис.10 - ТДС с трафиком
!Рис.11 - ТДС, схема
!Рис.12 - работа с шелами
!Рис.13 - работа с шелами
!Рис.14 - Дополнительно - чекер
!Рис.15 - Дополнительно - отчеты
!Рис.16 - Дополнительно - шаблоны iframe
!Рис.17 - Дополнительно - Контроль прокси
!Рис.18 - Дополнительно - ssh чекер
!Рис.19 - Дополнительно - swf-ифрэймер
!Рис.20 - Дополнительно - системнеые настройки
!Рис.21 - Дополнительно - upload система
!Рис.22 - Общие настройки
Итак, стоит понять, что же мы можем протестить на данном комплексе...
В первую очередь меня интересовало:
1. скорость работы данного комплекса
2. правильность определения cms и способ внедрения в каждую из них
3. получение трафика
4. уборка после себя (в случае если надо подчиститься)
Приступим к цифрам и тестам..
В наличии сервер со 100mb каналом и белым ip.
Тест1
Начнем с азов. Затестим скорость валидации имеющихся у меня 16К аккаунтов, собранных из разных источников в незапамятные времена (т. е. заведомо у нас много bad-ов)
Всего 16025 аккаунтов
09:26 - включил
10:39 - стоп
Итого - 73 минуты = 4380 секунд
Скорость валидации: 3,66 аккаунта в секунду = 219,5 аккаунта в минуту.
Итог:
1248 - GOOD-ов
14759 - BAD-ов
45 - SSH акков
Аккаунты аккуратно разложились по файлам. Гуды, бэды, ssh, все как положено.
Тест2
Оценим скорость анализатора содержимого имеющихся good-ов из отчеканного списка. При работе данный анализ не обязателен. Система может его производить по-мере фрэйминга. Но раз есть - попробуем.
1248 аккаунтов на входе.
10:46 - старт
10:56 - стоп
11:38 - еще обрабатывает то что было в процессе
10 минут = 600 секунд
2,08 акка в секунду = 124,8 в минуту (это даже не скорость обработки, это скорость создания потоков).
После этой процедуры мы имеем в дополнение к списку гудов, бэдов и ssh, список CMS, alexa_rank, google_pr, yandex_tic, sites_list, ssh_list_full_info, web_scripts_list.
Давайте поймем что нам это дало.
1. у нас появился список имеющихся CMS
2. у нас появились релеи для трафика
3. у нас есть список доменов с их рейтингами (где это возможно)
Тест3
Проифрэймим наш список GOOD-ов
1248 аккаунтов на входе.
11:39 - start
14:56 - еще работает
Определить скорость не удасться, да и глупо это... Сейчас объясню. Чем больше файлов на серваке - тем дольше процесс обработки. Нельзя, по-сути, сделать или вывести цифру с которой обрабатывает один ftp т.к. они сильно отличаются. На одной ftp будет три файла, а на следующей нарвемся на дорвей с 1000 файлов. Разница будет глобально отличаться...
Второй момент - при большом количестве файлов система здорово зависит от скорости канала. Притом в обе стороны. В тесте 100mb/sec. У полноценных клиентов почти поголовно 1Gb/sec каналы. и скорость там значительно выше. Ну и потери на прокси.
Интересное из беседы:
Тест4
Смотрим куда же внедрился «зловредный» код, не сломали ли нам шаблон\cms
давайте для начала узнаем какие cms/скрипты определяет, и под что имеются готовые правила:
Как видно из списка - здесь наборы правил не только под cms. Рулезы написаны и под типы некоторых файлов (swf) и под фрэймворки (Twitter Bootstrap, jQuery).
Но, почему-то заявленных 300 cms я не увидел в списке...
Судя по набору имеющихся в моем списке cms/скриптов, подопытным становится три набора правил из предоставленных мне:
1. Joomla
2. Wordpress
3. Jquery
Я взял ради примера только три сайта. По одному на каждый набор правил.
Смотрим:
Joomla
!Рис.23 - Сайт в списке с определенной CMS
!Рис.24 - Список обработанных на ftp файлов
Wordpress
!Рис.25 - Сайт в списке с определенной CMS
!Рис.26 - Список обработанных на ftp файлов
jquery
!Рис.27 - Сайт в списке с определенной CMS
!Рис.28 - Список обработанных на ftp файлов
Меня в данных тестах удивило очень и очень многое. В частности, если точно определена cms, то по идее фрэймить должно только строго определенные файлы ну или наборы файлов по правилам. И действительно. По джумле мне предоставили рулез, согластно которому, фрэймятся определенные индексы в определенных папках. НО. В некоторых моих тестах я заметил что помимо увиденного правила отработало и js в корне, и часть файлов в папках которые тупо валялись у меня на тестовом сервере. Я задал вопрос ЗАЧЕМ?
Таким образом ответ сводится к тому, что сейчас идет гонка за трафиком. И для полного охвата всего что попадает в монстрика - ему приходится пережевывать все на свете. А отследить версии cms не представляется возможным. Посему часто фрэймится все что попадается под руку.
Второй момент который мне не понравился - это что на многих ftp файлы не фрэймит. Где-то, допустим, не хватает прав... Но на других есть php файлы (хотя это и не сайт, а тупо пользовательские скрипты какие-то) но они доступны. Тем не менее их не тронуло. Логика мне осталась непонятна.
Тест5
Смотрим убрал ли он за собой следы? Не осталось ли что-то где-то?
15:56 - старт
16:12 - стоп.
Как видим из теста - за 16 минут почистило все обработанные ftp. Проверка показала, что тулза пробежалась исключительно по зараженным файлам (список которых естественно сохранился в процессе фрэйминга) и удалила все вставки по ключевым меткам.
Скорость работы естественно благодаря списку очень сильно возрастает. Затраты времени идут только на подключение, скачивание зараженных файлов, чистка вставок, залив обратно на сервер.
Такая обработка напрямую зависит от скорости сервака на котором крутится софт и скорости сервака где лежат зараженные файлы.
Логи:
web-shell
В качестве примера мне были показаны основные принципы работы с web-shell. В теории - все должно быть одинаково как и с ftp. Но, как оказывается, разница есть.
На самом деле все упирается в два нюанса:
1. Права шелла на сервере.
2. Разный принцип обработки.
!Рис.12 - работа с шелами
!Рис.13 - работа с шелами
Давайте определимся в чем же разница более широко.
Итак. Первый пункт - это ограничений прав файла на сервере. Если шелл имеет права более высокого уровня нежели сайт-жертва - он обрабатывает все файлы на сервере по типу. Соответственно фрэймится все, что доступно, включая другие сайты расположенные на этом же сервере, если и они доступны для записи.
Второй момент - это невозможность за всем поспеть. Ввиду того, что шеллам изначально уделялось не столь большое внимание - фрэймятся именно все доступные файл в зависимости от типа. Ни о каком определении cms по-средством шелла в данный момент речи не идет. Но это в планах.
TDS
Теперь подумаем на кой было реализовывать свою ТДС?
Ответ оказался гениально просто. Для того что бы подсадить клиента на систему и предоставить ему все, что может понадобиться. НО, и даже не это все. Оказывается в данный момент идет реализация нового алгоритма отслеживания источников трафика в зависимости от потоков на ТДС. Выражаясь простым языком, имея в распоряжении эту ТДС можно контролировать пофайлово с какого источника и отдельного скрипта на нем идет в частности траф. Т.е. система сохранила список зараженных файлов на серваке. Отследила с каких зараженный файлов идет траф, а с каких нет. Зашла опять на серв и почистила там где нет трафа. Далее, если спалился iframe - чистить код значительно проще, т.к.мест где нужно заменить содержимое значительно меньше. Да и общая палевность значительно уменьшается. Ну что ж... умно... если доделают как обещают.
/BODY
)
