Japanese keyword hack: як я вычысціў заражаны сайт

Што бачыць уладальнік і што бачыць Google

Галоўная асаблівасць гэтага заражэння ў тым, што ўладальніку сайта паказваць няма чаго. Старонкі адкрываюцца, дызайн на месцы, формы працуюць. Заражэнне паказвае сябе толькі пошукаваму роботу.

Адказваў за гэта падменены index.php — адзіны файл, праз які праходзіць кожны запыт да сайта. У норме ён важыць каля паўтара кілабайта. Тут ён важыў 16 622 байты, і лішнія пятнаццаць кілабайт былі зашыфраваным кодам, які рабіў роўна адну рэч: глядзеў, хто прыйшоў. Калі ў запыце значыўся Googlebot, Bing, Baidu ці робат Яндэкса — або калі наведвальнік прыйшоў з японскага Google — замест старонкі сайта аддавалася японская старонка пра сумкі і красоўкі са спасылкамі на чужыя крамы.

Прыём называецца клоакінг: розны адказ розным наведвальнікам. Уладальнік бачыць свой сайт, пошукавік бачыць спам, і ў выдачы паступова аказваюцца сотні старонак, якіх на сайце ніколі не было.

Як гэта праяўляецца

• у Google па запыце site:вашсайт.pl знаходзяцца чужыя старонкі з іерогліфамі;
• Search Console паведамляе пра ўзлом ці паказвае ў справаздачы адрасы, якіх вы не ствaралі;
• пошукавы трафік падае без бачнай прычыны;
• сам сайт пры гэтым працуе нармальна — менавіта таму праблему заўважаюць позна.

Што ляжала на серверы

Усяго я выдаліў 777 файлаў. Гэта не адна закладка, а абжытая інфраструктура, якую нарошчвалі гадамі:

• 191 старонка-дарвей у фармаце .shtml. Фармат абраны невыпадкова: сервер выконвае ўнутры такога файла сістэмную каманду, і кожны зварот да дарвея нанова ствараў на сайце бэкдор. Гэта значыць, выдаліць адзін шкодны файл было мала — яго тут жа аднаўляла суседняя старонка.
• 576 тэставых загрузчыкаў у часовай папцы — па файле на кожнае мажлівае пашырэнне. Так атакуючы высвятляў, які тып файла прапусціць хостынг.
• 22 панэлі кіравання сайтам выгляду папка/выпадковы_лік/index.php, раскіданыя па каталогах.
• Чатыры буйныя закладкі ў корані, уключаючы файлавы менеджар на 86 кілабайт і асобны маленькі файл, прызначэнне якога я растлумачу ніжэй, — ён аказаўся самай цікавай знаходкай.
• 8 каталогаў-дарвеяў, у тым ліку папка wp-includes — на сайце, які працуе не на WordPress. Атака была масавай і неразборлівай: раскладвалі ўсё запар, што-небудзь ды спрацуе.
• Файлы, замаскіраваныя пад ядро сістэмы: ляжаць сярод службовых папак, маюць праўдападобныя імёны і нават капірайт распрацоўшчыка ў шапцы. Вачыма па спісе файлаў такое не знаходзіцца.

Узломшчык абараняў сваю здабычу

Асобна мяне ўразіў .htaccess — файл наладаў сервера. Атакуючы перапісаў яго так, што выкананне любых PHP-файлаў на сайце было забаронена, акрамя кароткага белага спісу. У спісе былі яго ўласныя закладкі.

Сэнс двайны: па-першае, чужыя ўзломшчыкі не змогуць скарыстацца тым жа ўваходам, па-другое, частка сканараў бяспекі ўпіраецца ў гэтую забарону і да шкоднага кода не даходзіць.

Чаму аднаўленне з рэзервовай копіі не дапамагло

Пакуль я разбіраўся, уладальнік savuk.eu зрабіў тое, што робіць большасць: у 9:27 раніцы аднавіў сайт з копіі хостынгу двухтыднёвай даўніны. Закладкі снежня 2022 года прыехалі назад разам з ёй.

Інакш і быць не магло. Заражэнне старэйшае за любую рэзервовую копію, якая захоўваецца ў хостынг-правайдара: копіі жывуць тыднямі, а закладка праляжала на сайце амаль чатыры гады. У архіве яна — такая ж частка сайта, як лагатып і тэксты.

Правіла простае: рэзервовая копія вяртае змест, а не бяспеку. Аднаўляць мае сэнс толькі пасля таго, як знойдзены і зачынены ўваход, і толькі з праверкай самога архіва.

Самае неачевіднае: выдалены файл працягвае працаваць

Гэта месца, на якім лёгка зрабіць няправільную выснову і страціць паўдня.

Заражаны index.php я замяніў на эталонны ў 14:13:53. Праз семнаццаць секунд, у 14:14:10, шкодны код зноў спрацаваў і стварыў свой службовы файл. Яшчэ хвіліну пасля гэтага робат Google атрымліваў з сайта старонку з дзевятнаццаццю кілабайтамі японскага спаму — у той час як звычайныя наведвальнікі бачылі заглушку «сайт на абслугоўванні».

Прычына не ў містыцы і не ў другой закладцы. PHP не чытае файл пры кожным запыце: ён трымае ў аператыўнай памяці ўжо скампіляваную копію (гэта называецца OPcache) і абнаўляе яе не адразу. Пакуль копія жывая, сервер працягвае выконваць код файла, якога на дыску больш няма.

Той самы маленькі файл у корані, пра які я згадаў вышэй, займаўся менавіта скіданнем гэтага кэшу. Атакуючы пра механізм ведаў і карыстаўся ім, каб яго праўкі прымяняліся імгненна.

Выснова для практыкі: пасля чысткі кэш трэба скінуць прымусова, інакш лёгка вырашыць, што заражэнне не прыбралася, і пачаць шукаць неіснуючую другую закладку.

Вынік правяраецца па логах, а не па спісе файлаў

Пустая папка нічога не даказвае. Даказваюць журналы сервера — у іх відаць, што менавіта сайт адказваў на кожны запыт.

На savuk.eu да скіду кэшу было 62 паспяховыя адказы на спам-адрасы, пасля скіду — ніводнага. Вось гэта і ёсць доказ, а не той факт, што файлы выдалены.

Другі абавязковы крок — запытаць старонку ад імя пошукавага робата. Клоакінг па вызначэнні не бачны са звычайнага браўзера, і праверка «я адкрыў сайт, усё нармальна» тут не працуе ўвогуле:

curl -A Googlebot https://вашсайт.pl/

У Windows каманду трэба набіраць як curl.exe: кароткае curl у PowerShell азначае зусім іншае і ключ -A не зразумее.

Калі ў адказе з'яўляюцца іерогліфы ці чужыя спасылкі, а ў браўзеры старонка чыстая — вы глядзіце роўна на тую праблему, пра якую гэты артыкул.

Што я зрабіў па кроках

1. Зняў поўны злепак усіх падазроных файлаў да выдалення — каб было з чым зверацца, калі нешта вернецца.
2. Перавёў сайт у рэжым абслугоўвання, каб падчас чысткі ён нічога не аддаваў ні людзям, ні робатам.
3. Выдаліў 777 файлаў заражэння.
4. Замяніў index.php на эталонны з дыстрыбутыва сістэмы.
5. Перапісаў .htaccess: вярнуў штатныя правілы, адключыў выкананне сістэмных каманд унутры старонак, забараніў выкананне праграмнага кода ў папках для карцінак, загрузак і часовых файлаў. Там ён не патрэбны ніколі, а менавіта туды яго і заліваюць.
6. Прымусова скінуў кэш PHP.
7. Праверыў вынік па журналах сервера і запытам ад імя Googlebot.

Чыстка — гэта палова працы

Выдаліць файлы недастаткова, бо ўваход застаецца адкрытым. Далей ідзе абавязковая частка — яна аднолькавая для любога заражанага сайта, і без яе ўсё вяртаецца:

• змяніць усе паролі — доступ да файлаў, панэль хостынгу, база даных, адміністратары сайта. Пароль ад файлавага доступу лічыцца скампраметаваным па змаўчанні: калі ён быў у атакуючага, любая чыстка бессэнсоўная;
• праверыць базу даных: ці не з'явілася лішніх адміністратараў і чужых пашырэнняў;
• абнавіць сістэму кіравання сайтам да актуальнай версіі;
• знесці пашырэнні, якія гадамі ніхто не абнаўляў, — гэта самы верагодны ўваход;
• разабрацца з журналамі. На гэтым серверы, напрыклад, ляжаў файл памылак на 21 гігабайт, які ніхто ніколі не адкрываў.

Што атака працягваецца, відаць проста ў логах: у той жа дзень адзін адрас метадычна перабіраў пашырэнні файлаў, спрабуючы нешта заліць, а дзясяткі іншых круцілі спам-адрасы ў надзеі, што яны зноў зарабяць.

Як праверыць свой сайт за пяць хвілін

Калі знайшлі — чатыры правілы

• Не аднаўляйце з рэзервовай копіі ўсляпую. Хутчэй за ўсё, заражэнне прыедзе разам з ёй.
• Спачатку паролі, потым файлы. Інакш вы чысціце сайт, да якога ў чужога чалавека па-ранейшаму ёсць ключы.
• Шукайце ўваход, а не толькі сляды. Выдаленая закладка без зачыненай дзіркі вяртаецца за суткі.
• Правярайце вынік па логах і запытам ад робата, а не па тым, што сайт адкрываецца.

І апошняе, менш тэхнічнае. savuk.eu быў заражаны амаль чатыры гады, і ўвесь гэты час ён выглядаў спраўным. Адзінае, што замінала заўважыць праблему раней, — адсутнасць звычкі хаця б раз у квартал зазіраць у Search Console і ў журналы сервера. Гэта бясплатна і займае дзесяць хвілін.

Калі па сваім сайце вы ўбачылі нешта падобнае і не хочаце разбірацца самі — напішыце мне, разбяромся. Адказы на частыя пытанні пра суправаджэнне сайтаў сабраны ў раздзеле FAQ.

Victor Parhimchik, заснавальнік вэб-студыі IT Deweloper