Последната уязвимост в wp2shell беше едно от най-големите събития в историята на сигурността на WordPress. Критичната верига от уязвимости комбинира два недостатъка, които позволиха на неаутентикирани атакуващи да експлоатират уязвими сайтове и в крайна сметка да изпълняват отдалечено злонамерен код, като потенциално поемат контрол над тях.

През първата седмица след разкриването бяха извършени над 45 милиона опита за експлоатация от близо 150 000 уникални мрежови източника. И докато обемът продължаваше да нараства, видяхме колко бързо разкриването на уязвимост може да се превърне в масова експлоатация. За сравнение, този мащаб беше приблизително 20 пъти по-голям от наблюдавания по време на Drupalgeddon, което илюстрира колко много се е увеличил капацитетът за автоматизирани атаки.

Излизайки от инцидента, не трябва да разглеждаме уязвимостта сама по себе си, а това с колко малко време разполагат защитниците сега между разкриването и широкоразпространената експлоатация. Екипите за сигурност трябва да изхвърлят процесите за управление на уязвимости, изградени около дни или седмици за оценка и отстраняване. Този времеви график вече не е точен. Сега те трябва да се подготвят за прозорец за реагиране, който все по-често се измерва в рамките на само няколко часа.

Масовата експлоатация вече не изисква точно насочване

Тази атака ни казва много за поведението на съвременните атакуващи. Един критичен знак е, че киберпрестъпниците вече не отделят време за внимателно идентифициране на уязвими среди, преди да действат.

По време на този инцидент видяхме автоматизирано сканиране за wp2shell да удря среди на Drupal, използвайки същите специфични за WordPress URL шаблони – сайтове, които първоначално никога не биха могли да бъдат уязвими към този конкретен недостатък.

Това е съществен детайл, защото показва, че сканирането не е било подбрано или ръководено от разузнаване. То беше насочено безразборно към всичко достъпно в интернет, като URL шаблонът извършваше единственото „насочване“. При мащаба на тази атака всички неуспешни заявки струват много малко на атакуващите. Това значително променя икономиката на експлоатацията от „идентифицирай, след това атакувай“ към „атакувай широко, след това идентифицирай какво е проработило“.

Въпреки че автоматизацията на експлоатацията не е нещо ново, днешните технологии за изкуствен интелект (ИИ) и големи езикови модели (LLM) потенциално могат да съкратят части от процеса още повече, като помагат за тълкуване на разкритията, адаптиране на Proof-of-Concept код, генериране на вариации на злонамерен код или отстраняване на проблеми в скриптове. Лидерите в областта на сигурността вече виждат как ИИ действа като мултипликатор на сили за легитимна работа по сигурността, като същата икономика се прилага и за атакуващите: повтарящите се технически задачи могат все по-бързо да се изпълняват в по-голям мащаб.

ИИ не е единствено отговорен за мащаба на тази атака. Екипите за сигурност трябва да работят с предположението, че новите уязвимости могат да бъдат приведени в действие по-бързо от всякога, независимо кои точно инструменти за автоматизация използват атакуващите.

Организациите вече не трябва да приемат, че неизвестността, платформените разлики или липсата на интерес от страна на атакуващите ще им спечелят значително време, тъй като този случай ни показа точно обратното.

Минимизирането на риска не е същото като отстраняването на уязвимостта

Прекъсването на веригата на експлоатация не означава непременно, че основната уязвимост е изчезнала. Например изолирането на базата на контейнери и контролите по време на изпълнение могат да блокират компонента за отдалечено изпълнение на код от веригата на атаката, като значително намалят потенциалното въздействие, дори когато дадена уязвимост се експлоатира активно в мащаб. Въпреки това, приложенията без инсталирани корекции за сигурност може все още да останат уязвими към други компоненти от веригата, като SQL инжекция, докато не бъдат напълно внедрени корекции на ниво приложение и по-широки мрежови защити.

Инфраструктурните защити, като контейнеризация, сегментация, WAF правила и контроли в периферията на мрежата, могат да осигурят критична защита, но те трябва да се разглеждат като слоеве, които купуват време на защитниците, а не като заместители на инсталирането на корекции за сигурност. Нито една единична мярка за безопасност не трябва да поема цялата тежест на защитата. Целта на ешелонираната отбрана е да гарантира, че когато един контрол се провали или блокира само един етап от атаката, друг застава между атакуващия и пълния компромат.

Тази разлика има значение, тъй като прилагането на корекции за сигурност след разкриване като това никога не е мигновено и не е равномерно. Седмици след първоначалната корекция все още виждаме смесена картина. Някои организации инсталираха корекции за сигурност в рамките на няколко дни, докато други остават изложени на риск и днес.

Този дълъг период на забавяне е точно там, където компенсиращите контроли доказват своята стойност, тъй като те са това, което стои между бавния цикъл на обновяване и активния компромат.

Прозорецът между разкриването и масовата експлоатация се свива, така че организациите може да не са в състояние реално да отстранят веднага всяка засегната уязвимост в приложенията. Ето защо архитектурата е толкова важна и тя трябва да ограничава размера на щетите, които защитникът може да понесе в пролуката между разкриването и отстраняването на уязвимостта.

Когато става въпрос за защита, целта не е да се омаловажи значението на инсталирането на корекции за сигурност. Целта е да се предотврати възможността една пропусната или забавена корекция незабавно да се превърне в голям пробив и пълномащабна атака.

Управлението на уязвимости трябва да се движи със скоростта на атакуващия

Когато погледнем традиционното приоритизиране на уязвимостите, обикновено виждаме...