Вордпресс взлом – Взлом сайта на wordpress или как защитить блог от взлома » Как создать сайт, расскрутить его и заработать с seodengi

Содержание

Хак сайта на WordPress, кому все это нужно и советы как этого избежать / Habr

Привет хабраUser!


Эта история началась около 2-х месяцев назад, когда мой хороший друг Александр, оказывающий услуги хостинга, при очередной проверке всех виртуальных машин антивирусом обнаружил подозрительный .js файл в корневой директории моего сайта, в VDS которую обслуживаю я сам, тогда я не придал этому значение… Но думаю любой администратор хостинга сразу забеспокоился бы.
Закончилось все, спустя только 2 месяца, после блокировки моего сайта корпорацией добра:
По тексту, я хочу рассказать Вам:

Краткое содержание:

Взлом, дальше с VDS начали происходить интересные вещи: Спам рассылки по нескольким тысяч адресатов, установка подозрительных скриптов, появление странных файлов в корне основного сайта. Скажу честно — было страшно… Но похоже я победил тьму).
Вступление:

Я пишу эту статью, еще и как записную книжку, что бы можно было к ней вернуться в случае повторения проблем. Кому интересен процесс борьбы со зловредами, он будет описан ниже. Букв будет много, поэтому, кому нужны практические советы — листаем до конца.
Как взломали мой сайт на моем же хостинге на Debian Wheezy или Хак сайта на WordPress и кому все это нужно

С какими проблемами я сталкивался и как воспринимал их.

Я успокоился сразу после того как не нашел тот самый js скрипт у себя на сайте. Сейчас понимаю, что это было роковой ошибкой.
Мой сайт крутится на Debian Wheezy, установлена панель управления хостингом i-mscp (преемница ispcp), есть еще несколько сайтов, тоже личные, поэтому администратор я один и ни кому не даю доступ на свою VDS.

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

Зачем тебе нужные все эти плагины\расширения\скрипты?

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

Прошло 2 недели, после того как я не отреагировал на первую угрозу. Я поимел следующую проблему.
Сижу на работе, и вдруг, мне в почту gmail, в папку spam начинают падать сообщения от моего почтового сервера postfix (там у меня настроена пересылка на личную почту) о том что, такое то сообщение не доставлено. Примерно 50 сообщений, о недоставке, в секунду.
Захожу на сервер и смотрю лог:
tail -f /var/log/mail.log

А там просто неимоверная скорость записи сообщений, останавливаю почтовик:
/etc/init.d/postfix stop

