CyberOps Associate Módulo 17 – Atacando lo que hacemos

Última actualización: abril 1, 2022

17.0. Introducción

17.0.1. ¿Por qué deberíamos tomar este módulo?

Los fundamentos de la red deben estar protegidos, pero no es suficiente para proteger completamente nuestra red. Los protocolos que se utilizan para llevar a cabo las actividades diarias de la organización, también deben estar protegidos. Además, los protocolos y el software que proporcionan servicios a través de la red también pueden ser el objetivo de los atacantes. Un analista de ciberseguridad debe estar familiarizado con las vulnerabilidades y amenazas a los fundamentos de la comunicación de red.

En este módulo, aprenderá cómo funcionan los protocolos comúnmente utilizados en la empresa y cómo son vulnerables a ataques y explotaciones.

17.0.2. ¿Qué aprenderemos en este módulo?

Título del módulo: Atacando lo que hacemos

Objetivo del Módulo: Explicar cómo las aplicaciones y servicios de red comunes son vulnerables a ataques.

Título del tema Objetivo del tema
Servicios IP Explique las vulnerabilidades del servicio IP.
Servicios empresariales Explicar cómo las vulnerabilidades IP permiten ataques a las redes.

17.1. Servicios IP

17.1.1. Vulnerabilidades de ARP

Los hosts transmiten una solicitud ARP hacia otros hosts del segmento de red para determinar la dirección MAC de un host con una dirección IP específica. Todos los hosts de la subred reciben y procesan la solicitud ARP. El host con la dirección IP que coincide con la de la solicitud ARP envía una respuesta ARP.

Reproduzca la animación para ver el proceso ARP en funcionamiento.

Cualquier cliente puede enviar una respuesta de ARP no solicitada llamada “ARP gratuito.» Esto suele hacerse cuando un dispositivo se inicia por primera vez para informar a todos los demás dispositivos de la red local sobre la dirección MAC del nuevo dispositivo. Cuando un host envía un ARP gratuito, otros hosts en la subred almacenan en sus tablas de ARP la dirección MAC y la dirección IP que contiene dicho ARP.

Sin embargo, esta característica de ARP también significa que cualquier host puede afirmar ser el dueño de cualquier IP/MAC que elija. Un atacante puede envenenar la caché ARP de los dispositivos en la red local y crear un ataque MiTM para redireccionar el tráfico. El objetivo es asociar la dirección MAC del atacante con la dirección IP de la Puerta de enlace por defecto en las caché ARP de los hosts del segmento LAN. Esto posiciona al atacante entre la víctima y todos los demás sistemas fuera de la subred local.

17.1.2. Envenenamiento de caché ARP

El envenenamiento de caché ARP se puede usar para lanzar varios ataques Man-in-the-middle.

Haga clic en cada botón para ver una ilustración y una explicación del proceso de envenenamiento de caché ARP.

  • Solicitud de ARP
  • Respuesta de ARP
  • Respuestas ARP gratuitas falsificadas
La figura muestra cómo funciona el envenenamiento de caché ARP. La PC-A requiere la dirección MAC de su Puerta de enlace por defecto (R1); por lo tanto, envía una solicitud ARP para la dirección MAC de 192.168.10.1.

En está figura, R1 actualiza su caché ARP con las direcciones IP y MAC de la PC-A y envía una respuesta de ARP a PC-A, la cual a su vez, actualiza su caché ARP con las direcciones IP y MAC del R1.

En la figura 3, el atacante envía dos respuestas de ARP gratuitas falsas usando su propia dirección MAC para las direcciones IP de destino indicadas. La PC-A actualiza su caché ARP con su Puerta de enlace por defecto, la cual ahora apunta hacia la MAC del host del atacante. El R1 también actualiza su caché ARP con la dirección IP de la PC-A y comienza a apuntar a la dirección MAC del atacante.

El anfitrión del atacante está ejecutando un ataque de envenenamiento ARP. El envenenamiento ARP puede ser pasivo o activo: Pasivo: Los atacantes roban información confidencial. Activo: Los atacantes modifican datos en tránsito o inyectan datos maliciosos.

Nota: Existen muchas herramientas disponibles en internet para crear ataques de ARP MiTM, como: dsniff, Cain & Abel, ettercap, Yersinia, entre otras.

17.1.3. Ataques DNS

El protocolo de Sistema de Nombres de Dominio (DNS) define un servicio automatizado que empareja los nombres de recursos, como www.cisco.com, con su respectiva dirección de red numérica, ya sea dirección IPv4 o IPv6. Incluye el formato para las consultas, respuestas y datos, y usa registros de recursos (RR) para identificar el tipo de respuesta de DNS.

La protección de DNS suele pasarse por alto. Sin embargo, es fundamental para el funcionamiento de una red y debe protegerse correctamente.

