blog

Content Security Policy (CSP), es una política declarativa de listas permitidas las cuales se aplican a través de la cabecera de respuesta Content-Security-Policy, o un elemento equivalente. Permite a los desarrolladores restringir las fuentes desde las cuales se cargan recursos como JavaScript, CSS, imágenes, archivos, etc. CSP es una técnica eficaz para defensa en profundidad, y de esta manera mitigar el riesgo de vulnerabilidades como Cross Site Scripting (XSS) y Clickjacking.

La Política de Seguridad de Contenidos soporta directivas, las cuales permiten un control granular del flujo de las políticas.

Utilizando el comando curl, se procede a obtener y revisar la cabecera o el elemento meta, para identificar inadecuadas configuraciones.

$ curl -s --head https:// www. xyz .com

Para evaluar por inadecuadas configuraciones en CSP, se busca por configuraciones inseguras examinando la cabecera de respuesta “Content-Security-Policy”, o el elemento meta.

• unsafe-inline Esta directiva permite scripts o estilos en linea, lo cual genera las aplicaciones sean susceptibles a ataques XSS.
• unsafe-eval Esta directiva permite el uso de eval() en la aplicación, además es susceptible a técnicas comunes de evasión, como inyección URL de datos.
• unsafe-hashes Esta directiva permite el uso de scripts/estilos en línea, asumiendo coincidan con los hashes especificados.
• Recursos como scripts pueden ser permitidos de ser cargados desde cualquier origen mediante la utilización del comodín (*) source.
  • También considerar comodines basados en coincidencias parciales, como: https: //* o *.cdn. com.
  • Considerar si las fuentes listadas permitidas proporcionan JSONP de puntos final, lo cual podría ser utilizado para evadir CSP o la política del mismo origen.

Se sugiere configurar una política fuerte para seguridad de contenidos, la cual reduzca la superficie de ataque de la aplicación. Los desarrolladores pueden verificar la fortaleza de la política para seguridad de contenidos mediante herramientas en línea como Google CSP Evaluator.

Fuentes:

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
https://csp-evaluator.withgoogle.com/

La función HTTP Strict Transport Security (HSTS) permite un servidor web informe al navegador del usuario, a través de una cabecera de respuesta especial, nunca debe establecer una conexión HTTP no cifrada con los servidores de dominio especificados. En lugar de esto, debería establecer automáticamente todas las peticiones de conexión para acceder hacia el sitio a través de HTTPS. Esto también evita los usuarios anulen los errores del certificado.

Considerando la importancia de este mecanismo de seguridad, es prudente verificar el sitio esté utilizando esta cabecera HTTP para garantizar todos los datos viajen encriptados entre el navegador web y el servidor.

El encabezado de seguridad de transporte estricto HTTP utiliza tres directivas específicas:

• max-age: para indicar la cantidad de segundos en los cuales el navegador debe convertir automáticamente todas las peticiones HTTP hacia HTTPS.
• includeSubDomains: para indicar todos los subdominios relacionados deben usar HTTPS.
• preload No oficial: para indicar los dominios están en la lista de precarga y los navegadores nunca deben conectarse sin HTTPS. Si bien esto es compatible con todos los principales navegadores, no es una parte oficial de la especificación.

A continuación se presenta un ejemplo de la implementación del encabezado HSTS:

$ curl -s –head https:// www. xyz. pe

Se debe verificar la presencia de este encabezado, pues su ausencia podría generar problemas de seguridad como:

• Los atacantes interceptan y acceden a información transferida a través de un canal de red no cifrado.
• Atacantes realizan ataques para manipulación en el medio (MITM), aprovechándose de los usuarios aceptando certificados los cuales no son de confianza.
• Usuarios ingresando por error una dirección en el navegador usando HTTP en lugar de HTTPS, o usuarios haciendo clic en un enlace correspondiente a una aplicación web utilizando incorrectamente el protocolo HTTP.

Se confirma la presencia de la cabecera HSTS examinando la respuesta desde el servidor.

Fuentes:

https://https.cio.gov/hsts/
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transp…

