blog

Los SSIs son directivas presentes sobre aplicaciones web utilizadas para alimentar una página HTML con contenidos dinámicos. Son similares a los CGIs, excepto el hecho de los SSIs ser utilizados para ejecutar algunas acciones antes de la página actual sea cargada o mientras la página está siendo visualizada. Para hacer esto el servidor web analiza SSI antes de proporcionar la página hacia el usuario.

Para la siguiente demostración se utiliza la versión de bWAPP incluida en OBWAP.

Ingresar a bWAPP, y seleccionar el “bug” de nombre “Server-Side Includes (SSI) Injection”, para luego hacer clic en el botón de nombre “Hack”.

En el formulario presentado, ingresar un nombre y un apellido. Luego hacer clic en el botón de nombre “Go”.

La página de respuesta incluye el nombre y el apellido ingresado, como también la dirección IP desde la cual se realiza la petición.

Utilizando la herramienta Zed Attack Proxy se analiza la página de respuesta, pues una manera de descubrir si la aplicación web es vulnerable, es verificando la presencia de páginas con extensión .stm, .shtm y .shtml. Sin embargo la ausencia de estas páginas no significa la aplicación está protegida contra ataques SSI.

Los comandos utilizados para inyectar SSI varían de acuerdo al sistema operativo del servidor. En este caso se está interactuando con un servidor Linux. El siguiente comando representa la sintaxis correcta a utilizar para ejecutar comandos del Sistema Operativo.

<!--#exec cmd="ls -l" -->

Utilizando la funcionalidad “Encode/Decode/Hash” de Zed Attack Proxy se codifica en URL el comando a enviar a través de la aplicación web.

Se activa la funcionalidad de interceptación de Zed Attack Proxy, para luego modificar el valor de parámetro de nombre “lastname”.

Si se ha ejecutado el comando correctamente en el sistema operativo del servidor, se obtiene un listado de nombres de archivos y directorios desde el servidor remoto donde reside la aplicación web vulnerable.

Un atacante de hecho también puede obtener el archivo “/etc/passwd”.

<!--#exec cmd="cat /etc/passwd" -->

El ataque SSI permite la explotación de una aplicación web inyectando scripts en páginas HTML o ejecutando remotamente código arbitrario. Esto puede ser explotado a través de la manipulación del SSI en uso en la aplicación o forzar su uso a través de los campos de entrada del usuario.

Es muy similar a la inyección de comandos, inyección HTML y XSS. La inyección SSI puede conducir a desfiguraciones del sitio web, control total del servidor y ataques de phishing.

Fuentes:

https://www.owasp.org/index.php/Server-Side_Includes_(SSI)_Injection
http://www.itsecgames.com/
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
http://httpd.apache.org/docs/current/mod/mod_include.html
https://httpd.apache.org/docs/current/howto/ssi.html

Una inyección HTML, también algunas veces referida como una desfiguración virtual, es un ataque sobre un usuario hecho posible por una vulnerabilidad de inyección en una aplicación web. Cuando una aplicación no maneja adecuadamente los datos proporcionados, un atacante puede proporcionar HTML válido típicamente mediante un valor de parámetro, e inyectar su propio contenido dentro de la página.

Este ataque es frecuentemente utilizado en conjunción con alguna forma de ingeniería social, pues el ataque está explotando una vulnerabilidad basada en el código y la confianza del usuario.

Para la siguiente demostración se utiliza la versión de bWAPP incluida en OBWAP.

Ingresar a bWAPP, y seleccionar el “bug” de nombre “HTML Injection – Reflected (GET)”, para luego hacer clic en el botón de nombre “Hack”.

En el formulario presentado, ingresar un primer nombre y un apellido. Luego hacer clic en el botón de nombre “Go”.

La página de respuesta incluye el texto “Welcome” seguido por el nombre y el apellido ingresado en el proceso anterior.

Utilizando Zed Attack Proxy se analiza la petición realizada, con especial atención en el método utilizado para enviar los datos del formulario y la URL.

También se analiza la respuesta recibida desde la aplicación web, con especial atención en el cuerpo de la respuesta donde se ubica el texto “Welcome”.