Los ataques DNS incluyen los siguientes:

  • Ataques de resolución abierta DNS
  • Ataques sigilosos DNS
  • Ataques Domain shadowing DNS
  • Ataques de tunelización DNS

Ataques de resolución abierta de DNS

Muchas organizaciones utilizan los servicios de los servidores DNS públicos abiertos, como GoogleDNS (8.8.8.8), para responder las consultas. Este tipo de servidor DNS se denomina resolución abierta. Una resolución de DNS abierta responde las consultas de clientes fuera de su dominio administrativo. Las resoluciones abiertas de DNS son vulnerables a múltiples actividades maliciosas, como las descritas en la tabla.

Vulnerabilidades de resolución de DNS Descripción
Ataques de envenenamiento caché DNS Los atacantes envían información falsificada de recursos de registro (RR) a un servidor (resolver) DNS para redirigir a los usuarios de sitios legítimos a sitios maliciosos. Los ataques de envenenamiento de caché DNS se pueden usar para informar al servidor DNS que utilice un servidor de nombres malicioso, el cual proporciona información RR para actividades maliciosas.
Amplificación y ataques de reflexión DNS Los atacantes usan ataques DoS o DDoS en servidores de resolución abierta de DNS (DNS open resolvers) para aumentar el volumen de los ataques y ocultar la verdadera fuente de un ataque. Los atacantes envían mensajes DNS a los servidores de resolución abierta usando la dirección IP de un host de destino. Estos ataques son posibles porque el servidor de resolución abierta responde las consultas de cualquiera que realice una pregunta.
Ataques de utilización de recursos DNS Un ataque DoS consume los servidores de resolución abierta de DNS. Este ataque DoS consume todos los recursos disponibles para afectar negativamente las operaciones del servidor de resolución abierta de DNS. El impacto de este ataque DoS puede requerir que el servidor de resolución abierta de DNS. se reinicie o requiera que los servicios sean detenidos y reiniciados.

Ataques sigilosos de DNS

Para ocultar su identidad, los atacantes también utilizan las siguientes técnicas DNS sigilosas para llevar a cabo sus ataques:

Técnicas de sigilo DNS Descripción
Fast Flux Los atacantes utilizan esta técnica para ocultar los sitios de Phishing y malware que les pertenecen, detrás de una red de hosts DNS comprometidos, la cual cambia rápidamente. Las direcciones IP de DNS cambian constantemente en cuestión de minutos. Las botnets a menudo emplean técnicas Fast Flux para esconder eficazmente servidores maliciosos, para que no sean detectados.
Double IP Flux Los atacantes utilizan esta técnica para cambiar rápidamente el hostname para las asignaciones de dirección IP y también para cambiar el servidor de nombres autorizados. Esto aumenta la dificultad para identificar el origen del ataque.
Algoritmos de generación de dominio Los atacantes usan esta técnica en malware para generar aleatoriamente nombres de dominio que puedan utilizarse como puntos de encuentro de sus servidores de Mando y control (C&C, siglas en inglés).

Ataques DNS Domain shadowing

El uso de Domain shadowing implica que el atacante recolecte credenciales de cuenta de dominio para crear múltiples subdominios para utilizarlos durante los ataques. Estos subdominios generalmente apuntan a servidores maliciosos sin alertar al propietario real del dominio principal.

17.1.4. Tunelizado DNS

Las botnets se han convertido en un método popular de ataque utilizado por los atacantes. La mayoría de las veces, las botnets se utilizan para propagar malware o iniciar ataques DDoS y suplantación de identidad.

A veces, el DNS en la empresa no se tiene en cuenta como un protocolo que las botnets pueden utilizar. Debido a esto, cuando se determina que el tráfico DNS es parte de un incidente, el ataque ya finalizó. Es necesario que el analista de ciberseguridad sea capaz de detectar cuándo un intruso utiliza la tunelización DNS para robar los datos, y así evitar y contener el ataque. Para lograr esto, el analista de seguridad debe implementar una solución que pueda bloquear las comunicaciones salientes de los hosts infectados.

Los atacantes que utilizan la tunelización DNS colocan tráfico que no es de DNS en tráfico DNS. Con frecuencia, este método evade las soluciones de seguridad. Para que el atacante utilice la tunelización DNS, se modifican los distintos tipos de registros de DNS, como TXT, MX, SRV, NULL, A, o CNAME. Por ejemplo, un registro TXT puede almacenar los comandos que son enviados hacia los bots de los host infectados como respuestas DNS. Un ataque de tunelización de DNS mediante TXT funciona así:

  1. Los datos se dividen en varias partes codificadas.
  2. Cada parte se coloca en una etiqueta de nombre de dominio de nivel inferior (lower level domain), de la consulta de DNS.
  3. Dado que no hay ninguna respuesta del DNS local o el de red para la consulta, la solicitud se envía a los servidores DNS recursivos del ISP.
  4. El servicio de DNS recursivo reenvía la consulta al servidor de nombres autorizados del atacante.
  5. El proceso se repite hasta que se envían todas las consultas que contienen las partes.
  6. Cuando el servidor de nombres autorizados del atacante recibe las consultas DNS de los dispositivos infectados, envía las respuestas para cada consulta DNS, las cuales contienen los comandos encapsulados y codificados.
  7. El malware en el host comprometido vuelve a combinar las partes y ejecuta los comandos ocultos dentro.

