Будни антихака продолжаются

shattered-glass

Ранее я рассказывал о сайте, который мне пришлось латать от дыр sql injection.  Залатал я их не мало и уже успокоился. Но как оказалось, покой нам только снится.

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

Да что ж там ломать-то, недоумевал я. Чтобы загрузить вредоносный контент, нужна какая то форма. Но никаких форм, принимающих файлы, на front-end сайта нет. Создателю этого самопала было просто негде, как мне казалось, накосячить. Иначе, можно было бы искать файлы в каких то временных папках или папках, куда осуществляется загрузка. Будучи в меру неаккуратным, можно создать подходящие лазейки для взлома в случае подобных форм.

Решил попробовать поискать «тонкие места» с помощью утилиты Манул. Интересный проект. Хоть утилита так и не смогла завершить сканирование — все время где то зависала — мне удалось поглядеть её логи без завершения процесса. От туда я почерпнул, что мест, которые нужно проверить в самопальном движке, более сотни.

Тем не менее, в процессе поисков я наткнулся на странные файлы в одном из каталогов сайта, которые должны были попадать на сайт посредством загрузки через файл-менеджер wysiwyg редактора, прикрученного к админке (back-end).

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

Почему они мне показались странными? Это были короткие XML вот такого содержания:

Т.е. это spam-редирект на какой то вшивый сайт по теме быстрого похудения. Были там и другие варианты исполнения редиректа. К примеру, урл сайта шифровался в шестнадцатеричный код.

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

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

А вот якобы файл флеш-анимации adobe (расширение у файла было .fla), а на самом деле скрипт на PHP.

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

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

Я думаю, что следующей линией обороны будет админка сайта. Которая вообще вся держится на честном слове, с молитвами о том, что к ней не подберут пароль. Если front-end это решето, то админка — просто дыра.

После зачистки, пришлось немного поправить config в FCKEditor. Теперь файл-менеджер не работает без инициализации админки. Что дальше?

Хакеры — ваш ход :)

Мало букафф? Читайте есчо !

Защита почты на сервисах yandex.ru и mail.ru

Март 17, 2016 г.

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

Читать

Wordpress XMLRPC DOS атака

Апрель 23, 2016 г.

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

Читать

 

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: