RFI (Remote File Inclusion) y LFI (Local File Inclusion) son de las vulnerabilidades más altas que nos podemos encontrar en un aplicativo, esto supone poder ejecutar en la aplicación código externo a la misma, ya sea habiendo conseguido subir un fichero malicioso a la misma (LFI) o ejecutando código malicioso en la aplicación alojado en otro servidor (RFI). A continuación no trataremos de enseñar a localizar este tipo de vulnerabilidades, sino de una vez encontradas poder explotarlas de la forma más eficiente posible.

Como hemos dicho anteriormente, no nos interesa saber como conseguimos ejecutar el código, si embebido en una foto, subiendo un archivo o remotamente, sino saber qué hacer después de haberlo conseguido para ello partiremos simplemente de un dominio www.owned.com en el que hemos conseguido subir un fichero con código malicioso (nos da lo mismo la extensión) por sencillez imaginaremos que la ruta del fichero malicioso es www.owned.com/imag/shell.php. El fichero shell.php puede contener una shell potente y compleja tipo C99, pero lo que nos interesa es tener claro el concepto por lo que nuestra “shell” contendrá simplemente: <? system($cmd); ?> rápidamente podemos ver que simplemente recibe un valor de entrada que recoge la variable cmd y es ejecutado en el sistema mediante la llamada system de PHP. Tenemos que tener en cuenta que para poder continuar crearemos un entorno “ideal”,en el que PHP no tiene deshabitado la realización de la llamada al sistema system. Dicho lo anterior podemos ejecutar comandos en el servidor llamando a nuestro archivo shell.php e indicando el valor de la variable cmd (comando a ejecutar).

Por ejemplo:

http://www.owned.com/imag/shell.php?cmd=ls

Nos podría mostrar en pantalla:

autor.jpg banner.jpg prueba.jpg shell.php

Los resultados se mostrarían de un forma muy incomodos, y para verlos bien tendríamos que ver el código HTML, una buena solución es realizar un pequeño script, en este caso en perl, para poder ver los resultados más cómodos desde nuestra consola, el script podría ser algo como:

Codigo en perl de nuestra mini-shell:

Tenemos que tener en cuenta que el archivo siempre estará en la misma ruta si no lo movemos, por lo que comandos como cd no tendrían mucho sentido en este caso.

Una vez aclarado esto podemos decir que tenemos cierto control sobre la maquina, en este caso tenemos las credenciales del usuario definido para el usuario PHP, si este fuera root cosa bastante improbable, el resto del post no tendría sentido, porque podríamos hacer lo que quisiéramos.

Pasemos a otras posibilidades dentro de la configuración del servidor (entendemos que al ser PHP lo idóneo sería un servidor Apache y un linux por supuesto ;)). Las posibilidades pueden variar, si es un servidor con hosting compartido, es muy raro (sería una cagada) que el usuario de PHP pudiera listar y recorrer toda la maquina, ya que se verían afectados no solo el aplicativo web vulnerable sino el resto de dominios. Para analizar si estamos en un chroot podríamos comprobarlo por ejemplo:

Visitando la web www.robtex.com/ y comprobar la ip del servidor “auditado”, allí podemos ver si hay más dominios en esa ip, si es así y no estamos en un chroot podríamos listar el resto de dominios existentes la carpeta destinada a ello en apache, normalmente /var/www/html/. Si por el contrario nos encontramos algo del tipo /var/www/vhost/ podemos deducir que estamos en un chroot.

• Si ejecutamos cat /etc/passwd y vemos cosas anormales, como si estuviera incompleto, cosas incoherentes, pocos usuarios, entonces podemos decir que estamos en un chroot.

• Si ejecutamos el comando d y vemos que solo aparece un número de usuario, o la información que muestra da signos de ser incompleta o poco previsible seguramente estemos bajo un chroot.

• En definitiva, tenemos que investigar y usar un poco la intuición, si ejecutamos uname -a y vemos el sistema que corre la maquina podemos intentar buscar archivos que sabemos que tienen que existir en la maquina, si por ejemplo estamos en un Debian podemos buscar el ´/etc/network/interfaces´, si no existe podríamos estar en un chroot, al igual que si hacemos un ´ls /bin/´ y vemos muy pocos comandos.

Llegados a este punto, si no estuvieramos en un chroot podemos intentar ver hasta que punto tenemos permisos para leer ciertos archivos críticos como claves de ssh, la configuración de ssh en ´/etc/ssh/sshd_config´, el archivo ´/etc/passwd´, y todo lo que se nos ocurra. También podemos ver que comandos podemos ejecutar sin ser root, aprovecharnos de comandos sensibles como ´wget´, ´netcat´ o ´curl´ para poder explotar al máximo la vulnerabilidad.

