...potevo anche intitolare "non sempre se lo conosci lo eviti"...
Stavo guardando gli ultimi problemi che hanno riguardato Joomla 3.x e mi sono soffermato sulla vulnerabilità trovata in /plugins/system/highlight/highlight.php
Mi fa molto specie la tempistica di reazione per la risoluzione del problema:
[-] Disclosure Timeline:
[31/10/2012] - Vendor notified
[08/11/2012] - Vendor asked for a proof of concept
[08/11/2012] - Proof of concept provided to the vendor
[04/02/2013] - Vendor update released
[27/02/2013] - Public disclosure
.. 4 mesi... vabbè questa è un po' polemica.... e io non voglio essere polemico,... di più
... quello che non riesco a digerire sono le prime due righe.
Io ricevo una mail dove vengo avvisato (gentilmente e correttamente) di una vulnerabilità della mia app...
Non so cosa abbia inviato, mi immagino come minimo due righe esplicative con indicazione dello script incriminato... solo che 8 giorni dopo gli torna un'altra mail che ufficialmente dice: "Vendor asked for a proof of concept" , tra le righe si legge "... non ho capito e non so riprodurla".
Credo in giornata è stato inviato il poc di exploit... tre mesi dopo arriva la patch.
La public disclosure è questa:
http://www.exploit-db.com/exploits/24551/Credo che l'impatto di una vulnerabilità non debba essere giudicato solo in base al "danno" procurabile sfruttandola ma anche in base alla sua riproducibilità da parte di uno svariato pubblico di pseudo-hackers.
Per meglio dire, ci sono vulnerabilità che pur essendo tali e magari con un impatto altissimo sono in realtà riproducibili da un ridottissimo numero di "esperti di sicurezza", magari perchè vengono usati vettori non esclusivi dell'applicazioni (complicità con linguaggi o sw server) ... quelle esistono tutt'oggi ma trovarvi il sito iniettato ha la stessa probabilità del 13 al totocalcio.
Questa è tutta un altra cosa.... e non solo era nota, aveva anche vinto un premio!
nel 2009, Esser, pubblica una serie di poc intitolandoli POC2009-ShockingNewsInPHPExploitation , trovate il pdf in rete.
Chiarissimo, inequivocabile, comprensibile anche per un pischelleto.
Si evince che con la deserializzazione si incorre facilmente in problemi non da poco, sia perchè causano crash del server sia perchè è un ottimo vettore per "infilarsi" in un oggetto, superando incapsulazioni e casting.
..Ma interesse di Esser non era certo bucarti il sito in php... forse era attratto di più dal primo problema.. su cui è andato a fare una bellissima disclosure vincendo il "Month of Php Security" del 2010.
Quì avevo fatto un articolo:
http://www.spazioalchimia.it/laboratorio/38-ps-2010-month-of-php-securityA noi invece basta fermarci al problema nei nostri script quando usiamo unserialize()
Non è difficile da trovare, anche un bimbo riesce con un grep a trovare tutte le volte che viene usata nei files e se tanto mi da tanto, spesso, è usata male.
Il problema causato in Joomla è stato proprio un Object injection manipolando una stringa serializzata, ma non è l'unico modo.
Chi ha scoperto questa vulnerabilita, in Joomla <3.0.3 e <2.5.11, ha anche pubblicato sul portale OWASP un articolo con suoi poc
https://www.owasp.org/index.php/PHP_Object_Injection
