Обнаружен вредоносный WSO РНР шэлл-скрипт /libraries/simplepie/idn/OpenIDOpenID.php (сайт на Joomla! 3). На данный момент определяется только некоторыми антивирусами как JS/SARS.S61, PHP:Decode-DE , Trojan.Html.Agent.vsvbn, PHP.Shell.354, php.cmdshell.unclassed.359.UNOFFICIAL.
В один "прекрасный" (это кому как) день, один из наших подопечных (http://ladynews.biz), в результате сканирования своего сайта антивирусом хостинга, получил вот такую вот мессагу:
В аккаунте обнаружены файлы с вредоносным содержимым. Настоятельно рекомендуем ограничить доступ к FTP аккаунту только с используемых Вами IP-адресов, а также воспользоваться антивирусной защитой для проверки аккаунта на наличие вирусов. Ознакомьтесь со статьей Рекомендации по безопасности и защите от взлома для предотвращения повторного заражения.
Разумеется, было предложено разобраться с этим безобразием, - сканирование штатным антивирусом ClamAV, с набором антивирусных баз по умолчанию, не дал дополнительного результата.
На момент начала этой истории (2015-10-23), этот вирусный шелл-скрипт отсутствовал в антивирусных БД большинства антивирусов включая таких "монстров" как Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro и т.п., что также 2015-10-23 было подтверждено онлайн-сканером VirusTotal . Лишь только несколько антивирусов смогли определить вредоносный PHP скрипт:
Антивирус Результат Дата обновления AhnLab- V3 JS/ SARS. S61 20151022 Avast PHP: Decode- DE [ Trj] 20151023 NANO- Antivirus Trojan. Html. Agent. vsvbn 20151023
В тот же день про обнаружение вредоносного скрипта были поставлены в известность ClamAV и Dr.Web. ClamAV пока упорно молчит, а Dr.Web на вредоносную посылку отреагировал в течении 24 часов:
Ваш запрос был проанализирован. Соответствующая запись добавлена в вирусную базу Dr.Web и будет доступна при следующем обновлении.
Угроза: PHP.Shell.354
Dr.Web сдержал своё обещание и вирусный скрипт OpenIDOpenID.php теперь определяется как PHP.Shell.354 , однако многие антивирусы такие как ClamAV, Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro и т.п., ещё понятия о нём не имеют (по состоянию на 2015-10-25).
Ок., файл мы удалили, а надолго ли? Откуда он взялся, мы можем только теряться в догадках. Что дальше? Начинаем ставить всякие Securitycheck компоненты и крутить правила в.htaccess запрещающие доступ к всему и вся ибо на шаред-хостинге (ака Виртуальный хостинг, shared hosting) на большее у нас нет полномочий. На долго ли эти меры спасут, никто не знает.
Кстати на тему всяких Securitycheck компонентов... Securitycheck - это компонент для Joomla! и вполне неплохой. А вот некий "Antivirus Website Protection " полнейший отстой которым я крайне никому нерекомендую использовать, вот подтверждённый практикой отзыв об этом "Antivirus Website Protection":
This Component also creates a pack.tar file in your /tmp that contains your configuration.php and any other passwords found! BE AWARE
Что в переводе означает: " этот компонент также создаёт резервную копию всего сайта в файле /tmp/pack.tar, который содержит configuration.php с паролями от БД! БУДЬТЕ ОСТОРОЖНЫ " - это говорит о том, что "Website Protection" от этого компонента и не пахнет, что также должно навести жертву на мысль про изменение путей к директориям /logs , /tmp , /cache и запрета доступа к ним.
Перейдя по этой ссылке можно понять, что проблеме как минимум больше года. Заглянув сюда поймём, что маскировка шэлл-скрипта выполнена не хитрыми base64_encode/gzdeflate , а значит ещё где-то должна быть часть вызывающая/подключающая OpenIDOpenID.php и выполняющая base64_decode/gzinflate . Значит OpenIDOpenID.php лишь результат (ака следствие), а не причина, где жертва жалуется на то что, с сервера начал отправляться спам в промышленных масштабах, а ручное удаление вредоносных файлов не помогает, после чего жертве кроме как на NIC-RU хостинг жаловаться больше не на кого. "Дырявый" виртуальный хостинг вполне может быть и оч. даже часто имхо люди там работают за з/п, а не за идею, но в некоторых случаях проблема может быть значительно глубже.
Вот к примеру "В файле Adobe Flash обнаружен вредоносный инжектор iFrame ". Думаю ни для кого не секрет, что на флэш можно писать интерфейсы для загрузки файлов на сайт и делать ещё много разных интересных вещей на языке ActionScript . Вирус в.swf файлах (Adobe Flash), как показала практика, может оставаться незамеченным годами и быть чёрной дверью в сайте (ака back door - задняя дверь ) через которую "закидываются" файлы вроде "OpenIDOpenID.php" удалять которые можно до посинения и безрезультатно.
Что же делать, как среди тысяч файлов найти "слабое звено"? Для этого нужно использовать так называемый эвристический анализ и в некоторых случаях применять антивирусные базы данных сторонних разработчиков. Следует брать во внимание, что эвристический анализ, в зависимости от его настроек, может давать много ложных срабатываний чем при использовании дополнительных вирусных сигнатур от сторонних разработчиков.
Где взять антивирусные базы данных сторонних разработчиков? Например базы данных с антивирусными сигнатурами от сторонних разработчиков для ClamAV можно взять бесплатно по адресам: www.securiteinfo.com, malwarepatrol.net, rfxn.com. Как использовать эти дополнительные антивирусные базы? Это уже совсем будет иная история. Можно сказать лишь то, что дополнительные антивирусные базы для ClamAV от rfxn.com (проект LMD (Linux Malware Detect)) нацелены на поиск вредоносного ПО именно в веб-приложениях и даёт более удачные результаты. rfxn.com так же заявляет, что 78% угроз, отпечатки которых содержатся в их БД не определяются более чем 30-ю коммерческими анти-вирусами, - и скорее всего так оно и есть.
Решено было запастись дополнительными антивирусными базами для ClamAV от malwarepatrol.net и rfxn.com, скачать резервную копию файлов сайта да просканировать их локально, вот результат сканирования:
$ clamscan / ladynews.biz / ../ game_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ farmfrenzy_pp_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ beachpartycraze_rus.swf: MBL_2934225.UNOFFICIAL FOUND / ../ hollydeluxe_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ loader_rus.swf: MBL_647563.UNOFFICIAL FOUND ----------- SCAN SUMMARY ----------- Known viruses: 4174348 Engine version: 0.98.7 Scanned directories: 3772 Scanned files: 18283 Infected files: 5 Total errors: 1 Data scanned: 417.76 MB Data read: 533.51 MB (ratio 0.78 :1 ) Time: 1039.768 sec (17 m 19 s)
/libraries/simplepie/idn/OpenIDOpenID.php как и выше упомянутые.swf файлы были удалены, а решена ли проблема? Пока сложно сказать, - копаем дальше...
Из расшифрованной версии файла /libraries/simplepie/idn/OpenIDOpenID.php (http://pastebin.com/WRLRLG9B), взглянув на константу @define("WSO_VERSION", "2.5"); , становится ясно, что это такой себе продукт под названием WSO. Немного покопав сеть по ключевому слову WSO были получены вот такие вот результаты:
Оказывается тема давно не нова, что ж берём в зубы regexxer, продолжаем колупать файлы сайта и обнаруживаем: Error opening directory "/home/user/libraries/joomla/cache/controller/cache": Отказано в доступе
Ага, вот ты с.ка где ещё серануло! Смотрим права на директорию , которой по умолчанию не должно быть, = chmod 111 (ака Выполнить для Владелец/Группа/Все). Таким образом что-то где-то сидит и рассырает себя по каталогам скрывая себя даже от вирусов чмодами 111.
Установив для каталога чмоды 551 и заглянув во внутрь, там был обнаружен /libraries/joomla/cache/controller/cache/cache/langs.php , исходный код которого выложен здесь: http://pastebin.com/JDTWpxjT - каталог /libraries/joomla/cache/controller/cache удаляем.
Отлично, теперь приводим в порядок чмоды на все файлы и каталоги:
# массовая смены прав (chmod) на файлы в директории./dirname и нижележащих find / home/ user/ public_html -type f -exec chmod 644 { } \; # массовая смены прав (chmod) на в./dirname и нижележащих find / home/ user/ public_html -type d -exec chmod 755 { } \;
Ещё раз повторяем проверку антивирусом с дополнительными базами clamscan /ladynews.biz , но якобы всё чисто.
Повторяем поиск файлов regexxer-ом и пробуем поискать по ключевым словам OpenIDOpenID, OpenID или WSO - и, приходим к выводу о том, что п.здец оказался намного ширше и глубже:
/administrator/components/com_admin/index.php и /templates/index.php вероятно были входными скриптами, в которых выполнялся основной код с помощью крайне не рекомендуемой к использованию функции eval() где также использовались:
Что ж, логика маскировки вредоносного кода ясна. Теперь же если мы поищем конструкцию " eval($ ", то мы обнаружим ещё очень много интересного:
Не от всех ещё вирусных РНР скриптов код выложен на pastebin.com ибо в течении 24 часов разрешается только 10 публикаций. В общем порядок удаления примерно следующий:
Да, чуть не забыл, - перед началом удаления вредоносных скриптов не помешает добавить в.htaccess несколько правил запрещающих прямое обращение к любым.php файлам в любых директориях, но разрешающие доступ только к корневым файлам / или /index.php и /administrator/ или /administrator/index.php - это перекроет противному злоумышленнику доступ к входящим шэлл-скриптам спрятанных в различных системных директориях:
{pub} {/pub} {reg}
# ---+++ PROTECT SOME FILES AND DIRECTORY +++--- # RewriteCond %{REQUEST_URI} !^/((index)+\.php|.*\.(htm|html|txt|xml)|+|.*/+|.*/.*\.(css|js|jpg|jpeg|png|gif|ico|eot|svg|ttf|woff|woff2|html)+)?$ RewriteCond %{REQUEST_URI} !^/(administrator)+/(index\.php)?$ RewriteRule ^(.*)$ - # # ---+++// PROTECTED SOME FILES AND DIRECTORY +++---
UPD 2015-10-28: Ну, что? Уже расслабились? Рано ещё...
Теперь ещё поищем в дебрях файлов сайта бинарные файлы, которых в движке не должно быть и в помине:
find / mypath/ -executable -type f find / mypath/ -type f -perm -u+x find / mypath/ -type f | xargs file | grep "\:\ *data$"
Кто ищет - тот всегда найдет (бинарные файлы):
Откуда выросли ноги у этой заразы достоверно установить не удалось, - то ли виновата недавно найденная в движке критическая уязвимость позволяющая выполнять SQL-инъекции и повышать привилегии, то ли упомянутые выше отмеченные как вредоносные.swf файлы, то ли ещё не обнаруженная до сих пор какая-то уязвимость в одном из сторонних компонентов или плагинов, то ли дырявый виртуальный веб-хостинг, - вопрос остаётся открытым?
На текущий момент обнаруженные вредоносные файлы вычищены, файлы движка полностью перезалиты, правилами в.htaccess выстроены баррикады... У кого есть время и кому интересно собрать воедино и поковырять эту кучу говна можете скачать архив wso-php-shell-in-joomla.zip - там упакованы все упомянутые выше вредоносные РНР файлы, пароль от архива: www.сайт
ИТОГО: Паранойи много не бывает, а любой бесплатный или коммерческий антивирус с его эвристикой вместе с дополнительными базами сигнатур далеко не панацея. Следовательно любые анти-вирусы являются устаревшим инструментом для защиты активной многопользовательской среды и для предотвращения различных неизвестных угроз следует использовать именно параноидальные методы защиты, например: виртуализация, SELinux, Bastille Linux, immutable bit, ecryptfs etc!
Большинство атак на корпоративные ресурсы подразумевают внедрение веб-шеллов - кода, который дает возможность управлять пораженными машинами извне сети. AntiShell Web Shell Hunter - это защитное средство, которое включает в себя целый набор механизмов для выявления веб-шеллов.
Web shell - это сценарий, который загружается на сервер и служит для удаленного администрирования. Вредоносным он становится только тогда, когда им управляет злоумышленник. И в этом случае он представляет серьезную угрозу.
Зараженный сервер не обязательно должен быть подключен к интернету - он может располагаться во внутренней сети компании. Тогда веб-шелл применяется для получения доступа к другим хостам с критически важными приложениями или информацией.
Для написания веб-шеллов применяется любой язык, поддерживаемый целевым веб-сервером. На практике чаще всего используются PHP и ASP, поскольку они наиболее популярны. Также распространены вредоносные программы на Perl, Ruby, Python и Unix shell.
Устанавливаются веб-шеллы довольно стандартным для вредоносных приложений способом - используя уязвимости в CMS или программном обеспечении веб-сервера. После этого они функционируют как бэкдоры, что позволяет злоумышленнику выполнять на удаленной машине произвольные команды, в том числе внедрять вымогательский софт или начинать атаки на другие серверы.
Особая опасность веб-шеллов заключается в их относительной простоте. Модификация сценария, в результате которой получается другая программа, - задача, с которой справится даже новичок. Из-за этого качества обнаружение веб-шеллов стандартными антивирусными средствами затруднено.
Подобно другим вредоносным программам, веб-шеллы можно идентифицировать по ряду внешних признаков. Однако значительная их часть может относиться и ко вполне легальным файлам, поэтому любые подозрительные индикаторы необходимо рассматривать в комплексе, анализируя целую картину, а не ее фрагменты.
Возможными показателями наличия веб-шелла на сервере могут быть:
Очевидно, что «ручной» анализ в данном случае если и возможен, то требует слишком много человеческих ресурсов, поэтому его применение лишено всякой практической целесообразности. Программа AntiShell Web Shell Hunter, разработанная компанией Garhi Technology, позволяет автоматизировать эту процедуру, причем ее разработчики утверждают, что она гарантированно распознает все известные веб-шеллы.
В основе приложения лежат следующие технологии:
Таким образом решается одна из главных проблем обнаружения веб-шеллов, связанная с разнообразием используемых языков и возможностью простой модификации. На работу AntiShell Web Shell Hunter эти факторы никак не влияют, что делает его универсальным и позволяет использовать для защиты любого сервера.
Поскольку файлы, которые не были изменены после предыдущего сканирования, исключаются из обработки, AntiShell Web Shell Hunter не создает высокой нагрузки на сервер. К тому же такой подход уменьшает время проверки.
При этом администраторы могут самостоятельно установить время проверки, исходя из суточных колебаний нагрузки на сервер. При необходимости ежедневный режим заменяется на еженедельный или даже ежемесячный, что позволяет оптимизировать работу всей системы.
Программа обнаруживает файлы, в которых содержится код веб-шелла, и предоставляет системному администратору полную информацию по объекту: дата и время создания, имя владельца, права и так далее.
Все эти данные (но не сами файлы) также поступают в клиентский центр компании-разработчика, который на их основании может обеспечить поддержку в обработке инцидента и исследовании его последствий. Клиенты, подписанные на платное обслуживание, также могут с помощью специальной утилиты загрузить сами зараженные файлы для дальнейшего анализа.
Сообщения о найденных объектах направляются системному администратору по электронной почте. У него нет никакой необходимости лично следить за процессом.
На сегодняшний день AntiShell Web Shell Hunter - единственный инструмент, ориентированный именно на обнаружение веб-шеллов. Ряд антивирусных приложений включают в себя аналогичную функцию, но только в виде дополнительной опции, которая по умолчанию неактивна. Как правило, они опираются исключительно на сигнатурный анализ, поэтому их эффективность оставляет желать лучшего.
Поскольку использование веб-шеллов для атак на серверы становится все более распространенным явлением, есть смысл защитить систему при помощи специализированного решения. Как говорится, безопасности никогда не бывает слишком много.
Недавно на необъятных просторах Интернета я натолкнулся на упоминание о "PHP Shell ". Пару лет назад мне эта утилита очень помогла и я сейчас хочу отдать своеобразный долг ее разработчику Martin Geisler (http://mgeisler.net/).
Каково назначение "PHP Shell"? Я полагаю, что каждый "продвинутый" веб-программист, не говоря тем более о сисадминах, сталкивался и использовал SSH. SSH позволяет нам получить удаленный доступ к серверу и выполнять на нем shell-команды (ну там всякие команды типа ходить по каталогам туда-сюда, вверх-вниз, перемещать, удалять и копировать файлы, запускать сценарии и всякие хитроумные утилитки), как будто бы провод к вашему монитору от системного блока удлинился до невероятных размеров и дошел, аж, до сервера хостера. Надо сказать, что возможно через ssh туннелировать и X-графику, изображение рабочего стола, показывая запущенные оконные приложения, но это явно не для веб-серверов.
Одним словом, если у вас на хостинге нет SSH, то "что не ладно в датском королевстве". Минус в том, зачастую SSH по умолчанию на вашем "свежем" сайте отключен, и требуется некоторое время поругаться со службой поддержки, чтобы ssh заработал. Именно так и случилось в тот далекий зимний вечер. Мне нужно было срочно перенести сайт с одной машины на другую, в ходе чего возникли проблемы, и я привычно потянулся к ярлыку putty на рабочем столе, дабы посмотреть что там "внутри" у пациента. Упс..., а поддержка ssh не активирована. Как быть? Если вы достаточно искушены в программировании на каком-то там языке, то не составит сложности написать небольшой скрипт реализующий нужную задачу. Я же открыв google и, пробежавшись по паре ссылок, нашел упоминание о PHP Shell. Одним словом, домой я ушел вовремя.
По правде говоря, мне очень повезло, что хватило тех урезанных возможностей работы с shell, которые предоставила мне PHP Shell - все же это его имитация.
В основе своей PHP Shell использует функцию php - proc_open. Эта функция запускает некоторую команду и открывает потоки ввода-вывода для того чтобы ввести некоторую информацию в приложение (имитируя ручной ввод как бы на клавиатуре) и вывести результаты работы (если вы знаете что такое pipes то речь как раз про них). По сути, функция proc_open является улучшенной и дополненной версией функций exec или system. Те, правда только запускали программу, и не давали возможность взаимодействовать с ней, вы должны были сразу в параметрах командной строки указать все необходимые для работы команды данные. proc_open позволяет создать pipes связанные с вашим php-скиптом, и соответсвенно вы можете имитировать ввод данных в программу и читать результаты ее работы. Для любителей бесплатных хостингов сразу скажу:
"НЕТ, С ПОМОЩЬЮ PHP Shell ВЫ НЕ СМОЖЕТЕ ПОЛУЧИТЬ ДОСТУП К SSH".
Дело в том, для бесплатных или очень дешевых хостингов привычно запускать php в режиме safe_mode. В нем отключен ряд функций, в том числе и proc_open.
"НЕТ, С ПОМОЩЬЮ PHPSHELL ВЫ НЕ СМОЖЕТЕ РАБОТАТЬ С ИНТЕРАКТИВНЫМИ ПРОГРАММАМИ".
Сама суть веб говорит нам, что не возможно запустить на удаленном сервере некоторую программку, которая бы продолжала работу и позволяла бы нам вводить и выводить данные в течении нескольких отдельных http-запросов.
"НЕТ, ВЫ НЕ МОЖЕТЕ ПОЛУЧИТЬ ДОСТУП КО ВСЕМ ПРОГРАММАМ, ФАЙЛАМ И ПАПКАМ НА СЕРВЕРЕ".
Скрипт работает либо от имени apache и тогда его возможности ограничены лишь тем, что в правах делать учетная запись apache. Либо как вариант если на хостинге используется suexec (http://en.wikipedia.org/wiki/SuEXEC), то ваши права будут совпадать с правами учетной записи от которой идет запуск php-скрипта.
Предположим, что это вас не остановило, и вы загрузили и распаковали архив на своем сервере в папку, скажем, phpshell. Если ввести в адресную строку браузера "как-то-называется-ваш-сайт/phpshell/phpshell.php" то вас попросят представиться, ввести имя и пароль - разумеется это не те учетные данные которые вы получили от вашего хостера
Так что вам нужно настроить права доступа: кто может получить доступ к shell через эту утилиту. Для этого в файле config.php найдите секцию users и добавьте в нее имя пользователя и пароль в следующем виде:
Vasyano=secret
Если вас смущает то что пароль задан в открытом виде то воспользовавшись файлом pwhash.php вы можете узнать свертку md5 пароля и в файле config.php будет храниться именно он
Теперь делаем повторную попытку входа и попадаем в окно, где в нижней части окна вводим команду, жмем "запуск" а затем результат ее выполнения отображается в центре окна страницы
На этом все, может и вам phpshell как-нибудь поможет.
