Parche para WordPress 2.0, 2.0.1 y 2.0.2 RC1 – Full path disclosure-, por daboblog

Daboblog pone a disposición de todos los usuarios los 17 archivos parcheados susceptibles de ser ejecutados y que permiten adivinar el path de nuestro WordPress y que evitan lo que los usuarios han determinado como un problema de seguridad, aunque el desarrollador echa la culpa a la configuración del server.

Puedes descargarte los archivos desde aquí

0 0 votos
Article Rating
Subscribe
Notify of
7 Comments
Oldest
Newest Most Voted
Opiniones Inline
Ver todos los comentarios
Anónimo
Anónimo
18 years ago

Repito una vez mas, no culpen a WordPress de la configuraciòn del servidor.

Ya en un post que hablo del tema, recomende para aquellos paranoicas un excelente firewall para proteger los servidores.

Anónimo
Anónimo
18 years ago

Hola Gustavo, tengo que “pastearme” aquí algo de lo que he puesto en el Daboblog, he ordenado algo el texto ¿Tu piensas que todo el mundo que usa wordpress tiene acceso a instalarse un firewall en su plan de alojamiento u otro soft para paliar algo que si lo he hecho yo a ellos les cuesta hacerlo 10 m?

He visto alguna solución como esta por ahí;

< directory /ruta/a/wordpress/ >
Options -Indexes
ErrorDocument 401 “error
ErrorDocument 403 “error
< /directory>

No lo solucionas en la mayoria de los casos y así está habiendo los problemas que veo, porque si si haces ese Indexes en el .htaccess dejas de ver todo el host, haz la prueba, no estoy de acuerdo con WordPress para nada y no es por crear polémica, lo de tener registers global en off creo que cualquier admin que sepa medianamente lo que hacer lo tendrá así, tampoco lo solucionas poniendo dentro de la carpeta en cuestión un “index.html” como he visto por ahí, según eso con el index.php valdría.

—————————

A ver, me explico, si tu vas por ejemplo a

http://www.daboblog.com/parche_wp/

(Donde tengo alojados los parches)

ahí no hay ningún index.hml ni nada, está bien configurado el server y como se puede ver no lista el directorio

Esto es lo que hay dentro. los parches como decía;

[root@libre3 /xxx/xxx/parche_wp]$ ls
leer_antes.txt wordpress_full_path_disclosure.tar.gz wordpress_parche_full_disclosure.zip

————————-

Globals en “off”

[root@libre3 ~]$ grep -i globals off /etc/php.ini
/etc/php.ini:; – register_globals = Off [Security, Performance]
/etc/php.ini:; Note that register_globals is going to be depracated (i.e., turned off by
/etc/php.ini:; Read http://php.net/manual/en/security.registerglobals.php for further
/etc/php.ini:; register_globals to be on; Using form variables as globals can easily lead
/etc/php.ini:register_globals = Off
/etc/php.ini:; to initialize a session variable in the global scope, albeit register_globals

————————-

Como se puede ver, no lista el directorio, es donde están los parches y en cambio esos archivos provocan un fallo que no tengo tiempo ( y si sueño XD) a explicar largamente.

el XSS creo que todo el mundo tiene claro que al ser solo ejecutado como admin pues…no se que es peor, que ejecuten el código o que se hagan admin XD, pero esto del listado de rutas es un error y grave de WordPress porque no lo solucionan porque no les sale de los huevos, así de claro y a ver, tu tienes Registers Global off, el Apache bien configurado etc etc y…te dejan con el culo al aire porque mucha gente no sabe de todas estas movidas o no tiene acceso a la configuración de su servidor como he dicho antes.

Y para acabar el mejor firewall para mi es iptables y si quieres ir un poco más allá puedes instalar algo como Mod Security aplicación Open Source que te puede evitar muchos problemas.

¿Que a nivel de server se pueden hacer otras cosas en lugar de parchear los 17 archivos? Pues si pero…no cambio la configuración de mi servidor por una sola aplicación y la “cabezonería” de unos cuantos ni loco, esto es una aberración a nivel de seguridad, mira,a mi me da igual lo que digan unos y otros, si hoy lo hacen bien lo diré, si mañana no pues también, al fin y al cabo yo hablo del tema pero doy una solución que funciona e intento solo aclarar los muchos errores que se están viendo a causa de que mucha gente ha puesto el codigo (como digo en Blog) con comillas dobles.

Con toda cordialidad Gustavo te diré que me preocupa más la seguridad de los usuarios que “el buen nombre de WordPress”. Que se pongan las pilas, le cerraron de mala manera en su foro a un user el topico por preguntarlo y se sobraron según pienso yo y mucha gente, el preguntaba algo razonable. De todos modos yo uso ese Soft y me gusta tanto o más como a ti, por eso he estado el tiempo necesario para ayudar al resto.

Un abrazo y para comprender mejor la situación, está todo en mi blog, me temo que no podré estar o contestar en tantos sitios a la vez, gracias a faq-mac por la cobertura -:)

