blog

Kali Linux “Vivo” (Live) proporciona un “modo forense”, una característica introducida primero en BackTrack Linux. La opción "Inicio vivo en modo forense" ha probado ser muy popular por varias razones:

• Kali Linux está disponible de manera amplia y fácil; muchos potenciales usuarios ya tienen una ISO de Kali o unidades USB de iniciables.
• Cuando surge una necesidad forense, Kali Linux “Vivo” permite sea rápido y fácil poder trabajar con Kali Linux.
• Kali Linux viene previamente cargado con el software forense de fuente abierta más popular, un conjunto de herramientas útil cuando se necesita realizar un trabajo forense.

Cuando se inicia en el modo de inicio forense, existen algunos cambios muy importantes en el funcionamiento regular del sistema:

1. Primero, el disco duro interno nunca es tocado. Si existe una partición de intercambio (swap), no se utilizará, y no se montará automáticamente ningún disco interno. Esto se verificó tomando primero un sistema estándar y eliminando el disco duro. Se generó un hash desde la unidad utilizando un paquete forense comercial. Luego se volvió a conectar el disco hacia la computadora para iniciar Kali Linux “Vivo” en modo forense. Después de utilizar Kali por un período de tiempo, se apagó el sistema, se retiró el disco duro, y se generó nuevamente un hash. Estos hashes coincidieron, lo cual indica en ningún momento se cambió sobre el disco.

2. El otro igualmente importante es, se desactiva el montaje automático de medios extraíbles. Las memorias USB, CD, y similares no se montarán automáticamente cuando se inserten. La idea detrás de esto es simple: en modo forense, no debería pasarse nada hacia ningún medio sin la acción directa del usuario. Todo lo cual sea realizado como usuario depende como es consecuente, del usuario.

Si planea utilizar Kali para cualquier tipo de análisis forense del mundo real, se recomienda no confiar simplemente en lo antes descrito. Todas las herramientas forenses siempre deben validarse para saber como se comportarán en cualquier circunstancia en las cuales vayan a utilizarse. Finalmente, mientras Kali continúa enfocándose en proporcionar la mejor colección de herramientas para pruebas de penetración de fuente abierta disponibles, siempre es posible se haya pasado por alto alguna herramienta forense de fuente abierta importante. El proyecto siempre buscando herramientas de fuente abierta de alta calidad, la cuales puedan ser agregadas a Kali para mejorarlo aún más.

Fuentes:

https://www.kali.org/docs/general-use/kali-linux-forensics-mode/
https://www.kali.org/get-kali/#kali-live

Las fallas relacionadas a fuga de información, proporcionan datos adicionales para la etapa de reconocimiento, las cuales son muy útiles durante un proyecto de hacking ético y pruebas de penetración.

Típicamente estás fallos no conducen directamente a la explotación. Pero la información obtenida durante esta etapa es utilizada como una entrada para etapas posteriores, como por ejemplo inyección SQL, adivinar contraseñas, y otros escenarios más.

Anotación importante

Los siguientes ejemplos se obtuvieron utilizando el motor de búsqueda Google. Yo NO realicé escaneos, ni otro tipo de interacción manual adicional. Únicamente ingrese a los enlaces mostrados, producto de buscar en Google.

Para el primer ejemplo, el mensaje de error es mostrado de manera estructurada, incluyendo rutas y nombres de archivos, como también nombres de columnas.

En el segundo escenario, el mensaje de error incluye el tipo de servidor de base de datos (Maria DB), además del nombre de una columna (idPlaza)

En el tercer ejemplo. El extenso mensaje revela el tipo de servidor (MariaDB), además de la consulta SQL, entre nombres de columnas, tablas y nombres de bases de datos.

Para el cuarto escenario, el mensaje de error expone también información del servidor (MariaDB), además parte de la consulta y nombres de tabla.

Para todos los ejemplos mencionados, se conoce se está interactuando con una base de datos backend MariaDB, y los errores cometidos por los diseñadores y programadores.