Para poder detener la tunelización DNS, debe utilizarse un filtro que inspecciona el tráfico de DNS. Preste especial atención a las consultas de DNS que son más largas de lo normal, o las que tienen un nombre de dominio sospechoso. Además, las soluciones de seguridad DNS, como Cisco Umbrella (Antes conocido como Cisco OpenDNS), bloquean gran parte del tráfico de la tunelización de DNS identificando dominios sospechosos. Los dominios asociados con servicios de DNS Dinámico deben considerarse altamente sospechosos.

17.1.5. DHCP

Los servidores DHCP proporcionan de manera dinámica, información de configuración de IP a los clientes. La figura muestra la secuencia típica de un intercambio de mensajes DHCP entre el cliente y el servidor.

Funcionamiento normal de DHCP

En la figura, un cliente transmite un mensaje de DHCP discover. El servidor DHCP responde con una oferta de unicast que incluye información de direccionamiento que el cliente puede usar. El cliente transmite una solicitud DHCP para decirle al servidor que acepta la oferta. El servidor le responde directamente con un acuse de recibo unicast, aceptando la solicitud.

17.1.6. Ataques de DHCP

Ataque de suplantación DHCP

Un ataque de suplantación DHCP se produce cuando un servidor DHCP malicioso se conecta a la red y proporciona parámetros de configuración IP falsos a los clientes legítimos. Un servidor malicioso puede proporcionar una variedad de información engañosa:

  • Puerta de enlace por defecto incorrecta: El atacante proporciona una puerta de enlace por defecto no válida o la dirección IP de su propio host para crear un ataque de MITM. Esto puede pasar totalmente inadvertido, ya que el intruso intercepta el flujo de datos que pasa a través de la red.
  • Servidor DNS incorrecto: El atacante proporciona una dirección del servidor DNS incorrecta que dirige al usuario a un sitio web malicioso.
  • Dirección IP incorrecta: El atacante proporciona una dirección IP no válida, una dirección IP de puerta de enlace por defecto no válida o ambas. Luego, el atacante crea un ataque DoS en el cliente DHCP.

Supongamos que un atacante conecta con éxito un servidor DHCP malicioso a un puerto de un switch en la misma subred que los clientes objetivos. El objetivo del servidor malicioso es proporcionarles a los clientes información de configuración IP falsa.

Haga clic en cada botón para ver una ilustración y una explicación de los pasos en un ataque de suplantación DHCP.

  • 1. El cliente transmite mensajes DHCP Discovery
  • 2. Los servidores DHCP responden con ofertas
  • 3. El cliente acepta la solicitud del DHCP malicioso
  • 4. El servidor DHCP malicioso hace acuse de recibo de la solicitud
En la figura, un cliente legítimo se conecta a la red y requiere parámetros de configuración de IP. Por lo tanto, el cliente transmite una solicitud de DHCP Discover en busca de una respuesta de un servidor DHCP. Ambos servidores recibirán el mensaje.

En la figura, se ejemplifica cómo el servidor DHCP malicioso y el legítimo responden ambos con parámetros de configuración IP válidos. El cliente responde a la primera oferta recibida.

En esta situación, el cliente recibió primero la oferta del servidor malicioso, y transmite una solicitud de DHCP aceptando los parámetros del servidor malicioso, como se muestra en la Figura. El servidor legítimo y el malicioso reciben la solicitud.

Sin embargo, solamente el servidor malicioso emite una respuesta unicast al cliente para acusar recibo de su solicitud, como se muestra en la figura. El servidor legítimo deja de comunicarse con el cliente porque la solicitud ya ha sido confirmada.

17.1.7. Práctica de laboratorio: Explorar tráfico DNS

En esta práctica de laboratorio cumpliremos con los siguientes objetivos:

  • Capturar tráfico DNS
  • Explorar tráfico de consultas DNS
  • Explorar tráfico de respuestas DNS

17.2. Servicios empresariales

17.2.1. HTTP y HTTPS

Casi todo el mundo usa navegadores de Internet. Bloquear la navegación web por completo no es una opción, ya que las empresas necesitan tener acceso a la web sin poner en riesgo la seguridad web.

