Protocolos dinámicos aleatorizados para atacantes Deter

Question

Protocolos dinámicos aleatorizados para atacantes Deter

#1 de Steffen Ullrich (1 votos)
#2 de Munchen (0 votos)

1

Imagina un protocolo que cambia periódicamente.
¿Qué pasaría si el orden de estos campos se cambiara mucho?
Un punto en el tiempo el protocolo podría ser

{ Payload, Checksum, Length, Flags, ID }

El siguiente punto en el tiempo se convierte en

{ Flags, Checksum, Payload, ID, Flags }

Después de un período establecido, el protocolo vuelve a cambiar.

Como atacante, el objetivo es saber de qué se trata un objetivo para explotarlo o encontrar agujeros. Si fuera a cambiar periódicamente, podría ser más difícil para un atacante saber cómo explotar una debilidad. También se podrían cambiar el código subyacente, los campos, la longitud del campo, el esquema de codificación / modulación y otras cosas.
Por supuesto, el cliente / servidor debería estar sincronizado con estos cambios. Esto suena como seguridad a través de la oscuridad, pero podría retrasar al atacante. ¿Se ha hecho antes? Si no, ¿parece que podría ser útil?

attacks defense protocols

pregunta dopobop 31.03.2016 - 00:50

fuente

2 respuestas

Lea otras preguntas en las etiquetas attacks defense protocols

sslstrip no funciona en LAN XSS en la solicitud GET no descodificada en el backend

score 1 · Answer 1

Si fuera a cambiar periódicamente, podría ser más difícil para un atacante saber cómo explotar una debilidad. ... el código subyacente ... Por supuesto, el cliente / servidor debería estar sincronizado con estos cambios.

Tal como lo descubrió usted mismo: el cliente y el servidor deberían estar sincronizados. Esto significa que debería haber algún estado en ambos lados o el servidor debe poder extraer el estado de los mensajes de los clientes y el cliente no debe poder inventar su propio estado. Si observa detenidamente estos requisitos, ya tiene las formas típicas de cifrado simétrico (es decir, el estado se relaciona con la clave de cifrado) o la autenticación (estado similar a la cookie de sesión). Ambas son técnicas establecidas y simples, así que ¿por qué inventar una nueva que sea más compleja y no ofrezca una mejor protección?

Con un estado de cookie de sesión, primero verifica si el cliente está autenticado antes de interpretar el resto de los datos. No es necesario cambiar el formato para el resto porque se ignora de todos modos si falla la autenticación.
Con los datos de cifrado primero se deben descifrar. No es necesario cambiar el formato porque la carga útil se ignora si el descifrado falla.

En los extremos, la seguridad depende solo de lo difícil que el atacante pueda adivinar el estado común. No importa si este estado es una clave de cifrado, una cookie de sesión o algún algoritmo que describa los cambios de formato. Solo que esta última es más compleja de implementar que las otras dos soluciones.

score 0 · Answer 2

Esto parece que estás viendo el TCP, pero el analizador tendría que determinar el diseño de alguna manera en una situación fuera de banda. Se podría construir en la pila de comunicación y rotar en base a un secreto compartido previamente, pero eventualmente se descubriría. Probablemente una ventana de 6 meses?

También cualquier regularidad de sus datos hace que sea más fácil averiguar dónde están los límites de los bytes y averiguar el esquema.