Миналата година популярен WordPress плъгин за форми с над 900 000 активни инсталации беше открит да съдържа критична уязвимост, позволяваща на неудостоверени нападатели да качват произволни файлове на всеки засегнат сайт. Кръпката беше пусната в рамките на 48 часа. Но седмици по-късно изследователи по сигурността все още намираха сайтове, неприложили обновлението — и тези сайтове бяха активно експлоатирани.
900 000 инсталации. Седмици на излагане. Всичко заради плъгин, инсталиран и забравен от повечето потребители.
Това не е рядък сценарий. Той е най-честият начин WordPress сайтовете да бъдат компрометирани.
Как всъщност работят уязвимостите на плъгините
WordPress плъгинът е код, изпълняван на вашия сървър с пълен достъп до базата данни и файловата система. Когато плъгинът има уязвимост, нападателят не се нуждае от вашата парола. Не трябва да ви подмамва да кликнете върху линк. Просто трябва да намери сайта ви, работещ с уязвимата версия на плъгина — което автоматизираните скенери правят постоянно, в мащаб — и да изпрати специално изработена заявка.
Най-честите видове уязвимости:
SQL инжекция. Плъгинът изгражда заявка към базата данни, използвайки въведени от потребителя данни без правилно санитизиране. Нападателят манипулира тези данни, за да извлече цялата ви потребителска таблица, включително имейл адреси и хешове на пароли. При WooCommerce магазини това означава имена, адреси и история на поръчките на клиентите.
Уязвимости при качване на файлове. Плъгин, приемащ качване на файлове — форми за контакт, галерии за продукти, мениджъри на документи — може да не валидира правилно какво се качва. Нападателят качва PHP файл, прикрит като изображение. Веднъж на сървъра ви, посещава URL адреса му и получава директно изпълнение на код: може да чете всеки файл, да пише всеки файл или да установи постоянен backdoor.
Cross-site scripting (XSS). Плъгинът рендерира въведени от потребителя данни на страницата без да ги изчиства. Нападателят инжектира JavaScript, изпълняван в браузъра на администратора при следващото посещение на таблото. Скриптът може да открадне сесийни бисквитки, да добави нов администраторски акаунт или да инсталира зловреден софтуер — без изобщо да докосне страницата ви за вход.
Нарушени контроли на достъпа. Плъгинът регистрира REST API endpoint или admin-ajax действие, но забравя да провери дали заявителят действително е оторизиран. Всеки посетител може да извика този endpoint и да извърши действия, ограничени за администратори.
Особено опасното е, че уязвимостта е в кода на плъгина — не в конфигурацията ви, не в паролата ви, не в нещо направено грешно от вас. Сайтът е уязвим в момента, в който плъгинът е инсталиран, а щом уязвимостта стане публично известна, часовникът тиктака.
Жизненият цикъл на пробив чрез плъгин
Разбирането на хронологията обяснява защо „ще го обновя следващата седмица” е толкова рискова позиция.
Откриване. Изследовател по сигурността или, за жалост, злонамерен играч открива уязвимост в плъгин. Ако е отговорен изследовател, я докладва частно на автора на плъгина.
Пускане на кръпка. Авторът пуска обновление, отстраняващо уязвимостта. Това е моментът, в който часовникът публично стартира. Кръпката може да бъде обратно инженирана, за да се разбере точно какво е променено и защо, давайки на нападателите прецизна рецепта за експлоатиране на непоправени версии.
Публично разкриване. Уязвимостта се публикува в бази данни като WPScan, CVE или разузнавателния канал на Wordfence. Автоматизираните скенери незабавно започват да сондират сайтове за уязвимата версия.
Масова експлоатация. В рамките на часове до дни след публичното разкриване уязвимостта се експлоатира в мащаб. Ботнети сканират милиони сайтове в търсене на уязвима версия на плъгина. Това не е целенасочено — сайтът ви не е специален. Просто е в списъка на сайтове с остарял софтуер.
Компрометиране. Сайтовете, неприложили обновлението, получават инсталирани backdoor-и, инжектиран зловреден код, извлечени данни или установена спам инфраструктура. Нерядко собственикът на сайта не разбира с седмици. Зловредният код е проектиран да бъде невидим — не иска да бъде открит, докато не свърши работата си.
Пролуката от значение е между пускането на кръпката и момента, в който вие я прилагате. За повечето неуправлявани сайтове тя е от седмици до месеци. За някои — никога. Редовно намираме клиентски сайтове с известни уязвимости от преди две години.
Какво показват числата
Годишният доклад на Sucuri за хакнати сайтове последователно показва, че остарелият софтуер — предимно плъгини — е водещата причина за компрометирани WordPress сайтове, отчитайки над 60% от инфекциите, разследвани от тях.
Базата данни с уязвимости на WPScan изброява хиляди известни уязвимости в WordPress плъгини. Всяка година се добавят по няколкостотин нови. Засегнатите плъгини не са неизвестни, рядко използвани — те включват широко инсталирани инструменти за форми за контакт, SEO, page builder-и, слайдери, резервни копия и WooCommerce разширения.
За e-commerce сайтове залозите са по-високи. Компрометиран WooCommerce магазин не само изтича данни — той създава регулаторна изложеност. По GDPR, пробив на лични данни трябва да бъде докладван на съответния надзорен орган в рамките на 72 часа от установяването. Глобата за неуведомяване може да достигне €10 милиона или 2% от глобалния годишен оборот, което от двете е по-голямо. Доверието на клиентите, веднъж загубено чрез известие за пробив, трудно се възстановява.
Предупредителните знаци, пропускани от повечето собственици на сайтове
Към момента, в който сайтът е очевидно компрометиран — резултати от търсене, показващи спам линкове, предупреждения в браузъра, спрян хостинг акаунт — пробивът обикновено е продължавал известно време. Ранните знаци са по-фини:
Необясними администраторски акаунти. Влезте в WordPress таблото и проверете Потребители → Всички потребители. Ако виждате администраторски акаунти, непознати за вас, сайтът ви почти сигурно е бил компрометиран. Нападателите ги създават, за да поддържат постоянен достъп дори след като оригиналната уязвимост е закърпена.
Модифицирани основни файлове. Основните файлове на WordPress — файловете в /wp-admin/ и /wp-includes/ — никога не трябва да се променят между обновленията. Ако скенер на файлове или хостинг контролния панел показва скорошни модификации на тези файлове, това е тревожен сигнал.
Изходящи заявки към непознати домейни. Проверете логовете за достъп на сървъра за POST заявки, изходящи към домейни, непознати за вас. Зловредният код нерядко се свързва с командно-контролни сървъри.
Инжектирано съдържание в базата данни. Злонамерен JavaScript или пренасочвания нерядко се съхраняват в базата данни, а не в файлове, правейки ги по-трудни за откриване с файлово сканиране. Потърсете в таблицата wp_options за <script> тагове или подозрителни URL адреси, нечуващи там.
Внезапни промени в трафика. Скок в трафика от необичайни географски зони или внезапен спад в органичния трафик от търсене (Google деиндексира инжектирани спам страници) могат да индикират компрометиране.
Тези знаци се появяват преди очевидните щети. Улавянето им изисква или инструменти за наблюдение, или редовни ръчни проверки — нито едно от двете не се случва автоматично.
Какво реално предотвратява редовната поддръжка
Бизнесите, с които работим по постоянни планове за поддръжка, не преживяват тези пробиви. Не защото уязвимостите не съществуват — те съществуват, редовно — а защото прозорецът на излагане се мери в часове, не в месеци.
Ето как изглежда правилен работен процес за поддръжка на практика:
Наблюдение за уязвимости. Следим предупрежденията за сигурност за всеки инсталиран плъгин на всеки управляван от нас сайт. Когато се разкрие уязвимост за плъгин на клиентски сайт, научаваме незабавно — не когато случайно влезем в таблото.
Тествани обновления в рамките на 24–48 часа. Критичните обновления за сигурност се прилагат в рамките на ден след пускането им, след основна проверка за съвместимост на staging копие. Това затваря прозореца на експлоатация преди автоматизираните скенери да са имали достатъчно време да атакуват сайта в мащаб.
Редовни одити на плъгините. Освен обновленията, периодично преглеждаме пълния списък с плъгини: кои са активни, кои — неактивни, кои са изоставени (без обновления от 12+ месеца) и кои са излишни. Неактивните плъгини се изтриват, не просто деактивират — неактивен плъгин с уязвимост при качване на файлове все още може да бъде експлоатиран.
Мониторинг на целостта на файловете. Автоматизираните проверки сравняват текущите хешове на файловете с известни добри базови линии. Всяка неочаквана модификация на файл задейства предупреждение, улавяйки инфекциите преди да се разпространят.
Наблюдение на базата данни. Сканираме базата данни за инжектирано съдържание по редовен график. Ако в wp_options или съдържанието на публикации се появят злонамерени скриптове, те се улавят преди да се изпълнят в браузърите на посетителите ви.
Цената на това постоянно внимание е малка част от цената на възстановяване след пробив — в пари, в загубено време и в доверието на клиентите, изграждано с години.
Проблемът с изоставените плъгини
Една категория уязвимости заслужава специално внимание: плъгини, повече не поддържани.
WordPress.org премахва плъгини от директорията си, когато се открие, че имат неразрешени уязвимости. Но премахването от директорията не ги премахва от милионите сайтове, вече инсталирали ги. Плъгин, премахнат от директорията преди три години, може все още да работи на вашия сайт — все още активно уязвим — без оставащ механизъм за обновяване.
Плъгините стават изоставени по различни причини: разработчикът е продължил напред, бизнес моделът не е проработил, плъгинът е бил заменен. Каквато и да е причината, изоставен плъгин е фиксирана цел. Уязвимостите му са известни и никога няма да бъдат закърпени.
Единственият безопасен подход към изоставените плъгини е тяхното премахване. Намерете алтернативна функционалност другаде или приемете загубата на тази функция. Поддържането на изоставен плъгин активен, защото разчитате на едно нещо, което прави, означава търговия с известен, постоянен риск за сигурността за незначително удобство.
Практическа отправна точка
Ако не сте на план за поддръжка и искате да разберете текущото си излагане:
-
Обновете всичко сега. Влезте, отидете на Табло → Обновления и приложете всяко налично обновление. Само това затваря повечето известни уязвимости.
-
Одитирайте списъка с плъгини. Под Плъгини → Инсталирани плъгини разгледайте всичко инсталирано. Изтрийте всичко неизползвано. За плъгини, неполучавали обновление над година, потърсете ги в базата данни на WPScan за проверка за известни уязвимости.
-
Проверете списъка с потребители. Потребители → Всички потребители. Премахнете всички акаунти, непознати за вас, особено администратори и редактори.
-
Инсталирайте монитор за целостта на файловете. Безплатната версия на Wordfence включва файлово сканиране. Стартирайте сканиране сега за проверка за съществуващи инфекции.
-
Настройте автоматични обновления за второстепенни версии. WordPress може автоматично да прилага второстепенни обновления за сигурност. Активирайте поне това — обработва най-критичните кръпки без ръчна намеса.
Тези стъпки отнемат час. Няма да ви осигурят постоянна защита — те са еднократна снимка — но ще затворят най-очевидните пропуски точно сега.
За постоянна защита честният отговор е, че ръчната поддръжка не се мащабира. Повечето собственици на сайтове не проверяват за обновления ежедневно, не наблюдават предупрежденията за сигурност и нямат staging среда за тестване на обновленията преди прилагането им. Това не е критика — просто не е тяхната работа. Именно затова съществуват постоянните планове за поддръжка. Вижте нашия WordPress Security Checklist за пълен преглед на това, как изглежда добре защитен сайт.