¿La perforación de agujeros pone una vulnerabilidad añadida en el lado del cliente

4

Los sitios web y los servidores a menudo son pirateados cuando existe una vulnerabilidad en el código del lado del servidor. ¿La perforación de agujeros UDP o TCP pone ese riesgo en los usuarios de la aplicación cuando las conexiones se vuelven de igual a igual?

Tomemos, por ejemplo, la práctica claramente vulnerable de ejecutar una entrada no saneada. Obviamente, esta práctica no se haría por diseño, pero este tipo de cosas sucede con demasiada frecuencia por error. En una configuración tradicional, si user_a interactúa con user_b primero tendríamos que user_a envíe información al servidor, el servidor procesará los datos y luego enviará algo a user_b . Con la perforación de agujeros, conseguimos un intercambio entre los dos usuarios, por lo que user_a envía datos a user_b , y user_b los procesa por sí mismo. Si hubiera una vulnerabilidad en la forma en que el servidor procesó la entrada (en este caso, ejecutándola sin desinfección), la vulnerabilidad podría estar presente en el lado del cliente, permitiendo que user_a inyecte y ejecute directamente el código en user_b's máquina.

Si se encontrara una vulnerabilidad grave en una aplicación de perforación (Skype y otros servicios de VoIP, algunos juegos en tiempo real multijugador, etc.), ¿hay algo que impida que un pirata informático malintencionado tenga acceso directo al sistema de cualquier usuario? interactúan con Si no es así, ¿son los programas peer to peer innecesariamente riesgosos? ¿Existe una manera general de mitigar este riesgo para las personas que crean estas aplicaciones? ¿Y qué pasa con las personas que usan estas aplicaciones? ¿Los programas como Skype dejan a los usuarios en un nivel de riesgo indebido (más de lo normal)?

    
pregunta rp.beltran 30.03.2016 - 05:03
fuente

2 respuestas

3

Considere el modelado de amenazas de los diferentes escenarios y dibuje límites de confianza razonables. Veo el modelo del servidor cliente de esta manera:

client-1 | server | client-2

y la vista de perforación de agujeros se vería así:

client-1 | server
client-2 | server
client-1 | client-2

En ambos casos, ni el cliente 1 ni el cliente 2 deben confiar implícitamente en los datos que llegan de una fuente externa, por lo que el código del cliente es responsable de validar la entrada.

Otra forma de verlo es si un atacante pudo inyectar un MITM en su conexión, independientemente de que provenga de un servidor o cliente, ¿debe confiar en esos datos?

Peer-to-peer aumenta la facilidad de un ataque al aumentar el número de vectores hostiles potenciales. También obliga al cliente a abrir un puerto de escucha para comunicarse (incluso si solo se abre temporalmente), en lugar de que el cliente siempre origine la conexión al servidor. Estos dos aumentan la superficie de ataque. Debido a estos aumentos, el cliente tiene un riesgo elevado de caer en una vulnerabilidad de 0 días.

Pero el riesgo planteado por un cliente vulnerable no cambia: independientemente del método de entrada, el atacante incumple al cliente y causa daños. El cliente aún debe estar protegido de la misma manera, independientemente del método de conexión.

    
respondido por el John Deters 31.03.2016 - 15:12
fuente
2

La pregunta depende en gran medida de la arquitectura de seguridad del software utilizada, pero sí, ha habido casos en los que la implementación del software peer to peer permitió que los malos actores accedan a los archivos en los discos duros de otras personas que participan en la red peer to peer. Del mismo modo, algunos de estos diseños también permiten a los participantes, o ISP, identificar los archivos que otros usuarios comparten de forma remota.

Esto dice que no significa que estas aplicaciones sean necesariamente inseguras; algunas podrían ser muy seguras, pero cada vez que agregue una aplicación que escuche Internet (u otros sistemas) está aumentando la superficie de ataque de la computadora. Este riesgo no es exclusivo del software peer to peer, pero es más probable que el software peer to peer tenga puertos de escucha.

Una vez más, realmente depende de los modelos de seguridad utilizados más que nada.

En general, todos los problemas de seguridad relacionados con la protección de un protocolo que no sea de igual a igual se aplicarán a los protocolos de igual a igual. Resulta que esto es un conjunto de conexiones de muchos a muchos en lugar de una a una o de una a muchas.

Nuevamente, podrían estar realmente seguros pero cada implementación será muy diferente.

    
respondido por el Trey Blalock 30.03.2016 - 07:30
fuente

Lea otras preguntas en las etiquetas