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


Взлом WordPress, виновны бесплатные темы!

Сегодня решил посмотреть, что творится в сфере взлома сайтов и был удивлён, оказывается, темы для «WordPress» могут быть уязвимы и это может грозить взломом блога. Злоумышленник может получить доступ к сайту с правами Администратора и распоряжаться ресурсам, так как ему угодно.

Уязвимости могут быть допущены разработчиками тем не специально – это просто ошибки, которые приводят к печальным последствиям! Если вещи и похуже и даже страшнее…

Более интересную информацию даёт сайт «revisium.com». Сообщается что порядка 54% тем, которые можно скачать бесплатно, заражены или уязвимы. 54% — это большая цифра, если вы используете бесплатную тему, стоит задуматься…

Например: Оказывается, что сайт «wordpress-ru.ru» предлагает 99% уязвимых тем!

Теперь уж точно, если мне нужно будет на скорую руку создать сайт, я не стану лениться и потрачу пару дней на создание темы, чем возьму бесплатную! Хотя в этой ситуации нет ни чего удивительного, мы же знаем, где бывает бесплатный сыр, правильно?

Как бесплатная тема приводит к взлому сайта?

Давайте залезем в шкуру злоумышленника и посмотрим, насколько просто можно взломать чужой блог?

Обратите внимание: Это статья ни побуждение к действию, действительно, тут представлена практически, пошаговая инструкция по взлому блога на «wordpress» Исключительно для наглядности и демонстрации простоты выполняемых действий, которые приведут к захвату чужого сайта! Подобной информации в сети и без меня хватает, так что, этот пост, как капля в море… Короче я отмазался!))

Большинство уязвимостей публикуются в открытом доступе, там же часто можно увидеть информацию, как использовать ту или иную «Дыру». Одним из таких ресурсов можно представить сайта «https://wpvulndb.com/»

Посмотрим, что там есть, например, видим, что тема с названием «QAEngine» имеет уязвимость. (Это вроде платная тема, ну нечего, это подливает масло в огонь) Из краткого описания следует «Privilege Escalation» то есть можно зайти на сайт «Гостем» и превратиться в «Администратора» выполним ряд несложных действий.

Теперь нужно найти уязвимый сайт, то есть тот сайт, который использует эту тему. В этом деле нам очень поможет всемогущий «Google»!

Смотрим, что выдаст поиск по запросу «inurl:themes/QAEngine» а в ответ мы получаем примерно 728 сайтов, не плохо, есть из чего выбрать!

Возьмем любой, первый попавшийся сайт и перейдём по нему, что видим.

Ну ладно, формируем ссылку и подставив к домену следующие:

/wp-admin/admin-ajax.php?action=ae-sync-user&method=create&user_login=WinKomp&user_pass=Password&role=administrator

Тут нас интересует следующие два параметра «user_login» и «user_pass» я им дал такие значения.

WinKomp– это логин.Password– это пароль.

Переходим по ссылке и читаем, то, что получили в ответ.

Слово «True» говорит о том, что все прошло успешно и новый пользователь с логином «WinKomp» и соответствующим паролем был успешно зарегистрирован на сайте. Это нужно проверить. Открыв страницу авторизации, вводим вышеуказанные данные и попадаем в админку сайта!

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

Что, можно сделать ещё? Например, пойти в редактор и поправить страницу с ошибкой «404» заменив её код на свой, например на «шелл»! Благодаря чему можно посмотреть, например пароли к базе данных.

Файлик «wp-config.php» как на ладони…

Это все малая часть, что может произойти с блогом, если использовать бесплатный шаблон! Ну да, в этом случаи платный, но не суть! Используя бесплатный последствия ещё хуже, можно загреметь в БАН поисковых машин, за то, что сайт превратился в «Линко помойку» и многое другое!…

Напоследок ошарашим Администратора и расскажем ему в чем дело! Так сказать доброе дело сделаем. (Я не чего не портил, там до меня все испортили, точнее кое что… я просто создал простенькую тему и залил туда)

winkomp.ru

Взломали сайт на WordPress, что делать

Доброго времени суток, всем читателям — Sozdaiblog.ru!

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

Люди жалуются на то, что их сайт взломали, и они не знают, как быть и что делать дальше.

Конечно, по мере возможности я пытаюсь им помочь, но на всех у меня не хватит, ни сил ни времени.

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

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

