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


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

Допустим вы изучили какую-нибудь дыру, будь то Уникод например или дыры в PHP, но как найти дырявый сайт? Ведь на угад в адресе вводить, что пальцем в небо… Здесь я попробуй рассказать вам как это делаю я и какие способы есть еще.Вы наверняка слышали от кого-нибудь, что : «Оружие хакеров – поисковики!», но не могли этого понять. Я тоже по первости не мог всосать, причем тут по…Допустим вы изучили какую-нибудь дыру, будь то Уникод например или дыры в PHP, но как найти дырявый сайт? Ведь на угад в адресе вводить, что пальцем в небо… Здесь я попробуй рассказать вам как это делаю я и какие способы есть еще.Вы наверняка слышали от кого-нибудь, что : «Оружие хакеров – поисковики!», но не могли этого понять. Я тоже по первости не мог всосать, причем тут поисковики, теперь всосал =). Давайте подробно разберем пример на поиске дырявых PHP. На самом деле все очень просто. Ну во-первых, нужно найти php страницы, для этого в поиске вводим:

Index.php

Теперь подумаем, сколько же сайтов в инете на php написано? Очень много, нужно как-нибудь укоротить найденное. Например добавим домен, если вы хотите искать только русские php сайты то запрос будет выглядеть примерно так:

.ru/index.php

Вот, количество найденных сайтов сократилось, но убрались лишь не нужные нам, что дальше… А дальше вот что. Дыра эта, про которую я уже писал, не в самой php, а в PHP-Nuke, ага, значит добавим запрос следующим образом:

.ru/index.php & nuke

Теперь поисковик будет искать все русские php сайты/порталы и из найденных выберет все, которые Nuke =). Далее читаем мою статью (Хакерство-Интернет-Админ-портала…) и проверяем найденное на вшивость. Вот и все!Как это делают другие. Вообще я знаю два способа, это вышеописанный и с помощью РОБОТОВ. БОТы, это специальные проги, которые дают ваш запрос на поисковики и возвращают результат, что очень экономит время поиска дыр. Сам я о них знаю мало. Если кто знает больше, в смысле, их точный алгоритм плиз говорите, я собираюсь написать БОТ, для участников HackZona. Дело в том, что в инете я найти их не мог, если кто знает ссылки, тоже скидывайте.Теперь пара советов. Во-первых, лучше всего искать на домене com, он более большой, отсюда и больше уязвимых сайтов. Во-вторых, поиск можно ограничивать до бесконечности, например, если вам нужны лишь порталы знакомств, то запорс будет выглядеть примерно так:

.ru/index.php & nuke & знакомства и т.д.

В-третьих, искать лучше всего на www.google.com и www.yahoo.com, в этом деле они рулят! Русские поисковики пока годны лишь для поиска статей :(. И на последок, я могу ошибаться в этой статье, но все вышеописанное работает на 100%. Если есть какие недочеты или не точности, скидывайте плиз в комментарий!Вот вроде и все, удачного вам поиска!

v-zlom.cc

Через какую дыру взломали сайт? / Блог компании Sprinthost / Хабр

Если сайт взломан, мало удалить с него вирус и загруженный 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/sh3
Эти файлы могут быть расположены как в корне сайта, так и в папке 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, убедившись, что уязвимый компонент также обновился, после чего снова открыть доступ к сайту.

habr.com

Взломали сайт. Где и как искать дырку? / Вопросы / MODX.im

С рассказами о том, что «движок дырявый и я его буду чинить за ваши деньги» чаще всего будешь заказчиком послан. С другой стороны — сломают — начнет заказчик ныть, что ему бесплатно должны чинить, раз такой движок поставили дырявый (мол надо было ставить другой, чего мы подсунули и так далее).Вас так послушаешь и начинаешь думать, что все клиенты сплошные нытики которым важно качество кода и безопасность. Конечно, если клиенту объяснять, что его сайт дыряв и нужно обновляться за деньги, то возникает куча вопросов. Но когда клиенту объясняют, что в движке найдена уязвимость и желательно бы обновиться. А это ваше время как программиста. То вопросов быть не должно.

Более того, уязвимость в движке — это не недоработка конечного программиста, который реализовывал нужный функционал на сайте. Сколько таких случаев было, когда какой-нибудь производитель выпускал партию телефонов с бракованной прошивкой. Что быть тем, кто уже успел купить? Обновляться самостоятельно, т.к. ПО не попадает под гарантийное обслуживание.

Развиваем ситуацию дальше. Что такое сайт под ключ у большинства веб-студий?

  • Дизайн
  • Верстка
  • Проверка корректности отображения в браузерах
  • Программирование
  • Тестирование функциональности
  • Копирайтинг
  • Наполнение сайта
А вот теперь вам, и многим другим, согласным с вашей позицией вопросы, после которых бред про заказчиков которые отказываются от какой-то CMS из-за каких-то топиков в которых рассказывается про какие-то уязвимости, лично я буду пропускать мимо ушей, если конечно оратор не делает визитки из 3-4 страниц за 1000$
  • В течении какого периода после сдачи проекта разработчик обязуется фиксить баги пропущенные во время тестирования?
  • Клиенту важно удобство админки или все-таки безопасность?
  • Где в этапах разработки «Аудит безопасности»?
  • Кто-то вообще заказывает «Аудит безопасности» дополнительно у сторонних подрядчиков, если так заморачивается про безопасность?
А теперь откройте хабр:Если я сайт сделал на WordPress неделю назад — я должен его на халяву обновлять? А если пол года/год/два? Популярность этих движков вообще хоть снизилась из-за этих уязвимостей?А вот наличие готовых рецептов взлома в открытом доступе — это прямой призыв к любому начинающему «хакеру» — «пойди, взломай, поржем вместе» ))Есть руководства как нужно писать код, а есть руководства как код писать нельзя. Если человек посты с описанием уязвимостей воспринимает как руководство к действию, то я думаю этот человек понимает что УК РФ тоже действует. При чем как правило, показательную порку «хакеров» устраивают именно с новичками, т.к. более матерых сложнее вычислить.

