¿Puede un ataque DDoS revelar información o usarse para montar un hack? Mi entendimiento es que todo el punto de DDoS o DoS es consumir todos los recursos / sobrecargas del servidor causando que se bloquee. Y esa es la única razón para hacer una DDoS.
He escuchado que DDoS se usa para obtener información. ¿Es eso cierto o totalmente falso?
Una DDoS sin duda le dará a un atacante información sobre los tiempos de respuesta, la capacidad de carga y el enrutamiento.
También puede proporcionar información sobre cómo se manejan los incidentes interna y externamente, así como sobre cómo se informan al público.
Pero esto no es lo que son los usos principales.
En general, las dos razones clave de DDoS son:
El primero es bien conocido, muy popular y su ejecución es relativamente sencilla, ya que la única defensa contra un ataque grande es un servicio de mitigación de DDoS de gran volumen.
El segundo se usa más raramente, pero se ve como parte del conjunto de herramientas de un atacante. Cargar el equipo de respuesta a incidentes puede hacer que sea más difícil para ellos detectar una intrusión, puede ocultar la verdadera razón del ataque y puede ocultar la evidencia de una intrusión entre un gran número de entradas de registro de la DDoS.
Una respuesta completa dependerá del ataque y de lo que se ataque, así que lo mantendré en general.
Un DoS puede filtrar información como efecto secundario. En tiempos anteriores, los conmutadores se usaban en redes para evitar que las máquinas escucharan la comunicación entre otras 2 máquinas. Debido a un problema de diseño, puedes volver a convertirlo en un gran dominio de colisión lanzando un ataque DoS contra el interruptor y puedes escuchar cualquier comunicación nuevamente. Explicación del ataque: Los interruptores aprenden qué máquina está conectada a qué puerto. Cuando una máquina envía un paquete a otra máquina, el conmutador busca en su memoria en qué puerto se encuentra esta máquina y reenvía el tráfico únicamente a este puerto. Una máquina en otro puerto no vería el tráfico. Surge un problema cuando hay más máquinas en la red que lo que cabría en la memoria del conmutador. Los comportamientos comunes son:
Especialmente comunes fueron el primer tipo. Un atacante dejaría que su máquina aparentara tener una gran cantidad de máquinas para estar en este puerto haciéndolo con transmisiones de anuncios.
Otro ataque relacionado con DoS es un ataque de degradación de seguridad. Tiene un sistema que consta de 2 subsistemas, A y B. B utiliza A para realizar comprobaciones de seguridad adicionales. Si B no responde a tiempo, A omitirá esta comprobación y la considerará exitosa. Si el atacante puede hacer un sistema DoS B, tiene un juego más fácil porque solo necesita pasar los controles de seguridad en el sistema A. Algunos sistemas están diseñados de esta manera porque la disponibilidad del sistema A es importante y nadie pensó que algún atacante pudiera hacer el sistema B de DoS o aceptaría el riesgo. No puedo darte los detalles de un ataque real, pero algunas listas negras antispam funcionan de esta manera.
También se sabe que algunos grupos / organizaciones avanzados lanzan (D) ataques DoS para distraerlos de su ataque real al atraer el foco del personal de seguridad al objetivo de la DDoS u ocultar el tráfico de ataque entre el tráfico DDoS.
Otra opción es que necesita esa cantidad de tráfico pero no necesita (D) DoS. Por ejemplo, algunos ataques a SSL requieren paquetes suficientes para recuperar / manipular información. Aquí el DoS sería un efecto secundario de la cantidad de tráfico.
Esto puede ser devastador cuando se usa contra servicios ocultos en la red Tor. Si tiene razones para creer que una determinada persona está hospedando un servicio oculto, puede probar esto lanzando un ataque contra un servicio abierto en el mismo hardware o en el mismo centro de datos. Si el servicio oculto falla, es posible que hayas confirmado que tu suposición es correcta y que la identidad detrás del servicio oculto se ha visto comprometida.
Cada vez que pruebe esto, obtendrá una muestra, que puede ser un falso positivo. Si lo haces las veces suficientes en intervalos aleatorios, puedes aumentar la probabilidad de estar en lo correcto.
Es posible usar un ataque DDOS para obtener información. Además de las respuestas de Rory Alsop y H. Idden, que se centran en obtener información de infraestructura o sobrecargar al equipo de respuesta a incidentes para que otros ataques permanezcan sin ser detectados por más tiempo, existen algunas otras posibilidades.
Aplicaciones de escala automática : cuando se trabaja con una plataforma de aplicaciones que escala automáticamente un ataque DDOS, se puede usar el hecho de que se escala automáticamente para hacer algo. Esto tendría que estar en concierto con algún otro tipo de ataque o información, pero la idea general es que si sabe lo suficiente como para explotar el proceso de "reinicio", podría usar DDOS para forzar a un nuevo servidor en línea que pasaría por el proceso de reinicio. , permitiendo tu exploit. Es importante tener en cuenta que esto es además de un problema de seguridad ya existente. Es solo la herramienta mediante la cual el exploit totalmente diferente se pone en línea (o tal vez se prueba). Un ejemplo del que puedo pensar es en un servidor de producción que aloja su base de código en un repositorio público de github, cuando las escalas introducen un nuevo código en el servidor y luego se inician. Podría agregar código incorrecto a ese repositorio de github (si no se administra correctamente), forzar un reinicio y tener su exploit.
Aplicaciones de primer orden de llegada : hay algunas aplicaciones que se "atienden por primera vez" en alguna parte de su proceso. IRC (de los comentarios) es un ejemplo, pero hay otros. Cualquier servicio que reserve algo para un usuario en un enfoque de primer orden de llegada, puede ser explotado a través de DDOS. Ya sea ocupando todos los espacios hasta que una persona específica obtenga el suyo, o forzando un reinicio y obteniendo otra posibilidad de "ranuras" después del reinicio. Estos son bastante comunes, y aunque un servicio que usa esto para la autenticación es un poco extraño, no es extraño. De hecho, los servicios de licencias hacen esto todo el tiempo. El primer usuario con una licencia de "ABC" es el usuario calificado de ABC. Si esos datos se pierden después de un reinicio, entonces DDOS podría provocar que se reinicie, y que su pie entre en la puerta.
Vulnerabilidades de inicio : he visto varias veces que el arranque del servidor hizo que los servicios se "dejaran en" por si acaso. Por ejemplo, dejemos activadas las contraseñas de SSH después del reinicio y luego las desactivamos después de un par de horas, en caso de que necesitemos acceso de emergencia. O bien, FTP está activado durante 30 minutos después de reiniciar. Esto es más común en los dispositivos de red. Cosas como "acceso wifi inseguro durante los primeros 2 minutos" o "cualquier cosa puede cargar cualquier cosa durante 2 minutos". Por lo general, esto es parte de un mecanismo de actualización / actualización. Por ejemplo, un enrutador Cisco puede aceptar cualquier dato TFTP que encuentre después de reiniciar. Algunas computadoras escucharán CUALQUIER servidor netboot al reiniciar. DDOS puede iniciar el reinicio y permitir la entrada de su "código incorrecto".
En esencia, un DDOS por sí mismo puede decirle algunas cosas, pero generalmente solo las cosas que son inútiles por sí mismas. Un DDOS junto con otros vectores de ataque puede ser extremadamente efectivo.
Nota Los métodos utilizados aquí funcionarán en un laboratorio, pero no es fácil para un equipo de seguridad (o incluso simplemente para TI). Si bien existen en la naturaleza, un atacante tendría que haber obtenido acceso / conocimiento de los aspectos internos mucho más allá del de alguien que solo está haciendo un DDOS.
Un ejemplo real de este suceso es con Steam. Ellos experimentaron un ataque DoS en el día de Navidad. En respuesta a eso, cambiaron las reglas de almacenamiento en caché del servicio de Steam, para que los clientes aún pudieran acceder a la página de la tienda. Desafortunadamente, terminaron cometiendo un error de configuración, que a veces hacía que los usuarios vieran la información personal de otros usuarios.
Los sistemas a veces tienen un comportamiento inesperado bajo una carga pesada del sistema, lo que puede llevar a vulnerabilidades de seguridad. Es una posibilidad para los hackers explotar esto, pero es poco probable que puedan planear esto, y el exploit es probablemente impredecible. También tienen que lidiar con el hecho de que el servidor probablemente tarda en responder debido a la gran carga.
En teoría, un ataque DDOS no solo podría distraer a un exploit como se menciona en otra respuesta, sino que también podría combinarse con uno.
Considere el error de Heartbleed , que devolvió información cuando se contactó a un servidor de una manera particular.
Uno podría aumentar la información obtenida del servidor contactando al servidor en un ataque DDOS y recolectando la información que fue liberada de esta manera.
Forzando el tiempo de arranque del servidor
Una cosa que se ha mencionado de forma tangencial en los comentarios, pero que no se ha abordado en ninguna de las otras respuestas excelentes, es que en ocasiones puede ser útil saber cuándo se inicia una aplicación / servidor. Por ejemplo, ciertos generadores de números aleatorios terriblemente inseguros (que nunca deben usarse para tareas relacionadas con la seguridad, pero siempre son de vez en cuando) utilizan la hora del sistema como su semilla "aleatoria".
Siendo ese el caso, si puede deducir cuándo se sembró el RNG (preferiblemente dentro de un par de minutos de precisión) y tener algunas muestras de la salida del generador, es razonablemente trivial encontrar la semilla y reconstruir el estado RNG para predecir los tokens futuros. Ahora, normalmente, un servidor no debe exponer su hora de inicio (aunque, de nuevo, algunos lo hacen invariablemente), sin embargo, si se puede usar un ataque DDoS para forzar el reinicio de un servidor, entonces habrá adquirido conocimiento del tiempo de inicio del servidor.
Esto puede llevar a una variedad de ataques basados en token como el secuestro de sesión.
Puede que se solucione, pero sé que en los primeros días de la Política de grupo un problema era sobrecargar el servidor de la Política de grupo y en algunas configuraciones se aplicaría la política local. Así que configuraríamos la política local como mínima. Solo se puede usar la denegación como una vulnerabilidad de la autoridad reducida de la política del servidor. Sé que no tengo todos los términos correctos, ha pasado un tiempo desde que hice el administrador de la Política de grupo.
Digamos que habías comprometido un enrutador pero ese enrutador no estaba recibiendo el tráfico que querías. Podría hacer un DoS en un buen enrutador para, con suerte, obtener tráfico hacia el enrutador pirateado.
Supongo que el ataque DoS se puede usar junto con el tipo de explotación de condición de raza. Cuando el servidor está muy cargado, el exploit será más fácil de usar.
Sin embargo, el ataque DoS solo puede proporcionar cierta información, como se mostró en las respuestas anteriores, sobre enrutamiento, tiempo de respuesta y manejo de incidentes internos.
¿Qué pasa con un ataque de tiempo? Esto se ha discutido como una posible vulnerabilidad de seguridad en Java , Python , probablemente muchos otros, y en realidad podría parecer un ataque de DOS.
Cuando varias bibliotecas comprueban la igualdad, generalmente están listas byte por byte y se comparan, devolviendo false si no coinciden. Si se utiliza algo así para verificar la contraseña / cookie, teóricamente pueden cronometrar la solicitud más larga y asumir que llegó más lejos a través de la comparación.
Por lo general no es increíblemente intrusivo. Depende de los puertos que estén abiertos y de los paquetes que se envíen. DDoS puede provenir de personas que refuerzan los datos y las bases de datos de su servidor, especialmente a través de LAN, y puede implicar un ataque discreto de fuerza bruta en algunos casos. Un servidor web típico es difícil de piratear, hospedo web y para videojuegos. Pregúntele a un profesional, o asumo que es una vulnerabilidad inevitable.
Lea otras preguntas en las etiquetas denial-of-service ddos