Para evaluar la factibilidad de realizar una inyección HTML se utilizará una etiqueta “IMG”, la cual insertará en la respuesta devuelta por la aplicación web, una imagen residente en otro servidor.

Se utiliza la herramienta “Encode/Decode/Hash” de Zed Attack Proxy para codificar en URL el código HTML a inyectar.

Utilizando Zed Attack Proxy se habilita su funcionalidad de interceptación. Para luego modificar el valor del parámetro de nombre “lastname”, con el código a inyectar.

La inyección HTML se ha realizado correctamente, y es factible ver una imagen externa como parte de la respuesta devuelta por la aplicación web vulnerable.

Una inyección HTML puede derivar en desfiguraciones a sitios web, ataques de phishing o explotación en el lado del cliente.

Fuentes:

https://www.owasp.org/index.php/HTML_Injection
http://www.itsecgames.com/
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Habiendo descubierto y enumerado casi todos los puertos TCP y UDP en estado abierto correspondientes al objetivo en evaluación, excepto el servicio HTTP atendiendo en el puerto TCP 80, se realiza este proceso el cual amerita una evaluación y análisis especial.

Puerto TCP 80

Según la información obtenida por Nmap, se detecta un servidor http Apache httpd 2.0.55 ((Unix) PHP/5.1.2). Lo cual se verifica estableciendo una sesión manual utilizando la herramienta netcat.

# echo -e "HEAD / HTTP/1.0\r\n" | nc -n -vv 192.168.0.100 80

Se procede a ejecutar todos los scripts NSE incluidos en Nmap pertinentes al servicio http.

# nmap -n -Pn -p80 --script http* 192.168.0.100

Se realizar una auditoría por fuerza bruta de contraseñas, pero la respuesta indica el recurso “/” no requiere autenticación.

Se realiza una medición del tiempo invertido por el sitio web para entregar una página web, devolviendo el tiempo mínimo y máximo invertido para obtener una página.

Se obtiene la fecha desde servicios HTTP. También se imprime la diferencia con el tiempo local. El tiempo local es el tiempo de envío de la petición HTTP, así esta diferencia incluye al menos la duración de un RTT.

Se enumeran directorios utilizados por servidores y aplicaciones web populares, encontrándose el archivo de nombre “/info.php”, el cual posiblemente sea un archivo con información. También se encontró el directorio de nombre “/icons/”, el cual podría ser un directorio potencialmente interesante, además de ser factible listar su contenido.

Se hace un spidering del sitio web en un intento de corresponder todas las páginas y urls contra una cadena definida. Las coincidencias son contabilizadas y agrupadas por la url bajo la cual fueron descubiertas. Se descubrieron en total 13 direcciones de correo electrónico.

http://192.168.0. 100/copyright.txt:
Correos electrónicos:
pentestlab@ De-ICE.net
twilhelm@ herot.net
twilhelm@ heorot.net

http://192.168.0. 100/index2.php:
Correos electrónicos:
marym@ herot.net
patrickp@ herot.net
thompsont@ herot.net
benedictb@ herot.net
genniege@ herot.net
michaelp@ herot.net
longe@ herot.net
adamsa@ herot.net
banterb@ herot.net
coffeec@ herot.net

Se realiza una petición HEAD por la carpeta raíz “/” del servidor web y se muestran las cabeceras devueltas.

Se enumeran cuales opciones son soportadas por el servidor HTTP enviando la petición OPTIONS. Esto lista los potenciales métodos riesgosos. También evalúa métodos no mencionados en las cabeceras OPTIONS individualmente y ve si son implementadas.

El host al parecer está limpio, no detectándose malware, y no se ha detectado tampoco una versión móvil.

Se intenta obtener la versión PHP desde el servidor web. PHP tiene un número de consultas mágicas las cuales retornan imágenes o texto el cual puede variar con la versión de PHP. La versión obtenida es la 5.1.2.

No se ha encontrado ningún script de dominio cruzado. Es decir la inclusión de scripts javascripts externos los cuales delegan parte de su seguridad a terceras entidades.

Se utiliza la información de la cabecera para obtener la versión del servidor HTTP. La cual es Apache/2.0.55 (Unix) PHP/5.1.2.

