[Analiza] CSRF – ranljivost oddaljene izvršljive kode v WordPress 5.1

Raziskovalci spletnega mesta RipTech so v WordPress 5.0 dokazali ranljivost oddaljene izvršitvene kode (Remote Code Execution). Objava razkriva še eno kritično ranljivost v WordPress 5.1, ki nepooblaščenemu napadalcu omogoča oddaljeno izvrševanje kode na kateri koli namestitvi WordPress-a pred različico 5.1.1.

Napadalec lahko prevzame katero koli spletno mesto WordPress, ki ima omogočene komentarje, tako da skrbnika ciljnega spletnega dnevnika preusmeri na napadalčevo spletno stran. Ko administrator – žrtev obišče zlonamerno spletno stran, se v ozadju izvede izkoriščanje navideznega ponarejanja zahtevkov (CSRF) v ciljnem blogu WordPress, brez da bi uporabnik to opazil. CSRF izkorišča zlorabo več logičnih in sanitarnih napak, ki omogočajo oddaljeno izvrševanje kode in popoln prevzem spletne strani.

Ranljivosti obstajajo v različicah WordPressa pred 5.1.1 in se lahko uporabijo pri privzetih nastavitvah.

WordPress, glede na prenose, uporablja več kot 33 % vseh spletnih strani na svetovnem spletu. Ker so komentarji bistvena značilnost spletnih dnevnikov in so privzeto omogočeni, je ranljivost tako prizadela milijone spletnih strani.

Tehnična analiza

CSRF v komentarju vodi v HTML vnos (»injection«). Ko uporabnik objavi nov komentar, WordPress ne izvaja CSRF preverjanja. Nekateri dodatki za WordPress, kot so ‘trackbacks’ in ‘pingbacks’ bi prenehali delovati, v kolikor bi se izvajalo preverjanje skladnosti. Tako lahko napadalec preko CSRF napada ustvari komentarje v imenu administratorja/skrbnika spletnega dnevnika WordPress-a.

Do tega pride, ker lahko administratorji/skrbniki v komentarjih WordPress spletnega dnevnika uporabljajo poljubne oznake HTML in celo <script> oznake. Teoretično lahko napadalec z zlorabo ranljivosti CSRF ustvari komentar, ki vsebuje zlonamerno JavaScript kodo.

WordPress poskuša ta problem rešiti z ustvarjanjem dodatnega administratorja/skrbnika v obrazcih za komentarje. Ko administrator/skrbnik predloži komentar in veljavno številko, se komentar ustvari brez sanitizacije. V primeru, da je ta številka neveljavna, je komentar ustvarjen, vendar je saniran.

Zajem kode prikazuje, kako se z obrazcem ravna v jedru WordPress-a:

Dejstvo, da se za obrazce za komentarje ne izvaja zaščita CSRF, je znano že od leta 2009. Vendar pa so sedaj raziskovalci odkrili logično napako v procesu saniranja za administratorje. Kot lahko vidite v zgornjem izseku kode, je komentar vedno dezinficiran z wp_filter_kses(), razen če je uporabnik, ki je ustvaril komentar, administrator/skrbnik s zmožnostjo unfiltered_html. Če je temu tako in ni na voljo nobene veljavne številke, bo komentar saniran in popravljen s pomočjo wp_filter_post_kses() – (vrstica 3242 zgornjega izseka kode).

Razlika med wp_filter_post_kses() in wp_filter_kses() leži v striktnosti. Obe funkciji prevzameta nesanitiziran komentar in dovolita le izbrane HTML oznake in atribute. Običajno so komentarji sanitirani z wp_filter_kses(), kar omogoča le zelo osnovne HTML oznake in atribute, kot je <a> oznaka v kombinaciji s href atributom.

To omogoča napadalcu, da ustvari komentarje, ki lahko vsebujejo veliko več HTML oznak in atributov, kot je v komentarjih dovoljeno. Čeprav je wp_filter_post_kses() veliko bolj dovzeten, še vedno odstranjuje vse oznake in atribute HTML, ki lahko vodijo v Cross-Site-Scripting ranljivost – XSS.

Eskaliranje HTML vnosa v shranjeni XSS

Dejstvo, da lahko vnašamo dodatne HTML oznake in atribute, vodi do shranjene ranljivosti XSS v jedru WordPress-a. To pa zato, ker se nekateri atributi, ki jih običajno ni mogoče nastaviti v komentarjih, razčlenijo in manipulirajo na napačen način, kar vodi do vnosov poljubnih atributov.

Ko bo WordPress dezinficiral komentar, bo v komentarju spremenil <a> oznake, z namenom optimizacije za namene SEO.

