Дупка в сигурността на WordPress предостави достъп до вашата база данни на лица, които никога не са влизали в профил. В продължение на 227 дни това отнемаше само една заявка. Не беше необходима парола, нито плъгин – просто адрес, който е част от WordPress от декември 2020 г.
WordPress е софтуер с отворен код, така че корекцията трябваше да бъде публикувана публично. Тя се появи в петък следобед: три комита, три файла с клеймо за време 16:27 UTC. Сравнявайки старата версия с новата, всеки може да разбере какво е било компрометирано.
Изследователите, които откриха проблема, се опитват да запазят поверителност въпреки това. Адам Куес от Searchlight Cyber е докладвал за него, а в тяхната статия се казва: „Предвид сериозността на грешката и за да дадем време на защитниците да инсталират корекции за сигурност, към момента не публикуваме технически подробности.“
Кодът по-долу идва от самия WordPress.
От версия WordPress 5.6 (декември 2020 г.) на всеки WordPress сайт съществува адрес, който позволява изпращането на няколко инструкции наведнъж. Той е предназначен за разработчици, надграждащи даден сайт. Намира се на /wp-json/batch/v1 и за достъп до него не е необходимо да сте влезли в системата.
Да започнем с по-лесната част. Поискайте от даден сайт публикации и задайте филтър „не са написани от тези автори“ и WordPress взема вашия списък и го вкарва директно в заявката към базата данни. Ето кода, който беше активен до петък:
Уловката се намира на един ред по-горе. WordPress принудително преобразуваше тези стойности в чисти числа само когато те пристигаха като списък. Изпратете ги по друг начин и вашият текст влизаше в заявката непроменен. Точно това представлява SQL инжекцията: вашите входящи данни спират да бъдат просто данни и стават част от изпълняваната команда.
Корекцията превръща всичко изпратено в чист списък от числа:
Сега за другата половина, която често се пропуска в новините.
Когато изпратите пакет (batch), WordPress изгражда два паралелни списъка. Единият съдържа информация кой манипулатор (handler) ще обслужи всяка от вашите инструкции. Другият отчита дали всяка една от тях е преминала проверките си. По-късно WordPress преминава през инструкциите по номера и чете позиция едно от първия списък и позиция едно от втория списък и т.н.
Това работи само ако и двата списъка останат с еднаква дължина.
До петък това не беше така. Ако някоя инструкция във вашия пакет имаше път, който WordPress не може да прочете, тя отиваше във втория списък, но не и в първия. От този момент нататък номерирането се изместваше с едно и всяка следваща инструкция се изпълняваше от манипулатора на съседната.
Това е объркването на пътя (route confusion). Корекцията е на един ред:
На страницата има и нещо, което би трябвало да каже на собствениците на сайтове какво да правят. Под заглавието „Смекчаване на последиците“ (Mitigation) препоръката гласи:
„Най-добрият начин да се защитите е да актуализирате WordPress до версия XXX възможно най-скоро.“
XXX. Временен маркер, който така и не е попълнен. Проверих отново тази сутрин, повече от 14 часа след като беше публикуван, и все още стои там. Страницата, чиято цел е да посочи безопасната версия, не я споменава.
WordPress е бил в подобна ситуация и преди. През януари 2017 г. изследовател от Sucuri откри уязвимост в същия този интерфейс. WordPress я коригира тихо и изчака една седмица преди да обяви каквото и да било по същата причина: да се даде време на сайтовете. Когато стана публично достояние, атакуващите анализираха корекцията и тръгнаха по обратния път. Wordfence преброи над 1,5 милиона деформирани (defaced) страници в рамките на няколко дни.
Ето какво се случи този път. Корекцията за сигурност стана публична в 16:27 UTC. Първото публично хранилище в GitHub с работещ експлойт се появи в 20:18 UTC същата вечер. Три часа и петдесет и една минути.
До тази сутрин вече имаше 24 такива. Скенери, Docker среди с уязвима версия на WordPress вътре и пълни технически анализи на първопричината. В един от тях директно се заявява, че анализът е направен чрез сравняване на старата и новата версия.
Нямаше изтичане на информация. Те просто прочетоха корекцията.
Сега за частта, с която трябва да се внимава, защото повечето медийни публикации след седмица ще сгрешат за нея.
Searchlight класифицира това като отдалечено изпълнение на код (RCE). WordPress и Cloudflare също го правят. Но ако прочетете независимите анализи, публикувани през нощта, се очертава по-точна картина.
Какво е сигурно: имаме неавтентифицирана SQL инжекция с пълен достъп за четене на базата данни. Хешове на пароли, съдържанието на wp_options.
Преминаването от четене на базата данни към изпълнение на код изисква съвпадането на още три неща. Потребителят на базата данни трябва да има права, каквито cPanel и хостинг доставчиците обикновено не дават. Трябва да има директория, в която MySQL може да пише и която уеб сървърът също обслужва. И файлът, който се запише там, трябва да може да бъде прочетен от уеб сървъра. При обикновен споделен хостинг тези условия не са изпълнени и заплахата се ограничава до четене на базата данни.
Cloudflare също постави писмено условие: пътят за изпълнение на код работи, „когато не се използва персистентно кеширане на обекти“. Searchlight твърди, че атаката няма предварителни условия. Тези две твърдения се разминават и все още няма публикувани доказателства в подкрепа на едното или другото.
Затова подходете по следния начин: приемете, че базата данни е четима. Считайте останалото за спорно и следете следващите публикации.