Se realiza un spidering al servidor web, y se muestra su estructura de directorio con número y tipos de archivos en cada carpeta. Los archivos listados de tener una extensión “Other” son aquellos quienes no tienen una extensión o son un documento raíz. Se han encontrado un archivo txt, dos archivos php y un archivo con otra extensión.

Se evalúa si el servidor web tiene la vulnerabilidad para el ataque de negación de servicio Slowloris. El servidor es probable sea vulnerable. Este resultado significa el servidor está sujeto a un ataque de “timeout-extension”, pero dependiendo de la arquitectura del servidor http y límites de recursos, una negación de servicio completa no siempre es posible. El completar la prueba requiere disparar la condición DOS y medir la respuesta del servidor.

No se encontrado ninguna vulnerabilidad de XSS almacenado. Tampoco un título para la página.

Se ha detectado el método TRACE habilitado. Si está habilitado, este devuelve los campos de respuesta las cuales fueron modificados en la respuesta.

Se ha detectado un posible proxy inverso. Para esto se explota las cabeceras HTTP Max-Forwards para detectar la presencia de proxys inversos.

Se ha verificado si diversas utilidades de crawling son permitidos por el host.

Todos estos resultados deben ser verificados cuidadosamente y luego analizados más profundamente. En primera instancia enfocándose en las direcciones de correo electrónico, cuyos nombres de usuario pueden ser utilizados para evaluar otros servicios, y tal vez obtener acceso hacia recursos de servidor o aplicación web. En segundo instancia evaluar si el servidor es vulnerable a un ataque DoS Slowloris.

Toda la información obtenida durante el proceso de enumeración permite alimentar nuevas pruebas a realizarse posteriormente, como también ser utilizadas en un escaneo de vulnerabilidades, explotación o acciones posteriores a la explotación.

Fuentes:

http://www.reydes.com/d/?q=Enumerar_los_Servicios_de_De_ICE_S1_100
https://nmap.org/nsedoc/scripts/http-brute.html
https://nmap.org/nsedoc/scripts/http-chrono.html
https://nmap.org/nsedoc/scripts/http-date.html
https://nmap.org/nsedoc/scripts/http-grep.html
https://nmap.org/nsedoc/scripts/http-headers.html
https://nmap.org/nsedoc/scripts/http-headers.html
https://nmap.org/nsedoc/scripts/http-malware-host.html
https://nmap.org/nsedoc/scripts/http-php-version.html
https://nmap.org/nsedoc/scripts/http-referer-checker.html
https://nmap.org/nsedoc/scripts/http-sitemap-generator.html
https://nmap.org/nsedoc/scripts/http-slowloris-check.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
https://nmap.org/nsedoc/scripts/http-trace.html
https://nmap.org/nsedoc/scripts/http-traceroute.html
https://nmap.org/nsedoc/scripts/http-useragent-tester.html

Luego de haber descubierto los puertos TCP y UDP en estado abierto o cerrado del objetivo en evaluación, el siguiente procedimiento implica enumerar cada servicio, tratando de obtener información más detallada como nombres de usuarios, acceso hacia recursos mal configurados, información sobre algún servicio desconocido, nombres de programas y versiones vulnerables, entre otra gran cantidad de información.

De los ocho puertos TCP reportados por la herramienta Nmap, séis de ellos se encuentran en estado abierto, y dos de ellos están en estado cerrado. El único puerto UDP encontrado está en estado abierto.

Puerto TCP 21

Según la información obtenida por Nmap se detecta un servidor vsftpd, aunque no se puede identificar su versión exacta. Al establecer una conexión utilizando un cliente ftp se muestra un mensaje el cual versa sobre la imposibilidad de enlazar un socket en atención IPv4. Este mensaje es altamente probable sea debido a un error en la configuración.

# ftp 192.168.0.10

Aún obteniendo este mensaje de error se procede a ejecutar todos los scripts NSE incluidos en nmap pertinentes al servicio ftp. No obteniéndose algún resultado adicional.

# nmap -n -Pn -p21 --script ftp* 192.168.0.100

Puerto TCP 22

Según la información obtenida por Nmap se detecta un servidor ssh OpenSSH 4.3 (protocol 1.99). Lo cual se verifica estableciendo una sesión manual utilizando un cliente ssh.