Para investigar los ataques basados en la web, los analistas de seguridad deben comprender muy bien cómo funciona un ataque estándar basado en la web. Normalmente, estas son las etapas de un típico ataque de web:

  1. La víctima, sin saberlo, visita una página web infectada con malware.
  2. La página web infectada redirige al usuario a menudo, mediante muchos servidores comprometidos, a un sitio que contiene código malicioso.
  3. El usuario visita este sitio con código malicioso y su computadora se infecta. Esto se conoce como «drive-by download». Cuando el usuario visita el sitio, un kit de ataque (exploit kit) escanea el software que se ejecuta en la computadora de la víctima incluyendo el Sistema Operativo, Java o Flash Player en busca de una vulnerabilidad en el software. El kit de ataque es, a menudo, es un script PHP y le proporciona al atacante una consola de administración para gestionar el ataque.
  4. Después de identificar un paquete de software vulnerable ejecutándose en la computadora de la víctima, el kit de ataque se comunica con el servidor de kit de ataque para descargar código que pueda aprovechar la vulnerabilidad para ejecutar código malicioso en la computadora de la víctima.
  5. Una vez que se infecta la computadora de la víctima, se conecta al servidor de malware y descarga una payload. La cual podría ser malware o un servicio de descarga de archivos que descarga otro malware.
  6. El paquete final de malware se ejecuta en la computadora de la víctima.

Independientemente del tipo de ataque que se utilice, el objetivo principal del atacante es asegurarse que el navegador web de la víctima llegue a su página web, la cual introduce el código malicioso en la computadora de la víctima.

Algunos sitios maliciosos toman ventaja de los complementos (plugins) vulnerables o de las vulnerabilidades del navegador para comprometer el sistema del cliente. Las redes más grandes dependen de los IDS para analizar los archivos descargados, en busca de malware. Si detectan que los archivos podrían contener malware, los IDS emiten alertas y registran el evento en archivos de registro para su posterior análisis.

Los registros de conexión del servidor suelen revelar información sobre el tipo de escaneo o de ataque. Los diferentes tipos de códigos de estado de conexión se enumeran aquí:

  • Informativo 1xx: Este corresponde a una respuesta provisional, que consiste solamente en la línea de estado y los encabezados opcionales. Finaliza con una línea vacía. No se necesitan encabezados para esta clase de código de estado. Los servidores NO DEBEN enviar una respuesta 1xx a un cliente HTTP/1.0, salvo en condiciones experimentales.
  • Correcto 2xx: La solicitud del cliente fue satisfactoriamente recibida, comprendida, y aceptada.
  • Redirección 3xx: El agente de usuario debe tomar medidas adicionales para completar la solicitud. Un cliente DEBE detectar bucles de redireccionamiento infinito, porque estos bucles generan tráfico de red por cada redireccionamiento.
  • Error de Cliente 4xx: Para casos en los que el cliente parece haber cometido un error. Excepto al responder a una solicitud de ENCABEZADO, el servidor DEBE incluir una entidad que contenga una explicación de la situación, y si es temporal. Los agentes de usuario DEBEN mostrar todas las entidades incluidas al usuario.
  • Error de Servidor 5xx: Para casos donde el servidor detecta que se equivocó, o no puede realizar la solicitud. Excepto al responder a una petición de ENCABEZADO (HEAD request), el servidor DEBE incluir una entidad que contenga una explicación de la situación de error, y si es temporal. Los agentes de usuario DEBEN mostrar todas las entidades incluidas al usuario.

Para defenderse de los ataques basados en la web, se deben implementar las siguientes medidas:

  • Actualizar siempre el Sistema Operativo y los navegadores con las últimas versiones y parches actuales.
  • Utilizar un proxy web como Cisco Cloud Web Security o Cisco Web Security Appliance para bloquear sitios maliciosos.
  • Utilizar las buenas prácticas de seguridad del Proyecto Abierto de Seguridad de Aplicaciones Web (Open Web Application Security Project, OWASP) durante el desarrollo de aplicaciones web.
  • Capacitar a los usuarios finales demostrándoles cómo evitar ataques basados en web.

El «Top 10 Web Application Security Risks» (Top 10 principales riesgos de seguridad para las aplicaciones Web de OWASP) está diseñado para ayudar a las organizaciones a crear aplicaciones web seguras. Es una lista útil de vulnerabilidades potenciales que son comúnmente aprovechadas por los atacantes.

17.2.2. Exploits HTTP comunes

iFrames maliciosos

Los atacantes suelen usar iFrames maliciosos. Un iFrame es un elemento HTML que le permite al navegador cargar otra página web desde otra fuente. Los ataques de iFrame se han vuelto muy comunes, ya que suelen utilizarse para insertar anuncios de otras fuentes en la página. Los atacantes comprometen un servidor web y modifican las páginas web agregando HTML para el iFrame malicioso. El HTML hace un enlace al servidor web del atacante. En algunos casos, la página iFrame que se carga consta de apenas algunos píxeles. Esto hace que el usuario tenga dificultades para ver el contenido. Debido a que el iFrame se ejecuta en la página, se puede utilizar para lanzar un exploit malicioso, como publicidad Spam, kits de ataque (exploit kits) y otros tipos de malware.

