martes, 28 de febrero de 2012

[Hack] Los peligros del phpinfo y como tirar un servidor

¿Cuantos hemos creado un fichero phpinfo? Y quizás es una de las cosas que primero se hacen al terminar de instalar php.

Para los que no saben, "phpinfo" es una pagina de información con datos de configuración de un servidor. Por lo general, cuando se está configurando un servidor, una forma de saber si funciona "php" es creando este archivo. Sencillamente, no es mas que generar un archivo con el contenido
<?php phpinfo(); ?>
y guardarlo como info.php (puede ser cualquier nombre con extensión *.php). De esta forma, basta con entrar a http://(tu pagina o ip)/phpinfo.php Y así ver la información, variables y configuración actual del servidor.

Y ¿Porque esto es peligroso?
Ya sea por olvido, para un posterior uso, o creyendo que nadie se va a dar cuenta de la existencia de este archivo (al no estar linkeado en la pagina). Los administradores, simplemente lo dejan, le cambian el nombre y listo. Tal vez un usuario común jamas se entere de la existencia del mismo, pero puede que un atacante lo descubra y utilice la información para posteriores ataques.
Cuando se va a iniciar un ataque, el primer paso es el Footprinting (Así se denomina a las diferentes técnicas para recabar información) tratando de obtener IPs, dns, información personal, puertos, servicios corriendo, versiones de programas, etc.

El phpinfo le otorga a un extraño por ejemplo:
-Saber algunos programas que están corriendo, mediante la variable PATH.
-Ver la versión del sistema operativo, sin la necesidad de hacer fingerpriting o utilizar un programa (que además deja huellas).
-Saber las versiones de los programas y módulos de apache. A partir de ello ver si existe algún bug, para después explotarlo.
-Ver permisos de algunos archivos.
-Ver la directiva safe_mode.
-En caso de ser vulnerable a LFI (Local File Inclusion donde se puede visualizar archivos del servidor o inyecta código en un fichero para luego ejecutarlo) podría ayudar a la explotación, debido a que la ejecución de un script se almacena de forma temporal. Al archivo con el script mediante un método gets o post, se visualizaría el nombre del archivo temporal generado en el phpinfo y ejecutar el fichero con el LFI.
-Encontrar una vulnerabilidad RFI (Remote File Inclusion donde se puede ejecutar una shell remota y entrar directamente al servidor) si allow_url_fopen está habilitado.
-Explotar un xss, mediante la variable de vector '?a[]=' agregandola a la url.
Entre otras cosas...

Analizando la salida del phpinfo.
Este es un ejemplo real de un phpinfo en un servidor.


-Cuando entramos a la pagina del phpinfo, nos encontramos con algo similar a esto. Fíjense que al comienzo ya nos dice la versión de php. De esta forma se puede saber que vulnerabilidades pueden llegar a explotarse. Y abajo el Sistema en que corre.


-En la parte de "apache2handler", tenemos la versión de apache. Al igual que antes con esto podemos saber que vulnerabilidades se puede explotar. En el apartado "Loaded Modules" los módulos que se están ejecutando. Esto es importante porque Si existe un bug en esa versión que lo genere un modulo este debe estar cargado.


-Esta es la parte que andaba buscando. Se puede ver que cabeceras del protocolo http se utilizan. La parte que me interesa es "HTTP_ACCEPT_ENCODING", fíjense que acepta "gzip, deflate", quiere decir que permite comprimir la respuesta antes de enviarla.

Verán, cuando nuestro explorador (IExplorer, Mozilla, Opera, Chrome etc..) envían una consulta http a un servidor al abrir una pagina, internamente se envía algo similar a esto (puede variar):
 GET /index.html HTTP/1.1
Host: www.pagina.com
User-Agent: nombre-cliente
Y el servidor internamente devuelve algo asi:
HTTP/1.1 200 OK
Date: Fri, 2 Mar 2012 18:39:05 GMT
Content-Type: text/html
Content-Length: 1221

<Cuerpo de la pagina>
...
Como el protocolo http utiliza múltiples cabeceras, uno puede enviar una cabecera modificada
para obtener una respuesta diferente. Un caso particular es el de los servidores de descarga, que utilizan "range", rango de bytes que se necesita para continuar la descarga.
Aprovechando esto, si enviamos múltiples consultas con diferentes rangos y a todas ellas, le decimos que los comprima con gzip, el servidor intentará atender todas estas consultas y finalmente colapsará.
-----------------------------
Para el exploit utilice lenguaje C++ y es bastante sencillo. En primer lugar se pide la url de la pagina, a partir de ella se obtiene la ip. Para cada consulta se crea un "hilo" y utilizando "socket" se envía la cabecera modificada.





Así que ya saben, acuerdense de deshabilitar el phpinfo. Actualizar los programas.
Aclaración: Esto no es un tutorial. Gonzac Studios no se hace responsable por el mal uso de este material.

jueves, 16 de febrero de 2012

[Hack] La vulnerabilidad que facebook no quiere corregir.

ACTUALIZACIÓN: (02/11/12) Si se fijan en los nuevos enlaces que envía facebook. Han modificado la estructura de los parámetros. Al parecer ya no funciona de la misma forma. 
------------

Esta entrada la iba a publicar mucho antes, pero en facebook necesitaban revisar antes el contenido, para no iniciar acciones legales. Así que hoy lo libero para todos.