# ssh -v -lroot 192.168.0.100

Se procede a ejecutar todos los scripts NSE incluidos en Nmap pertinentes al servicio ssh. Obteniéndose información adicional relevante, como la huella de las llaves del servidor ssh. También se obtiene el número de algoritmos (para cifrado, compresión, etc.) ofrecidos por el servidor objetivo ssh 2. También se verifica el hecho del servidor ssh soporta un protocolo obsoleto y menos seguro, como es la versión 1.

# nmap -n -Pn -p22 --script ssh* 192.168.0.100

Puerto TCP 25

Según la información obtenida por Nmap se detecta un servidor smtp Sendmail 8.13.7/8.13.7. Lo cual se verifica estableciendo una sesión manual utilizando la herramienta netcat.

El servidor smtp soporta ciertos métodos; como EXPN, RCPT o VRFY; los cuales pueden ser utilizados para enumerar usuarios válidos.

Para este propósito es factible utilizar la herramienta smtp-user-enum, utilizando el método RCPT y una lista genérica de usuarios para sistemas Unix, la cual se incluye por defecto en la herramienta Metasploit Framework. Mediante este método se enumeran 19 usuarios válidos en el sistema objetivo.

# smtp-user-enum -m 1 -M RCPT -U /usr/share/metasploit-framework/data/wordlists/unix_users.txt -t 192.168.0.100

Se procede a ejecutar todos los scripts NSE incluidos en Nmap pertinentes al servicio smtp. Obteniéndose información sobre los comandos extendidos soportados por el servidor smtp. Adicionalmente se intenta retransmitir correo mediante la utilización de una combinación predefinida de comandos SMTP. El objetivo es verificar si el servidor smtp es un vulnerable a la retransmisión de correo.

# nmap -n -Pn -p25 --script smtp* 192.168.0.100

Puerto TCP 110

Según la información obtenida por Nmap se detecta un servidor pop Openwall popa3d. Esto no puede ser verificado únicamente estableciendo una sesión manual utilizando la herramienta netcat.

# nc -n -vv 192.168.0.100 110

Se procede a ejecutar todos los scripts NSE incluidos en Nmap pertinentes al servicio pop3. No obteniéndose tampoco información relevante adicional.

# nmap -n -Pn -p110 --script pop* 192.168.0.100

Puerto TCP 143

Según la información obtenida por Nmap se detecta un servidor imap UW imapd 2004.357. Lo cual se verifica estableciendo una sesión manual utilizando la herramienta netcat.

# nc -n -vv 192.168.0.100 143

Se procede a ejecutar todos los scripts NSE incluidos en Nmap pertinentes al servicio imap. Obteniéndose información sobre las capacidades del servidor de correo IMAP. El comando CAPABILITY permite a un cliente consultar al servidor cuales comandos soporta y posiblemente cualquier política especifica del sitio.

# nmap -n -Pn -p143 --script imap* 192.168.0.100

El puerto TCP 80 requiere una evaluación y análisis particular. Razón por la cual se detallará este proceso en otra publicación.

Los scripts NSE de Nmap utilizados han sido ejecutados con su configuración por defecto, de hecho es factible configurar algunos de ellos; como por ejemplo los realizando ataques por fuerza bruta; para optimizar su capacidad de obtener información relevante para nuestra evaluación.

Fuentes:

http://www.reydes.com/d/?q=Escaneo_de_Puertos_Versiones_y_Sistema_Opera…
https://wiki.archlinux.org/index.php/Very_Secure_FTP_Daemon
http://www.basicconfig.com/linuxnetwork/ftp_server
https://nmap.org/nsedoc/scripts/ssh-hostkey.html
https://nmap.org/nsedoc/scripts/ssh2-enum-algos.html
https://nmap.org/nsedoc/scripts/sshv1.html
https://tools.ietf.org/html/rfc821
http://pentestmonkey.net/tools/user-enumeration/smtp-user-enum
https://nmap.org/nsedoc/scripts/smtp-commands.html
https://nmap.org/nsedoc/scripts/smtp-open-relay.html
https://nmap.org/nsedoc/scripts/imap-capabilities.html

