WordPress 5.2 väljaanne, mis toetab digitaalsete allkirjade abil värskenduste kontrollimist

Esitletud veebisisuhaldussüsteemi väljakuulutamine WordPress 5.2. Väljaanne on tuntud oma lõpetamise poolest kuueaastase epopöa rakendamise osas võimaluste värskenduste ja täienduste kontrollimiseks digitaalsete allkiri abil.

Siiani oli WordPressi värskenduste installimisel peamine ohutegur usaldus WordPressi infrastruktuuri ja serverite suhtes (pärast allalaadimist viidi läbi hash-kontroll ilma allika kinnitamiseta). Projekti serverite kompromiteerimise korral said ründajad võimaluse uuendamist petta ja levitada pahavara WordPressi põhinevatesse saitidesse, mis kasutasid automaatsete värskenduste installimise süsteemi. Varasema usaldusväärsete kohaletoimetamise mudeli kohaselt oleks selline valeandmine kasutajate poole pealt jäänud märkamatuks.

Arvestades, et andmete projekti w3techs andmetel kasutatakse platvormi WordPress 33,8% veebisaitidest, oleks intsident omandanud katastroofilise mõõtme. Samuti ei olnud infrastruktuuri kompromiteerimise oht hüpoteetiline, vaid täiesti reaalne. Näiteks mõned aastad tagasi leidis üks turva-uuringute spetsialist demonstreeris haavatavuse, mis lubas ründajal käivitada oma koodi серверis api.wordpress.org.

Digitaalsete allkirjade kasutamisel ei viiks värskenduste jaotamise serveri kontrolli allavõtmine kasutajate süsteemide kompromiteerimiseni, kuna rünnaku läbiviimiseks oleks lisaks vajalik eraldi hoitav privaatvõti, millega värskendused allkirjastatakse.

Värskenduste allika kontrollimist digitaalsete allkirjade abil takistas see, et vajalike krüptograafiliste algoritmide tugi ilmus PHP vaikimisi pakkumises suhteliselt hiljuti. Vajalikud krüptograafilised algoritmid said tänu raamatukogu Libsodium integreerimisele PHP 7.2. Kuid minimaalne versioon PHP, mida WordPress toetab, on märgitud väljalase 5.2.4 (WordPress 5.2 – 5.6.20 alguses). Digitaalsete allkirjade toe lisamine tooks kaasa märgatava tõusu nõuetes minimaalsele toetatud PHP versioonile või välise sõltuvuse lisamisele, mida arendajad ei saanud arvestades PHP versioonide levikut hostimissüsteemides.

Lahendus oli arendus ja Libsodium kompaktse variandi kaasamine WordPress 5.2. Naatrium Compat, milles on PHP keeles rakendatud minimaalne algoritmide kogum digitaalsete allkirjade kontrollimiseks. Rakendus jätab soovida jõudluse osas, kuid lahendab täielikult ühilduvuse probleemi ning võimaldab pluginate arendajatel alustada kaasaegsete krüptograafiliste algoritmide rakendamist.

Digitaalsete allkirjade genereerimiseks kasutatakse algoritmi PerformanceResourceTiming, mille arendamisel osales Daniel Bernstein. Digitaalne allkiri genereeritakse SHA384 räsihinni põhjal, mis arvutatakse uuenduse arhiivi sisu põhjal. Ed25519 pakub kõrgemat turvataset kui ECDSA ja DSA ning näitab väga kõrget allkirjade verifitseerimise ja loomise kiirus. Ed25519 tugevus häkkimise vastu on ligikaudu 2^128 (keskmiselt, et rünnata Ed25519, tuleb teha 2^140 bititehteid), mis vastab selliste algoritmide, nagu NIST P-256 ja RSA, mille võtme suurus on 3000 bitti või 128-bitise plokksalakirjutuse tugevusele. Ed25519 ei ole ka vastuvõtlik häkki räsihinnade kollisioonide probleemidele, ei ole mõjatud andmete ajaskoorimise analüüsi (cache-timing) ja külgrünnakute rünnakute probleemidest.