Итак.

Полезная статья по теме: http://www.secbot.org/what-todo-if-hacked

Стук в дверь службы поддержки Веб-Хостинга.

 

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

 

  • Переустановить WordPress.
  • Восстановить из резервной копии.
  • Удалить инфицированные файлы.

 

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

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

 

Кто, зачем и как взламывает и заражает WordPress сайты?

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

В основном, 99,9% взломов и заражений происходит при помощи скриптов и автоматизированного программного обеспечения.

 

Как это работает?

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

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

Всё, как у живого человека, ослаб иммунитет, и Вы подхватили вирус.

 

Почему Ваш сайт, хорошая цель для хакера?

 

Вы оставляете следы: Первое, что ищет робот, это следы. Под словом след, подразумевается версия движка в HTML или ссылка в footer.php. Следы бывают разные и их очень много.

Ваш сервер уязвим: Хакеры, специально ищут серверы, у которых листинг — «directory indexing», по умолчанию оставлен открытым. Такого быть не должно. Оставив — «directory indexing» доступными, это аналогично тому, что дать хакеру рентгеновский аппарат для проверки внутренностей сайта.

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

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

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

Многие сайты и блоги пострадали, из-за плохой конфигурации Веб-Хостера.

Собственный склероз: Представьте, надумали Вы прикрутить к блогу — Форум! Скачали программку и установили её на поддомене. Прошло какое-то время, и Вы забыли про Форум, ну или просто забили.  Так он там и остался висеть мёртвым грузом. С годами, программное обеспечение устарело. До него добрались хакеры и с помощью старых дыр сломали Ваш обновлённый WordPress. Вот так, лечите склероз.

Общественная уязвимость:  Обычные люди понятия не имеют, что используя общественный Wi-Fi, они подвергают себя риску быть взломанным.

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

Уязвимость в операционной системе Веб-Хостера: Ваш сайт работает на сервере, под руководством  Веб-Хостера, который в свою очередь устанавливает на сервер операционные системы (Linux, Windows, или Mac). Так вот,  те компании, которые халатно относились к обновлению программ и использовали Windows, были взломаны не один раз. Поэтому, советую отдать предпочтению Хостеру на Linux.

 

Что делать если Ваш сайт на WordPress Взломали!

 

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

 

Я не могу войти в WordPress!

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

Если у Вас, не получается войти в панель администратора WordPress, то очевидно Вы наблюдаете один из следующих симптомов:

 

1. Когда Вы пытаетесь войти в панель администратора, выскакивает белый экран смерти (пустой экран).

2. При попытке входа, Вас перенаправляют на левую страницу или страницу — «404 Not found».

3. Ваш пароль и логин не работают.

4. Нет доступа к просмотру каталогов, через FTP-клиента.

 

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

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

 

Восстановление доступа к приборной панели WordPress:

 

1. Измените на Веб-Хостинге свои учётные записи (логин, пароль) и данные FTP-клиента.

2. С помощью FTP, сделайте копию Вашего сайта на рабочем столе компьютера (как настроить FTP-клиент).

3. Войдите в панель управления Веб-Хостинга, перейдите в раздел баз данных MySQL и выберите — «PHPMyAdmin». Как только всё загрузится, слева, на приборной панели, найдите Вашу базу данных и кликните по ней мышкой (если, Вы не знаете, как называется БД, смотрите в файле WP-config.php, который находится в корневом каталоге Вашего сайта):

 

 

4. В верхнем меню, нажмите на вкладку — «Экспорт»:

 

 

5. В новом окне, ставим способ экспорта — «Обычный» и выделяем всю таблицу.

6. Ниже, выбираем — «Сохранить как файл» и задаём компрессию:

 

 

7. Опускаемся в подвал и нажимаем — OK. Копию БД, сохраняем на рабочий стол.

8. Через FTP, заходим в корневую папку Вашего сайта и находим файл — «Htaccess». Этот файл есть у каждого сайта под управлением WordPress. Если Вы его не видите, возможно, что он скрыт. Для его обнаружения, в настройках FTP-клиента установите — «Принудительно отображать скрытые файлы». Затем, удалите его.

9. Зайдите в папку — «wp-admin», встретив там аналогичный файл — «Htaccess», удаляйте.

10. Откройте папку — «wp-content/plugins» и удалите все плагины (не бойтесь, Вы ведь сделали резервную копию на рабочем столе компьютера).