To naredimo z razčlenitvijo niza atributov (npr.: href=”#” title=”some link” rel=”nofollow”) <a> oznak v asociativno polje (vrstica 3004 zajete kode), kjer je ključ ime in vrednost atributa. 

WordPress preveri, ali je rel atribut nastavljen. Ta atribut lahko nastavite le, če je komentar filtriran prek wp_filter_post_kses(). Če je, obdeluje rel atribut in nato <a> ponovno združi oznako.

Napaka se pojavlja v vrsticah 3017 in 3018 izseka, kjer se vrednosti atributov združijo nazaj, ne da bi se povrnili.

Napadalec lahko ustvari komentar, ki vsebuje oblikovano <a> oznako in npr. nastavi title atribut sidra title=’XSS ” onmouseover=alert(1) id=”‘. Ta atribut je veljaven HTML in bi opravil korak sanitizacije. Vendar pa to deluje samo, ker izdelani znak title uporablja enojne narekovaje.

Ko se atributi spet združijo, se vrednost title atributa obda v dvojne narekovaje (vrstica 3018). To pomeni, da lahko napadalec vpiše dodatne atribute HTML, tako da doda dodatni dvojni citat, ki zapre title atribut.

Primer: <a title=’XSS ” onmouseover=evilCode() id=” ‘> se spremeni v <a title=”XSS ” onmouseover=evilCode() id=” “> po obdelavi.

Ker je bil komentar na tej točki že dezinficiran, je vpisani upravljalnik dogodka onmouseover shranjen v bazi podatkov in se ne odstrani. To omogoča napadalcem, da vstavijo shranjen XSS na ciljno spletno mesto, tako da prikličejo to pomanjkljivost dezinfekcije z ranljivostjo CSRF.

Neposredno izvajanje XSS preko iframe-a

Po tem ko napadalec z ustvarjanjem zlonamernih komentarjev pridobi možnost oddaljenega izvrševanja kode, je njegov naslednji korak, da dobi JavaScript skripto, ki jo izvaja administrator/skrbnik. Komentar je prikazan v predelu ciljnega WordPress bloga. Vmesnik ni zaščiten z glavo X-Frame-Options s samim WordPressom. To pomeni, da je komentar mogoče prikazati v skritem <iframe> na napadalčevi spletni strani. Ker je vnesen atribut upravljalec dogodkov onmouseover, lahko napadalec s pomočjo iframe sledi kurzorju miške upravljalca in takoj sproži XSS.

To napadalcu omogoča, da izvrši poljubno JavaScript kodo s pravicami skrbnika, ki je sprožil ranljivost CSRF na ciljnem spletnem mestu. Java Script koda se izvede v ozadju, ne da bi administrator to opazil.

Postopek izvajanja JavaScripta v oddaljeno izvrševanje kode

Ko napadalec pridobi možnost izvajanja poljubne JavaScript kode s sejo administratorja/skrbnika, je oddaljeno izvrševanje kode enostavno. WordPress skrbnikom spletnega dnevnika omogoča neposredno urejanje datotek .php tem in vtičnikov znotraj nadzorne plošče. Z vstavljanjem stranskih vrat v PHP, lahko napadalec pridobi poljubno izvajanje PHP kode na oddaljenem spletnem strežniku.

Varnosti popravek

WordPress v osnovni nastavitvi samodejno namesti varnostne popravke. Nameščeno morate imeti zadnjo različico 5.1.1. Če ste iz katerega koli razloga onemogočili funkcijo samodejnega posodabljanja, lahko tudi onemogočite komentarje, dokler ni nameščen varnostni popravek. Najpomembneje pa je, da se odjavite iz seje administratorja/skrbnika, preden obiščete druga spletna mesta.

Več o varnosti spletnih strani WordPress si preberite v beli knjigi ‘WordPress – kako varen je?’, kjer smo predstavili 20 koristnih nasvetov, ki jih velja upoštevati.

Povzetek

Izkoriščanje ranljivosti napadalcu omogoča, da prevzame katero koli spletno mesto WordPress s privzetimi nastavitvami. S tem, da skrbnika spletne strani spelje na svojo zlonamerno spletno stran. Napadeni na spletni strani napadalca ne opazi ničesar, prav tako sem mu ni potrebno vključiti v nobeno drugo obliko interakcije. Dovolj je že obisk spletne strani, ki jo je postavil napadalec.

Z našimi strokovnjaki za kibernetsko varnost lahko hitro ugotovimo, ali lahko napadalci preko vaše ranljive spletne strani pridejo do vseh pomembnih poslovnih informacij.

 

Author photo
Povzeto po prispevku na Ripstech blogu.

Želite več strokovnih vsebin s področja kibernetske varnosti?

Naročite naš mesečni e-novičnik.

 

[grwebform url="https://app.getresponse.com/view_webform_v2.js?u=V1sSi&webforms_id=6394102" css="on" center="off" center_margin="200"/]
[iframe-popup id="2"]