Estas son algunas maneras de evitar o reducir los iFrames maliciosos:

  • Utilizar un proxy web para bloquear sitios maliciosos.
  • Debido a que los atacantes suelen cambiar la fuente HTML del iFrame en un sitio web comprometido, nos debemos asegurar de que los desarrolladores web no utilicen iFrames. Esto aislará cualquier contenido de sitios web de terceros y facilitará la búsqueda de páginas modificadas.
  • Utilizar un servicio como Cisco Umbrella para evitar que los usuarios visiten sitios web que se sabe que son maliciosos.
  • Asegurarse de que el usuario final entienda lo que es un iFrame. Los atacantes suelen utilizar este método en ataques basados en web.

Ataque de redireccionamiento HTTP 302 (cushioning HTTP 302)

Otro tipo de ataque HTTP es el ataque de redireccionamiento HTTP 302. Los atacantes utilizan el código de respuesta HTTP 302 Found (Encontrado) para dirigir el navegador web del usuario a una nueva ubicación. Los atacantes suelen utilizar funciones legítimas de HTTP como redireccionamientos HTTP para llevar a cabo sus ataques. HTTP permite a los servidores redirigir una solicitud HTTP de cliente a un servidor diferente. El redireccionamiento HTTP se utiliza, por ejemplo, cuando el contenido de la web se ha trasladado a una dirección URL o un nombre de dominio diferentes. Esto permite que la dirección URL y los marcadores anteriores continúen funcionando. Por lo tanto, los analistas de seguridad deben comprender cómo funciona una característica como el redireccionamiento HTTP y cómo se usa durante los ataques.

Cuando la respuesta del servidor es un estado HTTP 302 Found, también proporciona la dirección URL en el campo de ubicación. El navegador cree que la nueva ubicación es la dirección URL en el encabezado, y a este se le invita a solicitar esta nueva dirección URL. Esta función de redireccionamiento puede utilizarse varias veces hasta que el navegador finalmente llega a la página que contiene el exploit. Los redireccionamientos pueden ser difíciles de detectar debido a que los redireccionamientos legítimos son comunes en la red.

Estas son algunas maneras de evitar o reducir los ataques de redireccionamiento HTTP 302:

  • Utilizar un proxy web para bloquear sitios maliciosos.
  • Utilizar un servicio como Cisco Umbrella para evitar que los usuarios visiten sitios web que se sabe que son maliciosos.
  • Asegurarse de que el usuario final entienda cómo es redirigido su navegador por una serie de redireccionamientos HTTP 302.

Domain shadowing

Cuando un atacante quiere crear un ataque de Domain shadowing, el atacante primero debe comprometer un dominio. Luego, el atacante debe crear múltiples subdominios de ese dominio para usarlos en los ataques. Una vez que lo hace, los inicio de sesión del registro secuestrados son utilizados para crear los subdominios que sean necesarios. Después de crear estos subdominios, los atacantes pueden utilizarlos como quieran, incluso si se detecta que son dominios maliciosos. Simplemente pueden crear más desde el dominio principal. La siguiente secuencia es comúnmente utilizada por los atacantes:

  1. Un sitio web es comprometido.
  2. El redireccionamiento HTTP 302 es utilizado para enviar el navegador a sitios web maliciosos.
  3. Se utiliza Domain shadowing para dirigir el navegador a un servidor comprometido.
  4. Se accede a una página que contiene un kit de ataque (exploit kit)
  5. Se descarga el malware de la página que contiene el exploit kit.

Estas son algunas maneras de evitar o reducir los ataques Domain shadowing:

  • Proteger todas las cuentas de propietario de dominio. Utilizar contraseñas fuertes y la autenticación de dos factores para asegurar estas cuentas tan importantes.
  • Utilizar un proxy web para bloquear sitios maliciosos.
  • Utilizar un servicio como Cisco Umbrella para evitar que los usuarios visiten sitios web que se sabe que son maliciosos.
  • Asegurarse de que los propietarios de dominios validen sus cuentas de registro y busquen cualquier subdominio que no hayan autorizado.

17.2.3. Correo electrónico

Durante más de 25 años, el correo electrónico ha evolucionado: pasó de ser una herramienta que usaban principalmente los profesionales técnicos y de investigación, a ser el pilar de las comunicaciones corporativas. Cada día se intercambian más de 100 000 millones de mensajes de correo electrónico corporativos. A medida que aumenta el uso del correo electrónico, la seguridad se vuelve una prioridad mayor. La manera en que los usuarios tienen acceso al correo electrónico hoy en día, también aumenta la oportunidad de ataques de malware. En el pasado, los usuarios corporativos accedían a correo electrónico basado en texto desde un servidor corporativo. El servidor corporativo estaba en una estación de trabajo protegida por el firewall de la empresa. Hoy en día se tiene acceso a los mensajes de correo electrónico desde muchos dispositivos diferentes que no suelen estar protegidos por el firewall de la empresa. HTML permite más ataques debido a la cantidad de accesos, los cuales a veces, puede esquivar las distintas capas de seguridad.