En caso de estar en un ´chroot´ también debemos ver que comandos tenemos habilitados para ejecutar, porque aunque no podamos salir de nuestra “jaula” tendremos habilitados una serie de comandos y quizás por algún despiste del admin tengamos habilitado algún comando sensible que nos pueda interesar para poder seguir “tirando de la cuerda”.

En cualquier caso la meta es conseguir credenciales de root por lo que debemos de ver la versión de sistema operativo y buscar en paginas como exploitdb.com alguna vulnerabilidad que este sin parchear y poder explotarla mediante algún exploit o cualquier otro método, si lo conseguimos perfecto, hemos owneado la maquina y ya sabéis que un gran poder conlleva una gran responsabilidad, así que sed buenos ;)

Bola Extra:

Normalmente un aplicativo basado en PHP va conectado a una BBDD normalmente MySQL, cuando se instala MySQL en la maquina al igual que pasa con apache, el sistema crea un usuario con unos privilegios y podemos intentar usar este usuario para recoger información del sistema o si mysql se ejecuta como root (bastante improbable) podemos leer directamente ficheros muy jugosos como /etc/shadow, puede que aun existiendo un chroot el usuario de MySQL este fuera del mismo, por alguna razón (aunque esto implique una vulnerabilidad evidente). Llegados a este punto y aprovechando nuestra vulnerabilidad inicial FI (File Inclusion) vamos a subir otro archivo en PHP que use las credenciales del usuario de MySQL para acceder a los recursos del sistema, para ello necesitamos el nombre de la BBDD, el usuario y la contraseña, por suerte para nosotros debido a la lógica de PHP en algún archivo con extensión php del aplicativo se encuentran estos datos, basta con navegar la web y ver sitios clave que se conectan a la BBDD como puede ser alta.php, feed.php, etc; ejecutando el comando cat, con nuestra shell, del contenido hasta dar con los que buscamos, una vez hecho un código como este nos valdría para poder mostrar por pantalla archivos del servidor:

MySQL:

Sobra decir que si tenemos las credenciales de la BBDD podemos hacer lo que queramos con ella ^_^, aunque ya que estamos no deberíamos contentarnos solo con la base de datos.

Nuestra nueva “shell” la hemos subido en: http://www.owned.com/imag/shellSQL.php e indicando el archivo a listar en la variable link si este existe nos lo mostrara por pantalla, el formato seria: http://www.owned.com/imag/shellSQL.php?file=%2fetc%2fnetwork%2finterfaces cabe indicar que la barra es sustituida por su código URL %2f. Podriamos ver algo como esto:

Contenido de un supuesto archivo /etc/network/interfaces:

Podeis obtener mas información de chrootaqui.

También teneis un cheat sheet de MySQL muy útil para estas tareas aquí.

Como veis entre este post y el anterior hay una gran distancia, tanto técnica como de tiempo, espero poder volver a escribir con la frecuencia que me gustaría y no dejar esto tan sumamente abandonado.

Bueno debido a mi nuevo oficio, tengo menos tiempo del que me gustaria para dedicarle al blog, pero últimamente lo que más ando haciendo es aprendiendo y dándome cuenta de lo poquito que sé, el post de hoy va a tratar de los proxys webs, este tipo de aplicaciones se usan mucho a la hora de hacer auditorias webs para ver que hay “por debajo”, con ellos podemos monitorizar todos los datos que se envían y que recibimos a la hora de realizar una navegación web, hay varios proxys; esta Webscarab que es uno de los más complejos en cuanto a opciones y usabilidad y de los más potentes; tenemos también Paros, que es un proyecto ya abandonado pero muy intuitivo y fácil de usar; y el que hasta ahora es mi favorito: ZAP (Zed Attack Proxy) que es un fork de Paros que sigue actualizándose, este será el que usaré, para este post. ZAP esta corriendo bajo Fedora14 y con un Firefox con el Addons FoxyProxy para poder gestionar rápidamente los proxys.

Este es el aspecto que presenta este proxy, primero tenemos que configurar la dirección del mismo que será a la que apunte el navegador para conectarse a internet. Para ellos simplemente Tools -> Options -> Local Proxy (yo lo tengo puesto por defecto 127.0.0.1:8080).