11. В папке — «wp-content», найдите — «themes» и удалите всё, кроме тем по умолчанию (повторяю, не пугайтесь, все темы есть в резерве).

12. Скачиваем последнюю версию WordPress, распаковываем её на рабочем столе и через FTP, поверх старых, загружаем новые файлы в корневую папку Вашего ресурса.

Если принципиально, то Вы вообще можете удалить все файлы в папках, оставив — «wp-config.php» и внутри — «wp-content», папку — «uploads», чтобы не потерять загруженные файлы (картинки и т. д.).

13. После загрузки файлов, открываем любой браузер и в адресной строке вписываем:

 

http:// Ваш сайт/wp-admin/upgrade.php

 

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

14. Затем, в адресной строке вписываем:

 

http:// Ваш сайт/wp-login.php

 

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

Для 99,9% сайтов, на этом этапе проблемы уже решаются, потому-что, когда выскакивает белый экран смерти или надпись о блокировки сайта, то это проблемы плагинов и тем. Как вариант, проблемы с файлом Htaccess. Если Вы решили, что вся соль в БД, переходите к следующему разделу статьи.

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

После удачной активации всех плагинов, можно загрузить тему оформления, но прежде проверить её на предмет подозрительных файлов.  В начале, проверьте файл — «footer.php» на наличие постороннего кода и закодированных ссылок (хакеры любят оставлять в подвале подарки).

Следующим этапом, проверьте — «functions.php» и убедитесь в отсутствии чужого кода. Ну и последнее, проверьте основные PHP файлы (header.php, index.php, page.php и т. д.). По окончанию исследования, загрузите тему на сервер, активируйте и побродите по сайту для более тщательной проверки.

 

Мой сайт на WordPress был взломан, но я могу зайти в панель администратора!

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

 

1. С помощью FTP, сделайте копию Вашего сайта на рабочем столе компьютера.

2. Войдите в панель управления Веб-Хостинга, перейдите в раздел баз данных MySQL и выберите — «PHPMyAdmin». Как только всё загрузится, слева, на приборной панели сайта, найдите Вашу базу данных и кликните по ней мышкой (если, Вы не знаете, как называется БД, смотрите в файле WP-config.php, который находится в корневом каталоге Вашего сайта).

3. В верхнем меню, нажмите на вкладку — «Экспорт».

4. В новом окне, ставим способ экспорта — «Обычный» и выделяем всю таблицу.

5. Ниже, выбираем — «Сохранить как файл» и задаём компрессию.

6. Опускаемся в подвал и нажимаем — OK. Копию БД, сохраняем на рабочий стол.

7. Откройте папку — «wp-content/plugins» и удалите все плагины (не бойтесь, Вы ведь сделали резервную копию на рабочем столе компьютера).

8. В папке — «wp-content», найдите — «themes» и удалите всё, кроме тем по умолчанию (повторяю, не пугайтесь, все темы есть в резерве).

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

 

После удачной активации всех плагинов, можно загрузить тему оформления, но прежде проверить её на предмет подозрительных файлов.  В начале, проверьте файл — «footer.php» на наличие постороннего кода и закодированных ссылок (хакеры любят оставлять в подвале подарки).

Следующим этапом, проверьте — «functions.php» и убедитесь в отсутствии чужого кода. Ну и последнее, проверьте основные PHP файлы (header.php, index.php, page.php и т. д.). По окончанию исследования, загрузите тему на сервер, активируйте и побродите по сайту для более тщательной проверки.

Если проблемы не решились, то стоит обратить внимание на базу данных.

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

Самый простой вариант, это импортировать копии в новую базу.

 

Как восстановить  базу данных WordPress, избавив её от инфекций.

 

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

Как я уже говорил, есть куча способов,  очисти БД, но они подходят не всем.

 

Поэтому, вот Вам самый простой и быстрый вариант:

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

 

1. Зайдите на хостинг и создайте новую БД. Запишите название БД, пароль и имя пользователя.

2. В корневой папке Вашего ресурса, откройте на редактирование файл — «WP-config.php» и замените существующие учётные записи БД на новые. Не забудьте изменить ключи аутентификации. Главное знать, что все остальные файлы у Вас в порядке, и Вы выполняете свои действия на чистом материале:

 

 

