¿Cuáles son algunos ejemplos de ataques de lenguaje administrados y dónde puedo obtener más información?

2

Soy un desarrollador de software que principalmente programa en C # y C. Actualmente estoy estudiando la transición al desarrollo relacionado con InfoSec. La mayoría de los recursos de aprendizaje sobre la explotación que he encontrado, tanto en línea como en libros físicos, parecen centrarse en C y en otros códigos no gestionados. Sin embargo, el código administrado no está completamente a salvo de las vulnerabilidades, aunque puede ser más difícil / imposible encontrar una vulnerabilidad de memoria.

¿Qué tipos de vulnerabilidades / vulnerabilidades en el lenguaje existen que han causado daños a los programas administrados? Me refiero a las vulnerabilidades técnicas que un programador puede abrir ingenuamente en el código o que son inherentes al lenguaje en sí. Esto podría aplicarse a cualquier lenguaje administrado, pero me estoy enfocando en C # o Java aquí.

    
pregunta the_endian 26.01.2017 - 21:35
fuente

1 respuesta

1

Es muy importante tener en cuenta que las vulnerabilidades de la memoria son los únicos problemas que existen.

Descubrí que son los errores lógicos los que realmente ponen de rodillas a un programa. Varios me han llevado a DDoS o RCE exitosos. Esto ocurre en todos los idiomas, el error humano puede ser explotado fácilmente y con frecuencia.

Aquí hay una lista de algunos, sin ningún orden en particular:

Validación incorrecta de entrada

Ejemplo de mundo real: inyección. Al ser parte del Top 10 de OWASP, se puede encontrar en cualquier lugar y en cualquier idioma. Especialmente la inyección SQL y XSS se destacan.

Excepciones no coincidentes

Ejemplo del mundo real: estos más a menudo que no conducen a una DDoS. Una vez miré un programa usando hilos y bloqueos. Lástima que de forma confiable pudiera activar un estado de excepción justo después de que se adquirió el bloqueo. Ouch.

Uso de funciones inseguras

Ejemplo de mundo real: muchos lenguajes de programación (especialmente los de script) ofrecen algún tipo de eval en tiempo real. El uso de estos es una mala práctica. ¿Sabes qué más es una mala práctica? Acelerando un prototipo sin terminar como el producto real. Sucede más a menudo de lo que piensas. Sé que este tipo de relación se relaciona con la validación de entrada, sin embargo, no siempre es necesaria la participación del usuario específicamente para explotarlas.

Pro-Tipp: Mis scripts grep para estas funciones antes de que se realice una evaluación. (Fuente conocida, obviamente)

Entorno de producción frente a dev.

Ejemplo del mundo real: un programa que utiliza sockets. En su entorno de desarrollo, cada máquina tenía una cantidad 'ilimitada' de sockets disponibles. Las computadoras en las que finalmente se implementó el software no lo hicieron. Su servidor podía bloquearse fácilmente, y también era una pieza crítica de infraestructura.

Malentendido o pereza del desarrollador

Ejemplo del mundo real: ¡Este es mi favorito por mucho! Una vez miré el servidor web, construido en Python. En Python, el controlador HTTP incorporado tiene una función 'do_METHOD' para cada método HTTP. Si desea su propio controlador, subclasifique y sobrescriba estas funciones, que es exactamente lo que hicieron. Ahora tenían una función que se llamaba 'do_WORK', que no tenía nada que ver con el servicio HTTP en absoluto . Python (por razones de compatibilidad hacia adelante, solo puedo suponer) llama a estas funciones haciendo coincidir cadenas . Lo que significa que Python realmente intentaría llamar a cualquier función con el nombre de 'do_METHOD' (donde método es el método establecido por un Cliente HTTP / Solicitud) estaría disponible. El método HTTP 'WORK' no era una cosa ... Hasta entonces. Por lo tanto, ahora podría llamar 'do_WORK' temprano y desencadenar una condición de carrera. Hermosa.

Estos son solo algunos, pero siempre recuerda: Las computadoras no cometen errores, los humanos sí.

    
respondido por el FMaz 26.01.2017 - 23:31
fuente

Lea otras preguntas en las etiquetas