Шинэчлэх хэдхэн секундэд серверийг тань эзлэх аюул: WordPress Core-д RCE цоорхой илэрч, 24 цагт 63 мянган халдлага бүртгэгдлээ

Дэлхийн нийт вэбсайтуудын дийлэнх хувийг хөдөлгөж буй WordPress платформд сүүлийн үед тохиолдоогүй онц ноцтой аюулгүй байдлын цоорхой илэрлээ. Хөгжүүлэгчдийн баг өнгөрсөн өдрүүдэд аюулгүй байдлын яаралтай засвар болох WordPress 7.1.4 хувилбарыг (мөн өмнөх 4.7 салбар хүртэлх хувилбаруудын хамт) нийтэд танилцуулсан ч халдагчид засварын дараа хормын ч завсарлага авсангүй.

Аюулгүй байдлын тэргүүлэгч байгууллага болох Wordfence-ийн мэдээлснээр, засвар нийтлэгдсэнээс хойш ердөө эхний 24 цагийн хугацаанд дэлхий даяар энэхүү цоорхойг онилсон нийт 62,969 удаагийн автомат халдлагын оролдлогыг амжилттай хаасан байна. Вэб хөгжүүлэгчид болон DevOps инженерүүдийг сандаргаад буй уг асуудлын техникийн нарийн ширийн юу байв?

Цоорхойн цаад шалтгаан: Predictable Path ба Race Condition

Энэхүү эмзэг байдалд олон улсын үнэлгээний CVSS системээр 8.1 (High) оноо өгөгдөөд буй бөгөөд WordPress Core-ийн 4.7 хувилбараас эхлээд 7.1.3 хүртэлх бүх хувилбарт нөлөөлж байжээ.

Асуудлын үндэс нь WordPress өөрийн бүрэн хэмжээний багц шинэчлэлтийг (full-package core upgrade) татаж аван задлах үйл явцад оршиж байв:

Таамаглахад хялбар зам (Predictable Staging Path): Шинэчлэлтийн үед WordPress татаж авсан багц файлуудаа нийтийн хандалттай wp-content/upgrade/ хавтас дотор задалдаг.
Инсталлерын файлууд хамт задлагдах: Энэ задлагдаж буй файлууд дунд анх шинээр суулгахад ашиглагддаг WordPress-ийн суулгацын скриптүүд, тэр дундаа тохиргоог дахин эхлүүлэх боломжтой setup-config.php багтаж байв.
Хамгаалалтгүй вэб хандалт: Хэрэв серверийн түвшинд wp-content/upgrade/ хавтас руу чиглэсэн хүсэлтийг хаагаагүй бол гаднын хэн ч вэб хөтчөөр дамжуулан энэ түр хавтсанд шууд хандах боломжтой байжээ.

Ингэснээр систем шинэчлэгдэх явцад бий болох богинохон цонхыг ашиглан халдагч түр хавтас доторх файлууд руу дур мэдэн хүсэлт илгээж, системд нэвтрэх эрхгүйгээр (unauthenticated) серверийн түвшинд дурын PHP код ажиллуулах (Remote Code Execution - RCE) нөхцөл бүрдэж байсан юм.

"Хэдхэн секундийн уралдаан": Халдагчид яаж ажиллаж байна вэ?

Лабораторийн хэвийн нөхцөлд шинэчлэлтийн түр файлууд задлагдаж, солигдоод, устгагдах үйл явц ердөө хэдхэн секунд л үргэлжилдэг. Энгийн хүн гараараа вэб хөтөч дээр хаяг бичиж уг цонхыг тааруулж амжих ямар ч боломжгүй.

Гэвч кибер ертөнцөд энэ бол жирийн асуудал. Халдагчид ботнет болон өндөр давтамжийн автомат скриптүүдийг ашиглан олон зуун мянган WordPress сайтууд руу wp-content/upgrade/.../setup-config.php хаягаар секундийн давтамжтайгаар тасралтгүй хүсэлт илгээж (polling) байна.

Хэрэв тухайн сайт автоматаар (эсвэл гараар) шинэчлэлт хийх тэр мөчтэй халдагчийн хүсэлт давхацвал (Race Condition-д ялбал) сервер халдагчийн хяналтад бүрэн шилжинэ. Засвар зарлагдмагц ийнхүү 63,000 шахам дайралт бүртгэгдсэн нь халдагчид энэ богино цонхыг "агнах" автоматчилагдсан сүлжээгээ шууд ажиллуулсны илрэл юм.