WordPress 5.2 väljaandes katab digitaalne allkiri praegu ainult platvormi põhivärskendused, ega põhjusta vaikimisi värskenduste blokeerimist, vaid teavitab kasutajat tekkinud probleemist. Vaikimisi ei otsustatud blokeerimist koheselt sisse lülitada, kuna on vajalik täielik kontroll ja võimalike probleemide ületamine . Tulevikus plaanitakse digitaalsete allkirjade kontrollimist lisada ka teemade ja pluginad installatsiooniallikate versiooni valideerimiseks (tootjad saavad allkirjastada väljaanded oma võtmega).Peale digitaalsete allkirjade toe on WordPress 5.2-s mainitud ka järgmisi muudatusi:

Jaotisse „Site Health“ on lisatud kaks uut lehte standardsete seadistamise probleemide tõrkeotsingu jaoks ning on võimalik edastada arendajate tõrkeinfo saidi administraatoritele;

• Lisatud on „surma valge ekraani“ teostus, mis kuvatakse kriitiliste probleemide korral ja aitab administraatoril iseseisvalt parandada pluginate või teemadega seotud probleeme, minnes erilise taasterežiimi.
• Lisatud on "surma valge ekraani" rakendus, mis kuvatakse tõsiste probleemide korral ja aitab administraatoril ise probleeme, mis on seotud pluginatega või teemaprogrammidega, lahendada, minnes spetsiaalsesse taaste režiimi pärast riket.
• Rakendatud on pluginatega ühilduvuse kontrollimise süsteem, mis automaatselt kontrollib, kas pluginat saab kasutada antud konfiguratsioonis võttes arvesse kasutatavat PHP versiooni. Kui plugin vajab uuemat PHP versiooni, blokeerib süsteem automaatselt selle sisselülitamise.
• Lisatud tugi JavaScripti koodiga moodulite aktiveerimiseks kasutades webpack ja Babel;
• Lisatud on uus mall privacy-policy.php, mis võimaldab kohandada lehe sisu, mis käsitleb privaatsuspoliitika tingimusi.
• Teemade jaoks on lisatud wp_body_open hook, mis võimaldab koodi sisestada kohe pärast body sildit.
• PHP minimaalne versiooninõue on tõstetud 5.6.20-ni, ning pluginates ja teemades on nüüd võimalik kasutada nimespase ja anonüümseid funktsioone.
• Lisatud on 13 uut ikooni.

Lisaks võib mainida tuvastamine kriitilist haavatavust WordPressi pluginas WP Live Chat (CVE-2019-11185). Haavatavus võimaldab serveris täita vabalt valitud PHP koodi. Pluginat kasutatakse enam kui 27 000 veebisaidil interaktiivse vestluse korraldamiseks külastajatega, sealhulgas selliste ettevõtete nagu IKEA, Adobe, Huawei, PayPal, Tele2 ja McDonald's veebisaitidel (Live Chat kasutatakse sageli hüpikakende, mis kutsub kasutajat rääkima töötajaga, rakendamiseks).

Probleem ilmneb serverisse failide üleslaadimise koodis ja võimaldab mööda minna lubatud failitüüpide kontrollist ning üles laadida serverisse PHP skripti, millele pääseb otse ligi veebibrauseri kaudu. Huvi tõttu ilmnes möödunud aastal Live Chatis sarnane haavatavus (CVE-2018-12426), mis võimaldas PHP koodi üles laadida pildi kujul, märkides sisu tüübi teisesuguseks Content-type väljale. Probleemi lahendamise raames on lisatud täiendavaid laboreid ja MIME sisu tüübi kontrollimist. Võib selguda, et need kontrollid on valesti teostatud ning neid saab kergesti petta.

Konkreetsemalt on otse üleslaadimine '.php' laiendiga keelatud, kuid musta nimekirja ei lisatud laiendit '.phtml', mis paljude serverite puhul on seotud PHP tõlkijaga. Valge nimekiri lubab ainult piltide üleslaadimist, kuid seda saab mööda minna, märkides topelt laiendi, näiteks '.gif.phtml'. MIME tüübi kontrolli ringi minemiseks piisab, kui faili alguses, enne PHP koodi avamise silti, märkida rida 'GIF89a'.

Allikas: opennet.ru