blog

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/

El método OPTIONS permite rápidamente preguntar a los servidores comuniquen sus métodos soportados. Aunque los métodos GET y HEAD se espera sean soportados, como los estándares sugieren su soporte es requerido, los otros métodos no necesitan ser soportados. Si el servidor receptor soporta el método OPTIONS, responde con la lista de los métodos soportados en la cabecera de repuesta Allow HTTP.

curl es herramienta de línea de comandos y una biblioteca para transferir datos con URL. Se utiliza en líneas de comando o guiones (scrtips) 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 y es el motor de transferencia de Internet para miles de aplicaciones de software en más de veinte mil millones de instalaciones. curl es utilizado a diario por prácticamente todos los usuarios de Internet en el mundo.

Se utiliza la opción “--help” para obtener una ayuda de sus comandos disponibles.

$ curl --help

Esta no es la ayuda completa, esto está dividido en categorías. Para obtener una descripción general de todas las categorías se utiliza la opción “--help category”.

$ curl –help category

Se procede a utilizar la herramienta curl para realizar una petición utilizando el método OPTIONS.

$ curl -i -X OPTIONS concytec. gob. pe
$ curl -i -X OPTIONS minsa. gob. pe

La opción “-i”, para HTTP y FTP incluye las cabeceras de respuesta en el resultado.

La opción “-X” cambia el método utilizado cuando se inicia la transferencia.

Como se puede visualizar en los resultados correspondientes a las dos peticiones realizadas, los métodos soportados son mostrados en la cabecera de nombre “Allow:”

Si se realizar una petición a métodos no soportados, el servidor responderá con un código de estado “405 Method Not Allowed”

Fuentes:

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

El protocolo de transporte QUIC tiene varias características deseables en un transporte para HTTP, como multiplexación de flujo, control de flujo por flujo, y establecimiento de conexión con baja latencia.

Introducción

La semántica HTTP se utiliza para una amplio rango de servicios en Internet. Esta semántica se ha utilizado más comúnmente con HTTP/1.1 y HTTP/2. HTTP/1.1 se ha utilizado en una variedad de capas de transporte y sesión, mientras HTTP/2 se ha utilizado principalmente con TLS sobre TCP. HTTP/3 admite la misma semántica a través de un nuevo protocolo de transporte: QUIC.

Versiones anteriores de HTTP

HTTP/1.1 utiliza campos de texto delimitados por espacios en blanco para transmitir mensajes HTTP. Aunque estos intercambios son legibles por los humanos, utilizar espacios en blanco para formatear mensajes conduce a una complejidad para interpretación, además de una tolerancia excesiva de comportamiento variante.

Debido a HTTP/1.1 no incluye una capa para multiplexación, múltiples conexiones TCP son utilizadas frecuentemente para atender solicitudes en paralelo. Sin embargo esto tiene un impacto negativo para el control de la congestión y la eficiencia de la red, pues TCP no comparte el control de la congestión entre múltiples conexiones.

HTTP/2 introdujo una capa de multiplexación y encuadre binario para mejorar la latencia sin modificar la capa de transporte. Sin embargo debido a la naturaleza paralela de la multiplexación en HTTP/2 no es visible en los mecanismos para recuperación de pérdidas de TCP, un paquete perdido o reordenado causa todas las transacciones activas experimenten un bloqueo, independientemente de si esa transacción se vio directamente afectada por el paquete perdido.

Delegación en QUIC

El protocolo de transporte QUIC incorpora multiplexación de flujo y control de flujo por flujo, similar al proporcionado por la capa de entramado de HTTP/2. Al proporcionar confiabilidad a nivel de flujo y control de congestión en toda la conexión, QUIC tiene la capacidad de mejorar el rendimiento de HTTP en comparación con un mapeo TCP. QUIC también incorpora TLS 1.3 en la capa de transporte, ofreciendo confidencialidad e integridad comparables con la ejecución de TLS sobre TCP, con la latencia de configuración de conexión mejorada de TCP Fast Open.

Descripción general del protocolo HTTP/3

HTTP/3 proporciona un transporte para la semántica HTTP utilizando el protocolo de transporte QUIC, además de una capa de estructura interna similar a HTTP/2.

Una vez el cliente conoce existe un servidor HTTP/3 en un determinado endpoint, abre una conexión QUIC. QUIC proporciona negociación de protocolos, multiplexación basada en flujos y control de flujo.

Dentro de cada flujo, la unidad básica de comunicación HTTP/3 es una trama. Cada tipo de trama sirve para propósitos diferentes. Por ejemplo las tramas HEADERS y DATA forman la base para las peticiones y respuestas HTTP. Las tramas aplicadas a toda la conexión se transmiten en un flujo de control dedicado.

La multiplexación de peticiones se realiza utilizando la abstracción de flujo QUIC. Cada par de petición-respuesta consume un único flujo QUIC. Las transmisiones son independientes entre si, por lo cual una transmisión bloqueada o la cual sufrió una pérdida de paquetes, no impide el progreso de otras transmisiones.

La inserción del servidor es un modo de interacción introducido en HTTP/2, la cual permite a un servidor enviar un intercambio de petición-respuesta hacia un cliente antes de el cliente realice la petición indicada. Esto compensa el uso de la red con una posible ganancia de latencia. Se utilizan varios tramas HTTP/3 para administrar la inserción del servidor, como PUSH_PROMISE, MAX_PUSH_ID y CANCEL_PUSH.

Al igual de HTTP/2, los campos de petición y respuesta se comprimen para su transmisión. Debido a HPACK se basa en la transmisión ordenada de secciones de campos comprimidos (una garantía no proporcionada por QUIC), HTTP/3 reemplaza HPACK con QPACK. QPACK utiliza flujos unidireccionales separados para modificar y rastrear el estado de la tabla de campos, mientras las secciones de campos codificados se refieren al estado de la tabla sin modificarla.

Fuentes:

https://httpwg.org/specs/rfc9114.html

HTTP/2 reemplaza la forma sobre como HTTP se expresa "en el cable". No se trata de una nueva escritura radical del protocolo; Los métodos HTTP, los códigos de estado, y la semántica son los mismos, como consecuencia debería ser posible utilizar las mismas API como en HTTP/1.x (posiblemente con algunas pequeñas adiciones) para representar el protocolo.

El enfoque del protocolo está en el desempeño; específicamente la latencia percibida por el usuario final, el uso de recursos de red y del servidor. Uno de los objetivos principales es permitir la utilización de una única conexión desde los navegadores hacia un sitio web.

La base del trabajo fue SPDY, pero HTTP/2 ha evolucionado para tener en consideración los aportes de la comunidad, incorporando varias mejoras en el proceso.

Se sugiere consultar el sitio web oficial para obtener más detalles sobre el alcance del trabajo, así como las preguntas frecuentes.

También se sugiere leer HTTP/2 JP, mantenido por la comunidad japonesa HTTP/2.

HTTP/2 se compone de dos especificaciones:

• Protocolo de transferencia de hipertexto versión 2 - RFC9113
• HPACK - Compresión de encabezado para HTTP/2 - RFC7541

Se realizan seguimientos de las implementaciones conocidas de HTTP/2, las cuales pueden ser encontradas en la wiki oficial del proyecto.

Fuentes:

https://http2.github.io/
https://httpwg.org/specs/rfc9113.html
https://httpwg.org/specs/rfc7541.html