Archivo de la etiqueta: https

Podcast – 31 – Denegación de servicio vía HTTP

En el capítulo de hoy hablaremos de las diferentes maneras en la que se puede producir un ataque de denegación de servicio a una página o servicio web usando el propio protocolo HTTP/HTTPS. Aunque es muy probable que en un ataque real se utilicen diferentes técnicas de forma simultánea, incluyendo diferentes protocolos con el objetivo de evitar las diferentes medidas de protección, en este capítulo hablaremos de un ataque puramente web.

Micro con feed

Fuente imagen:PerfectYourPodcast

Empecemos por las bases. El protocolo HTTP (HyperText Transfer Protocol) tiene tres métodos de solicitud de información en las peticiones del cliente al servidor:

  1. El método HEAD (cabecera) sirve para el cliente solicite información básica sobre una web en concreto, pero no la página en sí. Se pensó en una época de recursos muy limitados para que el cliente supiera a qué atenerse (tamaño, velocidad, etc.) antes de descargar realmente el contenido. Hoy en día es el método menos usado. Tanto las peticiones como las respuestas son ligeras.
  2. El método GET es el más habitual en la navegación: el cliente solicita un recurso y el servidor se lo entrega. El cliente envía una petición pequeña (tan sólo una cadena de texto con el URI del recurso que solicita) mientras que el servidor puede enviar una gran cantidad de información (texto HTML, imágenes. audios o incluso vídeos). La aparición de las aplicaciones web dinámicas ha hecho que en las URL de las peticiones se puedan añadir variables y parámetros que el servidor debe analizar y gestionar para modificar su respuesta en función de estos. Así nos encontramos con una petición ligera, pero con una respuesta por parte del servidor que puede, o no, ser muy pesada (tanto por tamaño de la información como por los recursos de memoria y cálculo necesarios para generarla). Se trata del método de petición más habitual.
  3. El método POST permite el envío de información desde el cliente al servidor. Sería el método utilizado para enviar la información rellenada en un formulario hacia el servidor: un ejemplo sería que al escribir un comentario en un blog el texto es enviado mediante este tipo de petición a una dirección concreta del blog para que lo trate. Lo mismo pasa cuando adjuntamos un archivo a nuestro webcorreo: el archivo adjunto viaja en una petición POST desde nuestro navegador al servidor web. En esta comunicación nos encontramos con una petición que puede ser pesada (dependerá de la información que queramos enviar) y cuya respuesta directa suele ser ligera (una confirmación de la recepción) pero que puede implicar un procesamiento elevado en la parte del servidor (pensad en los conversores de formatos de audio, vídeo, etc. que hay en Internet).

Tras este rápido repaso a los métodos de petición definidos en el protocolo HTTP y, teniendo en cuenta que lo que queremos es saturar una aplicación web de tal forma que la dejemos inaccesible de cara a los usuarios legítimos veremos qué tipos de ataques de denegación de servicio, puramente web, podemos realizar.

Tipos de ataques de denegación de servicio usando HTTP

Saturación de su línea de datos

Se trataría del ataque de denegación de servicio más tradicional y que requiere menos conocimientos técnicos.
Uno de los recursos limitados que tiene cualquier servicio web es su ancho de banda disponible para sus usuarios. Cualquier petición debe llegar desde los clientes hasta los servidores web utilizando una línea de comunicaciones, por lo que el envío de peticiones HTTP de gran tamaño o bien que generen un gran tamaño en su respuesta puede hacer que el servicio quede inaccesible.
Tradicionalmente se solía lanzar múltiples conexiones de tipo POST con una gran cantidad de información de tal forma que se pudiera saturar la conexión a Internet de los servidores. Otra forma sería realizar peticiones GET a un recurso muy pesado (un vídeo, por ejemplo) de forma que se envié muchas veces llegando a saturar su propia línea.
Como veis se trata de conseguir atascar la conexión a Internet de la aplicación web a base de generar un gran volumen de tráfico. Las tecnologías “cloud” dificultan la posibilidad de saturación de un punto único por lo que son una gran defensa frente a este tipo de ataques de fuerza bruta. Los sistemas de caché permiten la distribución de elementos no dinámicos de forma eficiente y distribuida por lo que se reducirían las posibilidades de saturación.

Saturación de los servidores

Error de servidor no disponible.

Error de servidor no disponible. Fuente imagen: eHost.com

