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

А началось все до жути банально – я, раньше делавший бэкап сайта вручную путем тупого копирования всех существующих папок на сервере себе на локальный компьютер, затем лезущий в 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 – обязательно проверяйте его версию при установке какой-либо темы. Сервис Ай-болит – может пригодится уже после того, как появились подозрения на то, что сайт взломан.

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