Los siguientes son ejemplos de amenazas de correo electrónico:

  • Ataques basados en archivos adjuntos: Los atacantes incrustan contenido malicioso en los archivos empresariales, por ejemplo, en un correo electrónico del departamento de TI. Los usuarios legítimos abren el contenido malicioso. El malware se usa en grandes ataques, usualmente apuntando hacia un área empresarial específica (por ejemplo contabilidad) , para que el malware parezca software legítimo, y así convencer a los usuarios que trabajan en esa área empresarial que abran los archivos adjuntos o hagan clic en los enlaces incrustados.
  • Suplantación de correo (email spoofing): Los atacantes crean mensajes de correo electrónico con una dirección de remitente falsificada, pretendiendo engañar al destinatario para que entregue dinero o información confidencial. Por ejemplo, un banco nos envía un correo electrónico solicitando actualizar nuestras credenciales. Cuando este mensaje tiene un logo del banco idéntico al de otros correos legítimos que hemos recibido, hay más probabilidades de que abramos los archivos adjuntos y de hacer clic en los enlaces. El mensaje de correo electrónico suplantado podría incluso solicitarnos que verifiquemos nuestras credenciales, para que el banco se asegure de que somos esa persona que intentan contactar, logrando exponer así su información de inicio de sesión.
  • Correo Spam: Los atacantes envían correo electrónico no solicitado que contiene publicidad o archivos maliciosos. Normalmente, este tipo de correo electrónico se envía para solicitar una respuesta que le indique al atacante que el correo es válido y que un usuario abrió el Spam.
  • Servidor de correo con open relay: Los atacantes toman ventaja de los servidores empresariales que están mal configurados como servidores de correo con «open relay», para así poder enviar grandes cantidades de Spam o de malware a usuarios desprevenidos. Este tipo de servidor mal configurado es un servidor SMTP que permite que cualquiera en internet pueda enviar correo Debido a que cualquier persona puede utilizar el servidor, este es vulnerable al Spam y a gusanos informáticos. Es posible enviar grandes cantidades de Spam utilizando un servidor de correo «open relay». Es importante que los servidores corporativos de correo electrónico nunca se configuren como servidores con open relay. Esto reducirá considerablemente la cantidad de correos electrónicos no solicitados (Spam).
  • Homógrafos: Los atacantes pueden utilizar caracteres de texto que son muy similares o incluso idénticos a los caracteres de texto legítimo. Por ejemplo, puede ser difícil distinguir entre una O (“O” mayúscula) y el 0 (número cero) o una l (“L” minúscula) y un 1 (número uno). Estos pueden utilizarse en correos electrónicos de Phishing para hacerlos muy convincentes. En DNS, estos caracteres son muy diferentes de la realidad. Cuando se realizan búsquedas en el registro de DNS, se encuentra una dirección URL totalmente diferente si se usa el enlace con el homógrafo en la búsqueda.

Al igual que cualquier otro servicio que escuche a un puerto en busca de conexiones entrantes, los servidores SMTP también pueden tener vulnerabilidades. Siempre debemos mantener al día el software de SMTP con parches y actualizaciones de software y de seguridad. Para evitar que los atacantes cumplan su tarea de engañar al usuario final, tenemos que implantar contramedidas. Utilizar un dispositivo de seguridad específico para correo electrónico, como el Cisco Email Security Appliance. Esto ayudará a detectar y bloquear muchos tipos conocidos de amenazas, como Phishing, Spam y malware. También recordemos capacitar al usuario final. Cuando los ataques superen las medidas de seguridad implementadas (lo harán a veces), el usuario final es la última línea de defensa. Debemos enseñarles a reconocer el Spam, los intentos de Phishing, los enlaces y las direcciones URL sospechosas, los homógrafos, y a nunca abrir archivos adjuntos sospechosos.

17.2.4. Bases de datos expuestas en la web

Las aplicaciones web suelen conectarse a una base de datos relacional para tener acceso a los datos. Como las bases de datos relacionales a menudo contienen datos confidenciales, son un objetivo frecuente de los ataques.

Inyección de código

Los atacantes son capaces de ejecutar comandos en el Sistema Operativo de un servidor web mediante una aplicación web vulnerable. Esto puede ocurrir si la aplicación web proporciona campos de entrada al atacante para ingresar datos maliciosos. Los comandos del atacante son ejecutados mediante la aplicación web y tienen los mismos permisos que dicha aplicación. Este tipo de ataques se usa porque usualmente no hay suficiente validación de las entradas. Un ejemplo es cuando un atacante «inyecta» código PHP en un campo de entrada inseguro en la página del servidor.

Inyección SQL