En los meses de vacaciones, mientras descansaba y leía el correo. Se me dio por cambiar unos parámetros de la url en facebook (de esa forma acceder mas rápido al contenido, y no tener que buscarlo), y vaya sorpresa que me di cuando apareció un cartel que decía "Bienvenido/a de vuelta ******* ******** (Nombre del usuario)", Y al hacer click en aceptar entraba directamente al facebook sin requerir contraseña. No podía creer que existiera tal error, o acaso ¿era una simple casualidad?. En ese momento no me percaté de tomarle una captura de pantalla, cerré el facebook y empecé aprobar cambiando los id de usuarios o con diferentes enlaces, a ver si volvía a ocurrir, y nada.
Comencé a buscar en la red a ver si había un caso registrado, una imagen o algo que hablase del mensaje de bienvenida y no hallé nada.
Hasta que analizando bien los parámetros pude volver a repetirlo, con otra cuenta.
-----------

Verán, cuando uno inicia sesión en alguna pagina la forma de permitir que los usuarios puedan navegar libremente por el sitio y este lo diferencie de otro usuarios. Se crean sesiones propiamente dicho, para las que se utiliza una cookies o la url con un identificación de usuario que puede ser fijo o aleatorio, variable dentro de la pagina o temporal.
Es decir, que un usuario en ese momento tiene un numero id lo suficientemente largo, lo que lo hace imposible de adivinar, y varía de un explorador a otro. Pero que no es inmune a técnicas de sidejacking (La sesión solo se puede usar mientras la "víctima" esté utilizando la pagina), hijacking (Secuestro de sesión, a través de "man in the middle" donde un atacante interfiere con la sesión).

¿Como funciona la vulnerabilidad?
Facebook cada cierto tiempo al cerrar y volver a conectar genera un nuevo identificador, pero si no iniciaste nuevamente sesión, cada notificación que te llega al correo utiliza el ultimo identificador de sesión y peor aun, como muchas aplicaciones moviles no cierran sesión para poder avisarte de un nuevo mensaje, este identificador permanece sin modificación.
Pero intenten abrir un comentario que llega al correo, desde otro explorador nos pide la contraseña. Lo mismo ocurriría desde otro PC.
Lo que no muchos saben es que facebook tiene una pagina para autentificar los identificadores, "autologin.php" que cuando coinciden los datos nos da la bienvenida nuevamente y nos pide hacer click en confirmar (solo la primera vez), así las demás veces nos redirigirá automaticamente a la publicación.
Explotando el autologin.
Si nos fijamos en las distintas publicaciones, dependiendo del tipo que sea utilizan el mismo formato y solo cambia el id de la publicación. La diferencia con estas url y las que nos envía facebook al mail es mínima. Ejemplo de una mensaje en el muro de otro usuario:
http://www.facebook.com/permalink.php?story_fbid=123456789012345&id=000000000000001
donde "story_fbid" es el identificador de la publicación y "id" mi identificador. Entonces lo que llegaria al mail del otro usuario sería:
http://www.facebook.com/n/?permalink.php&story_fbid=123456789012345&id=000000000000001&mid=2G5f0e365f3eaf3d73G5e92G294b1&bcode=mNXa4XoZ&n_m=otro_usuario%40hotmail.com

Fíjense que no hay mucha diferencia, "mid" y "bcode" son los parámetros que se asignan para identificar la sesión. Utilizando esa url y a menos que estés conectado a esa cuenta, va a pedir contraseña.
Para que funcione el autologin se necesita engañar al servidor enviando dos url. Una con los parámetros "mid" y "bcode" falsos y otra con los últimos utilizados.

1-Buscamos los datos de la publicacion:


2-Armamos la primera url con los datos obtenidos, mid es una secuencia de 29 0 30 dígitos inventada y bcode una secuencia de 8 digitos también inventada.
http://www.facebook.com/n/?permalink.php&story_fbid=115819891876976&id=100003*********&mid=2G5f0e365f3eaf3d73G5e92G294b1&bcode=mNXa4XoZ&n_m=pepe_usuario%40hotmail.com
Al querer entrar nos va a pedir la contraseña.


3-Conseguir la url o los parametros mid y bcode para agregarlos a alguna publicación. Tienen que ser los utilizados mas recientemente.

4-En la ventana anterior, donde nos pidió la contraseña. Borrar la url y colocar la nueva url. El autologin va a comprobar nuevamente los parámetros y mostrará la siguiente ventana.


5-Al hacer click en continuar nos enviará directamente a la publicación, pero logueado con la cuenta del usuario. ;)

-----------------
Según facebook "They require a malicious person to be in control of a user's email inbox in order to gain access to their Facebook account." pero es solo una de las formas, veamos 4 casos que me han funcionado:

1-Ataque pos explotacion: Si tenemos acceso a su correo, o tenemos la oportunidad de acceder solo nos enviamos el correo de la ultima notificacion a nuestra cuenta.

2-Ingenieria social:


3-A través del autocompletar o historial del explorador.




4-A través de una búsqueda web especialmente diseñada, para entrar a cuentas al azar.
-----------------
Si ya tenias que lidiar con la intercepción de contraseñas, ahora esto. Obviamente no lo van a corregir porque se requiere también de acciones externas. Pero acaso ¿no es el mismo problema que al olvidarte la contraseña sea mandada al mail?