Problemática Actual

El código Exploit, independientemente del lenguaje en el que esté desarrollado (C, C++, Python, Perl), tiene como objetivo aprovecharse de una vulnerabilidad puntual y permitir a un atacante acciones, que van desde causar una denegación de servicio hasta ejecutar código arbitrario en el sistema.

Actualmente, el tiempo que media entre el reporte de una vulnerabilidad, con su consecuente publicación del parche, y la generación y publicación de código Exploit se está reduciendo considerablemente. Por el contrario, la probabilidad de que un atacante explote una vulnerabilidad aún no parcheada, va en considerable aumento.

Asimismo, muchas vulnerabilidades pueden atenuarse con sencillez (workaround) mientras el parche es evaluado en un ambiente de prueba. Sin embargo, en casos más extremos, la posibilidad de mitigar el riesgo desciende por diferentes razones, a saber: la carencia de recursos técnicos y la deficiencia de skills de los Recursos Humanos que administran la tecnología, que dejan como única solución “Aplicable” el parche, que debe ser previamente testeado y no siempre soluciona el problema. Por su parte, el código Exploit es público y cualquiera que posea las habilidades necesarias puede utilizarlo.

Con frecuencia el parche no es aplicado (o es demorado en su aplicación) a causa de una falsa creencia de los administradores de seguridad, que suelen pensar que como no existe Exploit para dicha vulnerabilidad, nadie podrá aprovecharse, cuando en realidad el código puede existir de manera no explícita y ser explotado con éxito.

Caso Práctico

Ahora pasemos a un ejemplo concreto: Microsoft publicó dos parches que solucionaban las siguientes vulnerabilidades. Por otro lado, el mismo día y con muy pocas horas de diferencia, se conocían los códigos para aprovecharse de ellas.

LSASS Vulnerability CAN-2003-0533
PCT Vulnerability CAN-2003-0719

Dichas vulnerabilidades, si bien afectan a la misma plataforma, son harto diferentes en su tratamiento. Continuando con lo que se mencionó antes, ambas pueden paliarse con la aplicación del parche, pero sólo una puede mitigarse fácilmente hasta que éste sea testado y aplicado.

LSASS Vulnerability CAN-2003-0533 se genera debido a un Stack Overflow en LSASRV.dll, del Local Security Authority Subsystem Service (LSASS). Un atacante, con acceso al puerto TCP 139 del sistema afectado, puede sin complicaciones tomar control del equipo a través de una shell, situación fácilmente mitigable si se siguen las recomendaciones a la hora de configurar las reglas de filtrado de un firewall, lo que da tiempo para testear el parche en un ambiente de prueba y reduce la probabilidad de ocurrencia de un ataque.

Resultaría evidente tener el puerto TCP 139 filtrado por un firewall, pero los hechos posteriores demostraron lo contrario. En este sentido, si una vulnerabilidad es muy masiva (la cantidad de sistemas afectados es elevada) el Exploit que ataca a un sistema, se convierte en un Worm que embiste indiscriminadamente miles de sistemas, y auto replica mediante su rutina de ataque. Aquí podemos mencionar el caso del Slammer que dejó sin servicio a los cajeros automáticos del Banco Nacional de los Estados Unidos de América.

PCT Vulnerability CAN-2003-0719 se produce a través de un Buffer Overrun en el Protocolo PCT (Private Communications Transport) y es parte de las librerías SSL de Microsoft. Dicha vulnerabilidad afecta a los sistemas que tienen SSL habilitado sin el correspondiente parche de seguridad, o sea, a los servidores que estén prestando servicios de HTTPS a través de puerto TCP 443.

Si lo comparamos con el apartado anterior, las posibilidades de mitigación están realmente limitadas, ya que no se puede filtrar el puerto mediante el cual se está ofreciendo servicios. Tampoco se puede aplicar el parche rápidamente, sin antes haberlo controlado en un ambiente de pruebas, y haber verificado que no existe ninguna anomalía en el funcionamiento del sistema.

Hay diferentes tipos de Workaround alternativos, que podrían darle solución al problema puntual planteado en el ejemplo, a saber:

• Wrapper: redirección de puertos vía SSL de 443 al puerto 80.
• Agregar una regla de detección del ataque al IPS (Patrón de Trafico).
• Incrementar la sensibilidad de los dispositivos de monitoreo.

También existen distintas metodologías de remediación, como la de Remediation by Simulation Attack, que aplica soluciones a vulnerabilidades, planteando y simulando escenarios de ataques y sus posibles soluciones. Para la elección de la estrategia se tienen en cuenta factores tales como la efectividad, la relación costo-beneficio de la implementación, y el costo administrativo y de recursos, entre otros.