Спам прекращается, пытаюсь выяснить как идет рассылка, но из-за нехватки опыта ни чего не понимаю.
Опытным путем удается выяснить, что если переименовать корневую директорию основного (sysrtfm точка ру) сайта или заблокировать домен в панели управления хостинга, то спам прекращается.
Приходит осознание того, что подломали основной сайт, но как?
Очищаю ВСЮ очередь почтовика на всякий:
postsuper -d ALL
(удаляется ~10000 писем)
часов 8 проверял руками директории сайта на наличие левых скриптов, отключал все плагины, запускал почтовик и снова получал рассылку( грустная рожица

Тут случайно, в корневой директории сайта, обнаруживаю папку css с файлом /css/sys0972500-1.php. Зная примерную структуру своей CMS, понимаю, что его такого файла быть не должно. Скачиваю резервную копию за прошлый месяц, распаковываю, и вижу, что файла там точно быть не должно. Как он там оказался? Этот вопрос пока без ответа, но права у него такие же как у остальных файлов.
Читаем лог апача:

tail -f /var/log/apache2/sysrtfm.ru.log

и видим там:
"POST /css/sys0972500-1.php HTTP/1.1" 404 55665 "-" "-" 

почти каждые 30 секунд.
Видимо кто то запускает этот скрипт издалека, инициируя рассылку.
Казалось бы, заблокировать IP и все, но он почти так же часто меняется. Удалил директорию с файлом, рассылки прекратились. Не приняв, практически, ни каких противодействий, т.к. не понял как произошёл взлом, оставил проблему как есть. Только сменил рутовый пароль на более сложный и по отключал плагины и скрипты которыми уже не пользуюсь.

Следующей обнаруженной проблемой стало, то что, на столько популярный движок WordPress, что его пытается подломать все кому не лень. Почитав логи Apache2, понял, что идет постоянная brute-force login attack на форму входа в административную панель. Но т.к. я об этом давно подозревал, у меня уже был установлен плагин блокировки пользователя после нескольких неудачных попыток входа (User Locker).

tail -f /var/log/apache2/sysrtfm.ru.log

видим там:
"POST /wp-login.php HTTP/1.0" 200 6891 "http://sysrtfm.ru/wp-login.php" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"

С очень высокой периодичностью. Защита от этого метода атаки, это тема для отдельного разговора. Тут я пока поставил дополнительный плагин, блокирующий атакующего по ip адресу после нескольких попыток входа.
Проблема номер три

Прошло 3 недели без спама и левых скриптов.
Зашел на VDS проверить логи и обнаруживаю, что в корне сайта все тот же файл, и опять запускается рассылка, но в гораздо меньших объемах… Взялся за голову.
Начинаю сканировать сайт online антивирусами:

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

Задача: очистить очередь отправлений и обнаружить причину.
Решение: вариантов, конечно, много. Рассмотрим один из них.

1. Подключаемся по SSH и смотрим очередь писем:

mailq

Да, писем много.

2. Отключаем почтовый сервер (стоит postfix)

/etc/init.d/postfix stop

3. Смотрим на соединения на 25й порт:

netstat -apn | grep :25

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

4. Очищаем очередь писем
Exim:

exipick -i | xargs exim -Mrm

Postfix:
postsuper -d ALL

Sendmail:
rm -rf /var/spool/mqueue/*

Конечно, при условии, что мы это сделать можем (в очереди могут быть реальные письма реальным пользователям).
postsuper -d ALL
postsuper: Deleted: 72849 messages

5. Пробуем включить расширенное логирование почты:

mv /usr/sbin/sendmail /usr/sbin/sendmail.org
touch /usr/sbin/sendmail
chmod +x /usr/sbin/sendmail
echo -n '#!/bin/bash
logger -p mail.info sendmail-ext-log: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}, pwd=${PWD}, uid=${UID}, user=$(whoami)
/usr/sbin/sendmail.org -t -i' > /usr/sbin/sendmail

6. Запускаем почтовый сервер

/etc/init.d/postfix start

7. Смотрим логи

tail -f /var/log/mail.info

Видим что-то вроде:
Jan 23 16:25:25 danma logger: sendmail-ext-log: site=, client=, script=send.php, pwd=/var/www/danma/data/www/site.ru, uid=33, user=www-data
Jan 23 16:25:25 danma postfix/pickup[11520]: E3CD259403D: uid=33 from=
Jan 23 16:25:25 danma postfix/cleanup[11522]: E3CD259403D: message-id=

Обращаю внимание, что это один из вариантов действий.
Если есть ID письма в жалобе — стоит посмотреть его в логах отправлений.
Бывает так, что на сервере стоит опенрелей.

А еще бывает, что просто подобрали пароль к ящику — на это так же стоит обратить внимание!


Взято от сюда, Автору спасибо!

После включения логирования я увидел, что спам рассылка запускается от этого скрипта (/css/sys0972500-1.php), но это было уже после того когда файл с директорией css появился в 3-й раз…
Как все таки меня подломали? Где? пока я это выяснял меня заразили еще чем то…

Проблема номер четыре

В этот раз мне написал друг, сказав, что на мой сайт его не пускает антивирус касперского,

а с другого компа не пускает гугл хром, показывая ту самую красную заглушку из шапки этой статьи… Я был очень огорчен увидев, что гугл забанил мой сайт, написав в панели инструментов вэбмастера примерно следующее:
“С вашего сайта производилась установка вредоносного ПО на клиентские ПК пользователей. Ссылки с которых производилась установка ниже:
Несколько ссылок с сайта”

Яндекс ни чего не подозревал…

Сразу скажу, проблему получилось победить достаточно быстро. Вот что я делал:

  1. Отключил кэширующий плагин CMS, для того чтобы файлы генерировались снова, а не брались вредоносные из кэша
  2. Еще раз проверил сайт по базам online антивирусов, реально пригодился больше всего вот этот antivirus-alarm ru
  3. т.к. в этой проверке было написано:
    содержит сомнительную ссылку по версии гугла: feeds feedburner com
    содержит сомнительную ссылку по версии гугла: www facebook com
    содержит сомнительную ссылку по версии гугла: www liveinternet ru

    То снова по отключал пачку сторонних плагинов WordPress, социальные кнопки, комментарии итд…
    Переход на сайты соц сетей, куда был кроспостинг моих статей были так же запрещены гуглом, из-за того, что там содержались материалы с моего сайта
  4. Создал запрос в тех поддержку гугл на пересмотр решения о блокировке (на той же странице где описана причина блокировки, раздел “Проблемы безопасности”)
  5. Заполнил форму для сообщения о неверном предупреждении о фишинге.
  6. Т.к. 2 последних пункта рассматриваются 24 часа, я начал активно искать причину возможного взлома. Тут до меня доходит, что я не проверял ftp!
  7. Читаем лог proftpd сервера:
    cat /var/log/proftpd/xferlog
    

    находим там очень интересное:
    176.28.52.119 42278 /var/www/virtual/sysrtfm.ru/htdocs/css/sys0972500-1.php a _ i r [email protected] ftp 0 * c
    

    И тут я все понял….(грустный смайлик( подломали аккаунт [email protected], я быстро поменял пароль и логин. А так же заблокировал все остальные ftp аккаунты. Проверив, что они ни где не задействованы.
    Нашел еще запись:
    31.7.234.34 0 /var/www/virtual/sysrtfm.ru/htdocs/css/c3x.php b _ o r [email protected] ftp 0 * c
    

    Это все из той же оперы, файлы удалил, но причина блокировки была не в этом.
  8. Дальше завел тему в форуме технической поддержки вэбмастеров гугл тут.
    Там добрые люди, нашли в скриптах, загружаемых с сайтом интересные вещи)
    Что сделал зловред:
    — Модифицировал через ftp файл wp-content/plugins/usernoise/js/usernoise.js приписав в самый конец еще один скрипт: /wp-includes/images/smilies/skynet.js
    Оказалось, что этот скрипт выполнялся только если браузер не гугл хром, загружая на ПК пользователя вредоносное ПО.
    — Затем был заражен файл /wp-content/plugins/lazy-load/js/lazy-load.js в который был прописан скрипт /wp-includes/images/crystal/gocubs.js
  9. Скачал программой WinSCP сайт на свой локальный диск, запустил total commander, перешел в скачанную директорию и запустил поиск выражений по всем файлам:
    cr"±"ipt
    skynet.js
    doc​ument.write
    

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

Спустя 12 часов гугл разблокировал мой сайт, но статистика все равно просела(
Сейчас проблема решена, но теперь я сделал много выводов….
Как нужно было бы реагировать на самом деле.

Сейчас я понимаю, что таких проблем на сайтах любого уровня допускать нельзя, от этого зависит не только ваша безопасность и финансовое положение, но и наиболее важная финансовая безопасность ваших клиентов…
Если бы я отреагировал правильно еще 2 месяца назад, на сообщение моего друга о найденном подозрительном файле js в папке с картинками. Все было бы иначе.
Это стало мне серьезным уроком и теперь я буду более серьезно смотреть на такие вещи! Чего советую и всем начинающим вэб программистам и не только!
Кто мне помог в решении проблем и в чем заключалась помощь

  1. Александр Крайнев — техническая и моральная поддержка, подсказки и советы, хостинг с защитой от ddos (itservices.su) на котором лежит мой сайт.
  2. Google аналитика — не только инструмент для SEO, но и средство поиска уязвимости. Там я смотрел куда чаще всего стучатся пользователи, как и в более примитивном инструменте статистики сайта AWStats. Например у меня, в топ 10 посещаемых страниц входит в первое место страница авторизации WP)))) как не странно тот самый брут форс, нужно что то с этим делать.
  3. Форум инструментов вэбмастеров гугл — очень полезная, оказалось, штука!, всем советую.
  4. Панель отладки Google Chrome — без нее я вообще ни чего не сделал бы… (жмем F12 на исследуемой странице и исследуем исследуем исследуем).
  5. Putty, WinSCP, TotalCommander — как без них) всегда под рукой!
Какие выводы я сделал для себя, оказавшись на грани срыва

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

Кому все это нужно? Все эти атаки, вирусы, шпионские программы? Многие знают ответ на эти вопросы. Я опишу свою точку зрения:

Есть множество людей\программистов\зловредов которые зарабатывают на том, чтобы предоставить ресурс для рекламных площадок или собирают информацию для ее дальнейшего использования все в тех же рекламных целях. Я думаю, что большинство атак на сайты и зловредных программ существуют для этих целей.
Рекламные компании в последующем покупают этот ресурс, чтобы подороже продать своим клиентам эту рекламную площадку.
Только представьте сеть из 100000 взломанных сайтов на бесплатном движке для блога — их взломал программист-зловред. Продал этот ресурс рекламной компании, рекламная компания готовит материал или ссылки для публикации, а программист в несколько кликов запускает всю эту компанию на взломанных сайтах, этот огромный трафик приносит колоссальные деньги по всему интернету.
Естественно возможных применений может быть масса, от безвредных школьников, которые просто учатся взламывать, до установки вредоносного ПО и кражу личных данных пользователей (передача 3-им лицам параметров кредитных карт, логинов и паролей от соц сетей) Все это носит глобальный характер и программисты-зловреды постоянно ищут уязвимости сайтов и популярных ресурсов.

Практические советы

Таких советов в интернете великое множество, я соберу тут действительно стоящие ИМХО:
  1. Никогда, ни в коем случае не оставляйте стандартные и простые имена пользователей для авторизации на своих сервисах (admin, user, login, administrator итд). Это позволит повысить защищенность на 50% минимум. Плюс к этому используйте капчу или проверку на человечность;
  2. Всегда делайте бэкап, тут не может быть вопросов, резервная копия должна быть всегда! Я например делаю РК локально и раз в ночь сливаю скриптом на яндекс диск через Webdav, а с диска раз в неделю перемещаю все на домашний компьютер:
    Bash скрипт монтирования ЯД, копирования РК и отправки уведомления:
    #!/bin/sh
    # время, когда запускается бэкап
    STARTB="`date +%Y-%m-%d-%H:%M:%S`" 
    # расположение резервных копий
    BACKUPDIR1="/var/www/virtual/sysrtfm.ru/backups/"
    # куда смонтирован яндекс диск
    YDISK="/mnt/yandex.disk"
    # папка на яндекс диске в которую копируем РК
    BTDIR="siteback"
    # путь до папки для РК на ЯД
    TARGETDIR="${YDISK}/${BTDIR}/"
    DATETIME="`date +%Y-%m-%d-%H_%M_%S`"
    # уникальное имя логфайла
    LOGFILEDATE="`date +%Y%m%d`"
    # путь до логфайла
    LOGFILE="/var/log/backupall-${LOGFILEDATE}.log"
    echo `date +%Y-%m-%d-%H:%M:%S`" старт бэкапа" >> $LOGFILE
    # размонтируем диск на всякий пожарный
    umount -f $YDISK >> $LOGFILE
    # монтируем ЯД
    echo `date +%Y-%m-%d-%H:%M:%S` "монтируем ${YDISK}" >> $LOGFILE
    mount -t davfs https://webdav.yandex.ru:443 $YDISK >> $LOGFILE
    #запуск РК
    echo `date +%Y-%m-%d-%H:%M:%S` "бэкапим в ${TARGETDIR}${DATETIME}" >> $LOGFILE
    mkdir ${TARGETDIR}${DATETIME} >> $LOGFILE
    cd $BACKUPDIR1 >> $LOGFILE
    cp -r -f -p * ${TARGETDIR}${DATETIME} >> $LOGFILE
    umount -f $YDISK >> $LOGFILE
    #отправляем админу уведомление
    ENDB="`date +%H:%M:%S`"
    # тема сообщения
    STARTEND="Backup script Start of ${STARTB} End of ${ENDB}"
    mail -s "${STARTEND}" [email protected] < $LOGFILE
    exit
    


  3. Как бы это не банально звучало, но теперь я всем советую генерировать или придумывать гораздо более сложный пароль. Пароли можно хранить или в блокнотике (АНикиБеники туда не доберутся) или запомнить с 10 раза. Но в любом случае это проще чем восстанавливать доступ и решать проблемы из-за утечки информации;
  4. Если используете популярные web скрипты или CMS, следите за их обновлениями т.к. дырки есть всегда. Старайтесь не использовать не проверенные скрипты без отзывов. Не используйте старые и не поддерживаемые WEB скрипты;
  5. Всегда есть возможность защитить административный WEB интерфейс либо плагином, либо настройкой авторизации через .httpasswd (мастер генерации таких файлов, которые просто нужно положить в защищаемую директорию)
  6. Если есть возможность включения SSL доступа к вашим сервисам — включите его! SFTP, HTTPS, Четыре шага в защите SSH;
  7. Берегите свою почту, на которую все завязано! Сильный пароль, двухэтапная авторизация маст хэв!

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

PS:

И так, я победил тьму, и я очень рад) опыт накоплен, сайт работает, система живет) осталось теперь только обсудить это с уважаемым сообществом habrahabr, но для ответа в комментариях мне нужен инвайт, поэтому я прошу НЛО запостить эту статью и подарить мне на Новый Год инвайт)
И я тогда, в свою очередь, зарегистрируюсь в проекте анонимных дедов морозов и подарю залежавшиеся полезные мелочи Хабраюзерам:

С Уважением Иван Левкин.

Термокружка Canon EF 24-105 с блендой — точная копия одноименного объектива. Кружка оснащена металлической термоколбой для сохранения постоянной температуры напитков, а так же герметично завинчивающейся крышкой с резиновой прокладкой.

Compact Slim Retractable Cable Style USB 2.0 Optical Mouse — Black (80CM-Cable)

EDUP Ultra-Mini Nano USB 2.0 802.11n 150Mbps Wifi/WLAN Wireless Network Adapter

Простой способ взлома популярных CMS (WordPress, Joomla, DruPal и другие)  

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

Программа XAttacker умеет искать сайты по доркам (через Bing) или работать с вашим списком сайтов, затем автоматически определяет CMS у каждого сайта и проверяет наличие популярных уязвимостей. Поддерживаемые системы управления контентом: WordPress, Joomla, DruPal, PrestaShop и Lokomedia. Если уязвимость найдена, то на сайт закачивается шелл.

Поскольку проверки полностью автоматизированные, а список знакомых программе уязвимых плагинов ограничен, то самое очевидное применение программы:

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

Программа знает о таких уязвимостях как:

[1] WordPress :

  • [+] Adblock Blocker
  • [+] WP All Import
  • [+] Blaze
  • [+] Catpro
  • [+] Cherry Plugin
  • [+] Download Manager
  • [+] Formcraft
  • [+] levoslideshow
  • [+] Power Zoomer
  • [+] Gravity Forms
  • [+] Revslider Upload Shell
  • [+] Revslider Dafece Ajax
  • [+] Revslider Get Config
  • [+] Showbiz
  • [+] Simple Ads Manager
  • [+] Slide Show Pro
  • [+] WP Mobile Detector
  • [+] Wysija
  • [+] InBoundio Marketing
  • [+] dzs-zoomsounds
  • [+] Reflex Gallery
  • [+] Creative Contact Form
  • [+] Work The Flow File Upload
  • [+] WP Job Manger
  • [+] PHP Event Calendar
  • [+] Synoptic
  • [+] Wp Shop
  • [+] Content Injection
  • [+] Cubed Theme NEW
  • [+] Rightnow Theme NEW
  • [+] Konzept NEW
  • [+] Omni Secure Files NEW
  • [+] Pitchprint NEW
  • [+] Satoshi NEW
  • [+] Pinboard NEW
  • [+] Barclaycart NEW

[2] Joomla

  • [+] Com Jce
  • [+] Com Media
  • [+] Com Jdownloads
  • [+] Com Fabrik
  • [+] Com Jdownloads Index
  • [+] Com Foxcontact
  • [+] Com Ads Manager
  • [+] Com Blog
  • [+] Com Users
  • [+] Com Weblinks
  • [+] mod_simplefileupload
  • [+] Com Facileforms NEW
  • [+] Com Jwallpapers NEW
  • [+] Com Extplorer NEW
  • [+] Com Rokdownloads NEW
  • [+] Com Sexycontactform NEW
  • [+] Com Jbcatalog NEW

[3] DruPal

  • [+] Add Admin
  • [+] Drupalgeddon NEW

[4] PrestaShop

  • [+] columnadverts
  • [+] soopamobile
  • [+] soopabanners
  • [+] Vtermslideshow
  • [+] simpleslideshow
  • [+] productpageadverts
  • [+] homepageadvertise
  • [+] homepageadvertise2
  • [+] jro_homepageadvertise
  • [+] attributewizardpro
  • [+] 1attributewizardpro
  • [+] AttributewizardproOLD
  • [+] attributewizardpro_x
  • [+] advancedslider
  • [+] cartabandonmentpro
  • [+] cartabandonmentproOld
  • [+] videostab
  • [+] wg24themeadministration
  • [+] fieldvmegamenu
  • [+] wdoptionpanel
  • [+] pk_flexmenu
  • [+] pk_vertflexmenu
  • [+] nvn_export_orders
  • [+] megamenu
  • [+] tdpsthemeoptionpanel
  • [+] psmodthemeoptionpanel
  • [+] masseditproduct
  • [+] blocktestimonial NEW

[5] Lokomedia

Массовая проверка и эксплуатация уязвимостей сайтов WordPress, Joomla, DruPal, PrestaShop и Lokomedia

Для установки программы:

git clone  https://github.com/Moham3dRiahi/XAttacker 
cd XAttacker/

Можно запускать без опций:

perl XAttacker.pl

Тогда программа выведет:

[+] You Have List Of Sites ?

[1] Yes

[2] No

[-] Choose :

Здесь спрашивается, имеется ли у нас список сайтов? Если отвечаем Да (нужно вписать цифру 1), тогда нужно будет указать путь до файла. Формат этого файла: один сайт на одну строку, обязательно указание протокола http или https.

Если ответим Нет (цифра 2), тогда появится меню:

[1] Bing Doker |> Here You Chose Da Country Dat U Want

[2] Bing Dorker |> Here I Will Grab Using Ur Dork World Wide Country Websites

[3] Mass Site Grab |> By Ip or Websites List

[4] Mass Site Grab |> Range Ip by Ip or Website list

[+] Choose Number :

Варианты следующие:

1. Поиск по доркам сайтов определённой страны

2. Поиск по доркам сайтов любой страны

3. Массовый сбор сайтов по IP или списку сайтов

4. Массовый сбор сайтов по диапазону IP или списку сайтов

В третьем и четвёртом случае сайты нужно указывать без протокола, то есть без http и https.

Мне больше интересна возможность проверки уже заготовленного большого количества сайтов.

Для этого запустите программу с опцией -l, после которой укажите имя файла со списком сайтов для проверки:

perl XAttacker.pl -l list.txt

В этом списке сайты должны быть с указанием протокола (http или https).

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

Также все уязвимые сайты будут перечислены с указанием найденной уязвимости в файл Result/vulntargets.txt.

Как ускорить работу XAttacker

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

Как составить списки сайтов

Самый простой способ получения списков — это парсинг страниц, где перечислено много сайтов. Это могут быть каталоги, результаты поисковой выдачи, разные агрегаторы и так далее.

К примеру, парсинг сайтов из популярного каталога:

curl -s  https://top.mail.ru/Rating/Computers-Programming/Today/Visitors/{1..60}.html  | grep -E '><at90 t_grey" href="//' | grep -E -o '>.*<' | sed 's/>//' | sed 's/<//' > prog.txt

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

Ещё пример:

echo "http://`curl -s  https://top.mail.ru/Rating/Job/Today/Visitors/{1..60}.html  | grep -E '><at90 t_grey" href="//' | grep -E -o '>.*<' | sed 's/>//' | sed 's/<//'`" > biz.txt

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

Парсинг сайтов: азы, продвинутые техники, сложные случаи

Регулярные выражения и команда grep

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

sed -i -e 's/^/http:\/\//' list.txt

В результате для каждого сайта в списке будет добавлена начальная строка «http://».

Заключение

Программа XAttacker очень простая в использовании, но новые уязвимости не добавлялись уже довольно давно, поэтому для того, чтобы она дала положительный результат нужно проверить действительно много сайтов.

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

Почему взламывают WordPress-сайты, и как этого избежать?

WordPress является самым популярным в мире “движком” для генерации готовых веб-сайтов. На его основе создано и успешно функционирует более 31% всех сайтов в Интернете, что означает сотни миллионов веб-ресурсов по всему миру. Такая популярность WordPress позволяет хакерам легко находить менее безопасные сайты и использовать их в своих корыстных целях.

У хакеров есть разные мотивы для взлома веб-сайта. Некоторые из них – новички, которые просто учатся использовать менее безопасные сайты. По большей части за взломом преследуются следующие цели:

  • распространение вредоносного ПО;
  • использование сайта для атаки на другие сайты;
  • рассылка спама в Интернете;
  • добывание криптовалют.

С учетом вышесказанного, давайте рассмотрим некоторые из главных причин взлома сайтов WordPress и способы их предотвращения.

1. Небезопасный хостинг

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

Этого можно легко избежать, выбрав лучший хостинг-провайдер WordPress для вашего сайта (например, Beget). Это гарантирует, что ваш сайт размещен на безопасной платформе. Правильно защищенные серверы могут блокировать многие из наиболее распространенных атак на сайты WordPress.

2. Использование простых паролей

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

Наиболее уязвимыми являются:

  • учетная запись администратора WordPress;
  • учетная запись панели управления хостингом;
  • FTP-аккаунты;
  • база данных MySQL;
  • учетные записи электронной почты.

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

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

3. Незащищенный доступ к админ-разделу

Область администрирования WordPress предоставляет пользователю доступ для выполнения различных действий сайте. Это также наиболее часто атакованная область сайта WordPress.

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

Сначала вы должны защитить паролем свою административную область WordPress. Это добавляет дополнительный уровень безопасности, и каждый, кто пытается получить к ней доступ, должен будет ввести дополнительный пароль.

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

4. Неверные права доступа файлов

Права доступа для файлов – это набор специальных правил, используемых вашим веб-сервером. Они помогают веб-серверу контролировать доступ к файлам на вашем сайте. Неправильные права доступа могут дать хакеру доступ для записи и изменения этих файлов.

Для всех ваших файлов WordPress права доступа должны иметь значение 644, а для папок – 755.

Права доступа к файлам WordPress

5. Отказ от обновлений ядра WordPress

Некоторые WordPress-пользователи боятся обновлять свои сайты WordPress, опасаясь, что это нарушит их работу.

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

Если вы опасаетесь, что обновление “сломает” ваш сайт, то можете создать полную резервную копию WordPress перед запуском обновления. Таким образом, если что-то пойдет не так, вы можете легко вернуться к предыдущей версии.

О том, как в WordPress сделать резервную копию сайта, мы детально рассматривали в одном из прошлых материалов.

6. Отказ от обновлений плагинов и тем

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

“Дыры” в безопасности и ошибки часто обнаруживаются в плагинах и темах WordPress. Обычно их авторы быстро исправляют их. Однако, если пользователь не обновляет свою тему или плагин, то они ничего не могут с этим поделать.

Убедитесь, что ваша тема WordPress и плагины обновлены.

7. Использование простого FTP вместо SFTP/SSH

Учетные записи FTP используются для загрузки файлов на ваш веб-сервер с помощью FTP-клиента (например, FileZilla). Большинство хостинг-провайдеров поддерживают FTP-соединение с использованием разных протоколов. Вы можете подключиться, используя простой FTP, SFTP или SSH.

Когда вы подключаетесь к своему сайту с помощью простого FTP, ваш пароль отправляется на сервер незашифрованным. Его можно легко украсть. Вместо использования FTP вы всегда должны использовать SFTP или SSH.

Вам не нужно будет менять свой FTP-клиент. Большинство FTP-клиентов могут подключаться к вашему сайту по SFTP, а также SSH. Вам просто нужно изменить протокол на SFTP/SSH при подключении к серверу вашего сайта.

8. Использование admin в качестве логина администратора

Использование admin в качестве логина администратора WordPress не рекомендуется. Следует немедленно изменить его на другое имя пользователя. Это было подробно описано в нашем материале.

9. Использование “зануленных” тем и плагинов

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

Вы всегда должны загружать плагины и темы WordPress из надежных источников, таких как веб-сайт разработчиков плагинов/тем или официальных репозиториев WordPress.

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

10. Отсутствие защиты файла wp-config.php

wp-config.php – основной файл конфигурации WordPress, в котором хранятся секретные ключи безопасности, данные для подключения к базе данных и прочая важная информация. Если эти данные попадут в руки хакеров, то они смогут получить полный контроль над вашим сайтом. Как защитить wp-config.php, было рассмотрено в следующем материале.

11. Используется стандартный префикс таблиц базы данных

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

Подробная инструкция изменения префиксов таблиц описано в нашей статье.

Если Вам понравилась статья — поделитесь с друзьями

Что делать, если взломали сайт на WordPress

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

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

Как узнать, что взломали сайт?

После взлома сайта, когда злоумышленнику открывается полный доступ управления или частичный, происходит, как правило, внедрение опасных скриптов. По сути, это реклама, вирусы и прочий мусор, который точно угробит ресурс. Самые распространённые выявления взлома:

  • На сайте появились не знакомые вам ссылки, ведущие на сторонние ресурсы.
  • На сайте установлена непонятная переадресация.
  • В кабинете вебмастера Google появилось сообщение, что на сайте обнаружены проблемы с безопасностью.
  • Не можете войти в админ-панель сайта.

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

Первые меры применения при взломе сайта WordPress

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

Сканирование ПК. Существует большая разновидность программных вирусов, целью которых является за получение личных данных. Они могут попасть на компьютер самыми различными путями. У вас на ПК должен быть установлен работающий антивирус, способный находить паразитов, а не заводить с ними дружбу. Вашим первым действием будет тщательное сканирование ПК на поиск вирусов, программ, ворующих пароли и.д. Это поможет определить вашу уязвимость.

Обращение к хостингу-провайдеру. Дальше следует обратиться к вашему хостингу с вопросом их безопасности. Так как, может быть, имеются следы массового взлома сайтов, которых объединяет один и тот же хостинг. Это будет явным признаком исходящей проблемы. А также обратите внимания на попытку смена почты вашего аккаунта и другие ранее неизвестные вам изменений. В общем, что-то странное и непонятное.

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

Смена паролей. Прежде чем вы начнете искать на сайте вирус, следует вначале сменить все пароли и логины на всех ресурсах, программах имеющие хоть какое-то отношение к вашему сайту. И конечно же, изменить пароли и логины к взломанному сайту, базе данных, FTP-клиенту, cPanel, расширению протокола SFTP, эл.почте. Еще один момент, смотрите чтобы в БД не было создано новых пользователей, если такие имеются, то полностью удаляйте их.

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

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

Сервисы поиска вирусов на сайте. В интернете можно найти много различных сервисов по поиску вирусов на сайте. Они могут оказаться полезными, даже, несмотря на то, что многие из них бесплатные. Кроме сервисов, имеются также отдельные скрипты, плагины, сканирующие сайт. Некоторые из них: https://www.virustotal.com/, http://antivirus-alarm.ru/proverka/, http://xseo.in/viruscan, https://sitecheck.sucuri.net/, https://www.revisium.com/ai/

Что делать, если нет резервного копирования сайта

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

Это основная часть работы, а дальше следует найти тот самый неуловимый вирус. Необходимо просмотреть все папки сайта начиная с корневых, заглянуть в конфигурационный файл (.htaccess), посмотреть все индексные файлы. Искать нужно файлы, изменённые за последнее время, php-скрипты (веб-шеллы) обычно именуемые довольно странно (drvx.php, tvd1660f.php), и смотреть все остальные файлы, которые могут вызывать сомнения. Первую очередь проверьте директории, разрешающие загрузку файлов (uploads, tmp, images, cache, user_files и т.д.)

Еще о безопасности

В заключение добавлю еще несколько полезных советов о безопасности. Для удобства они изложены в статье о файле .htaccess в WordPress, где вы найдете способы блокировки и защиты важных файлов. А также задумайтесь о переходе на выделенный сервер, если того позволяют средства.

Официальный мануал WordPress в случае взлома сайта: https://codex.wordpress.org/FAQ_My_site_was_hacked

Еще один мануал — http://www.secbot.org/what-todo-if-hacked/

На этом, пожалуй, закончим.

Происходит редирект, взломали сайт | WordPress.org Русский

Модератор Yui

(@fierevere)

ゆい

https://ru.wordpress.org/support/topic/%d0%b2%d0%b7%d0%bb%d0%be%d0%bc%d0%b0%d0%bb%d0%b8-%d1%81%d0%b0%d0%b9%d1%82%d0%bf%d1%80%d0%be%d0%b8%d1%81%d1%85%d0%be%d0%b4%d0%b8%d1%82-%d1%80%d0%b5%d0%b4%d0%b8%d1%80%d0%b5%d0%ba%d1%82/
дубль, и там я вам кинула ссылку на страницу в кодексе, что нужно делать
ту тему закрою, т.к. в ней меньше информации

Сегодня была такая же тема, оказалось все проще чем кажется, надо лишь зайти в Базу Данных, и там в wp_options вернуть siteurl на свой.

Модератор Yui

(@fierevere)

ゆい

в wp_options вернуть siteurl

обычно взломщики такого не делают, разве что случайно что-то пошло у них не так.
Такое обычно делают сами администраторы сайта

обычно взломщики такого не делают, разве что случайно что-то пошло у них не так.
Такое обычно делают сами администраторы сайта

У меня вот так произошло, вчера утром взломщик как то зарегистрировался и сменил siteurl.

Этот сайт делает по другому
Он прописывает вирус в head блогах. Это в шаблонах. При чем в любых CMS
А так же в корне
wp-load.php
wp-links-opml.php

Удаляйте его код.

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

Удаляйте его код.

Вы перепутали тех. форум с ТВ «шоу».

sevlad, а Вы бы лучше рекомендации давали, а не прикалывались. Не хорошо так модератору!!!

Нужно перелазить эти файлы
wp-load.php
wp-links-opml.php

А в Вашей теме в файле header.php может быть такие коды, удалите их.
<script language=javascript>var _0xfcc55=["\x66\x72\x6F\x6D\x

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

а Вы бы лучше рекомендации давали, а не прикалывались. Не хорошо так модератору!!!

Они даны сразу же в первом ответе (yui). Печально, что их не замечают и дают разные «советы» — фантазии.

А в обязанности модератора как раз и входит следить за порядком на форуме.

«heavenlydevil (@heavenlydevil)
4 мес., 3 нед. назад
Сегодня была такая же тема, оказалось все проще чем кажется, надо лишь зайти в Базу Данных, и там в wp_options вернуть siteurl на свой.»
Сегодня именно этим способом вылечился. Да, и кроме siteurl нужно так же и home изменить на свой домашний url поменять! Спасибо, heavenlydevil!

Сегодня именно этим способом вылечился.

Неужели кроме этого больше ничего нет? Звучит как-то слишком просто.

конечно не просто — надо плагин удалить, который виноват в этом. Иначе снова появится сайт для редиректа.

Самой основной защитой является установка постоянно обновляемых и с высоким рейтингом плагинов. Там, где разработчики следят за своими плагинами — там меньше всего вероятность взлома.

Далее нужно устанавливать защиту на свои блоги, а не делать это тогда, когда жаренный петух в задницу клюнул.

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

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

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

Самой основной защитой является установка постоянно обновляемых и с высоким рейтингом плагинов. Там, где разработчики следят за своими плагинами — там меньше всего вероятность взлома.

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

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

Это не специалист, а любитель. Ну или вас просто «вежливо отшили».

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

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

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

Яндекс никак не отвечает за стабильную работу вашего сайта, и странно обвинять компанию в своих ошибках. Гугл — это Гугл, у них другие мощности и другие возможности.

С той же проблемой боролся две недели, постоянно после отката с бекапа вставляли редирект максмимум через 6-8 часов после восстановление, нагуглил что уявзмим плагин Related Posts Yuzo, после сноса плагина взломы прекратились. Может у Вас та же история.
вот решение: https://searchengines.guru/showthread.php?t=1013982&page=2

zashibiz, 1 — за почти полгода, думаю, ТС уже решил свою проблему; 2 — про «Yuzo» тут уже несколько тем есть и описаны решения; 3 — вот это: «Дата регистрации: 27.04.2019» и «Ответов создано: 1» со ссылкой на сторонний ресурс выглядит как-то подозрительно.

Почему нельзя устанавливать взломанные темы и плагины Вордпресс

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

Почему нужно избегать взломанных тем и плагинов WordPress

Взломанные темы и плагины Вордпресс – это пиратские копии платных тем WordPress и плагинов, распространяемых неэтично в Интернете. Люди, распространяющие взломанные программные продукты, утверждают, что, поскольку WordPress и любые производные работы (например, плагины и темы) лицензируются под лицензией GPL, вполне нормально копировать и распространять их.

Специализированный хостинг для сайтов на WordPress!Специализированный хостинг для сайтов на WordPress! Hostenko - Лучший WordPress хостингHostenko - Лучший WordPress хостинг

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

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

1. Безопасность

безопасность тем вордпрессбезопасность тем вордпресс

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

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

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

2. Конфиденциальность

конфиденциальность вордпресс тем

конфиденциальность вордпресс тем

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

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

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

3. Плохо для SEO

SEO взломанных вордпресс тем

SEO взломанных вордпресс тем

Пиратские темы WordPress и плагины могут полностью уничтожить SEO. Они могут добавлять спам-ссылки на ваш сайт или захватывать ваших пользователей и перенаправлять их на плохие веб-сайты.

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

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

Смотрите также:

30 лучших бесплатных WordPress тем для бизнеса 2018

4. Юридические вопросы

юридические аспекты вордпресс темюридические аспекты вордпресс тем

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

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

5. Отсутствие доступа к обновлениям

взломанные фордпресс темы не обновляютсявзломанные фордпресс темы не обновляются

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

Это оставляет ваш сайт с устаревшей версией, которая может содержать ошибки и быть небезопасной. Сам WordPress регулярно выпускает новые версии. Темы и плагины также должны обновляться, чтобы оставаться совместимыми с последними изменениями. Поскольку взломанная тема или плагин не могут быть обновлены, ваш сайт может плохо себя вести или стать недоступным.

6. Поддержка и документация

поддержка взломанных вордпресс темподдержка взломанных вордпресс тем

Даже самые опытные пользователи WordPress нуждаются в поддержке и документации, чтобы правильно использовать премиальные темы и плагины WordPress.

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

Если вы используете взломанную тему WordPress или плагин, то вы сами по себе. Вы не можете попросить разработчиков помочь вам, когда нужна помощь. Вы также не получаете доступ к документации и учебным пособиям, поскольку они доступны только платным клиентам.

7. Доступ к новым функциям

доступ к новым функциям вордпресс темдоступ к новым функциям вордпресс тем

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

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

Смотрите также:

Лучшие бесплатные шаблоны WordPress марта 2018

8. Неэтичное использование препятствует инновациям

инновации вордпресс теминновации вордпресс тем

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

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

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

9. Изобилие бесплатных альтернатив

бесплатные темы вордпрессбесплатные темы вордпресс

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

На самом деле, многие премиум плагины WordPress  имеют ограниченные бесплатные версии, которые помогут вам начать работу. Нужна контактная форма? Начните с бесплатной версии WPForms Lite. Нужна Google Analytics? Попробуйте бесплатную версию MonsterInsights.

Смотрите также:

10 плагинов WordPress, использующих искусственный интеллект и машинное обучение

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

Мы надеемся, что эта статья помогла вам узнать, почему вы должны избегать взломанных плагинов и тем WordPress.

Hostenko - Лучший WordPress хостингHostenko - Лучший WordPress хостинг

Источник: www.wpbeginner.com

Специализированный хостинг для сайтов на WordPress!Специализированный хостинг для сайтов на WordPress!

Смотрите также:

Принцип взлома премиум тем для WordPress. И не только

Всего пару лет назад адаптировать понравившуюся тему для популярной CMS WordPress было очень просто: достаточно было базовых знаний программирования на php, или хотя бы понимание принципов программирования вообще и интернета под рукой. Но в наиболее «выигрышные» премиум-темы со временем стали встраивать защиту от умельцев.

Первые ласточки

Поначалу было несложно разгадать код: стоило выбросить ссылки на функцию, которая проверяет «правильность» установленной темы — и следующий кусок кода сам обнаруживал себя ошибкой в определённом месте. Как правило в нём была зашифрована сама функция проверки, причём не в чистом php-коде, а зашифрованная алгоритмом base64. Собственно, можно было и сразу поискать в файлах темы функции base64_decode(), раскодировать их в любом онлайн-раскодировщике, и дальше по полученному php-коду уже понять, что она делает.

Чаще всего зашифрованная функция просто проверяла наличие некоторых строк или переменных в шапке темы, блокируя работу сайта, если что-то было изменено назойливым сайтописателем. Почти всегда проблема решалась простым затиранием этой функции, независимо от того, перехватывала ли она вызовы каких-то стандартных подпрограмм самого WordPress’а, или нет. Пример такой последовательности действий описан на сайте selfbiz.ru.

Но время не стоит на месте, и в один прекрасный момент поиск base64 также перестал давать результаты. Что случилось?

Шахтёрский ребус

На мой взгляд, анализ кода новых тем не мог не привести к фрагменту явно закодированного блока в functions.php, да всего одна строчка в footer.php немного настораживала предупреждениями, что её стирать не надо (тема и правда начинала ругаться при их затирании, хотя обычный html-комментарий около этого кода легко убивал двух зайцев). Навязчивую строчку в подвале экранировать (хотя и не уничтожить полностью) удавалось, но всё же оставался непонятным механизм проверки взлома.

Интересным было и то, что среди шифрованного кода заветной фразы «base64» не было вовсе, только куча переменных. Но глаз-то не обманешь — после них шёл явно шифр base64. И вдруг догадка пришла сама собой.

$rHaN='4';$VqrC='s';$NRoFK='e';$DYxma='_';$tNTdm='b';$hqZJRO='d';
$dXUGlnu='6';$OJWdVR='e';$SmsCe='e';$UjaUX='o';$DEYPS='c';$yVKLW='d';$vGCkjJc='a';
$olVOigbC=$tNTdm.$vGCkjJc.$VqrC.$OJWdVR.$dXUGlnu.$rHaN.$DYxma.$hqZJRO.$NRoFK.$DEYPS.$UjaUX.$yVKLW.$SmsCe;$TwUY='g';$pDpWoq='a';$NUuRmO='n';$edaMRVh='t';$MhkU='l';$LaaPNe='i';$VXQfspm='f';$iVzdTp='e';$veIN='z';$uZIiZkvz=$TwUY.$veIN.$LaaPNe.$NUuRmO.$VXQfspm.$MhkU.$pDpWoq.$edaMRVh.$iVzdTp;$Fdiq='r';$heIC='r';$aflnkj='_';$jORVFNd='s';$upLthOA='t';$rfMnKzq='o';$VYNYS='t';$ZLti='3';$xdOy='1';$mfYQuUeL=$jORVFNd.$VYNYS.$heIC.$aflnkj.$Fdiq.$rfMnKzq.$upLthOA.$xdOy.$ZLti;$JvasOQV='s';$bgsiq='r';$UJQwNeq='t';$jQqlL='r';$lGnUc='e';$nReiM='v';$Qudgjdcq=$JvasOQV.$UJQwNeq.$jQqlL.$bgsiq.$lGnUc.$nReiM;
eval($uZIiZkvz($olVOigbC($mfYQuUeL($Qudgjdcq('C8/Kami/+//+9iCIT9eAc0PCd9CYnC7VaRYKORhYDBsi81  [...]

Не так страшен чёрт

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

Решение оказалось простым: заменить вызовы переменных на их значения. Первая же группа переменных со значениями 4, s, e, _, b, d, 6, e, e, o, c, d, a — это… да что там угадывать: это же base64_decode, с переставленными местами буквами, чтобы мы не догадались. Убираем в коде первые 13 переменных — теперь мы знаем, что $olVOigbC — это base64_decode. Осталось понять, что закодировано.

Анализируем следующий набор переменных. Угадайте, что означает g, a, n, t, l, i, f, e, z ? Ответ: это gzinflate — функция, которая распаковывает сжатую строку. Вот вам второй ключ: что-то сжато, закодировано, и выполняется кодом. Идём дальше.

r, r, _, s, t, o, t, 3, 1 — это, конечно же, str_rot13 (иногда догадка приходит раньше, чем успеваешь сложить значения переменных в цепочку).

s, r, t, r, e, v — ещё проще — strrev (ну ладно, даже если не знаете такой функции, всё равно буква за буквой сложить из исходных переменных слово — дело времени и Ctrl+F).

Ну всё, дальше по коду — eval. Что имеем на данный момент?

$olVOigbC=base64_decode;
$uZIiZkvz=gzinflate;
$mfYQuUeL=str_rot13;
$Qudgjdcq=strrev;
eval($uZIiZkvz($olVOigbC($mfYQuUeL($Qudgjdcq('C8/Kami/+//+9iCIT9eAc0PCd9CYnC7VaRYKORhYDBsi81 [...]

Нужно ли объяснять, что это на самом деле:

eval(gzinflate(base64_decode(str_rot13(strrev('C8/Kami/+//+9iCIT9eAc0PCd9CYnC7VaRYKORhYDBsi81+ [...]

Если вы поняли все предыдущие действия, дальнейший рассказ превращается в банальную прозу. Остаётся найти онлайн-функцию strrev(), чтобы перевернуть строку… и так далее, пока не получится читабельный код.

Почти всё…

Беда в том, что после раскодировки может получиться снова закодированная строка, вернее eval(gzinflate… и так далее. Это означает, что программисту было не лень одну и ту же строку тридцать раз закодировать аналогичным методом (иногда набор функций в цепочке варьируется). Если делать все преобразования вручную — конечно, надоест. Но никто не мешает создать php-файл, который будет выполнять цепочку функций (без eval, конечно) пошагово (например, раскодировал — снова вставил, нажал «выполнить» и т.д. Хотя бы по бедности сделать php, в котором будет echo base64_decode(rot13… — куда можно будет снова вставлять полученный результат и снова исполнять.

И вроде бы счастье когда-то наступит. Но иногда программисты решают ещё больше заморочить голову. Тогда после раскодировки получается новая последовательность:

$jh__j='4';$qt____________y='s';$to__d='e';$en_____________t='_';$ne____________l='b';$bp_____________p='d';$zb____j='6';$nt______________j='e';$ga________q='e';$xk______l='o';$se___________j='c';$de_____________c='d';$je___n='a';

Тут и ежу понятно: внутри ещё раз та же 4, s, e, _, b, d, 6, e, e, o, c, d, a — base64_decode. Тогда придётся пройти ещё один круг (Кстати, одна из переменных состояла из переменных $zb____________y=f.u.n.c.t.i.o.n._.e.x.i.s.t.s; — так что расслабляться не стоит). И так — пока не доберёшься до результата.

Стоит ли оно того? Возможно. Так, в одном из разобранных кодов я увидел прямое обращение к файлу с проверкой на таймаут… и это в eval’е! А если интернет тормознёт в момент чтения — получается, тема не заработает? И потом, если хостинг брался «в обрез», то два-три-четыре десятка обращений к php-функциям сказываются явно не в лучшую сторону на производительности сайта, правда? Тогда уж точно придётся ломать, чтобы починить…

Выводы

Разумеется, я написал всё это не для того, чтобы взять — и в лоб взламывать что-то. Алгоритм кодирования можно применить, например у себя на сайте, или, скажем, в коде, за который могут не заплатить. Решать вам.

Методики засекречивания кода продолжают развиваться, и ещё вчера простой и открытый php теперь свободно превращается во что-то нечитаемое простым глазом.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *