Kiril Kadiev 
Клиент ни потърси, защото трие заразени файлове, а те се връщат. Това е типичният признак за SC 4.0.3. Не трийте повече, преди сайтът да бъде спрян за проверка.
Ако търсите "изтривам файл и се появява отново", вероятно сте попаднали на самовъзстановяващ се malware. При него частичното чистене не помага. Докато сайтът работи, една заявка може да върне премахнатите компоненти.
Не възстановявайте веднага стар архив и не влизайте в WordPress администрацията. Първо уведомете хостинг компанията. После трябва да се запази копие за разследване, да се намерят всички засегнати инсталации и чак тогава да започне чистенето.
Какво представлява SC 4.0.3
SC 4.0.3 е самовъзстановяващ се зловреден код за WordPress. Той не разчита на един заразен файл. Разполага компонентите си на около девет независими места. Те се наблюдават и се възстановяват взаимно.
Ако бъдат премахнати осем от девет копия, останалото може да върне целия комплект за часове. Понякога това става в рамките на една заявка към сайта. Затова сканирането може първо да покаже чист резултат, а после да намери същия WordPress вирус отново.
SC 4.0.3 не е създаден да чупи видимо сайта. Собственикът отваря страниците и вижда обичайното съдържание. На ботовете на търсачките обаче се показва друго съдържание чрез SEO cloaking по User-Agent. В наблюдаваните случаи това беше хазартен спам на чужд език.
Това прикриване позволява проблемът да остане незабелязан. Сайтът изглежда нормално, но Google индексира страници, които собственикът никога не е създавал.
Как да разпознаете заразата
Един симптом не е достатъчен за окончателна диагноза. Съчетанието на няколко от следващите признаци обаче е сериозна причина сайтът да бъде спрян и проверен.
Файловете и предупрежденията се връщат
Класическият признак е прост. Изтривате подозрителен файл, а той се появява отново. Сканиращият плъгин намира една и съща заплаха при всяка проверка. Някои плъгини се самоизключват или започват да дават грешки, защото компонент на заразата се зарежда преди тях.
Това не означава непременно, че някой влиза ръчно всеки път. По-вероятно е да е останало друго активно копие, което възстановява премахнатото.
Search Console показва непознати адреси
Проверете Google Search Console. Следете за рязък скок в броя на страниците, адреси, които не сте създавали, и заглавия на чужд език. При маскираните зарази проблемът често се вижда първо там.
Не разчитайте само на това, което виждате в браузъра си. SC 4.0.3 може да сервира различно съдържание според User-Agent.
Посетителите виждат пренасочвания
Възможно е клиент да съобщи за пренасочване, което вие не успявате да повторите. Решението кого да пренасочи може да зависи от User-Agent, източника на трафика или от това дали човекът е посещавал сайта наскоро.
Други следи са дублирани плъгини на различни места и файлове с безсмислени имена. Те не доказват сами по себе си зараза, но трябва да бъдат проверени.
Какво не трябва да правите
Най-естествените реакции при хакнат WordPress сайт могат да унищожат следите или да задействат възстановяването на кода. Затова тези действия трябва да бъдат избегнати още в началото.
Не трийте файлове, докато сайтът работи
Всяка заявка към работещия сайт може да активира останал компонент. Частичното чистене се превръща в надпревара, която не може да бъде спечелена файл по файл.
Правилният подход е сайтът да се спре. Всички известни копия се премахват наведнъж и едва след това сайтът се връща онлайн.
Не възстановявайте архив напосоки
Заразата може да е присъствала седмици или месеци, преди да бъде открита. Старият архив вероятно съдържа същите компоненти. Възстановяването им няма да реши проблема.
То може и да изтрие времената и файловете, по които се установява откъде е дошъл пробивът. Архивът първо се пази като доказателство и се проверява. Не се използва автоматично за връщане на сайта.
Не влизайте в администрацията
Не отваряйте WordPress администрацията, докато сайтът не е потвърдено чист. Service worker в браузъра на администратор може да продължи да зарежда стар скрипт от кеша и да го върне обратно.
Уведомете и хостинг компанията. Част от компонентите може да са извън обхвата на обикновения FTP достъп. Само хостингът може да провери дали проблемът се е разпространил към съседни акаунти.
Къде се крият компонентите
SC 4.0.3 използва места, които WordPress зарежда рано или които обичайният файлов мениджър и списъкът с плъгини не показват добре.
Кодът може да тръгне преди WordPress
Една от основните следи е файлът .user.ini. В него има директива auto_prepend_file, която сочи към PHP файл с шестнайсетично име в wp-content, например от вида fdd66935.php.
Посоченият файл се изпълнява преди всеки PHP файл на сайта. Това включва и самия WordPress. Дори цялото ядро да бъде изтрито и качено наново, компонентът продължава да работи, ако .user.ini е останал.
До PHP файла може да има скрит близнак с точка отпред, например .fdd66935.php. Много файлови мениджъри не показват такива файлове по подразбиране.
Архивите пазят комплект за възстановяване
В wp-content са намирани архиви с шестнайсетични имена, например 3610625e.zip. Те са около няколко десетки килобайта и съдържат комплект за възстановяване на заразата.
Това обяснява защо изтриването на видимия PHP файл не е достатъчно. Архивът остава на място и друг компонент може отново да разгъне съдържанието му.
WordPress зарежда някои копия автоматично
Проверяват се drop-in файловете advanced-cache.php, object-cache.php и db.php. WordPress ги зарежда автоматично и много рано, преди темата и преди повечето плъгини.
Проверява се и wp-content/mu-plugins. Задължителните плъгини в тази папка не се виждат в обикновения списък с плъгини и нямат бутон за деактивиране. Компоненти може да има и в базата данни, най-често в таблицата с настройките.
Подправените дати оставят воден знак
Кодът подправя времената на файловете си. Публичният скенер ux2dev/wordpress-sc403-cleaner използва критерий, който сме проверили при заразени инсталации. Остатъкът от времето на подозрителните файлове при деление на 100 000 е точно 93819.
Обикновен файл попада на тази стойност с вероятност едно на сто хиляди. При проверените инсталации критерият съвпадна едновременно за .user.ini, скритите архиви и mu-плъгина.
Скенерът проверява по дванайсет критерия. Той умишлено не трие нищо, а само докладва. Това е важно, защото първата задача е да се установи обхватът, без да се унищожават следите.
Правилният ред за чистене
При SC 4.0.3 редът има значение. Сайтът се спира, състоянието се архивира, намират се всички инсталации и всички компоненти се изваждат едновременно.
Спрете сайта и запазете доказателствата
Преди промени се прави пълен архив на файловете и базата. Този архив не е предназначен за автоматично възстановяване. Той пази времената, подозрителните файлове и данните, нужни за разследването.
Бекъпът трябва да бъде проверен. Стандартната команда на WP-CLI за износ на базата може да отчете успех и да създаде файл от двайсет байта, тоест празен архив, без предупреждение. Базата се изважда с mysqldump, а размерът на всеки създаден архив се сверява.
Намерете всички WordPress инсталации
Един хостинг акаунт често съдържа повече сайтове, отколкото собственикът помни. При акаунт, който поехме за чистене, папка, описана като стар и неизползван сайт, съдържаше пет работещи сайта.
Забравената инсталация не се обновява, но работи със същите права като останалите. Обхождането не трябва да се прави по спомен. Всяка папка с wp-settings.php е отделна WordPress инсталация и трябва да бъде проверена.
Намерете входа, а не само товара
Товарът е това, което заразата прави. Входът е мястото, през което е проникнала. Ако входът остане отворен, сайтът може да бъде заразен отново след чистенето.
Датите на промяна дават ориентир кога е започнал проблемът. Логовете за достъп показват какво е било заявено непосредствено преди първата промяна. Обикновено там се вижда заявка към плъгин с известна дупка.
Премахнете всичко едновременно
Компонентите се преместват настрани по предварително подготвен списък. Не се трият окончателно, за да останат достъпни за проверка. Това включва .user.ini, скритите близнаци, архивите, drop-in файловете, mu-плъгините и записите в базата.
Ядрото и плъгините се свалят наново от официалните източници и се заменят изцяло. Не се поправят ред по ред. Ръчното премахване на инжектиран код лесно пропуска промяна.
wp-content не може просто да бъде заменена. Тя съдържа качени файлове и специфични за сайта данни. Преглежда се файл по файл. PHP файл в папката за качени изображения е практически винаги зловреден, независимо от името му.
Сменете достъпа и почистете браузърите
В един и същи час се сменят паролите на всички администратори, паролата за FTP, контролния панел и потребителя на базата. Сменят се и ключовете за сесиите в wp-config.php. Това прекратява активните WordPress сесии.
Проверяват се непознати администратори, чужди SSH ключове и планирани задачи. Cron задача, която веднъж на час сваля и изпълнява външен файл, ще върне заразата след всяко чистене.
Накрая се чистят данните за сайта в браузърите на всички, които са влизали в администрацията. Service worker се намира в браузъра, а не на сървъра. Затова може да преживее пълна подмяна на файловете.
Как се заключва чистият сайт
Защитните правила се добавят едва след потвърдено чистене. Иначе могат да скрият симптомите или да попречат на проверката, без да премахнат активната зараза.
Забранете изпълнението на PHP
PHP се забранява в wp-content/uploads, wp-content/upgrade и wp-includes. Правилото за .htaccess е:
<Files *.php> Require all denied </Files>
Това не предотвратява качването на файл, но не позволява той да бъде изпълнен като PHP от тези папки.
Ограничете публичната информация и входовете
Забраняват се readme.html, license.txt, wp-config-sample.php, debug.log и остатъците от разработка. Изключва се показването на съдържанието на папките. Автоматичните скенери използват тази информация, за да преценят какво да атакуват.
Спира се и изброяването на потребители през параметъра author:
RewriteCond %{QUERY_STRING} (^|&)author=\d [NC] RewriteRule ^ - [F,L] Същото важи за /wp-json/wp/v2/users. При един прегледан сайт този адрес връщаше осем килобайта с потребителски имена на всеки посетител.
xmlrpc.php се спира, ако не се използва мобилното приложение на WordPress или външна интеграция. Този файл позволява стотици опити за влизане в една заявка.
Как се проверява резултатът
Проверката трябва да мине през публичния адрес на сайта, както го отваря обикновен посетител. Заявка към 127.0.0.1 с подадено име на сайта не е надежден тест. При споделен хостинг тя може да попадне на подразбиращия се сайт на машината.
Във всеки тест трябва да има контрол. Освен забранените адреси се отваря файл, който със сигурност съществува и трябва да върне нормален отговор. Ако и той дава грешка, проблемът е в метода на проверка, а не непременно в сайта.
Някои хостинги показват страница срещу ботове при серия еднотипни заявки. Затова проверките се правят една по една, с пауза и с нормален браузърски идентификатор.
Накрая се създава списък с контролните суми на всички файлове. Той се пази извън сайта. След няколко дни се прави ново сравнение. Ако отпечатъкът съвпада, няма върнали се файлове. При по-късна промяна списъкът показва точно кои файлове са различни.
Капаните, които бавят чистенето
- Плъгинът отказва да се обнови. WordPress проверява съвместимостта с ядрото и версията на PHP. Отказът може да е защита, а не повреда. Неприятният резултат е, че старото ядро държи заключени и поправките по сигурността.
- Старият домейн вече не работи. Това не прави файловете безопасни. Инсталацията остава на сървъра и може да бъде изпълнена от човек, който знае пътя до нея.
- Сканиращият плъгин отчита чист резултат. Той работи вътре в WordPress, докато
.user.iniи drop-in компонентите се зареждат преди него. Затова един плъгин не е достатъчен за проверка на SC 4.0.3.
Неизползваните инсталации трябва да бъдат свалени, а не оставени в странична папка. Ако няколко сайта делят един хостинг акаунт, пробивът в един от тях поставя под риск всички останали.
Какво пази сайта след чистенето
- Редовни обновявания. Виждали сме пробиви през дупки, за които поправка е имало месеци по-рано.
- Двуфакторно влизане. То трябва да е включено за всички администратори.
- Бекъп извън сървъра. Копие на същата машина не е достатъчно.
- Отделен акаунт за всеки сайт. Така един пробив не дава същите права върху останалите сайтове.
- Премахване на старите инсталации. Сайт, който не се използва, се архивира извън сървъра и се сваля.
- Проверка на Search Console. Там маскираното спам съдържание често се вижда преди промяна в самия сайт.
Тези мерки не заменят чистенето. Те намаляват вероятността същият вход да остане отворен и помагат следващата промяна да бъде забелязана навреме.
Кога трябва да се включи хостингът
При съмнение за SC 4.0.3 хостингът трябва да бъде уведомен още преди чистенето. Българските хостинг компании вече имат процедура за тази зараза. Те могат да проверят компоненти извън FTP достъпа и разпространение към други акаунти.
За второ мнение може да използвате и публикуваните указания на JUMP.BG. Те описват същия тип самовъзстановяващо се поведение.
Ако имате хакнат WordPress сайт, файловете се връщат или Search Console показва чужди страници, пишете ни. Ще проверим обхвата и ще подредим чистенето така, че доказателствата да се запазят, а всички компоненти да бъдат премахнати наведнъж.