El escenario para DE-ICE S1.100; el cual es un LiveCD; es relacionado sobre el CEO de una pequeña empresa quien ha sido presionado por la junta directiva para tener una prueba de penetración hecha dentro de la compañía. El CEO cree la compañía es segura, siente esto es un desperdicio de dinero, especialmente porque él ya hizo un escaneo de vulnerabilidades en su red (utilizando nessus). Para hacer a la junta directiva feliz, él decide contratar a una persona por un trabajo de cinco días; y como él no cree su compañía sea insegura; se contrata a la persona para únicamente evaluar un servidor, un viejo sistema el cual tiene unicamente una lista basada en web sobre información de contacto de la compañía.

El CEO espera esta persona proporcione evidencia sobre las practicas de seguridad aceptadas seguidas por los administradores, y por lo tanto no se podría ser capaz de obtener acceso hacía el objetivo evaluado.

Se ejecuta la herramienta nmap para realizar un escaneo de puertos TCP y un escaneo de versiones. La opción “-n” no hace resolución hacia un DNS. La opción “-Pn”, trata todos los hosts como en funcionamiento, evitando el descubrimiento del host. La opción “-sV” realiza un escaneo de versiones, probando cada puerto TCP abierto para determinar información sobre el servicio y versión. La opción "-p-" define el escaneo de 65,535 puertos TCP.

# nmap -n -Pn -sV -p- 192.168.0.100

Ahora se ejecuta la herramienta nmap para realizar un escaneo de puertos UDP. Considerar aquí no se está definiendo el rango de puertos UDP, por lo tanto nmap escanea los 1000 puertos UDP más populares.

# nmap -n -Pn -sU 192.168.0.100

Nmap también permite detectar el sistema operativo utilizando la opción “-O”. Para el siguiente escaneo únicamente se definen los puertos TCP y UDP encontrados en estado abierto o cerrado, mediante los anteriores escaneos.

# nmap -n -Pn -sV -pT:20,21,22,25,80,110,143,443,U:53 -O 192.168.0.100

El siguiente proceso a realizar será el enumerar cada servicio tratando de obtener información más detallada como nombres de usuarios, acceso a recursos mal configurados, información sobre algún servicio desconocido, nombres de programas y versiones vulnerables, entre otra gran cantidad de información.

Fuentes:

https://www.vulnhub.com/entry/de-ice-s1100,8/
https://nmap.org/
https://www.kali.org/

Más allá de las técnicas ordinarias para la captura del banner en sistemas GNU/Linux, los atacantes maliciosos pueden utilizar la manera en la cual el sistema o sus aplicaciones se comunican por defecto, como un medio para identificar el respectivo sistema operativo, sin considerar los baners configurados.

Estas características, o huellas, pueden consistir de mensajes de error, puertos abiertos, valores TTL (Time To Live), propiedades de la pila TCP/IP, o cualquier otro detalle el cual pueda ser detectado a través del tráfico de la red o análisis de datos. Algunas de las herramientas utilizadas para obtener información sobre la huella del sistema operativo son nmap, p0f y ettercap.

Para la siguiente demostración se utilizará Kali Linux 2.0 y una máquina virtual basada en GNU/Linux De-Ice 1.100.

Para la primera demostración se utiliza la herramienta nmap con su opción “-O”.

Una de las funcionalidades mejor conocida de Nmap es la detección remota del sistema operativo utilizando la huella de la pila TCP/IP. Nmap envía una serie de paquetes TCP y UDP hacia el host remoto y examina prácticamente cada bit en las respuestas. Después de realizar una docena de pruebas como muestreo ISN TCP, soporte u ordenamiento de opciones TCP, muestreo ID IP, y verificación del tamaño inicial de ventana, Nmap compara los resultados con su base de datos “nmap-os-db” de mas de 2,600 huellas conocidas de sistemas operativos, e imprime los detalles del sistema operativo si encuentra una coincidencia. Cada huella incluye una descripción textual de forma libre del sistema operativo, y una clasificación la cual proporciona el nombre del proveedor, sistema operativo subyacente, generación del sistema operativo y tipo de dispositivo.

# nmap -n -Pn -p- -sV -O 192.168. 0.X

