La mia prima (immeritata) CVE

Ciao a tutti, oggi vi parlerò di come ho trovato la mia prima CVE.

Prima di partire col racconto, premetto che era la prima volta che cercavo vulnerabilità su plugin wordpress e l’approccio avuto col CNA (spiegherò dopo cos’è) non è stato dei migliori quindi non prendetelo come esempio.

Perchè cercare vulnerabilità su plugin wordpress?

C’è da dire che non sono partito subito sui plugin WP, ho inizato a bucare qualche piccolo software in php ma le vulnerabilità erano troppo banali e apparte qualche ID su exploit-db non davano alcuna soddisfazione. Così sono passato a textpattern, un piccolo ma emergente CMS di cui avevo sentito parlare, e dopo un’oretta circa avevo trovato un file upload to RCE, anche se authenticated, e mi ero già messo a scrivere un exploit in python quando per pura curiosità sono andato a cercare textpattern su exploit-db e ho scoperto che la vuln era già pubblica, inutile dire la mia reazione. Così ho deciso di cercare su plugin wordpress perchè ci stava molta scelta ed era l’unico CMS che conoscevo abbastanza.

Il plugin

A questo punto ho iniziato a cercare plugin che sembrassero avere più vulnerabilità (voi riderete, ma ride bene chi ride ultimo) e ho trovato WPSchoolPress, che permette di gestire un’istituto scolastico dalla propria dashboard, tra l’altro fatto davvero bene. Così ho iniziato dal principio testando ogni pagina e facendo code review con le mie modestissime skill di PHP e ho trovato che i dev usavano la funzione wp_sanitize_text_field() (dettagli qui), che toglie > e < da una data stringa, per prevenire XSS. Subito mi è tornata in mente una stored XSS che avevo trovato in uno di quei software che testavo prima e dopo aver trovato un parametro che era riflesso in un tag <input> ho provato a rompere il parametro text e iniettarci un evento che eseguisse codice JavaScript per poi richiuderlo. Il payload finale era " onclick=alert(1) test=" e dopo averlo inviato e aver ricaricato la pagina è apparso l’alert.

Il tanto agognato alert(1)

Disclosure

Dopo aver trovato questa stored XSS (anche se authenticated) ero in hype, ho chiesto su qualche gruppo come reportarlo e mi hanno consigliato wpscan, i CNA (CVE Numbering Authorities) che si occupano di gestire e verificare vulnerabilità reportate su WP core, plugin e temi. Dopo poche ore mi ha risposto Erwan, che ha confermato la vulnerabilità e mi ha preso a pizze (scherzosamente eh), infatti nel report avevo menzionato 3 pagine affette da XSS ma gli avevo dato il PoC di una sola (mi domando ancora perchè) e tanto per ingigantire il tutto avevo anche scritto che via XSS si potevano rubare i cookie di sessione di un admin, peccato che WordPress avesse tutti i cookie con la flag HTTPOnly, insomma una figuraccia. Ho risposto scusandomi per la faccenda dei cookie e gli ho inviato i due PoC mancanti, lui mi ha risposto convalidando tutto e assegnandomi la CVE-2021-24664. A questo punto ho continuato a cercare vuln su altri plugin (erroraccio, ci stava una SQLi e una XSS unauth che sono state reportate da altri dopo) e dopo pochi giorni visto che tutto taceva ho deciso di chiedergli a che punto stavano, e mi ha risposto dicendo che non stavano gestendo solo la mia vulnerabiltà, un’altra bella figura insomma. Dopo quasi tre mesi i dev hanno fixato passando tutto via htmlspecialchars, e l’undici novembra c’è stata public disclosure. Nonostante la vulnerabilità non meritasse una CVE è stato molto soddisfacente.

Link vari

Conclusioni

Da questo ho imparato

  • Dopo aver trovato una vulnerabilità si continua a cercarne sullo stesso plugin
  • Non si stressano troppo i triager
  • Bisogna valutare bene se vale la pena chiedere una CVE

Spero che questo primo articolo vi sia stato d’aiuto o che almeno vi sia piaciuto, le critiche sono le benvenute: @Davidet su telegram

Posted in web