Modificando WordPress y aportando mi granito de arena
Pues después de que tenga varios problemas que ya arregle con los del hosting que tengo y de tomar una decisión acerca de la situación (si al final voy a escoger dreamhost, que espero de aquí a un mes ya estemos hospedados en el por que depende mas del cash que de mi) y pues habiendo acabado casi todo mis pendientes desde mi tarea, trabajos, proyectos me quedo un poco de tiempo libre para pues usarlo en algo productivo.
Lo primero que se me ocurrió es checar BuqTraq un mailing-list de SecurityFocus sobre vulnerabilidades o defectos de software, que tengo en mi cuenta de gmail con un filtro y una etiqueta para evitar que estos mails (por que suelen ser bastantes) se cuelen con otros de mayor importancia, leyendo me encuentro tres vulnerabilidades 0-Day (sin parche publico por parte del fabricante que sea “estable o seguro”) en wordpress, de las tres, una la califico de riesgo mediano y las otras dos de riesgo muy bajo, es mas no son vulnerabilidades yo les pondría defectos, son errores de programación que revelan información “valiosa” (si con todo y comillas lo valiosa).
Bueno no hay de que alarmarse, como dije en mis post anteriores yo modifico algunas cositas de mi wordpress para que quede a mi gusto, las modificaciones no son tantas pero si me sirven para ver como es que el equipo de desarrollo de wordpress le gusta moverse, así que después de ver y leer los advisories correspondientes, lo primero que hice fue entrar al trac de wordpress, que es un sito que ya he visitado anteriormente y que suelo frecuentar para revisar que cambios se vienen en la próxima versión, la posible fecha de salida de la próxima versión estable y si hay por ahí algún fix o aditamento que seria bueno ya contar con el, moviendo por ahí encontré las “posibles” soluciones (recuerden que todas las soluciones que están en el trac no siempre son las que van a salir y algunas veces son soluciones temporales que les faltan revisiones, así que hay que tener cuidado con que solución optas ya que suele haber mas de una para un problema) a dos de los problemas presentados en los advisories que leí en SecurityFocus, así que me dije manos a la obra empezemos a modificar…
El Primero que me puse en mente de solucionar fue la vulnerabilidad de riesgo mediano la cual es un XSRF/XSS, osea un XSS (o Cross Site Scripting) combinado con un XSRF (o Cross Site Request Forgery), que para los que no lo conozcan en palabras humanas son vulnerabilidades que permiten la inyección de código desde el lado del cliente(XSS) que se tiene que combinar con otra vulnerabilidad que también en palabras humanas le podríamos decir como las que permiten que un usuario autenticado de algún sistema (como el dashboard de wordpress) al dar click(u otra acción) realizen una acción sin que estos se den cuenta de que lo han hecho(XSRF), se que esta ultima es difícil de entender pero lo importante es saber que impacto puede tener sobre un sistema un error así, aunque como dije yo lo califico de riesgo mediano ya que se necesita atraer a la victima hacia la trampa, algo no tan difícil pero si laborioso, el impacto consiste en que un atacante puede hacer una pagina o link especialmente hecho para que el usuario-victima (previamente autentificado) inyecte codigo que le pueda servir al atacante para robar las credenciales de autenticacion del usuario-victima (digase cookies) para luego tratar de reusar esas credenciales y loguearse al sistema como si fuera la usuario-victima, todo un trabalenguas pero estoy seguro que entenderan las posibilidades de alcanze que puede tener.
Pero bueno despues de tanta palabreria vamos al asunto, entrado al trac nos encontramos con el ticket 3879 donde se habla sobre esta vulnerabilidad y se rectifica sobre que esta vulnerabilidad corresponde al panel AYS y no a la funcion delete como se expuso en el advisory y al parecer se da una solucion que se piensa optar como la final, no es mucho trabajo apenas y son dos lineas que se le cambian/añaden al archivo “wp-includes/functions.php”, para los que no tengan idea de que añadir, simplemente lo que esta marcado en rojo es lo que estaba antes y lo marcado con verde es lo nuevo, las dos columnas antes corresponde la primera a la numeracion antes de aplicar el parche y la segunda la numeracion despues de aplicar el parche, realmente no creo que se pierdan, pero de todos modos si sienten que no tienen idea de que hacer, esperen mientras sale la version 2.1.2 de la linea estable (de aqui a dos semanas posiblemente) y seria bueno que opten por el momento (o por siempre) al terminar de hacer algo en el panel de wordpress salgan del sistema asi no estaran autenticados y no se podra caer tan facil en la vulnerabilidad.
Ahora la que viene no representa casi ningun tipo de riesgo mas que de soltar informacion “valiosa” (nuevamente repito con todo y comillas lo valiosa) ya que al poner en el buscador uno o mas espacios(si un ” “) o una o mas comas (”,”) se produce un error de Syntaxis de SQL, desgraciadamente fue anunciada yo creo que de manera erronea como SQL Injection y esto hace que mucha gente inexperta en el tema sienta panico, pero si trabajaras con ella sabrias que si añades algo mas a la busqueda que sea distinto de coma o espacio obtenemos una busqueda correcta con lo cual no hay error de Syntaxis SQL, algunos pensaran “oye pero si pones algo mas significa que se ejecuto tu cadena o tu sql injection bien”, pues bien como dije tienen que leer y trabajar un poco mas con ella, lo que pasa es que al sanitizar la coma o el espacio no queda nada y trata de completar dentro del SQL algo asi “… AND ($search) …” y como $search es NULL o nada por que se sanitizo, nos queda algo como “… AND () …”, asi que realmente no estas inyectando si no que se sanitizo tu inyeccion y se quedo en NULL provocando un error de syntaxis sql, asi como dije esta bug se sobre valoro ya que lo unico que te da es informacion “valiosa” como el prefijo de tabla usado (que puede ser usado para hacer una inyeccion sql), aunque no representa un riesgo como dije siempre hay que estar parcheados y a nadie le gustan que en su web salgan tan feos errores.
Bueno ahora iremos al grano hay dos tickets en el trac que hablan sobre esta vulnerabilidad una para el espacio y otra para la coma y para cada una hay un parche, mi recomendacion es tomar la de la coma por que es mas general, ya que alivia la de la coma y la del espacio y como dije antes parece ser es la que saldra al final, en la version estable.
Bueno la tercera es como la segunda pero tiene mas restricciones para funcionar ya que se requiere que register globals este ON (una directiva de php que ya se esta optando por no tener prendida debido a los riesgos que provoca) y lo parecido a la segunda es que tambien solo da informacion “valiosa” como el prefijo de la tabla y en algunos casos el directorio absoluto de la web (Full Path Disclousure), esta vulnerabilidad que puedes leer en este advisory, que para mi es un defecto y no una vulnerabilidad, la cual fue encontrada por Xy7 de Bug.Center.Team fue publicado hace mas de cercanos 2 meses y pues me extraño que nada se haya hablado o hecho, asi que me di el trabajo de investigar por mi parte y asi aportar mi granito de arena a wordpress, abri mi ticket (despues de leer los manuales sobre el manejo de SVN, creacion de parches, reporte, etc…, por que soy nuevo en esto) y mande una primera solucion temporal a el bug mencionado y agregando uno mas que encontre en otra variable pero que correspondia a la misma linea del bug, al poco rato vi que se podia expandir a mas variables asi que tuve que poner una nueva solucion mas general, cabe recordar que esta solucion no esta aun calificada como resuelta pero bueno segun mis pruebas locales y en este blog, funciona perfectamente y pues la verdad no se las recomiendo totalmente hasta que pase el filtro de resuelto pero de todos modos siempre es bueno tener una pequeña defensa al menos.
Para terminar nuestro trabajo y para los que se quieran sentir mas elite o aumentar su ego
, lo ultimo que hice fue modificar el archivo “wp-includes/version.php” que guarda (por si no sabias) el numero de version de WordPress asi que le hice un cambio de “2.1.1″ a “2.1.2-Alpha-GX”, osea version 2.1.2 Alpha edicion GX (g30rg3_x) XDDDD, se ve bien elite y aumenta mi ego XDDD, pero bueno es opcional, yo realmente sin mentirles los hice para recordarme que tengo una version modificada por su servidor y que aun esta en desarrollo y no es la estable.
Para terminar de finiquitar unas demostraciones en-vivo usando los blogs que me leo diario para demostrarles, cada vulnerabilidad tratada…
De la Primera es obvio que no puedo poner, pero de todos modos el advisory ofrecio bastantes pruebas de concepto…
De la segunda:
http://michoacano.com.mx/?s=+
http://www.masio.com.mx/es+en/?s=+
http://isopixel.net/?s=+
De la tercera (Version SQL Error):
http://michoacano.com.mx/?m[]=
http://isopixel.net/?m[]=
De la tercera (Version Full Path Disclousure):
http://isopixel.net/?cat[]=
http://dougal.gunters.org/?category_name[]=
Ahora si hasta la proxima…
Saludos pa todos los valientes que leyeron todo eso sin llegar antes al final 













Escrito por: Michoacano
1 de Marzo del 2007 a las 7:18 pm
Por que me andas juakeando :(, xd a parchar a parchar xD
Escrito por: g30rg3_x
2 de Marzo del 2007 a las 10:43 am
XDDDD, dale parcheate que sigues con esa vuln y yo creo que por consecuente tendras la del XSS/XSRF
Saludos
Escrito por: Masiosare
2 de Marzo del 2007 a las 12:42 pm
Ahh que cabron
Por lo menos quitale las ligas jaja.
De hecho no se si sean el mismo problema (no lei el post completo :P) pero recuerdo que por lo menos mi sitio tenia una vulnerabilidad similar cuando generabas un 404. Pero creo que ya no funciona…
Por cierto, si quieres un descuento con dreamhost avisame. =)
Escrito por: DarK-ZeRo
3 de Marzo del 2007 a las 10:25 pm
jajaja, bien g30rg3 por los bugs
te felicito ;). Vamos a ver si sigo con mi blog yo.
jajaja y no busco fama ¬¬
Nos vemos!
Salu2!