5 lecciones de seguridad a partir de intrusiones reales (Parte 1)

Por Greg Shipley, Tyler Allison y Tom Wabiszeczwicz

La regla no escrita en las compañías es que cuanto menos se sepa de intrusiones, mejor. Por cada conocimiento público de datos robados hay docenas de intromisiones que no afloran en las noticias.

Este código del silencio puede evitar que socios y clientes se enfaden y evita un embrollo en materia de relaciones públicas, pero dificulta que el sector como un todo aprenda de los errores y mejore las prácticas referentes a la seguridad de la información y de gestión de riesgos. Por esto, el presente artículo se basa en observaciones directas de irrupciones contra la seguridad en el mundo real acerca de las cuales hemos realizado investigaciones forenses con el fin de ayudar a las empresas a entender cómo ocurren esas intrusiones y qué pueden hacer para protegerse.

Neohapsis, la empresa para la que trabajamos, ha llevado a cabo investigaciones de algunos de los mayores robos de datos sensibles. Después de centenares de casos podemos afirmas inequívocamente que los atacantes son ahora más sofisticados que jamás antes. Saben aprovechar hábilmente controles de la seguridad laxos y prácticas operativas desidiosas y están armados de herramientas que van de las comunes de gestión de redes, a malware a la medida. Las tácticas y tecnología para asegurar la información también han avanzado, aunque no al mismo paso.

La buena noticia es que existen métodos razonables y bien entendidos para mitigar muchas de las invasiones que hemos visto; sólo que se requiere que esos métodos se implementen a mayor escala. Comenzaremos describiendo tres intrusiones reales.

Los sitios web de una empresa sirven a menudo como ‘cabeza de playa’ para los agresores. En una investigación que realizamos en una firma de servicios financieros, los delincuentes aprovecharon una vulnerabilidad que encontraron en una aplicación web en un servidor web que da la cara al público. Dicho servidor no albergaba datos críticos y no era particularmente importante para la organización y lo que obtuvieron tampoco fue particularmente impresionante. Los atacantes encontraron una vulnerabilidad de inyección en el SQL y luego usaron una función “xp_cmdshell” para que sus herramientas pudieran tener un agarre en el servidor.

Como la compañía no había considerado que el servidor o la aplicación fueran particularmente críticos, no habían establecido muchos controles de monitoreo en torno a ellos y el ataque pasó inadvertido.

Los atacantes usaron el servidor invadido como su base. Desplegaron herramientas y escáneres y pasaron varios meses mapeando meticulosamente la red sin ser detectados. Una vez encontraron los sistemas donde se contenían los datos que buscaban, simplemente copiaron la información, la colocaron en un archivo zip y se marcharon.

La organización tenía tecnología estándar en cuanto a antivirus y firewall, pero la única razón por la que se percataron del ataque fue por el uso de los datos robados en el mundo real; de no haber sido por esto, la compañía con probabilidad no se habría enterado de la intromisión.

En otra investigación llegamos a la conclusión de que los atacantes emplearon idéntico manual: ingresaron al servidor de comercio electrónico basado en web que tenía un comerciante en línea. Sin embargo, una vez que los intrusos se abrieron camino hacia los sistemas de bases de datos en busca de los números de las tarjetas de crédito, se toparon con que esos números estaban encriptados. ¡Un tanto a favor de los buenos!, ¿verdad? No fue así. Por desgracia, las claves de desencripción estaban almacenadas en los mismos sistemas, o sea, los atacantes habían conseguido literalmente las llaves del reino.

Finalmente trabajamos en varios casos en que los atacantes lograron entrar a través de sistemas de punto de ventas.

El equipo de soporte del sistema de punto de ventas del fabricante usaba aplicaciones comunes de acceso remoto, por ejemplo VNC, como modo de obtener acceso a los sistemas para soporte y reparación de averías. Pero el fabricante usaba la misma contraseña para el acceso remoto con cada cliente. Los atacantes conocieron la contraseña y simplemente corrieron escaneos conjuntos de los demás sistemas que encajaban en un perfil similar. El resto fue fácil.

Hemos sacado cinco lecciones esenciales de estas y otras intrusiones ocurridas en el mundo real:
1) tomarse en serio la seguridad de las aplicaciones web;
2) añadir capas de controles de seguridad;
3) entender los límites de la tecnología de seguridad;
4) revisar los sistemas de terceros;
5) saber que una mala respuesta a un incidente es peor que no responder al incidente.

1) Tomarse en serio la seguridad de las aplicaciones web
Las aplicaciones web suelen ser el trampolín de los atacantes. Continuamos viendo equipos IT que han parchado los sistemas y desplegado firewalls, pero estos equipos quedan desprotegidos por aplicaciones con fallas de fácil explotación.

La mejor defensa de una empresa es integrar la seguridad en el ciclo de vida del desarrollo de aplicaciones. Construir código con menos defectos en la seguridad proporciona un mayor rédito en seguridad que pegar ‘curitas’ a las aplicaciones vivas. El uso de tecnología de escaneo de las aplicaciones web, como AppScanner (IBM) o WebInspect (HP), para asegurarse de la calidad o los procesos de revisión es crítico. Las compañías que compran aplicaciones, en vez de construirlas, deberían revisar esas aplicaciones o solicitar a los fabricantes que realicen estimaciones de la seguridad y que terceros puedan comprobar.

Los firewalls en las aplicaciones web sirven como controles secundarios de la seguridad. Estos productos están diseñados para detectar ataques conocidos e identificar la conducta sospechosa que pudiera indicar que ha ocurrido un intento de intromisión. Con todo, no son más que una ayuda, pues no llegan al síntoma original, que son las prácticas de desarrollo defectuosas y aplicaciones vulnerables. Un firewall en aplicaciones web puede ganar tiempo, pero las compañías actúan tontamente si no solucionan las causas fundamentales del riesgo.

Artículos relacionados

1. Las 46 fallas de seguridad del iPhone 3.0
2. Puntos flacos de seguridad en iPhone, expuestos en YouTube
3. En la era del Facebook, los problemas IT son pesadillas para el CIO (Parte 2)
4. En la era del Facebook, los problemas IT son pesadillas para el CIO (Parte 1)
5. Resumen de la Rolling Review: seguridad de los smartphone