Después tendríamos que configurar el navegador (en este caso Firefox y su plugin FoxyProxy), para ello añadimos la dirección del proxy a la lista de nuestro complemento, una vez configurado y guardado podemos empezar a navegar por cualquier web. Recordad que tenemos que seleccionar el perfil del nuevo proxy en el Firefox para poder ver lo que hacemos.

Vamos a comprobar que todo funciona, para ello vamos a realizar una navegación simple por Google por ejemplo y comprobar que nos enseña ZAP:

Como vemos en el ejemplo se ha realizado la búsqueda de la palabra “hola” en Google, esto se ha producido mediante un método GET, y estos son los datos que podemos ver que se han enviado en uno de los 11 envíos/recibos de datos:

En esa petición podemos ver como enviá el navegador los datos solicitados a Google y de que forma este predefine el envió de los mismos, como dijimos más arriba es mediante un método GET, eso significa que si copiamos la petición veríamos la búsqueda y si en el campo q= podemos “adiós” y lo enviamos por nuestro navegador podemos ver como Google busca el dato nuevo, es decir mediante un proxy web podemos modificar TODA la información que nuestro ordenador enviá al servidor web y muchas veces saltarnos las verificaciones que realiza el navegador del formato de nuestros datos mediante por ejemplo un JavaScript que se ejecuta en nuestros navegadores de forma local (cosa insegura por esta razón). Como podemos ver en la siguiente captura podemos ver y modificar todos los parámetros que vemos, como el nombre del navegador, el site de donde venimos, etc.

Como hemos comentado este envió se realiza mediante un método GET, otro método más “seguro o invisible” sería enviarlo mediante un método POST, una forma de localizarlos es cuando realizamos por ejemplo una búsqueda en un campo y en el navegador solo vemos algo del tipo http://www.dominio.com/busqueda.php podríamos deducir que se trata de un POST.

Aquí podemos ver otra característica de ZAP, mediante el botón Break podemos crear un punto de interrupción a partir del cual podemos controlar, modificar y analizar los datos que se envían desde el navegador hasta el servidor destino:

Dentro del rectángulo rojo encontramos tres botones, el primero en verde es el que crea el Break, el siguiente confirmaría el envío actual y daría paso a la siguiente interrupción y el botón Play cancelaría el Break y haría que la comunicación vuelva a ser fluida y sin espera ni interrupciones, entre envío y envío de datos.

Esta es la explicación básica de como funciona un proxy web y como se crearía un Break o Trap, estos programas tienen otras funcionalidades como escaneres de puertos, de vulnerabilidades, spiders que analizan el site listando todos los directorios, etc.

Hace relativamente poco entre en contacto a raíz de un paper publicado en hackxcrack con una potentísima aplicación llamada scapy. Scapy es una herramienta escrita en python que nos permite desde crear paquetes UDP o TCP, hasta realizar un montón de cosas más con la potencia implícita que nos da python, escaneos de puertos, ataques DDoS, como herramienta didactica, etc. Tengo preparado otro post más de scapy y me gustaria poder dedicarle el tiempo que se merece para poder hacer una serie de ellos y poder explicar y entender ciertas cosas. En este primer post vamos a aprender como se genera un paquete TCP y como se vería en Wireshark y si lo recibimos con ncat.

Como sabemos UDP es un protocolo de red en el nivel de transporte que permite el envío de datos sin haber establecido previamente una conexión. Por lo que en este primer post de introducción veremos la facilidad de crear y enviar un paquete.

Las herramientas que yo he usado fueron, un linux con scapy y un mac con ncat y wireshark.

Entramos en materia, lo primero es tener claro cuales son las ip’s origen y destino y el puerto por el que queremos conectarnos.

Ejecutamos Scapy y si hacemos ls(IP()) vemos lo siguiente:

Son todos los campos de un paquete en la capa IP, vienen definidos de la siguiente forma: nombreDato : tipoDato = ValorActual. Para nuestro ejemplo solo nos valdría dst (ip destino) y src (ip origen). Por lo que tecleamos: (en mi caso)

c_IP=IP(dst="47.69.69.22" , src="47.69.69.55")

Hemos creado un objeto llamado c_IP que contiene los valores por defecto de la capa IP excepto los moficicados (src y dst). Podemos listar la parte modificada de la capa con el comando c_IP.

Ahora vamos con la capa UDP, si la listamos ls(UDP()) vemos lo siguiente:

Al igual que en el resultado anterior, en este caso podemos ver los campos de un paquete en su capa UDP. Para nuestro caso solo nos valdría dport (puerto destino) y sport (puerto origen). Por lo que tecleamos: (en mi caso)