WhatWeb identifica sitios web. Su meta es responder a la pregunta "¿Qué es ese sitio web?". WhatWeb reconoce las tecnologías web, incluyendo los sistemas para administración de contenido (CMS), plataformas para blogs, paquetes para estadísticas/análisis, librerías JavaScript, servidores web, y dispositivos incorporados. WhatWeb tiene más de 1,800 complementos, cada uno para reconocer algo diferente. WhatWeb también identifica números de versión, direcciones de correo electrónico, ID de cuenta, módulos de framework web, errores SQL, y más.

WhatWeb puede ser sigiloso y rápido, o minucioso pero lento. WhatWeb admite un nivel de agresión para controlar el equilibrio entre velocidad y fiabilidad. Cuando visita un sitio web en su navegador, la transacción incluye muchos indicios sobre cuales tecnologías web están impulsando este sitio web. Algunas veces, una sola visita hacia una página web contiene suficiente información para identificar el sitio web, pero cuando no es así, WhatWeb puede interrogar más al sitio web. El nivel predeterminado de agresión, llamado "sigiloso", es el más rápido y requiere solo una petición HTTP de un sitio web. Esto es adecuado para escanear sitios web públicos. Se han desarrollado modos más agresivos para su uso en pruebas de penetración.

La mayoría de los plugins de WhatWeb son completos y reconocen una diversidad de señales, desde sutiles hasta obvias. Por ejemplo la mayoría de los sitios web de WordPress se pueden identificar mediante la etiqueta meta HTML, p. '', pero una minoría de sitios web de WordPress elimina esta etiqueta de identificación, pero esto no frustra a WhatWeb. El plugin de WhatWeb para WordPress tiene más de 15 pruebas, las cuales incluyen verificar el favicon, archivos de instalación predeterminados, páginas de inicio de sesión, y verificar "/ wp-content /" dentro de los enlaces relativos.

Al ejecutar la herramienta whatweb con la opción “-h”, se muestra un resumen de sus principales opciones.

$ whatweb -h

El modo más simple para escanear un sitio web es simplemente definiéndolo.

$ whatweb https:// cee xxxx.pe

Se escanean dos sitios web con descripciones verbosas de los plugins

$ whatweb -v https:// xxxx.pe https:// xxxx.pe

La opción “-v“ genera verbosidad incluyendo las descripciones de los plugins. Utilizar dos veces para depuración.

Dado el hecho se han definido dos sitios web a escanear, se presenta la información obtenida del segundo sitio web de manera secuencial.

Se procede a ejecutar un un escaneo agresivo.

$ whatweb -a 3 https:// xxxx .pe/

La opción “-a” controla los niveles de agresión, una compensación entre velocidad/sigilosidad y fiabilidad. El número “3” implica si un plugin de nivel 1 coincide, se realizarán peticiones adicionales.

Es factible con whatweb escanear una red rápidamente suprimiendo los mensajes de error.

$ whatweb --no-errors 137.116.79.103/24

La opción “--no-errors” suprime los mensajes de error.

Entre la información obtenida de todos los escaneos realizados se tienen; país, tecnologías utilizada y sus versiones, direcciones IP, título, cabeceras poco comunes, mensajes de error, cabeceras HTTP, códigos HTTP, redirecciones, correos electrónicos, sistema operativo y su versión, versión SSL/TLS, métodos HTTP soportados, entre otros elementos.

Esta información es muy importante para tratar de obtener una huella digital sobre los componentes utilizados por las aplicaciones web.

Fuentes:

https://github.com/urbanadventurer/WhatWeb
https://www.morningstarsecurity.com/research/whatweb

El Spider o “Araña” es una herramienta la cual se utiliza para descubrir automáticamente nuevos recursos (URLs) en un sitio particular. Inicia con una lista de URLs a visitar, denominadas semillas, lo cual depende de como se inicie el Spider. Luego el Spider visita estas URLs, identificando todos los hipervínculos en la página, para luego agregarlos a la lista de URLs a visitar , continuando el proceso de manera recursiva, siempre se encuentren nuevos recursos.

El Spider puede ser configurado e iniciado utilizando el recuadro de diálogo “Spider”.

Durante el procesamiento de una URL, El Spider realiza una petición para obtener el recurso, para luego analizar la respuesta, identificando así los hipervínculos. Actualmente tiene el siguiente comportamiento al procesar tipos de respuestas:

El Spider es configurado utilizando la Pantalla de Opciones del Spider.

HTML

