En casos más desafortunados se puede usar la misma técnica para ejecutar código remotamente en las aplicaciones locales (como por ejemplo un script en php o ASP que ejecute comandos de sistema). Esa variante se conoce como RFI (Remote File Inclusion).
Prueba de Concepto:
http://www.udesarrollo.cl/cursos/carreras.php?sede=C&carrera=1200NC
En este caso vemos que existe un script llamado "carreras.php" donde la variable "carrera" se encarga de llamar la información requerida mediante un código. El problema se presenta porque carrera no está restringiendo sus solicitudes solamente a aquellas permitidas y en consecuencia se pueden mostrar en pantalla archivos con información importante del sistema:
"http://www.udesarrollo.cl/cursos/carreras.php?sede=C&carrera=../../../../../../../../etc/passwd" (Copiar el Link y pegar en el navegador y agregar al final "% y 00")
Al cargar la página se puede leer la siguiente información:
Simplemente hemos reemplazado el 1200NC por ../../../../../../../../etc/passwd con "% y 00".
Esto se puede probar con varios archivos del sistema:
"http://www.udesarrollo.cl/cursos/carreras.php?sede=C&carrera=../../../../../../../../proc/version" (Copiar el Link y pegar en el navegador y agregar al final "% y 00")
Al cargar la página se puede leer la siguiente información:
SOLUCIÓN
1.- Programar detalladamente y tratar de depurar los errores y posibles problemas de seguridad (como LFI, RFI, XSS, SQL Injection, etc). Es responsabilidad de los desarrolladores informarse acerca de las técnicas que utilizan los hackers para vulnerar sus sistemas. En este sitio web les ayudamos a comprender mejor estos métodos de tal manera que conozcan como evitarlos en un futuro.
3.- Utilizar reglas en mod_rewrite para Apache usando el archivo .htaccess para bloquear los intentos de intrusión. Ejemplo:
# de la URL. Con esta regla es imposible lanzar ataques de inyección (SQL, XSS,
#etc)RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(-\.')
[OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)
(<>%3C%3E)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^
(javacurlwget)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)
(libwww-perllibwwwperlsnoopycurlwgetwinhttppythonniktoscanclshttparchiverloaderemailharvestfetchextractgrabminersuckreaperleach)(.*) [NC,OR]
RewriteCond %{REQUEST_URI} ^(/,/;//'/`/%2C/%3C/%3E/%27/////) [NC,OR]
RewriteCond %{HTTP_REFERER} ^(.*)(%08%09%0A%0B%0C%0D%0E%0F%2C<>'%3C%3E%26%23%27%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)(%08%09%0A%0B%0C%0D%0E%0F%2C%3C%3E%27%26%23%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)('-<>,/\\\.a\.c\.t\.d\.p\.i\.e\.j)(.*) [NC,OR]
RewriteCond %{HTTP_COOKIE} ^(.*)(<>'%3C%3E%27)(.*) [NC]
4.- Incentivar el uso de ModSecurity para Apache, el cual es un método sumamente efectivo para detectar y prevenir malformaciones en las URL y otros tipos de ataques vía WEB.
PS: Ya avisamos hace unos días y no lo solucionaron. Por eso lo publiqué. Gracias a Viking0 por la info.
Otros sitios vulnerables al mismo problema, los cuales avisamos hace mucho tiempo y aún no lo solucionan (no hay mucho interés):
http://www.talcahuano.co.cl/pagina.php?pg=../../../../../../../../../../../etc/passwd...
Consultas y comentarios complementarios:
a) ¿Cual es la finalidad de enviar el caracter NULL al final del nombre del archivo (al final de la URL)? Además, aunque comparto que es recomendable habilitar safe_mode, creo que la solución correcta y definitiva en estos casos es que el script no sea vulnerable a exploits, la misión del desarrollador es filtrar el dato de entrada en base a sus valores posibles y por ejemplo, en este caso solo admitir caracreres alfabéticos y números.
Rta del autor: El hecho de incluir o no un símbolo NULL al final va a depender de como esté construida la la variable donde se le pasan parámetros. Simplemente se va intentando con cual calza hasta que muestra el archivo. Ocurre también muchas veces que se finaliza la frase con un símbolo de interrogación "?".Yo no soy desarrollador de PHP por lo tanto no soy el más indicado para darte la respuesta técnica precisa de porqué se hace la inclusión del símbolo, pero espero que alguien que sepa más PHP pueda aclararlo detalladamente para que podamos comprender de mejor manera este tipo de solicitudes.
Por otro lado comparto plenamente lo que mencionas respecto a la correcta validación de datos por parte del programador de la aplicación. Son ellos los que tienen la principal responsabilidad en este tipo de asuntos.
Transcribo literalmente lo siguiente desde el libro Hackers en Linux , página 560, capítulo de Servidores Web y contenido dinámico:
Verificar los caracteres que incluye el nombre del archivo
Los crackers pueden muy fácilmene enviar caacteres peligrosos en los datos de los formularios. Un ejemplo claro de carácter peligroso que puede provocar graves problemas es el carácter nulo (\0, representado en las URL como "%" y "00" ). Perl (al contrario que C) admite cadenas que incluyan el carácter nulo. Sin embargo, si una de estas cadenas se pasa en algún momento a alguna función del sistema (una función C) el carácter nulo se interpretará como un fin de cadena. Supongamos el siguiente programa:
$archivo = $ query-> param ('archivo') . '.html';open F, $archivo;
Sin embargo, si un cracker invoca el programa utilizando una cadena que incluya el carácter nulo archivo=%2Fetc%Fpasswd, el valor de $ archivo será /etc/passwd\0.html.
Cuando se le pase a la función open() el archivo /etc/passwd\0.html esta cadena será procesada por una función C que interpretará el carácter nulo como un fin de cadena. Al final, la cadena que verá la función C será: "/etc/passwd"
Y el cracker se hará con una copia del archivo /etc/passwd (lo que se muestra en este ejemplo de la UDD).
NOTA: Puede ver una descripción muy detallada de este problema en un excelente documento titulado "PERL CGI Problems", escrito por Rain Forrest Puppy.
Autor: Paulo Colomés F - Administrador seguridad-informatica.cl
6 comentarios:
Que gracia tiene la prueba de "concepto".La ejecucion se hará con los permisos del usuario que este usando Apache o el servidor WEB especifico o el usuario predeterminado en el engine de PHP.
Obtener una copia de /etc/passwd es completamente absurdo.Las password estan en /etc/shadow.Lo único que verás son los usuarios de la maquina.
y no creo que puedas leer ese archivo de esta manera, /etc/passwd tiene permisos de lectura para todo el mundo, pero /etc/shadow sólo para el grupo del root.
claro tienes un punto de acceso y eso ya es grave, pero el punto es que leer el fichero /etc/passwd no me dá acceso mayor al sistema como insinuas(implicitamente),de que te puede servir un fichero sin las password, sólo con los nombres de usuarios? no es muy "practico" y todo esto está limitado a lo que puede escribir/leer el usuario de apache o PHP.
claro no espero que muestres algo critico, eso sería irresponsable, pero mencionar que el fichero /etc/passwd no es útil debería ser mencionado, se dá a entender de que con eso la maquina esta lista para demolicion.
Les adjunto respuesta de Paulo a Rafael (Publicada en la web del autor):
------------------------
Lo que pasa Raphael es que
On Octubre 23rd, 2007 Administrador says:
Lo que pasa Raphael es que todo depende del punto de vista como lo mires. Si uno tiene un servidor donde la seguridad no es una prioridad, claro que ver esto no será ningún super descubrimiento, sin embargo si tu servidor requiere de un alto nivel de seguridad, el hecho de andar mostrando este tipo de información hace que los ataques sean más fáciles porque ya se están suministrando suficientes datos válidos (ej, cuentas de usuario existentes en el sistema). Claro, tu punto de vista es de lograr el acceso inmediato al archivo de contraseñas (/etc/shadow) lo cual claramente no se puede dado los permisos, pero los hackers se valen de un sin fin de técnicas para lograr infiltrar sistemas y muchas veces lo logran con el escalamiento de privilegios.
Además, no tan solo se puede leer el archivo /etc/passwd, si no que todos los cuales puedan ser accesados por el usuario bajo el cual corre Apache, como por ejemplo "httpd.conf" donde hay información respecto a los posibles virtualhosts de la máquina si es que el servidor corre más sitios web.
En definitiva el archivo /etc/passwd no es, como tu bien dices, algo crítico para lograr acceso a un sistema remoto pero sin embargo es bastante útil porque proporciona información que debiese ser privada facilitando en gran magnitud el trabajo de un atacante porque ya con tener algunos usuarios válidos tiene la mitad de la pega hecha.
Existen algunos exploits para servidores FTP y SSH, los cuales logran determinar si un usuario equis existe o no en la máquina utilizando técnicas de timing contra los procesos de sistema, y las listas de bugs (SecurityFocus, CERT, etc) clasifican ese tipo de vulnerabilidades como de riesgo medio. Esto de /etc/passwd cae en la misma calificación.
En todo caso este ejemplo no estaba orientado a "destruir" el servidor de la UDD, si no que a mostrar que utilizando esas técnicas es posible leer localmente archivos del servidor, vulnerabilidad mundialmente conocida como LFI (Local File Inclusion).
Este tipo de temas es bastante práctico ponerlo en discusión porque siempre es necesario tener el punto de vista de distintos tipos de personas y administradores de servicios.
Espero haber sido de ayuda
Paulo Colomés F
Administrador seguridad-informatica.cl
Mas comentarios de de Raphael:
----
On Octubre 25th, 2007 Raphael (no verificado) says:
....
vuelvo a repetir, estas reuniendo informacion solamente(lo cual tambien es importante... ) al obtener el fichero => passwd , pero no es algo critico, en tu post planteas que es algo critico, eso estoy criticando; por supuesto es impresentable que puedas leer ese archivo, pero no tiene riesgo inmedito para la maquina. Y estas insinuando;implicitamente que las password cifradas estan ahi... eso es incorrecto e impreciso, no digo que no tengas claro eso, pero en el post original eso no queda claro y cualquiera que lo lea pensara cosas erradas.
y por supuesto que puedes leer otros ficheros, pero para los que tengas permisos de lectura para el usuario que este usando el webserver o el engine PHP , eso lo deje claro y queda claro tambien en tu post original, bueno en realidad no, no mencionas que los permisos o nivel de acceso inicial son heredados de este usuario y grupo.
Y con todo respeto no me has sido de ayuda, no te he preguntado nada, no tengo dudas al respecto y es raro ver un post que he realizado en otro lugar aparecer aca como si lo hubiese hecho YO en esta web. Por lo menos podrias mencionar desde donde proviene el comentario y no poner un asunto al mensaje señalando que te estoy haciendo una "consulta". Y llegue a el por google alert.
Saludos
Raphael
Parece que se armo un debate sobre el tema...
Me parece que es muy bueno y que ayuda a otros lectores, adjunto nuevos comentarios.
Grupo Cryptex
--------------
On Octubre 25th, 2007 Administrador says:
Estimado amigo,
"me voy a tomar el tiempo para responderte.
Debieses informarte más acerca del "cross posting", el cual es un método muy utilizado en los blogs donde tú dejas un mensaje en un sitio web e inmediatamente aparece reflejado en otro. El artículo que tú respondiste en ese sitio web fue "crossposteado" desde acá, por lo tanto si dejas tu mensje allá aparecerá replicado en este tópico que es el sitio original. Esto se hace en forma AUTOMATICA. Puedes leer http://en.wikipedia.org/wiki/Crossposting para mayor información.
"vuelvo a repetir, estas reuniendo informacion solamente(lo cual tambien es importante... ) al obtener el fichero => passwd , pero no es algo critico, en tu post planteas que es algo critico, eso estoy criticando; "
¿Donde dije la palabra crítico? Si va a leer entre líneas, no tergiverse el mensaje.
Como dije. Informate sobre el crossposting, ya que por lo visto no estás enterado de que lo que dejas en un sitio web puede aparecer replicado en cientos más (ups!).
Saludos.
Paulo Colomés F
Administrador seguridad-informatica.cl
Sigues mal
On Octubre 25th, 2007 Raphael (no verificado) says:
Me parece que agregar un Subject ficticio en el caso que estes haciendo crossposting es peligroso , cambias el sentido del comentario. Generalmente queda algun link hacia el post y sitio original, pero si tu dices que es crossposting no pondre en duda tu palabra, te creo. No requiero que me expliques conceptos como crossposting, pero te agradezco el tiempo que te tomaste, pero no era necesario en lo mas minimo.
La palabra critica no la mencionas exactamente es sencible, lo que dije claramente es que estas insinuando que las password estan en passwd.
Sigues mal; el ejemplo es pesimo desde cualquier punto de vista, no explicas el real contexto del problema y parece mas grave de lo que es, no estoy viendo nada que no este escrito en tu post original. Como dije es impresentable que puedas leer cualquier archivo de la maquina sin autorizacion, pero explica el problema completo y no omitas involuntariamente informacion. No intento desmerecerte, pero debes ser mas preciso.
Todo aquel que nunca alla hecho esto, todo aquel que no conozca Unix, pensara que con esto tienes las password y los usuarios de la maquina, a eso apunto con mi comentario original, a eso me he referido en cualquier momento, eso estoy criticando y al hecho de que no comentas el completo contexto del problema, por ejemplo que apartir de ahi puedes escalar privelegios en la maquina, en tu articulo eso no queda claro ni se menciona.Esto ultimo lo dejas claro respondiendo en este sitio, pero en tu ejemplo eso no es asi.
Lo que estoy diciendo que es super claro y evidente, solo trato de hacer una critica constructiva sino otro seria el tomo de mis respuestas. Sino lo ves asi eso es problema tuyo, generalmente evito este tipo de discusiones improductivas. Y no soy visistante de este sitio por lo que no me interesa seguir con esto mayormente, solo hacer la critica que ya he hecho y al parecer fue mal recibida.
No quiero armar una polemica, pero creo que estamos teniendo un sana discusion, o no lo crees asi?
saludos
Raphael
Por supuesto, nunca he
On Octubre 25th, 2007 Administrador says:
Por supuesto, nunca he dejado de pensar así ;)
Paulo Colomés F
Administrador seguridad-informatica.cl
Publicar un comentario