Cambiamos el enfoque a intentar dejar inoperativos los propios servidores web. Para ello intentaremos realizar peticiones, ya sean GET o POST, que impliquen una gran carga de trabajo en el servidor. Se trata de dejarlos sin memoria o capacidad de cálculo de forma que dejen de responder a peticiones legítimas. Probablemente el ejemplo que hemos indicado antes de los conversores de formato de audio online que hemos comentado antes sea perfecto para este punto: un atacante podría solicitar muchas veces la conversión de un audio muy largo (para maximizar el consumo de su petición) de tal forma que llegue a dejar sin recursos al sistema que se verá forzado a ignorar peticiones legítimas. Este tipo de ataque requiere un mínimo de análisis de la aplicación web a atacar para descubrir cuál sería el proceso que más consume y actuar sobre él.
El reparto de trabajo entre diferentes servidores web de una misma granja permite minimizar la exposición de este tipo de ataques (ya que al aumentar la capacidad de cálculo obliga al atacante a incrementar su esfuerzo) y hoy en día la capacidad de crecimiento dinámico, y automatizado, de las plataformas cloud dificultan seriamente este tipo de ataques, aunque el hecho de que luego haya que pagar al proveedor “cloud” por el número de servidores, memoria o CPU usadas puede hacer que el hecho de aguantar el ataque y dar servicio a sus clientes no sea económicamente rentable a corto plazo. Por esto generalmente las aplicaciones web tienen una capacidad de crecimiento limitadas.

Saturación de sus propias defensas

En este escenario buscaríamos que al activar las propias defensas antidenegación (anti-DDoS, IPS, etc.) se agravara el problema o, en el caso más elaborado, se enmascarase el verdadero ataque a la aplicación web. Los sistemas IPS que analizan el tráfico HTTP deben mantener una serie de sesiones para confirmar el correcto funcionamiento y la legitimidad del tráfico por lo que también son susceptibles de ser saturados. Cuando un IPS es saturado puede generar una sobrereacción que bloquee todo el tráfico web (consiguiendo una denegación de servicio autoinflingida) o bien activar un modo pasivo donde el sistema deja de analizar el tráfico al no poder gestionarlo. Si se llega a este segundo comportamiento un atacante malicioso podría utilizar esta ventana para lanzar inyecciones SQL o exfiltrar información sin ser detectado entre todo el tráfico malicioso ‘común’. Este comportamiento puede agravarse si tratamos con tráfico seguro (HTTPS) donde el servidor IPS deba descifrar y recifrar el tráfico para poder analizarlo, consumiendo una mayor cantidad de recursos propios. Así pues, un correcto dimensionamiento de estos sistemas de defensa es muy importante.

Podcast – 31 – Denegación de servicio vía HTTP

Podcast – 24 – HTTPS

Tras explicar en los últimos capítulos la composición de los certificados digitales y analizar el caso específico de la autoridad de certificación Let’s Encrypt, hoy hablaremos sobre el uso más conocido de estos certificados: la navegación segura mediante HTTPS. Ya comentamos antes que una de las primeras recomendaciones de seguridad es no introducir usuarios o contraseñas en páginas web que no estén cifradas (hay que mirar el candadito en la barra de navegación).

protocolo http/https

Navegación segura con HTTPS.
Fuente imagen: MineHeros

Antes de entrar en el funcionamiento exacto de HTTPS, hablemos un poco de criptografía. Sin entrar en detalles podemos decir que hay dos grandes bloques de sistemas de cifrado: los de clave simétrica (donde se utiliza la misma clave para cifrar y descifrar) y los de clave asimétrica (donde hay dos claves diferentes: una para cifrar y otra para descifrar). Dentro de los algoritmos asimétricos, destacamos la criptografía de clave pública. Estos algoritmos tienen la característica de que una de las claves es pública y la conoce todo el mundo, y aún así es computacionalmente imposible obtener la otra clave (privada). En nuestro caso, el navegador del usuario podría utilizar la clave pública del servidor (que está disponible en el certificado X.509) para enviar información que sólo pueda ser leída por el servidor web (que tendrá la clave privada para descifrar el mensaje enviado).

Diffie-Hellman es un protocolo, que coge el nombre de los apellidos de sus dos autores, que permite generar una clave común para los dos interlocutores (navegador y servidor web) a partir de unos parámetros iniciales. Una vez se haya acordado la clave simétrica que usarán para esa conexión ya puede empezar la transferencia de inforamción de forma confidencial.

Funcionamiento de HTTPS

Micro con feed

Fuente imagen:PerfectYourPodcast

Cuando un navegador acceder a una página web (por ejemplo el securizando.com), el servidor le suele redirigir, si está disponible, a la versión HTTPS. El navegador se descarga el certificado público de la web y lo utiliza para cifrar la siguiente comunicación cliente>servidor. De esta forma únicamente el servidor puede leer la información enviada. ¿Qué se envía? Pues los parámetros de inicio del protocolo Diffie-Hellman para la generación de una clave simétrica.