Los resultados exponen un Sistema Operativo Linux 2.6.X. Y entre los detalles del sistema operativo se incluye un rango desde 2.6.13 hasta 2.6.32. Lo cual es correcto, si verificamos esto cuando se obtenga acceso local hacia el sistema objetivo, por ejemplo.

A la técnica utilizada por Nmap u otra herramienta la cual envía paquetes hacia el objetivo de evaluación para luego analizar las respuestas, se le denomina un reconocimiento activo de la huella del sistema operativo.

P0f es una herramienta la cual realiza un reconocimiento pasivo de la huella del sistema operativo.

Para la segunda demostración se utiliza P0f. P0f utiliza un arreglo de mecanismos puramente pasivos sobre la huella para identificar a los jugadores detrás de cualquier comunicación TCP/IP incidental (frecuentemente algo tan pequeño como un SYN normal) sin interferir de ninguna manera. P0f puede operar en segundo plano como un demonio, y ofrece un API sencillo en tiempo real para componentes de terceros quienes deseen obtener información adicional sobre los actores en comunicación.

Se ejecuta p0f. La opción “-p” coloca en modo promiscuo a la interfaz de red.

# p0f -i eth0 -p

Para propósito de la demostración se visita el sitio web del objetivo utilizando un navegador web.

La información obtenida por p0f indica un sistema operativo Linux con Kernel 2.6.X. Lo cual corrobora la información obtenida utilizando la herramienta Nmap.

Otra herramienta la cual realiza un reconocimiento pasivo de la huella del sistema operativo es Ettercap. La principal idea en esto es analizar la información pasiva proviniendo desde el host cuando este hace o recibe peticiones con otros hosts. Esta información es suficiente para detectar el sistema operativo y los servicios en funcionamiento del host. En este escenario se mira en paquetes SYN y SYN+ACK, además de recolectar alguna información interesante, como tamaño de ventana, MSS, TTL, escala de ventana, SACK, NOP, DF, marcas de tiempo y paquetes SYN o SYN+ACK.

Definir la iniciación de un “Unified Sniffing” o “Bridged Sniffing”, para luego iniciar el Sniffing. Con un navegador web se visita el sitio web del objetivo en evaluación.

Visualizar la información obtenida en “Profiles” o Perfiles, para luego hacer doble clic en la dirección IP correspondiente al host objetivo.

La información expuesta por Ettercap indica el sistema operativo más cercano es un Linux con un Kernel desde 2.6.9 hasta 2.6.11.

En este caso la información obtenida por Ettercap no es correcta, pues es objetivo de evaluación es un Linux con Kernel 2.6.16.

Existen herramientas como IPTables incluidos por defecto en la mayoría de distribuciones Linux, las cuales pueden mezclar la huella de un sistema operativo GNU/Linux, y de esta manera pelear contra las técnicas tratando de identificar esta información.

Fuentes:

https://www.kali.org/
https://www.vulnhub.com/entry/de-ice-s1100,8/
https://nmap.org/book/man-os-detection.html
http://lcamtuf.coredump.cx/p0f3/
https://github.com/Ettercap/ettercap

bWAPP, es una aplicación web libre y de fuente abierta deliberadamente insegura. Esta ayuda a los entusiastas en seguridad, desarrolladores, y estudiantes, a descubrir y prevenir vulnerabilidades web. BWAPP permite preparase para conducir proyectos satisfactorios de pruebas de penetración y hacking ético.

BWAPP es único, pues contienen más de 100 vulnerabilidades web. Abarca las fallas web más conocidas, incluyendo todos los riesgos del proyecto OWASP TOP 10.

Para la siguiente demostración se utilizará la versión más reciente de Samurai WTF, y la versión de bWAPP incluida en OBWAP. El nivel de seguridad está definida a “low” o bajo.

Ingresar hacia el formulario de “Login” de bWAPP.

Se intentará encontrar la contraseña correcta del usuario de nombre “bee”. Se ingresa entonces cualquier contraseña para este usuario.

El mensaje de respuesta indica la no validez de las credenciales, o la inactividad del usuario.

Utilizando ZAP, se ubica la petición donde se envían los datos de este formulario hacia la aplicación web, incluyendo el nombre de usuario y contraseña.

Se selecciona la contraseña y se ejecuta la herramienta “Fuzz” de ZAP.