Fuente:

https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Expos…
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…

SecLists es el compañero del profesional en pruebas de penetración y hacking ético. Es una colección de múltiples tipos de listas utilizadas durante las evaluaciones en ciberseguridad, recopiladas en un solo lugar. Los tipos de listas incluyen nombres de usuario, contraseñas, URLs, patrones de datos confidenciales, cargas útiles (Payloads) para fuzzing, shells vía web y mucho más. Su propósito es permitir un profesional coloque este repositorio dentro de una nueva caja para pruebas, para tener acceso hacia todo tipo de listas factibles de ser necesitadas.

SecLists está estructurado en nueve directorios; Descubrimiento (Discovery), Fuzzing, Indicadores de Compromiso (IOC), Misceláneo (Miscellaneous), Contraseñas (Passwords), Coincidencia de Patrones (Pattern-Matching), Cargas Útiles (Payloads), Nombres de Usuario (Usernames), y Shells Web (Web-Shells).

$ ls -l /usr/share/seclists/

Es factible también utilizar el comando tree para visualizar la estructura de directorios de manera recursiva.

$ tree -d /usr/share/seclists

Al momento de realizar la presente publicación está constituido de 109 directorios.

Siempre se sugiere revisar el contenido de los archivos antes de utilizarlas para realizar las evaluaciones.

$ column /usr/share/seclists/Passwords/500-worst-passwords.txt

Fuentes:

https://github.com/danielmiessler/SecLists
https://www.kali.org/tools/seclists/

Los comentarios pueden ser muy reveladores. Pueden incluir de todo, desde nombres de usuario y contraseñas, hasta elementos relevantes sobre la gestión, además de lenguajes particulares. Como mínimo los comentarios pueden proporcionar información la cual puede ayudar a lanzar ataques de ingeniería social. En muchos casos también pueden mostrar como funciona la aplicación en su interior ,o indicar partes de la aplicación conteniendo problemas. Por alguna razón los desarrolladores frecuentemente olvidan el usuario final puede simplemente hacer clic en "Ver código fuente", utilizando su navegador web.

Para los siguientes ejemplos únicamente se utiliza el navegador, y la funcionalidad de visualizar el código fuente.

En el primer ejemplo a través de los comentarios se expone información sobre la utilización de un plugin de WordPress de nombre WP Super Cache.

En este segundo escenario, se encuentra, una URL incluyendo entre sus diversos parámetros, un parámetro, “custid”, “user”, y “password”, los cuales tienen definidos valores.

Para el tercer ejemplo los comentarios revelan referencias hacia enlaces factibles de ser accedidos directamente, pero no mostrados en el sitio web.

En el cuarto escenario se encuentra una breve linea correspondiente a código PHP.

Reiterar la importancia de realizar este tipo de revisiones simples pero efectivas.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appl…
https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Appl…

Las herramientas automáticas para realizar Spidering se conocen como "robots". Estos son frecuentemente utilizados por los motores de búsqueda, como Google, Bing, o Yandex, para generar una base de datos de las páginas disponibles en la Web. Los robots también pueden ser utilizados por los administradores del sitio web para verificar la validez de los enlaces, por spammers para recolectar direcciones de correo electrónico, o para otros propósitos.

El Protocolo para la exclusión de robots es un estándar no oficial y de uso común, el cual permite a los administradores de sitios web especificar cuales áreas los robots no deben rastrear. Los administradores simplemente crean un archivo de nombre “robots.txt” en el directorio raíz del sitio web, para luego enumerar en este los directorios y páginas los cuales no deben ser rastreados. Muchos robots; incluido el rastreador de Google; buscan este archivo y actúan en consecuencia. Sin embargo los robots pueden ignorar este archivo, y también puede ser útil para los ciberatacantes porque proporciona una lista conveniente de páginas y directorios para los cuales los administradores no quieren se acceda ampliamente.