3. Теперь, откройте любой браузер и войдите на свой сайт.  Как в первый раз, Вы должны попасть на диалоговое окно, в котором будет предложена установка WordPress. Соглашайтесь с установкой и вводите новые учётные данные.

4. После успешной установи, вернитесь на свой хостинг в то место, откуда мы экспортировали старую БД (управление базами, PHPMyAdmin). Выберите новую  базу и рядом с кнопкой — «Экспорт» нажмите на — «Импорт». В открывшемся окне, найдите вкладку обзора папок на Вашем компьютере, нажмите и найдите на рабочем столе ранее скаченную копию старой БД:

 

 

Далее опуститесь в подвал хостинга и нажмите — OK. В промежутке этих действий, не забудьте выставить формат импортируемых файлов (это всё в том же окне).

 

5. Включите плагины.

6. Активируйте Вашу тему.

 

Теперь, Вы должны иметь абсолютно чистую БД и если Вы следовали первым двум разделам статьи, то и чистые плагины, а так же безопасную тему оформления. Единственное, Вам придётся заново делать все настройки плагинов и движка, но это маленькая цена за 100% чистую и новую БД.

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

Поэтому, чай убираем в сторонку и читаем следующий раздел.

 

Как обезопасить сайт на WordPress от взлома хакеров.

 

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

 

Чтобы Ваш сайт не взломали, как говорится — на лету, воспользуйтесь несколькими советами:

Пароли: Скорее всего, как и все остальные Вы используете пароли, которые легко запомнить. Кроме того, большинство людей склонны к использованию одинаковых паролей и логинов, ко всему. Это значит, что если хакер получает доступ к одному сайту, то он может получить доступ и к facebook, Twitter, Онлайн-Банку, Электронной почте и многому другому.

 

  • Всегда используйте разные имена входа на все Ваши счета.  Никогда не используйте один и тот же логин, на всех сайтах. Старайтесь добавлять к именам цифры.
  • Используйте надёжные пароли (номера, буквы, символы). Если Вы сомневаетесь в надёжности пароля, то можете использовать специальные генераторы (genpas.narod.ru; strongpasswordgenerator.com). Кроме того, чем длиннее пароль, тем труднее его взломать. Многие используют от 8 до 15 знаков.

 

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

Перехват учётных данных: Будьте очень внимательны, когда Вы подключаетесь к своему сайту  в общественных местах. Используйте только зашифрованный Wi-Fi. Никогда не пытайтесь войти через общественный Wi-Fi в приборную панель WordPress, FTP или Веб-Хостинга, если Вы не можете использовать безопасное соединение  — https:// secure connection.

Использовать плагины безопасности: Если у Вас есть возможность, то обязательно используйте различные плагины безопасности, такие как — Login LockDown или Secure WordPress.

Google Webmaster Tools: C помощью Google Webmaster Tools, можно настроить отправку почтовых уведомлений, при появлении на Вашем ресурсе вредоносного программного обеспечения.

Для получения дополнительной защиты, Вы можете воспользоваться следующим материалом:

 

 

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

Был ли Ваш сайт когда-либо взломан?  Что Вы делали для его восстановления и очистки от вредоносного кода?  Давайте поможем друг другу и поделимся ценным опытом!

Я свой шаг уже сделал, а Вы?

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

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

На сегодня это всё. До новых статей!

 

С уважением, Денис Черников!

Интересное по теме:

Сделайте, пожалуйста, доброе дело, расскажите о блоге своим друзьям:

sozdaiblog.ru

Взлом сайта на WordPress с помощью комментария

На платформе WordPress работает пятая часть всех сайтов в интернете, так что малейшая уязвимость в CMS или популярных плагинах привлекает пристальное внимание. Тем более такой мега-баг, какой обнаружил финский хакер Йоуко Пюннёнен (Jouko Pynnönen) из компании Klikki Oy. Он раскрыл технические подробности в минувшее воскресенье.

Критическая уязвимость 0day (на момент публикации в воскресенье патча не было, но он вышел в понедельник) затрагивает встроенную систему публикации комментариев WordPress, которая до сих пор широко используется на многих сайтах. Оказывается, если опубликовать достаточно длинный комментарий (64k символов), то можно вызвать баг, который приводит к исполнению постороннего кода с этой HTML-страницы.

Образец комментария

<a title='x onmouseover=alert(unescape(/hello%20world/.source)) style=position:absolute;left:0;top:0;width:5000px;height:5000px AAAAAAAAAAAA...[64 kb]..AAA'></a>

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

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