Se crea un nuevo Payload o Carga Útil seleccionado un archivo conteniendo una lista de palabras, las cuales serán intentadas como posibles contraseñas.

Finalizada la ejecución de la herramienta “Fuzz” de ZAP. La contraseña encontrada para el usuario “bee” es “bug”. Se puede analizar para esto la columna “Code”, “Reason”, entre otros.

Fuentes:

http://www.itsecgames.com/
https://sourceforge.net/projects/samurai/
https://github.com/zaproxy/zaproxy
https://sourceforge.net/projects/owaspbwa/

Recon-ng es una framework con completas características para el reconocimiento web escrito en Python. Completo con módulos independientes, interacción con una base de datos, funciones incorporadas convenientemente y ayuda interactiva. Recon-ng proporciona un poderoso entorno en el cual se puede conducir un rápido y exhaustivo reconocimiento basado en web de fuente abierta.

Recon-ng tiene un entorno similar a Metasploit Framework, reduciendo la curva de aprendizaje para aprovechar el framework. Sin embargo es algo diferente. Recon-ng no está hecho para competir con los frameworks existentes, pues está diseñado exclusivamente para reconocimiento basado en web de fuente abierta. Si se requiere explotar se debe utilizar Metasploit Framework. Si se desea hacer ingeniería social se debe utilizar Social-Engineer Toolkis. Si se requiere conducir un reconocimiento se debe utilizar Recon-ng.

Recon-ng es un framework completamente modular y facilita la contribución de nuevos desarrolladores de Python. Cada módulo es una subclase de la clase “module”. La clase “module” es una interprete “cmd” personalizado equipado con funcionalidades incorporadas los cuales proporcionan interfaces simples para tareas comunes, como salidas estandarizadas, interacción con la base de datos, hacer peticiones web, y gestionar llaves API. Por lo tanto todo el trabajo duro ha sido hecho. Construir módulos es simple y toma pocos minutos.

A continuación se detalla el procedimiento para instalar la versión más reciente de Recon-ng al momento de publicar el presente escrito.

Clonar el repositorio de recon-ng

$ git clone https://LaNMaSteR53@bitbucket.org/LaNMaSteR53/recon-ng.git

Ingresar al directorio de nombre “recon-ng” e instalar las dependencias.

$ sudo pip install -r REQUIREMENTS

Ejecutar Recon-ng con la opción “-h” para mostrar sus opciones.

$ ./recon-ng -h

Si todo ha sido realizado correctamente ya es factible utilizar Recon-ng.

$ ./recon-ng

Fuentes:

https://bitbucket.org/LaNMaSteR53/recon-ng
https://bitbucket.org/LaNMaSteR53/recon-ng/wiki/Usage%20Guide
https://sourceforge.net/projects/samurai/

Parsero es un script gratuito escrito en Python el cual lee el archivo Robots.txt de un servidor web y busca la entradas Deshabilitadas. Las entradas Deshabilitadas le indican a los motores de búsqueda los directorios o archivos hospedados sobre un servidor web los cuales no deben ser indexados. Por ejemplo “Disallow:/portal/login” implica el contenido de www. Dominio .com/portal /login no está permitido de ser indexado por los “crawlers” como Google, Bing, Yahoo, entre otros. De esta manera el administrador pueden decidir no compartir información sensible o privada con los motores de búsqueda.

Pero algunas veces estas rutas tipeadas en las entradas Deshabilitadas son directamente accedibles por los usuarios sin utilizar un motor de búsqueda, sólo visitando la URL y la Ruta, y algunas veces no están disponibles para ser visitadas por nadie. Es realmente común los administradores escriban muchas Deshabilitaciones, estando algunas de ellas disponibles y algunas de ellas no. Se puede utilizar Parsero para verificar el código de estado HTTP de cada entrada Deshabilitada para verificar automáticamente si estos directorios están disponibles o no.

También, el hecho de los administradores escriban un archivo Robots.txt, no significa los archivos o directorios tipeados en las entradas Deshabilitadas no sean indexados por Bing, Google, Yahoo, entre otros. Por esta razón, Parsero es capaz de buscar en Bing para localizar contenido indexado sin la autorización del administrador web. Parsero verificará el código de estado HTTP de la misma manera para cada resultado de Bing.