c_UDP=UDP(dport=5005 , sport=1024)

Hemos creado un objeto llamado c_UDP que contiene los valores por defecto de la capa UDP excepto los modificados (dport y sport). Podemos listar la parte modificada de la capa con el comando c_UDP.

Lo siguiente seria añadir un payload, es decir la información contenida en el paquete, en nuestro caso será un mensaje pero podría ser streaming de video, VoIP o cualquier otro formato que viaje en UDP. Tecleamos:

payload="Hola mundo -> UDP

Una vez rellenado el payload procedemos a ensamblar el paquete creado de la siguiente forma:

pqt=c_IP/c_UDP/payload 		#El paquete recibe el nombre "pqt"

Si lanzamos pqt podemos ver como quedaría nuestro paquete ensamblado:

Ahora solo tendríamos que enviarlo, esto se hace con el comando send(nombrePaquete) en nuestro caso: send(pqt)

Pero antes de enviarlo vamos a abrir nuestro wireshark para ver como se vería. Para poder localizarlo mejor podemos poner el filtro:

ip.src_host==47.69.69.55 || udp.port ==5005

Este filtro haría que solo se mostrara los paquetes que salen de la ip 47.69.69.55 (donde ejecutamos scapy) y que vayan destinados al puerto 5005 y mediante UDP.

Aquí tenéis la captura del wireshark y la información del paquete, este paquete es  es rechazado por el host destino porque tiene el puerto cerrado y no espera nada.

Sin embargo si ejecutamos el ncat de esta forma:

ncat -v -u -l -p 1024

-v : modo verbose activo
-u : modo UDP
-l : indicamos que lo ponemos en escucha
-p 1024 : especificamos puerto

Estaríamos diciendo con este comando que dejamos el puerto 1024 UDP a la escucha de cualquier conexión entrante y al indicar modo verbo que nos especifique todo, al enviar el paquete con scapy veríamos lo siguiente:

Y aquí os pongo la captura completa de lo hecho con scapy, como veréis, muy sencillo:

Y hasta aquí el post de hoy, espero poder volver a subir la frecuencia de publicación próximamente.