Los administradores de sitios web también pueden utilizar la etiqueta META de HTML Robots para indicar aquello los robots no deben ver una página en particular. Sin embargo este método no es de uso común.

De manera alterna a “Robots” se pueden utilizar meta etiquetas (meta tags) sobre páginas individuales.

Las etiquetas (tags) para prevenir el contenido esté en caché son:

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

Estos dos primeros deben utilizarse pues diferentes clientes respetan cada uno de estos.

Las etiquetas (tags) para controlar los spiders de motores de búsqueda y hacia donde irán son:

<META NAME="ROBOTS" CONTENT="INDEX,NOFOLLOW">
<META NAME="GOOGLEBOT" CONTENT="NOARCHIVE">

Estas dos son útiles para controlar los bots correspondientes a los motores de búsqueda.

Fuentes:

https://www.robotstxt.org/

Nikto 2.5 es un escáner de fuente abierta (GPL) para servidores web, el cual realiza pruebas completas contra servidores web por múltiples elementos, incluidos más de 7,000 archivos/programas potencialmente peligrosos, busca versiones obsoletas de más de 1,250 servidores, además de problemas específicos de versiones en más de 270 servidores. También verifica elementos sobre la configuración del servidor, como la presencia de múltiples archivos índice, opciones del servidor HTTP, además intentará identificar los servidores web y el software instalados. Los elementos y complementos para realizar escaneo se actualizan con frecuencia y se pueden actualizar automáticamente.

La versión más reciente al momento de realizar esta publicación corresponde a la versión 2.5 de Nikto. La cual incluye ahora una nueva característica para escanear direcciones IPv6.

En la ayuda de Nikto se puede visualizar la opción “-ipv6”.

$ nikto -Help

Se procede a realizar un escaneo con Nikto.

$ nikto -ipv6 -h [2800:200:f008:b481:b595:524d:7834:d0a3] -p 80

La opción “-ipv6” escanea únicamente la dirección IPv6

La opción “-h” define el host o ULR a escanear

La opción “-p” define el puerto a utilizar, por defecto es el 80

Si se presenta un mensaje de error relacionado con la definición de la dirección IPv6. Definir la dirección IPv4 entre símbolos de corchetes.

Fuentes:

https://cirt.net/Nikto2
https://github.com/sullo/nikto
https://github.com/sullo/nikto/wiki

Un elemento a buscar durante las evaluaciones son las páginas por defecto. Estos pueden ser archivos instalados cuando se construyó el servidor. Ejemplos de esto son la página de bienvenida de Apache o sobre algunos de los scripts de muestra instalados en IIS.

Una técnica para verificar las páginas por defecto es acceder hacia el servidor a mediante su dirección IP. Muchos servidores están configurados para ofrecer diferentes páginas según el nombre de host completamente calificado por solicitado por el cliente, pero los administradores del servidor algunas veces olvidan configurar un sitio personalizado para la dirección IP, lo cual revela páginas web predeterminadas.

Los ejemplos a continuación presentado únicamente implicaron visitar la dirección IP hacia la cual resuelven diferentes sitios web.

Página por defecto de Apache HTTP Server.

Página de login para IBM Websphere Portal

Página de Securi Website Firewall.

Páginas de error devuelta por imperva

Existen también herramientas disponibles para encontrar contenido por defecto, como Nikto2.

Fuentes:

https://httpd.apache.org/docs/trunk/getting-started.html
https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/ww…

Este script inicia repetidamente conexiones SSLv3/TLS, cada vez intentando un nuevo cifrado o compresor mientras registra si un host lo acepta o rechaza. El resultado final es una lista de todas las suites de cifrado y compresores aceptadas por un servidor.