Procesa etiquetas específicas, identificando enlaces hacia nuevos recursos:

• Base - Manejo adecuado
• A, Link, Area, Base - atributo 'href'
• Applet, Audio, Embed, Frame, IFrame, Input, Script, Img, Video - atributo 'src'
• Blockquote - atributo 'cite'
• Meta: 'http-equiv' para 'location', 'refresh' y 'Content-Security-Policy', 'name' para 'msapplication-config'
• Applet - 'codebase', atributos de 'archive'
• Img - Atributos 'longdesc', 'lowsrc', 'dynsrc', 'srcset'
• Isindex - atributo 'action'
• Object - 'base de código', atributos 'data'
• Param - atributo 'value'
• Svg: atributos 'href' y 'xlink:href' de los elementos 'image' y 'script'
• Table - atributo 'background'
• Video - atributo 'poster'
• Form: manejo adecuado de formularios con el método GET y POST. Los valores de los campos se generan de forma válida, incluidos los tipos de entrada de HTML 5.0 'form', 'formaction', 'formmethod', y los atributos de botones también son respetan.
• Comentarios: etiquetas válidas encontradas en comentarios también se analizan, si se especifican en la pantalla de opciones del Spider.
• Import - atributo de 'implementation'
• Inline string: etiquetas 'p', 'title', 'li', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6' y 'blockquote'

Archivo robots.txt

Si se configura en la pantalla de Opciones del Spider, también analiza el archivo 'Robots.txt', y se intenta identificar nuevos recursos utilizando las reglas especificadas. Cabe mencionar el Spider no sigue las reglas especificadas en el archivo 'Robots.txt'.

Archivo sitemap.xml

Si se configura en la pantalla de Opciones del Spider, el Spider también analiza el archivo 'sitemap.xml' e intenta identificar nuevos recursos.

Archivos metadatos SVN

Si se configura en la pantalla de Opciones del Spider, el Spider también debe interpretar los archivos de metadatos SVN e intentar identificar nuevos recursos.

Archivos metadatos Git

Si se configura en la pantalla de Opciones del Spider, el Spider también debe interpretar los archivos de metadatos de Git e intentar identificar nuevos recursos.

Archivos .DS_Store

Si se configura en la pantalla de Opciones del Spider, el Spider también debe interpretar archivos .DS_Store e intentar identificar nuevos recursos.

Archivos Atom OData

El Spider también debe interpretar los archivos .DS_Store, e intentar identificar nuevos recursos. El contenido de OData utilizando el formato Atom es actualmente soportado. Se procesan todos los enlaces incluidos (relativos o absolutos).

Archivos SVG

Los archivos de imagen SVG se analizan para identificar los atributos HREF y extraer/resolver cualquier enlace contenido.

Respuesta de Texto No HTML

Las respuestas de texto se analizan analizando el patrón de URL

Respuesta No Texto

Las respuestas de texto se analizan analizando el patrón de URL. Actualmente, el Spider no procesa este tipo de recursos.

Otros Aspectos

• Cuando se verifica si una URL ya se visitó, el comportamiento en relación a como se manejan los parámetros, se puede configurar en la pantalla de Opciones del Spider.
• Cuando se verifica si una URL ya se visitó, existen algunos parámetros comunes los cuales se ignoran: jsessionid, phpsessid, aspsessionid, utm_*
• El comportamiento del Spider con respecto a las cookies, depende de cómo se inicia el Spider y cuales opciones están habilitadas. Para obtener más detalles, consulte la pantalla Opciones de lSpider.

Fuentes:

https://www.zaproxy.org
https://www.zaproxy.org/docs/desktop/addons/spider/

human.txt es una iniciativa para conocer a las personas quienes están detrás de un sitio. Toma la forma de un archivo de texto contiendo información sobre las diferentes personas quienes han contribuido con la construcción del sitio. Este archivo frecuentemente;pero no siempre; contiene información relacionada con la carrera o sitios/rutas laborales.

El archivo "humans.txt" puede ser visualizado directamente a través de un navegador web, o ser descargado, para luego ser visualizado.

El archivo puede estar presente en la raíz del servidor web o en el directorio de nombre /.well-known/

https:// example. com/humans.txt