Repasando:

  1. El navegador accede al servidor web y se descarga su certificado X.509 donde se encuentra su clave pública.
  2. El navegador inicia el protocolo Diffie-Hellman para conseguir una clave de sesión. Cifra los parámetros iniciales con la clave pública del servidor y se la envía.
  3. El servidor recibe los parámetros y inicia su parte del protocolo Diffie-Hellman. Envía sus parámetros al cliente firmados (así el cliente se asegura de que realmente es el servidor el que los envía y no un tercero). Este parámetro no va cifrado, pero el protocolo Diffie-Hellman hace que sólo con este parámetro no se pueda conseguir la clave final.
  4. Ahora el navegador sigue con el protocolo Diffie-Hellman y calcula la clave simétrica de sesión. A partir de este momento la comunicación entre cliente y servidor irá cifrada con la clave que han calculado los dos extremos.

Podcast – 24 – HTTPS

Descarga directa.

Podcast – 22 – Certificados digitales

Los certificados de claves públicas X.509 nacieron como estándar de la Unión Internacional de Telecomunicaciones en 1988, si bien han ido evolucionando y actualmente la versión 3 se definió en 2008. La seguridad se basa en que una autoridad de certificación en la que confiamos (en realidad confia nuestro navegador), indica que la web a la que accedemos es la que dice ser (se evalúa el dominio) y por lo tanto se puede usar esta clave pública para cifrar la información de tal forma que sólo el servidor web pueda leer la información enviada.

Icono de certificado digital

Icono de certificado digital.
Fuente imagen:TuAsesorProfesional

Veamos los campos básicos de un certificado de dominio:

  1. Identificador de versión. Los valores aceptables son 1, 2 y 3. En el caso del certificado de Securizando.com la versión es la 3.
  2. Número de serie del certificado. Cada certificado emitido por una autoridad de certificación debe tener un número de serie único.
  3. Identificador del algoritmo de firmado. En el caso del certificado del blog es algoritmo es SHA-256 con cifrado RSA.
  4. Nombre del emisor. En el ejemplo el certificado de securizando.com está emitido por COMODO
  5. Periodo de validez. Este campo se basa en dos fechas: la de inicio de validez y la de caducidad. En nuestro ejemplo el certificado es válido del 22 de diciembre de 2016 al 23 de diciembre de 2018.
  6. Nombre del sujeto. Este campo identifica la identidad cuya clave pública está certificada. En nuestro ejemplo securizando.com
  7. Información de clave pública del sujeto. Este campo contiene la clave pública, sus parámetros y el identificador del algoritmo con el que se emplea la clave.
  8. Aquí aparecen algunos campos opcionales, si bien casi siempre se incluye la información de los protocolos CRL y OCSP que permiten confirmar que un certificado sea válido. Como estos protocolos no están estandarizados (aunque todas las autoridades de certificación los usen) no tienen un campo específico en el certificado y cae dentro de los opcionales
  9. Firma del certificado. La autoridad de certificación firma todo el contenido del cifrado para demostrar que ha sido emitido por dicha CA y no ha sido modificado

Existen diferentes campos opcionales (declaración de políticas de la entidad certificadora, restricciones del certificado, etc.).

¿Cómo se usa el certificado X.509?

Micro con feed

Fuente imagen:PerfectYourPodcast

Cuando nuestro navegador accede a una web, descarga el certificado asociado a la misma. El navegador comprueba que el certificado está correctamente firmado por la CA, corresponde al dominio de la web accedida y el estamos dentro del período de validez. Una vez realizadas estas comprobaciones básicas, revisará mediante los protocolos CRL y OCSP
que no haya sido revocado. Si todas las comprobaciones son correctas, empezará un intercambio de mensajes para definir una clave de sesión usando el certificado recién comprobado como punto de inicio del protocolo de cifrado. En realidad por cada sesión se calcula una nueva clave de cifrado, pero el protocolo siempre se inicia con mensajes cifrados usando el certificado digital X.509.

Recomendaciones

  1. La Universidad Complutense de Madrid organiza, dentro de los Cursos de Verano de El Escorial,
    el curso de dos días títulado «La ciberseguridad como eje de la transformación digital». El curso se celebra los dia 10 y 11 de julio y el primer día tiene un corte más empresarial, con
    los CISO de Orange y FCC y una mesa redonda donde irá el director del Instituno Nacional de Ciberseguridad. El segundo día, será una jornada más práctica, incluyendo un taller.
  2. La segunda recomendación tiene un alcance más sencillo: se trata de una charla «Ciberseguridad: El reto empresarial del siglo XXI» de la Cámara de Comercio de Mallorca que se celebra
    el próximo jueves 22 de junio. Es gratuita y estaré por ahí de oyente.

Descarga directa.