Para la siguiente demostración se instalará Parsero en Samurai WTF.

Descargar la versión más reciente de Parsero desde su repositorio github.

$ sudo git clone https://github.com/behindthefirewalls/Parsero

Ejecuta el script de nombre “setup.py” para proceder con su instalación.

$ sudo python setup.py install

Ejecutar Parsero. La opción “-h” mostrará la ayuda de la herramienta.

$ python3 parsero.py -h

Al ejecutar la herramienta, se muestra un mensaje donde se indica la necesidad de instalar Beautifulsoup.

Se indica a pip3 instalar beautifulsoup4.

$ sudo pip3 install beautifulsoup4

Ejecutar Parsero nuevamente. La opción -u define la URL a analizar. La opción “-sb” busca en Bing las Deshabilitaciones indexadas.

$ python3 parsero.py -u www. Dominio. info -sb

Los resultados obtenidos identifican un directorio con acceso prohibido. Y un segundo directorio el cual está disponible. Al buscar en Bing el enlace, no ha sido factible encontrarlo, y un segundo enlace es factible de ser accedido.

En los resultados obtenidos de la siguiente prueba se ha encontrado catorce enlaces, de los cuales once están disponibles. Uno no encontrado, uno prohibido y otro no aceptable.

$ python3 parsero.py -u www. Dominio2 . info -sb

En las búsquedas realizadas en Bing por estos directorios, únicamente uno de ellos devuelve el mensaje de ser una petición errónea.

La herramienta también permite mostrar únicamente los códigos de estado “HTTP 200” y escanear una lista de dominios desde un archivo.

Fuentes:

https://github.com/behindthefirewalls/Parsero
http://www.behindthefirewalls.com/2013/12/parsero-tool-to-audit-robotst…
https://sourceforge.net/projects/samurai/

DotDotPwn es un fuzzer muy inteligente y flexible para descubrir vulnerabilidades de recorrido de directorio en software como servidores HTTP/FTP/TFTP, y plataformas web como CMSs, ERP blog, entre otros.

También tiene un módulo independiente de protocolo para enviar un payload requerido hacia un host y puerto especificado. De otro lado, también podría ser utilizado en la forma de un script utilizando el módulo STDOUT.

La herramienta está escrita en el lenguaje de programación perl y puede ser ejecutada sobre plataformas *NIX o Windows.

Los módulos de fuzzing soportados en la más reciente versión son; HTTP, HTTP URL, FTP, TFTP, Payload (Independiente del protocolo) y STDOUT.

La siguiente demostración detalla el procedimiento de instalación de DotDotPwn en Samurai WTF. Aunque de hecho este procedimiento puede ser aplicado en otras distribuciones GNU/Linux.

Se recomienda descargar y utilizar la más versión más recientemente mejorada de DotDotPwn desde los repositorios de github.

$ git clone https://github.com/wireghoul/dotdotpwn.git

Entre los requerimientos para instalar DotDotPwn, se define la instalación previa de Perl 5.8.8 y 5.10. Además de Nmap, únicamente si se planea utilizar la funcionalidad para la detección del Sistema Operativo (se necesita privilegios de root).

$ perl -v
$ nmap -V

DotDotPwn también requiere la instalación previa de los módulos Perl; Net::FTP, TFTP, Time::HiRes, Socket, IO::Socket, Getopt::Std y Switch.

Estos módulos pueden ser fácilmente instalados ejecutando los siguientes comandos como root. Dado el hecho de ejecutar por primera vez “CPAN”, primero se realiza su configuración.

$ sudo cpan

En nuestro escenario, se ha indicado a CPAN realizar una configuración automática.

> install Net::FTP

> install TFTP

> install Time::HiRes

> install Socket
> install IO:Socket
> install getopt::Std

Ejecutar la herramienta DotDotPwn. Si todo se ha realizado correctamente, se visualizará su modo de uso y todas sus opciones disponibles.

$ ./dotdotpwn.pl

Fuentes:

https://github.com/wireghoul/dotdotpwn
http://dotdotpwn.blogspot.pe/
https://www.owasp.org/index.php/Path_Traversal
https://sourceforge.net/projects/samurai/