Entre la información obtenida se incluyen los nombres completos de personas laborando para la organización, incluyendo su cargo. Como también detalles precisas sobre las tecnologías web utilizadas para el sitio web.

Existen varias razones por las cuales esto podría ser de interés en los escenarios de prueba, incluyendo:

• Recopilación de inteligencia desde fuentes abiertas
• Reconocimiento y Mapeo de la aplicación web
• Ataques de ingeniería social

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…

“Cuando los riesgos de seguridad en servicios web son descubiertos por investigadores independientes en seguridad, quienes comprenden la severidad del riesgo, frecuentemente carecen de los canales para exponerlos adecuadamente. Como resultado de esto, los problemas de seguridad pueden quedar sin ser reportados. security.txt define un estándar para ayudar a las organizaciones a definir el proceso para los investigadores de seguridad divulguen las vulnerabilidades de seguridad de manera segura”.

Los archivos security.txt han sido implementados por Google, Facebook, GitHub, gobierno del Reino Unido y muchas otras organizaciones. Además, el Ministerio de Justicia del Reino Unido, la Agencia de Seguridad de Infraestructura y Ciberseguridad (EE. UU.), el gobierno francés, el gobierno italiano, el gobierno holandés y el Centro de Seguridad Cibernética de Australia respaldan el uso de archivos “security.txt”.

El archivo “security.txt” puede ser visualizado directamente a través de un navegador web, o ser descargado, para luego ser visualizado.

El archivo puede estar presente en la raíz del servidor web o en el directorio de nombre /.well-known/

https:// example. com/security.txt
https:// example. com/.well-known/security.txt

Existen múltiples razones por las cuales esto podría ser de interés en los escenarios de prueba, incluyendo:

• Identificar rutas o recursos adicionales para incluir en el descubrimiento/análisis
• Recopilación de inteligencia desde fuentes abiertas
• Encontrar información sobre Bug Bounties, etc
• Ingeniería social

Fuentes:

https://securitytxt.org/
https://www.rfc-editor.org/rfc/rfc9116.html
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…

Desde Nikto 2.1.2 los plugins puede ser seleccionados individualmente, además de ser factible definir directamente parámetros.

Una cadena para la selección de plugins puede ser pasada a través de la línea de comandos, utilizando el parámetro “-Plugin”. Está constituida de una lista de nombres de plugins separados por punto y coma, incluyendo los parámetros de opción entre paréntesis.

La opción “-list-plugins” mostrará los nombres de los plugins y parámetros.

$ nikto -list-plugins

Para la siguiente demostración se utiliza el plugin de nombre “headers” incluido en Nikto2, el cual realizará varias verificaciones contra las cabeceras devueltas desde una petición HTTP.

$ nikto -host 192.168.0.82 -port 80,443,5800,5985 -Plugin headers

La opción “-host” define la dirección IP o nombre de host a escanear

La opción “-port” define el puertos o puertos a escanear separados por comas.

La opción “-Plugin” define la cadena de plugins seleccionados a ejecutar

Para la presente demostración se ha definido el escaneo de cuatro puertos TCP, en los cuales Nmap identifico previamente servicios HTTP.

Finaliza la ejecución de Nikto2 y el plugin “headers”, en los resultados se encuentra información sobre versiones del servidor web, módulos y sus versiones, cabeceras no definidas, información sobre SSL, redirecciones, o algún tema relevante desde la perspectiva de la ciberseguridad.

Aunque la información expuesta por el servidor no es necesariamente en sí misma una vulnerabilidad, es información la cual puede ayudar a los ciberatacantes a explotar otras vulnerabilidades existentes. Esta información también puede llevar a los ciberatacantes a encontrar vulnerabilidades específicas sobre la versión del servidor.

Fuentes:

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

Este script correspondiente al motor para scripts de Nmap, utiliza la cabecera del servidor HTTP, por la información faltante de versión. Actualmente es inviable con las pruebas de versión, debido a la necesidad de hacer coincidir correctamente los servicios no siendo HTTP.

Se procede primero a realizar un escaneo de versión con Nmap, utilizando la opción “-sV”, especificando únicamente los puertos a escanear con la opción “-p”

$ sudo nmap -p21,25,53,80,110,135,443,445,3306,3389,5800,5900,5985,49667,49669,49671 -sV 192.168. 0.82