Anónimo
Anónimo
18 years ago

Extraido de el php.ini:

; Print out errors (as a part of the output). For production web sites,
; you’re strongly encouraged to turn this feature off, and use error logging
; instead (see below). Keeping display_errors enabled on a production web site
; may reveal security information to end users, such as file paths on your Web
; server, your database schema or other information.
display_errors = On

Si el servicio de hosting donde esta hospedada mi pagina no me diera esas consideraciones minimas de seguridad, mudaria a la brevedad.

Anónimo
Anónimo
18 years ago

hola Gustavo, eso no me dice nada nuevo, se nota que no estás acostumbrado a trabajar con un servidor, mira, en el caso que nos ocupa, esas consideraciones de seguridad pasan facilmente por WordPress pero no se porque le das tantas vueltas, parcheas los archivos y punto, problema resuelto.

Tu crees que alguien va a instalar algo por un tema puntual de wp? no son tan importantes y un servidor no se puede llevar así, el problema en este caso está en un comportamiento irregular que crea la aplicación pero repito que no lo quieran hacer porque no les sale de las narices no quiere decir que no se parchee en 5 min -:)

Saludos !

Anónimo
Anónimo
18 years ago

Muchas gracias dabo,parcheado y funcionando correctamente.no hagas caso y sigue independiente y a Gustavo,antes wp no era asi,no tardarian nada en hacerlo pero no quieren,dabo se queja pero da una informacion que a mi me funciona y soy una de las que por culpa de que alguien pego mal el php o las comillas no le funcionaba el parche.gracias y un saludo

Anónimo
Anónimo
18 years ago

Dabo el patch perfect,funcionando a tope y suscribo lo que dices arriba,muchos no tenemos posibilidad de tocar nada de nuestra configuracion,gracias por pensar en nosotros :):).

Anónimo
Anónimo
18 years ago

Hola, Había quedado también en escribiros algo sobre como solucionar este Bug que se genera al ejecutar uno de los 17 archivos vía web desde el servidor, concrétamente, la clave está en la configuración del PHP.

Comentar primeramente y me repito que mucha gente no tiene acceso a la configuración de su servidor Apache o del PHP y en mi opinión es muy fácil para la gente del WordPress solucionarlo a nivel de código porque son 2 líneas únicamente.

Dicho esto, vamos a hablar del Bug y de como hacer que no se haga presente. Mi colega Rául Naveiras me dice que sería bueno explicarlo, está aquí conmigo y os pone unas líneas. “En un sistema en producción en el que estén alojadas ya unas webs funcionando correctamente, lo normal es que la variable en el “php.ini” debería estar de este modo “display_errors” con el valor Off”.

Esto que comentaba Raúl, suele ser lo recomendable pero no vayáis a pensar que todos los administradores lo tienen así configurado, se puede también paliarlo a nivel de Apache para la configuración de ese host de este modo; php_admin_value display_errors Off.

Para que el administrador pueda ver que error da alguna aplicación en concreto ya que no se visualizan vía web en pantalla, se puede habilitar un registro interno de log para consultarlo cuando se necesite.

Básicamente es eso, el “full path disclosure” o adivinación de la ruta del WordPress , no es algo que se pueda catalogar como de “muy grave” pero sabiendo la ruta “maestra” de donde se alojan las webs, en el caso de un ataque o de ejecución de un exploit contra la web/servidor, puede ser más efectivo porqué irá “directo”.

Saludos

7
0
Me encantaría saber tu opinión, por favor, deja un comentariox
()
x