SQL es el lenguaje que se utiliza para consultar una base de datos relacional. Los atacantes utilizan las inyecciones SQL para irrumpir en la base de datos relacional, crear consultas SQL maliciosas y obtener datos confidenciales de la base de datos relacional.

Uno de los ataques de base de datos más común es el ataque de inyección SQL. Este ataque consiste en inyectar una consulta SQL usando los datos de entrada desde el cliente hacia la aplicación. Un ataque exitoso de inyección SQL, puede leer los datos confidenciales de la base de datos, modificarlos, ejecutar operaciones de administración de la base de datos y, a veces, emitir comandos al Sistema Operativo.

A menos que una aplicación utilice validación estricta para los datos de entrada, será vulnerable al ataque de inyección SQL. Si una aplicación acepta y procesa los datos suministrados por el usuario sin ninguna validación de datos de entrada, un atacante podría ingresar una entrada string maliciosa para desencadenar el ataque de inyección SQL.

Los analistas de seguridad deben ser capaces de reconocer consultas SQL sospechosas para detectar si se realizaron ataques de inyección SQL en la base de datos relacional. Deben tener la capacidad de determinar cuál ID de usuario usó el atacante para iniciar sesión y, después, identificar cualquier información o acceso posterior que el atacante podría haber usado tras un inicio de sesión satisfactorio.

17.2.5. Client-side Scripting

Cross-Site Scripting

No todos los ataques se inician desde el servidor. El Cross-Site Scripting (XSS) ocurre cuando páginas web que se ejecutan en el navegador web del cliente, se inyectan con scripts maliciosos. Estos scripts pueden ser usados por Visual Basic, JavaScript, entre otros, para tener acceso a una computadora, recopilar información confidencial o desplegar más ataques y propagar malware. Al igual que con la inyección SQL, el XSS suele originarse cuando el atacante publica contenido en un sitio web confiable que no tiene validación de entrada. Los futuros visitantes del sitio web de confianza estarán expuestos al contenido publicado por el atacante.

Existen dos tipos principales de XSS:

  • Almacenado (persistente): Este es permanentemente almacenado en el servidor infectado y es recibido por todos los que visiten la página afectada.
  • Reflejado (no persistente): Este solo requiere que el script malicioso se encuentre localizado en un enlace y los visitantes hagan clic en él para infectarse.

Estas son algunas maneras de prevenir o reducir los ataques XSS:

  • Asegúrese de que los desarrolladores de aplicaciones web conozcan las vulnerabilidades de XSS y cómo evitarlas.
  • Utilizar una implementación de IPS para detectar y evitar scripts maliciosos.
  • Utilizar un proxy web para bloquear sitios maliciosos.
  • Utilizar un servicio como Cisco Umbrella para evitar que los usuarios visiten sitios web que se sabe que son maliciosos.
  • Al igual que con las demás medidas de seguridad, asegurarse de capacitar a los usuarios finales. Enseñarles a identificar los ataques de Phishing y notificar al personal de seguridad de la información si tienen cualquier tipo de sospecha relacionada con la seguridad.

17.2.6. Práctica de laboratorio: Atacar una base de datos MySQL

En esta práctica de laboratorio revisarán un archivo PCAP de un ataque anterior a una base de datos SQL.

17.2.7. Práctica de laboratorio: Leer archivos de registro de un servidor

En esta práctica de laboratorio se cumplirán los siguientes objetivos:

  • Reading Log Files with catmore, and less
  • Archivos de registro y Syslog
  • Log Files and journalctl

17.3. Atacando lo que hacemos, Resumen

17.3.1. ¿Qué aprendimos en este módulo?

Servicios IP

Los hosts transmiten una solicitud de ARP hacia otros hosts del segmento, para determinar la dirección MAC de un host con una dirección IP específica. Cualquier cliente puede enviar una respuesta de ARP no solicitada llamada «ARP gratuito.» Está característica de ARP también significa que cualquier host puede decir ser el dueño de cualquier dirección IP/MAC que escoja. Un atacante puede envenenar la caché ARP de los dispositivos en la red local y crear un ataque MiTM para redireccionar el tráfico.