Энгийн хамгаалалтын плагинууд яагаад хүчин мөхөсдөж байна вэ?

Энэхүү халдлагын хамгийн таагүй хэсэг нь уг хүсэлт үндсэн WordPress системийн цөмийг (core bootstrap lifecycle) дуудалгүйгээр шууд Apache/Nginx-ээр дамжин тухайн түр PHP файл дээр тусдаг.

Энэ нь юу гэсэн үг вэ гэвэл: WordPress дотор суудаг ихэнх хамгаалалтын залгаас буюу плагинууд (application-level WAF) уг хүсэлтийг олж харж ч чадахгүй өнгөрөх эрсдэлтэй. Систем ачаалагдахаас өмнө шууд файлын түвшинд гүйцэтгэгдэж байгаа тул хамгаалалтыг заавал серверийн түвшинд давхар хийх шаардлагатай болж байна.

Вэб хөгжүүлэгчид яг одоо юу хийх хэрэгтэй вэ?

Хэрэв та WordPress ашигладаг вэбсайт эсвэл e-commerce платформ хөгжүүлж, удирддаг бол дараах 3 алхмыг хойшлуулалгүй хэрэгжүүлэхийг зөвлөж байна:

1. Нэн даруй 7.1.4 хувилбар руу шинэчлэх

Хэрэв таны сайт дээр automatic background updates идэвхтэй бол систем автоматаар шинэчлэгдсэн байх магадлал өндөр. Гэвч WordPress Dashboard-ын Updates хэсэг рүү орж, хувилбараа 7.1.4 (эсвэл өөрийн ашиглаж буй салбарын хамгийн сүүлийн хамгаалалтын хувилбар) болсныг заавал шалгаж баталгаажуул.

2. Вэб серверийн түвшинд түр хавтсыг блок хийх

Шинэчлэлт хийж дууссан ч гэсэн ирээдүйн эрсдэлээс сэргийлж вэб серверийн тохиргоондоо wp-content/upgrade/ хавтас руу гаднаас шууд хандахыг бүрэн хаагаарай.

Nginx тохиргоонд:

location ~* ^/wp-content/upgrade/ {
    deny all;
    return 403;
}

Apache (.htaccess) тохиргоонд:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Энэхүү ганц дүрмийг серверийн тохиргоонд нэмснээр түр зуурын файл үүссэн ч гаднаас хандах ямар ч аргагүй болж, race condition ашиглах боломжийг 100% хаана.

3. Серверийн Access Log-оо шүүх

Таны сервер рүү сэжигтэй хандалт хийгдсэн эсэхийг мэдэхийн тулд серверийн лог дээрээс дараах төрлийн хүсэлтүүдийг шалгаарай:

grep -i "wp-content/upgrade" /var/log/nginx/access.log

Хэрэв setup-config.php болон upgrade хавтас руу маш богино хугацаанд олон тооны GET/POST хүсэлтүүд ирсэн байвал таны серверийг халдагчдын бот онилсон байх магадлалтай.

Дүгнэлт: Инженерийн сургамж

Энэхүү хэрэг явдал нь програм хангамжийн архитектурт "Түр зуурын файлын менежмент" ямар ноцтой аюул дагуулж болохыг харуулсан сонгодог жишээ боллоо. Вэбээр шууд дуудагдах боломжтой зам дээр суулгацын скрипт задлах логик нь хэдийгээр олон жил ажиллаж ирсэн ч автомат ботнетуудын эрин үед хамгийн аюултай цоорхой болон хувирчээ.

Аливаа системд зөвхөн аппликейшний дотоод код найдвартай байх нь хангалтгүй бөгөөд серверийн түвшний хязгаарлалт, хандалтын хяналт давхар ажиллаж байж л бүрэн хамгаалалт бүрддэг (Defense in Depth) гэдгийг санаж, сайтуудынхаа тохиргоог дахин нэг нягтлаарай.

Эх сурвалж: The Hacker News, Wordfence Intelligence Research, WordPress.org Core Security Release Notes.