Патч вышел в понедельник 27 апреля: WordPress 4.2.1.

Поделись новостью с друзьями:

xakep.ru

Немного о бэкапе, или как я случайно взломал чужой блог на WordPress

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

А началось все до жути банально — я, раньше делавший бэкап сайта вручную путем тупого копирования всех существующих папок на сервере себе на локальный компьютер, затем лезущий в phpMyAdmin, и оттуда сохраняющий дамп базы, решил поставить себе плагин, позволяющий делать это в автоматическом режиме. Выбор пал на BackWPup, как обладающий самыми широкими настройками по регулярности бэкапов, позволяющий делать копии не только базы данных, но и всех файлов на сайте, а также поддерживающий создание бэкапов не только на сервере, но и скидывание их по ФТП, в дропбокс, e-mail, и т.д.

И вот, раздумывая, куда бы класть файлы по фтп, я набрел на один очень занятный хостинг файлов, а вернее — файлхранилище с доступом по  ftp — fileplaneta.com. Однако, как оказалось при ближайшем рассмотрении, он не только не шифрует ссылки на закачанные на него файлы, но и по умолчанию при загрузке включает их публичный доступ, так что все файлы, как на ладони высвечиваются у любого пользователя зашедшего на этот ресурс, более того — присутствует сортировка и продвинутый поиск. Сразу возникла мысль — как же так, это значит, что любой бэкап, закачаный туда, сразу станет достоянием общественности? Решил это проверить. BackWPup создает по умолчанию архивы со стандартными наименованиями, по которым я и задал поиск, сразу же найдя пару. Нет, это какой-то бред, подумал я, такого просто не может быть. Ладно, давайте посмотрим, а можно ли вообще что-нибудь с этим сделать. Честно говоря, все остальное я делал, вовсе не намереваясь кого-либо ломать, или чего еще в этом духе, абсолютно не разбираясь в этом, и предполагая, что где-то там будет непреодолимая преграда и защита, которую я просто не смогу пройти. Иными словами, на примере найденых бэкапов хотел проверить, что же меня ждет, если я к нему (файлпланете) привяжу BackWPup. Но все произошло так быстро, что я даже не успел опомниться. В скачаном бэкапе конечно же, лежал файл wp-config.php, в котором, конечно же, лежали в незашифрованом виде все данные доступа к базе данных сайта, включая логин, пароль, хост, к которому коннектится. Запустил первый попавшийся клиент для управления и администрирования MySQL под windows (первым попался какой-то SQLyog Community Edition — жутко тупая программа в сравнении с phpMyAdmin, как мне показалось — но честно говоря, я в этом абсолютно не разбираюсь, поэтому точно утверждать не буду, может это в умелых руках — наоборот верх совершенства :)). Ввел туда всю информацию из wp-config.php, нажал кнопку соединиться — бац — я в чужой базе данных. Нет, понятно, что реальные е-мэйлы автора, умело скрытые на сайте, логины и пароли в зашифрованом виде были доступны из ее дампа уже в бэкапе — но то, что можно будет так просто войти — этого я уже совсем не ожидал. Стало интересно, а смогу ли я войти в сам блог? Кул хацкер, скорее всего, недолго думая, поменял бы пароли админов, а заодно и е-мэйл, и выслал бы себе новый. Но поскольку меньше всего я хотел кому-то причинить какой-либо вред, то я просто создал в таблице wp_users еще одного пользователя, назвав его незамысловато wordpress, и даже не вводя е-мэйл, никнейм, и всю основную лабуду, сгенерировал MD5 пароль, тоже вставив его в таблицу, после чего дал этому юзеру права администратора в таблице wp_usermeta, присвоив значение wp_user_level равный 10 и прописав wp_capabilities в виде a:1:{s:13:»administrator»;b:1;}. Еще безопаснее для блога, конечно, было подобрать пароль по md5 хэшу, (судя по всему, он был не сильно сложный), но меня интересовала принципиальная возможность входа в админку, поэтому совсем уж заморачиваться я не стал. В браузере к адресу сайта я добавил /wp-admin, ввел логин wordpres и пароль, для которого я генерировал md5 хэш, и спустя секунду я был уже в админке. Это я все так долго описываю, а на самом деле все заняло не больше двух минут, из которых самое долгое — было скачивание windows клиента для администрирования MySQL. Честно говоря, я аж офигел, ну никак не ожидал такого, и под некоторым впечатлением нахожусь даже сейчас. Сначала я подумал, что надо написать автору сайта на е-мэйл, чтобы он убрал бэкапы с этого хостинга, поменял все пароли (никто не знает ведь, кто еще мог уже успеть скачать бэкап его сайта до меня, маловероятно, что я первый до этого додумался), и впредь более осмотрительно относился к безопасности, но звучало все это так невероятно, что для демонстрации возможности я оставил предупреждение в виде черновика в самой админке, хотя так и подмывало нажать кнопочку опубликовать :).

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

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