Cada suite de cifrado se muestra con una calificación de letras (desde la A hasta la F) lo cual indica la fortaleza de la conexión. El grado se basa en la fortaleza criptográfica para el intercambio de llaves y cifrado del flujo. La elección del algoritmo para integridad del mensaje (hash) no es un factor. La línea de salida iniciando con el texto "fortaleza mínima", muestra la fortaleza del cifrado más débil ofrecido. La puntuación se basa en la Guía para la clasificación de servidores SSL de Qualys SSL Labs, pero no tiene en consideración la compatibilidad con el protocolo (versión TLS), lo cual constituye el 30 % de la clasificación de SSL Labs.

SSLv3/TLSv1 requieren más esfuerzo para determinar cuales cifrados y métodos para compresión admite un servidor comparado con SSLv2. Un cliente enumera los cifrados y compresores capaz de ser admitidos, y el servidor responderá con un único cifrado y compresor elegidos, o con un aviso de rechazo.

Algunos servidores utilizan el orden de las suites para cifrado del cliente: eligiendo el primero de las suites ofrecidas por el cliente las cuales también admiten. Otros servidores prefieren sus propias ordenes: escogen su suite preferida entre las ofrecidas por el cliente. En el caso del pedido del servidor, el script realiza pruebas adicionales para descubrir la lista de preferencias ordenadas del servidor. De lo contrario la lista se ordena alfabéticamente.

El script advertirá sobre ciertas configuraciones incorrectas de SSL, como certificados firmados MD5, parámetros DH efímeros de baja calidad, y la vulnerabilidad POODLE.

Este script es intrusivo, pues debe iniciar muchas conexiones hacia un servidor, siendo por lo tanto bastante ruidoso.

Se recomienda utilizar este script junto con la detección de versión (-sV), para descubrir servicios SSL/TLS ejecutándose en puertos inesperados. Para los puertos SSL más comunes como 443, 25 (con STARTTLS), 3389, etc., el script es lo suficientemente inteligente como para ejecutarse por si solo.

Se ejecuta el script ssl-enum-chipher de Nmap.

$ sudo nmap -Pn -sV -p443 --script ssl-enum-ciphers -iL serversgobpe.txt

La opción “-Pn” trata todos los hosts como su estuviese en línea o en funcionamiento

La opción “-sV” prueba los puertos abiertos para determinar información sobre el servicio y versión.

La opción “--script” es una lista separada por comas de directorios, archivos script, o categorías de scripts.

La opción “-iL” define un lista de entrada de hosts o redes.

Para el primer host escaneado la menor fortaleza identifica es A.

Para el segundo host escaneado se presenta una advertencia sobre el intercambio de llaves (DH 1024) es de menor fortaleza comparado con la llave del certificado.

Para el tercer host escaneado se presentan más advertencias aún. Sobre el cifrado 3DES de bloques de 64 bits es vulnerable al ataque de nombres SWEET32. Así mismo el cifrado RC4 roto es obsoleto en base al RFC 7465. También mencionad la suite de cifrado utiliza MD5 para la integridad del mensajes, y por último obre el intercambio de llaves (DH 1024) es de menor fortaleza comparado con la llave del certificado.

Como es consecuente inferir, se deben revisar y gestionar adecuadamente las advertencias presentadas por el script ssl-enum-ciphers de Nmap.

Fuentes:

https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
https://www.cisa.gov/news-events/alerts/2014/10/17/ssl-30-protocol-vuln…
https://www.ssllabs.com/projects/rating-guide/
https://www.ssllabs.com/ssltest/

Los parámetros criptográficos sobre el estado de sesión son producidos por el protocolo TLS Handshake, el cual opera sobre la capa de registro TLS. Cuando un cliente y un servidor TLS comienzan a comunicarse por primera vez, acuerdan una versión de protocolo, seleccionan algoritmos criptográficos, opcionalmente se autentican entre sí, y utilizan técnicas para encriptación de clave pública, con el propósito de generar secretos compartidos.

A continuación se detallan el proceso TLS Handshake:

Mensaje "Client Hello": El cliente inicia el handshake enviando un mensaje "hello" hacia el servidor. El mensaje incluirá cual versión de TLS admite el cliente, la suites de encriptación soportados, y una cadena de bytes aleatorios conocida como "client random “.