У меня еще много мыслей есть по этому поводу. Но на мой взгляд вы мыслите однобоко и далеко не как менеджер. Но при всем при этом размышляете на темы менеджмента: «двиг уязвим — я теряю клиентов» или же «Двиг уязвим — меня наеХал программист». Попробуйте думать так: «Двиг уязвим — на этом можно заработать» или же «Двиг уязвим — нужно проконсультироваться как максимально обезопасить себя от взломов». Подумайте на досуге об этом.

Уже хотел заканчивать, но все-таки добавлю. Большинство клиентов вообще не просматривают блоги и форумы для программистов/разработчиков. И уж тем более не мониторят сайты типа http://www.securityfocus.com/. От куда им вообще узнавать про уязвимости и необходимость обновляться, кроме как не от конкретного разработчика? И это при всем при том, что кидисы зарабатывающие на взломах мониторят эти сайты регулярно! Вот вы, как программист часто мониторите дырки/фиксы дырок в движках с которыми работаете? Как оперативно вы узнаете о багах и принимаете решение, что нужно срочно обновляться? Так что вы еще должны спасибо говорить тем людям, которые на каждом углу кричат про критическую уязвимость. А не сидеть в танке боясь спугнуть клиента своей некачественной работой. Или быть может она на самом деле не качественная и есть чего бояться, при чем далеко не из-за дырявого движка на котором работает сайт?

P.S. Без обид, в конце был риторический вопрос.

modx.im

Как найти уязвимость на сайте раньше хакера

Александр Чернуха - лечение сайтов от вирусовСегодня хочу представить вам своего коллегу, который прекрасно знает, как найти уязвимость на сайте и надежно ее залатать. Моя сфера – оптимизация сайтов, Александр Чернуха же специализируется на лечении веб-ресурсов от заражения вирусами и установке защиты на них от разного рода действий хакеров (ссылка для нуждающихся в услугах: https://protectyoursite.ru/установка-защиты-на-сайт.

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

Найти уязвимость на сайте – проще не бывает

Автор Александр Чернуха

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

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

Конечно, не последнюю роль в этом случае играет и правильная настройка файла robots.txt для закрытия от индексации системных путей. Однако сейчас речь пойдет о другом.

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

Чем опасны шеллы

Специальные боты находят дыру на сайте и закидывают в неприметное место вирусный файл удаленного исполнения – шелл (shell). После этого о сайте на время забывается – в среднем, на месяц: этого срока хватает, чтобы логи взлома удалились и резервные копии переписались на файлы с вирусом. После такого “испытательного срока” вирус активизируется и начинает незаметно делать свою работу.

Пересмотрели свою работу и поисковые системы. Если раньше на сайте был вредоносный код, то можно было его сразу убрать и отправить запрос в вебмастере на исправление ситуации, и через день-два сайт снова в строю.

В последнее время стало популярно на сайте располагать дорвеи – создание на домене тысяч новых страниц для черной SEO-оптимизации. Такой вирус СЕО очень быстро проиндексируется не только известными и популярными поисковиками СНГ, но зачастую и китайскими или другого рода зарубежными агрегаторами.

Найти уязвимость на сайте

Последствия взлома сайта

Впоследствии Гугл и Яндекс сделают к вашему сайту пометку “Возможно, этот сайт был взломан” и понизят или выкинут из выдачи. В этом случае вывод сайта из черного списка может затянуться на несколько недель и даже месяцев.

Ссылки на взломанные страницы

Ссылки на взломанные страницы в индексе более 6 месяцев

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

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

Поэтому важно не только оперативно находить вирусы на сайте, а также предотвращать их попадание. Если нет достаточных знаний по установке и настройке правильной защиты сайта, то стоит обратиться к опытным специалистам безопасности.

nadezhdakhachaturova.ru