1. Выкладывание бэкапа на общественный ресурс.

2. Доступ любого пользователя к ссылке на его скачивание.

3. Возможность удаленного редактирования базы данных.

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

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

1. Файлпланете.ком — луч лютой ненависти. Нельзя так относится к данным своих пользователей.

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

3. Удаленное управление базой данных — зло. Гораздо лучше, если она будет на localhost, и доступна из кабинета хостера, это хоть чуть усложнит жизнь взломщикам. Естественно, в кабинет должен быть свой пароль, а не такой же, как на базу.

4. Делая бекап сайта — BackWPup не просто так создает каталог со сложным названием, типа backwpup-9x9z9-logs, в который кладет логи. Не надо светить где-либо название этого каталога. Файл лога имеет стандартное название — типа backwpup_log_2010-01-01_04-08-08.html, ну или такой же архив. Учитывая, что бэкапы делаются, как правило, не реже раза в неделю, и зная название каталога, даже несмотря на то, что добавляется дата и время создания  — подобрать название ссылки к логу простым парсером не составит никакого труда — а по ним прямая ссылка до самого файла бэкапа вычисляется на раз. Также не надо класть их, и сами бэкапы в каталоги с простым названием. И вообще, подумайте — так ли нужны вам логи о процессе бэкапа. Ну и естественно — название самого файла бэкапа. Прямая ссылка на скачивание файла бэкапа с вашего сервера — должна быть максимально закрыта от скачивания, придумайте сложный префикс перед названием, уберите backwpup из него.

5. Крайний идиотизм вордперсса — хранить все данные о базе данных, включая пароль, в незашифрованном виде, но наверное, иначе нельзя. Используйте для базы данных пароль, отличающийся от всех остальных паролей — конечно, это не спасет, если wp-config.php кто-нибудь скачает из какого-нибудь архива (слава богу, просто с сайта скачать его не даст апач), но по крайней мере, он сможет залезть только в ваш блог, но не почту, скажем. Да и вход в сам блог будет невозможен, в случае, если у вас нет удаленного управления базой. И запомните — какие бы  Login LockDown вы не ставили (который сам по себе — не слишком безопасен и имеет несколько неприятных особенностей (но незаменим при совместном использовании с ThreeWP Activity Monitor) — без «3вп активити монитора» лучше пользуйтесь Login Security Solution (этот, правда до конца не блокирует IP, а просто увеличивает время ввода данных) или Limit Login Attempts (этот, правда, не защищает от горизонтальных атак) и оба они не совсем совместимы с ThreeWP Activity Monitor) — если будете разбрасываться своими бэкапами в общем, и wp-config.php в частности — ничем хорошим это не закончится.

6. Поищите, а нет ли какого скрытого администратора у вас на блоге?

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

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

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

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

1

chewriter.ru

Как хакеры используют взломанные WordPress-сайты

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

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

«Что хакеры сделали с вашим сайтом?»

Мы получили в общей сложности 873 ответа, которые были каталогизированы нами, как показано на графике ниже. Многие из ответов подпадали под разные категории.

Мы не стали размещать такие ответы, как «установили бэкдор» или «установили вредоносное ПО». Это может быть сделано с разными целями. Вместо этого мы решили узнать, как именно злоумышленники использовали взломанный сайт.

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

Дефейс сайта / вывод сайта из строя

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

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

Пример дефейса:

Чем это полезно для нападающих?

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

Рассылка спама

Email-спам остается огромной проблемой. Согласно Statistica, в декабре 2015 на долю спама пришлось 54.4% всего email-трафика сети. По данным опрошенных нами пользователей, 19.8% взломанных WordPress-сайтов использовались для рассылки email-спама.

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

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