De hecho Este escaneo de versión realiza un buen trabajo para identificar el servicio correcto, como también los detalles sobre su correspondiente versión.

Se procede a utilizar el script de nombre “http-server-header”.

$ sudo nmap -p21,25,53,80,110,135,443,445,3306,3389,5800,5900,5985,49667,49669,49671 -sV --script http-server-header 192.168 .0.82

Se concentra la atención sobre todo en los servicios HTTP, pues este script; como todos los incluidos con Nmap, son ejecutados en base al cumplimiento de ciertas condiciones.

Se verifica como la información obtenida por el escaneo de versión de Nmap, cuanto por el script de nombre “http-server-header”, son similares.

Aunque esta información expuesta por el servidor no es necesariamente en si misma una vulnerabilidad, es información la cual puede ayudar a los ciberatacantes a explotar otras potenciales vulnerabilidades existentes.

Fuente:

https://nmap.org/nsedoc/scripts/http-server-header.html

Web shells o “shells vía web” son los scripts (guiones), los cuales están programados en diversos lenguajes de programación; como PHP, Python, ASP, Perl, etc. Se utilizan comúnmente como puerta traseras para obtener acceso no autorizado en cualquier servidor, cargándolo en el servidor web.

Un ciberatacante puede realizar directamente la operación de lectura y escritura una vez la puerta trasera es cargada en el servidor, pudiendo editar cualquier archivo o eliminar el archivo. Kali Linux incluye una colección de webshells para servidores ASP, ASPX, CFM, JSP, Perl, y PHP, los cuales están ubicados en el directorio “/usr/share/webshells”.

$ tree /usr/share/webshells/

Para ejemplificar algunos de los shells, se visualiza un webshell simple escrito en PHP.

$ cat /usr/share/webshells/php/simple-backdoor.php

Esta archivo debe ser copiado hacia un directorio factible de ser accedido por el ciberatacante. Esto puede ser realizado explotando una vulnerabilidad, mala configuración, o cualquier otro escenario

http://192.1 68.0.70:8585/simple-backdoor.php ?cmd=set

Tener en consideración; los comandos remotos vía web serán ejecutado con los privilegios del usuario con el cual se ejecuta el servidor o la aplicación web.

Fuentes:

https://www.kali.org/tools/webshells/
https://gitlab.com/kalilinux/packages/webshells
https://github.com/0waizKhan/Kali-Webshells

GNU MAC Changer es una utilidad para facilitar la manipulación de las direcciones MAC correspondientes a las interfaces de red. Las direcciones MAC son identificadores únicos en las redes, solo necesitan ser únicos, pudiéndose cambiar en la mayoría de hardware para redes. Las direcciones MAC han comenzado a ser abusadas por empresas de marketing sin escrúpulos, agencias gubernamentales, y otros organismos, para proporcionar una manera fácil de rastrear una computadora a través de múltiples redes. Al cambiar la dirección MAC con regularidad, este tipo de seguimiento se puede frustrar o, al menos dificultarlo.

Entre sus principales características se tienen:

• Establecer una dirección MAC específica para una interfaz de red
• Configurar un MAC aleatoriamente
• Establecer un MAC de otro proveedor
• Establecer otra MAC del mismo proveedor
• Configure un MAC del mismo tipo (por ejemplo: tarjeta inalámbrica)
• Mostrar una lista MAC de proveedores (más de 6200 elementos) para elegir

La opción “-h” de la herramienta macchanger muestra un resumen de sus principales opciones.

$ sudo macchanger -h

Para obtener un listado de los proveedores conocidos se utiliza la opción “-l”

$ sudo macchanger -l

Aunque la herramienta permite visualizar la dirección MAC actual utilizando la opción “-s”, se utiliza el comando “ip” para obtener esta información

$ ip link

Ahora se procede a cambiar la dirección MAC por una del proveedor ATARI CORPORATION.

$ sudo macchanger eth0 --m 00:00:36:12:34:56

La opción “-m” permite definir la nueva dirección MAC.

Se visualiza el cambio de la dirección MAC ha sido realizada exitosamente.

También es factible utilizar la opción “-b” para pretender ser la dirección MAC “de fabrica”.

Fuentes:

https://github.com/alobbs/macchanger
https://linux.die.net/man/8/ip