El protocolo DNS define un servicio automatizado que empareja los nombres de recursos, como www.cisco.com, con su respectiva dirección IP. Incluye el formato de mensaje de consultas, respuestas y datos. Utiliza Registros de recursos (RR) para identificar el tipo de respuesta DNS. DNS es fundamental para la operación y funcionamiento de una red y debe ser protegido correctamente. Muchas empresas utilizan los servicios públicos de servidores de resolución DNS abierta (open resolvers) para responder las consultas. Los servidores de DNS abiertos son vulnerables a varias actividades maliciosas, incluido el envenenamiento de caché DNS, en el que se proporcionan registros falsificados al servidor abierto. En los ataques de amplificación y reflexión DNS, se aprovecha la naturaleza benigna del protocolo DNS, para causar ataques DoS o DDoS. En los ataques de utilización de recursos DNS, se inicia un ataque DoS contra el propio servidor DNS. Los atacantes suelen ocultarse utilizando técnicas sigilosas, como Fast Flux, una técnica en la cual los servidores maliciosos cambian rápidamente su dirección IP. Los atacantes también utilizan Double IP Flux para cambiar rápidamente su nombre de dominio para las asignaciones de dirección IP y también cambiar el servidor de nombres autorizados. Los atacantes también podrían utilizar «Domain shadowing» para ocultar el origen de sus ataques mediante la recolección de credenciales de cuenta de dominio, para crear múltiples subdominios para utilizarlos durante los ataques. A veces, el DNS en la empresa no se tiene en cuenta como un protocolo que las botnets pueden utilizar. Los atacantes que utilizan la tunelización DNS colocan tráfico que no es de DNS en tráfico DNS. Con frecuencia, este método evita las soluciones de seguridad. Para poder detener la tunelización DNS, debe utilizarse un filtro que inspeccione el tráfico de DNS. Los servidores DNS dinámicos son populares entre los atacantes y el tráfico que utiliza DNS Dinámico debería ser una preocupación especial para el analista de ciberseguridad.

DHCP utiliza un intercambio simple de mensajes de broadcast y unicast para proporcionar a los hosts información de direccionamiento. Un ataque de suplantación DHCP se produce cuando un servidor DHCP malicioso se conecta a la red, y proporciona parámetros falsos de configuración IP a los clientes legítimos. El servidor malicioso puede proporcionar información incorrecta sobre la puerta de enlace por defecto, el servidor DNS o direcciones IP.

Servicios empresariales

Los navegadores web son utilizados por casi todos a nivel mundial. Bloquear por completo la navegación web no es una opción, ya que las empresas necesitan tener acceso a la web. Los analistas de ciberseguridad deben tener una buena comprensión sobre cómo funciona un ataque estándar basado en web. Las fases comunes de un ataque típico web incluyen que la victima (sin saberlo) acceda a una página web que ha sido comprometida con malware. La página web comprometida redirige al usuario a un sitio que aloja código malicioso. El navegador visita este sitio y el código malicioso infecta su computadora. Esto se conoce como «drive-by download». Independientemente del tipo de ataque que se utilice, el objetivo principal del atacante es asegurarse que el navegador web de la víctima llegue a su página web, la cual introduce el código malicioso en la computadora de la víctima. Algunos sitios maliciosos toman ventaja de los complementos (plugins) vulnerables o de las vulnerabilidades del navegador para comprometer el sistema del cliente. Las redes más grandes dependen de los IDS para analizar los archivos descargados, en busca de malware. Si detectan que los archivos podrían contener malware, los IDS emiten alertas y registran el evento en archivos de registro (log files) para su posterior análisis. Los registros de conexión del servidor suelen revelar información sobre el tipo de escaneo o de ataque. Los diferentes grupos de códigos de estado de conexión incluyen Informativo 1xxCorrecto 2xxRedirección 3xxError de cliente 4xx, y Error de servidor 5xx. Para defenderse contra ataques basados en web, las contramedidas que deben utilizarse incluyen actualizar siempre el Sistema Operativo y los navegadores con los últimos parches y actualizaciones, usar un proxy web para bloquear sitios maliciosos, usar las buenas prácticas de seguridad del Proyecto Abierto de Seguridad de Aplicaciones Web (Open Web Application Security Project, OWASP) al desarrollar aplicaciones web, y capacitar a los usuarios finales enseñándoles cómo evitar ataques basados en la web.

Hay una serie de ataques que utilizan el correo electrónico para llevar payloads de malware o para obtener información personal. Los servidores SMTP también pueden tener vulnerabilidades y deben mantenerse actualizados con los parches. Los dispositivos de seguridad de correo electrónico pueden detectar y bloquear muchos tipos de amenazas de correo electrónico conocidas, como Phishing, Spam y malware.

Las aplicaciones web suelen conectarse a bases de datos. Debido a que estas bases de datos pueden contener información confidencial, son un objetivo frecuente de los ataques. Los ataques de inyección de código e inyección de SQL aprovechan campos de entrada que no tienen suficiente validación, y así enviar comandos a bases de datos u otras aplicaciones con el fin de obtener acceso a información privada. Los ataques de Cross-Site Scripting (Scripting entre sitios, XSS) se producen cuando los exploradores ejecutan scripts maliciosos en el cliente y proporcionan a los atacantes acceso a información confidencial en el host local.

El «Top 10 Web Application Security Risks» de OWASP está diseñado para ayudar a las organizaciones a crear aplicaciones web seguras. Es una lista útil de vulnerabilidades potenciales que son comúnmente aprovechadas por los atacantes.

 

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
¿Tienes otra pregunta? Por favor comentax