Чем это полезно для нападающих?

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

SEO-спам

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

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

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

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

Чем это полезно для нападающих?

Я считаю, что многие из вас знают, что выход в топ поисковой выдачи – отличный способ привлечь трафик к сайтам. С помощью SEO-спама хакеры могут направлять трафик с легитимных сайтов на свои собственные ресурсы.

Вредоносные редиректы

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

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

Чем это полезно для нападающих?

Основная мотивация для хакеров – получить трафик для своего вредоносного контента.

Размещение фишинговых страниц

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

Пример фишинговой страницы:

Чем это полезно для нападающих?

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

Распространение вредоносного ПО

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

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

Влияние этого на вашу репутацию будет длительным и очень серьезным. К счастью, только 2.9% респондентов сообщили об этом.

Чем это полезно для нападающих?

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

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

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

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

Чем это полезно для нападающих?

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

Украденные email-адреса могут использоваться для спама. Очевидно, более высокую ценность имеет такая информация, как данные кредитных карт.

Атака на другие сайты

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

Чем это полезно для нападающих?

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

Программы-вымогатели

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

Пример подобных атак:

Чем это полезно для нападающих?

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

Размещение вредоносного контента

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

Чем это полезно для нападающих?

Атакующий получает бесплатное хранилище файлов, которое имеет отличную репутацию (доверенный домен и IP-адрес).

Referrer-спам

Если вы использовали ранее Google Analytics, вы, скорее всего, сталкивались уже с referrer-спамом. Referrer-спам – это трафик, который приходит с поддельного реферера. Спамер пытается заставить владельца сайта перейти по ссылке в реферере, привлекая трафик на свой сайт.

Пример такого спама:

Чем это полезно для нападающих?

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

Заключение

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

oddstyle.ru

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

Привет хабра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

habr.com

Как защитить WordPress от взлома

Рано или поздно владелец каждого крупного интернет ресурса должен задуматься о безопасности своего проекта. Поэтому, если вы ищете, как защитить сайт на WordPress от взлома, эта статья для вас.Самым простым способом защиты является установка специальных плагинов. Так как WordPress – очень популярная CMS, то для нее таких плагинов существует огромное количество. Каждый из них обладает своими плюсами и минусами, особенностями, но мы рассмотрим два наиболее популярных и действенных.

1) Remove WP version and shortlink

Это один из самых простых и полезных плагинов, защищающих WordPress от взлома. Принцип его работы строится на том, что он скрывает версию вашей WordPress от злоумышленников. Это очень важно, потому что хакеры, взламывая сайт, в первую очередь пытаются узнать версию WordPress. Знание установленной версии дает взломщикам информацию об уязвимостях CMS, а именно уязвимости – это то, за что может зацепиться злоумышленник, взламывая сайт. Безусловно, этот плагин не обеспечит вашему сайту полной защиты. Но, учитывая его простоту, мы советуем установить «Remove WP version and shortlink», чтобы усложнить взлом вашего ресурса.

2) Wordfence Security

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

Главные функции и особенности данного плагина:

  • Встроенный Firewall. Эта функция защитит ваш сайт от подавляющего большинства возможных угроз и уязвимостей.
  • Сканирование. Плагин оснащен функцией сканирования по расписанию. Если он находит какие-нибудь угрозы для сайта, администратору тут же отправляется письмо с уведомлением о выявленных опасностях. Одним из самых популярных методов взлома сайта является добавление в файлы вредоносного кода, который не может быть найден антивирусом. Плагин с этой опасностью справляется намного лучше: он проверяет файлы на предмет изменений кода и отправляет результаты администратору сайта. В случае, если изменения были сделаны не владельцем, плагин позволяет восстановить исходный код файлов.
  • Кэширование страниц. Эта функция позволяет ускорить загрузку страниц сайта в несколько раз.
  • Аудит паролей пользователей. Плагин выявляет посетителей вашего сайта со слабыми паролями и позволяет уведомить их об этом, предложив сменить пароль на более безопасный. Если на вашем сайте есть регистрация пользователей, эта функция будет очень полезна.
  • Защита от взлома пароля. Очень часто аккаунты администраторов сайта подвергаются попыткам взлома путем подбора паролей. Данная функция плагина ограничивает число попыток входа и, при исчерпании этого лимита, запрещает доступ ip-адресу злоумышленника.

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

adminvps.ru