Mensaje 'Server Hello': En respuesta al mensaje “Client Hello”, el servidor envía un mensaje conteniendo el certificado SSL del servidor, la suite de encriptación seleccionada por el servidor, y el "server random", otra cadena aleatoria de bytes generada por el servidor.

Autenticación: El cliente verifica el certificado SSL del servidor con la autoridad certificadora quien lo emitió. Esto confirma el servidor es quien dice ser, y el cliente está interactuando con el propietario real del dominio.

“premaster secret”: El cliente envía una cadena aleatoria más de bytes, el "premaster secret". Este se cifra con la llave pública, y solo el servidor puede desencriptarlo con la llave privada. (El cliente obtiene la llave pública desde el certificado SSL del servidor).

Llave privada utilizada: El servidor desencripta el “premaster secret”.

Llaves de sesión creadas: Tanto el cliente cuanto el servidor generan llaves de sesión a partir del “client random”, el “server random”, y el “premaster secret” estro. Deberían llegar a los mismos resultados.

El cliente está listo: El cliente envía un mensaje "finished", el cual está encriptado con una llave de sesión.

El servidor está listo: El servidor envía un mensaje "finished" encriptado con una llave de sesión. Se logra un encriptado simétrico seguro: Se completa el handshake, y la comunicación continúa utilizando las llaves de sesión.

Anotar el flujo y el proceso exactos del handshake dependen de la versión de SSL/TLS, como de l suite de encriptación seleccionada. El flujo descrito corresponde a la versión TLS 1.2, y utiliza una negociación de llaves basada en RSA en lugar de Diffie-Helman.

Fuentes:

https://datatracker.ietf.org/doc/html/rfc5246

El campo de cabecera "Server" contiene información sobre el software utilizado por el servidor de origen para manejar la petición, los cuales los clientes frecuentemente utilizan para ayudar a identificar el alcance sobre problemas de interoperabilidad reportados, para solucionar o adaptar peticiones para evitar limitaciones particulares del servidor, y para análisis sobre el uso del servidor o del sistema operativo. Un servidor de origen PUEDE generar un campo de cabecera del servidor en sus respuestas.

curl se utiliza en líneas de comando o guiones (scripts) para transferir datos. curl también se utiliza en automóviles, televisores, encaminadores, impresoras, equipos de audio, teléfonos móviles, tabletas, dispositivos médicos, decodificadores, juegos de computadora, reproductores multimedia, siendo el motor de transferencia de Internet para miles de aplicaciones de software en más de veinte mil millones de instalaciones.

Para el siguiente ejemplo se utiliza un archivo conteniendo las URLs a ser evaluadas. El formato de las URLs, en el archivo es el siguiente:

url = www .domino .gob

Se ejecuta curl para realizar peticiones a diversos servidores y obtener sus cabeceras.

La opción “-s” es el modo silencioso. No muestra el progreso o mensajes de error. Silencia a curl. Pero muestra los datos consultados.

La opción “--head” para obtiene únicamente las cabeceras de respuesta. El método HEAD correspondiente a HTTP obtiene únicamente la cabecera del documento.

La opción “-K” especifica un archivo de texto desde el cual curl leerá argumentos.

$ curl -s --head -K serversgobpe.txt

Los resultados obtenidos son bastante detallados. Pero si el propósito es únicamente listar información de la cabecera server, es factible filtrarlos con el comando grep.

$ curl -s --head -K serversgobpe.txt | grep -i server:

De hecho también es factible modificar el anterior comando ejecutado para mostrar el servidor web con su correspondiente cabecera “Server”.

La cabecera Server indica el servidor web más mas cercano al usuario final. Server puede frecuentemente ser impactado por servidores proxy en capa de aplicación, u otros sistemas en la infraestructura de la aplicación.

Fuentes:

https://www.rfc-editor.org/rfc/rfc9110.html
https://curl.se/