Hola a todos, la razón de este post, es más bien porque después de experimentar durante este fin de semana mil y un problemas para poder hacer jailbreak en mi iPad con el mensaje repetido hasta la saciedad de Failed :(, decidi buscar y encontre en un hilo de MacRumors donde explicaba como solucionar este problema, con esto no digo que en los sitios como iPhoneros o iPadizate no este bien explicado, sino que a mi no me funciono, asi que paso a explicaos rapidamente como lo hice:

Lo primero es tener instalado el último firmware en vuestro iPad 4.2.1, despues haced una copia de restauración de vuestros datos por si acaso haciendo una copia de seguridad con iTunes (yo no lo hice desde una restauración limpia, lo reconozco :D) y ahora ya podemos entrar en materia:

1. Desde la web de greenpois0n descargaos el ejecutable (en este caso mac).
2. Conectar el iPad al Mac
3. Abrir un Terminal<
4. Y ejecutad desde ahi el ejecutable tipo: open greenpois0n.app/Contents/MacOS/greenpois0n
5. Se os abrira otra ventana de terminal, no la cerreis
6. Seguid las instrucciones para poner vuestro iPad en modo DFU
7. Si pusisteis bien el iPad en DFU (cosa que yo no hice a la primera) ya deberiais tener el iPad desbloqueado
8. En caso de no tener el loader de Cydia instalado podeis descargaos Redsn0w 0.9.7b6 y instalar Cydia desde ahí

Con estos simples pasos lo tendríais hecho, como veis más que un post en un tips o miniguia para vuestro problemilla.

Cuando hablamos de seguridad de la información, una pieza muy importante para saber de lo que hablamos muchas veces es poder verlo, es decir comprobarlo; hay muchas pruebas que no podemos realizar, cuando hablamos por ejemplo de un súper servidor o de un software de firewall muy determinado es complicado poder investigar sobre ello o probar una determinada vulnerabilidad existente. Sin embargo hoy os voy a hablar sobre un software que virtualiza el sistema operativo de los switch y router de Cisco, se trata de GNS3, un software multiplataforma, que es muy útil, ya que se adapta perfectamente con Wireshark, Qemu e incluso si tenemos varias tarjetas de red podemos emular una red desde ellas y ver como se comportaría el modelo determinado de router. En este post intentare explicaos como instalarlo.

Instalación en Windows

Descargar GNS3, el paquete incluye Dynamips (un software necesario para correr GNS3), Putty (cliente para conexiones SSH y telnet por excelencia), WinPCAP (conjunto de librerías para trabajar con protocolos de red presente en los analizadores de red) y Quemu/Pemu (librerías para poder conectar GNS3 con Qemu, software libre emulador de sistemas operativos tipo VMware).

• Como la mayoría de las instalaciones en windows hacemos un “next, next…”

• Nos aparecerá una ventana con dos acciones necesarias a realizar:

• El paso 1 nos dice que tenemos que configurar y comprobar el path. Y comprobar si el software esta trabajando en una ruta que nos valga.

• Una vez realizados estos pasos solo nos quedara seleccionar los IOS desde la carpeta seleccionada en el paso anterior, para ello nos vamos a Editar -> Imagenes IOS y hypervisors. En la pestaña de Imágenes en Image Files seleccionamos el/los IOS que usaremos y podemos configurar algunos datos más como el modelo donde lo aplicaremos el IOS, la RAM del mismo y otras opciones.

• El último paso es testera el modulo Dynamips, para ello en Editar -> Preferencias -> Dynamips le damos al botón Test y debería salir un mensaje en verde, si es así ya podremos empezar a usar GNS3 en windows.

Instalación en MacOS

• Lo primero es descargar el archivo de aqui

• Una vez descargado, como una aplicación normal de MacOS copiamos el .app a la carpeta que queramos, ahora tenemos que descargarnos desde aqui > el Dynagen (Dynamips), para hacer funcionar el GNS3.

• Una vez descargado al igual que en windows Editar -> Preferencias -> Dynamips y ahí en ruta del ejecutable tendremos que escribir (a mi no me dejo seleccionarlo directamente) la ruta donde tenemos descargado dynamips, por ejemplo: /Users/danito/Desktop/Dynagen/dynamips una vez hecho esto y para asegurarse si pulsamos abajo el botón de test ya tendríamos listo el GNS3 en MacOS, ya solo nos quedaría seleccionar los IOS.

• Para seleccionar los IOS es la misma operación que en windows, desde Editar -> Imagenes IOS y hypervisors. En la pestaña de Imágenes en Image Files seleccionamos el/los IOS que usaremos y podemos configurar algunos datos más como el modelo donde lo aplicaremos el IOS, la RAM del mismo y otras opciones.

Consideraciones generales y consejos:

Como ya os comentaba en la introducción, una de las cosas que más me gusta de este software es que puedes conectar maquinas virtuales Qemu, esto nos da mucha versatilidad y le da mucha potencia a la aplicación siendo la capacidad de GNS3 la que nosotros queramos (emulación y prueba de DDos, MiTM, secularizar Apache, BBDD, etc). También podemos ‘meter’ en medio un Wireshark que nos puede ayudar a entender que esta pasando, desde problemas de red antes de hacer una subida de una configuración a reproducción, hasta estudiar los protocolos de enrolamiento viendo los paquetes que se envían entre equipos, etc.

También es valido este software para facilitar el estudio de certificaciones como CCNA, CCNP, CCNA-Sec, etc, teniendo en cuenta que GNS3 es mucho mas potente que el ya conocido PacketTracer de CISCO.

Es conveniente explicar que GNS3 es un software de emulación y necesita un sistema operativo IOS que emular, el cual se supone que es ilegal distribuirlo, pero ya sabéis como conseguirlo. Cuando consigáis o os compréis una IOS para practicar recordar que siempre es interesante que la IOS acepte crypto (opciones de seguridad) para ello una forma de guiarse es con el nombre que tiene, si lleva el sufijo k9, también comentaros que este software no emula equipos de capa 2 como switches, la única forma de trabajar con switchs es con un firmware de un equipo router multicapa, es decir que tiene opciones de configuración de switchs), yo uso el modelo Cisco 3725 y una posible IOS seria: c3725-adventerprisek9-mz.124-7.bin.

Espero poder hacer una entrega futura, cuando disponga de más tiempo, explicando como meter un GNS3 en una red puenteado con una interfaz de red y usarlo de servidor DHCP spoofeado para redirigir el tráfico de nuevo al original y poder ver lo que pasa con los equipos que ‘pesquemos’. Como ya sabéis el limite lo pone el conocimiento y la imaginación que tengamos, imaginaos añadiendo un proxy en PHP al que habilitemos SSL-strip ;).