Llegamos a ustedes gracias a:



Reportajes y análisis

Aterradoras APT: 6 lecciones aprendidas

[15/03/2014] Las amenazas persistentes avanzadas (APT, por sus siglas en inglés) han ganado mucha atención en los últimos tiempos, merecidamente. Las APT son, posiblemente, el problema de seguridad más peligroso para las organizaciones empresariales de hoy, habida cuenta de su naturaleza específica.
Un ataque de APT es iniciado típicamente por una organización profesional con sede en un país diferente al de la organización víctima, lo que complica la aplicación de la ley. Estas organizaciones de hackers a menudo se dividen en equipos especializados que trabajan juntos para infiltrarse en redes y sistemas corporativos, y extraer la mayor cantidad de información valiosa como sea posible. Hackear ilegalmente otras empresas es su trabajo del día. Y la mayoría es muy buena en eso.
En opinión de los expertos, las APT han comprometido la infraestructura de información de cualquier empresa que sea relevante. La pregunta no es si usted ha sido comprometido por una APT, sino si se ha dado cuenta de ello.
He ayudado a compañías a combatir y prevenir las APT por casi una década. En ese tiempo, he amasado una cantidad de historias de guerra desde las trincheras de la seguridad de TI. He aquí algunos de los mejores cuentos de la vida real, no solo de la persecución, sino de las lecciones aprendidas.
Historia de guerra de APT N° 1. Los ojos de las APT lo están vigilando
Una vez pasé más de un año respondiendo un ataque de una APT en una compañía multinacional que estaba involucrada en todo, desde satélites de alta tecnología y armas hasta refrigeradoras y educación. Cuando recibí la llamada, el cliente ya había sido golpeado por otros dos ataques de APT, lo cual no es inusual. La mayoría de las empresas que descubren un APT generalmente averiguan que el mismo ha estado ahí durante años. Un cliente con el que trabajé fue comprometido por tres equipos de la APT diferentes, durante los últimos ocho años -no es de extrañar en lo más mínimo.
La multinacional tomó finalmente en serio la lucha contra el ataque. El equipo completo de TI fue llamado en conjunto para responder; se creó una fuerza laboral grande con un único propósito, en la que estuvieron todos los expertos relevantes. Se decidió que varios meses en el futuro todos los passwords deberían resetearse.
Podría preguntarse por qué el retraso en reestablecer los passwords. El restablecimiento de passwords siempre debe ser programado para el futuro, en estas situaciones, porque no resulta útil el cambio de contraseñas para eliminar una APT, si no puede garantizar que los malos puedan regresar. Identifique las debilidades más relevantes, arréglelas, luego cambie los passwords. Esa es la mejor defensa.
Como en casi todas las empresas con las que trabajé, todos los involucrados juraron guardar el secreto. Se establecieron palabras código, de manera que el equipo pudiera discutir diversos aspectos del proyecto en e-mails (posiblemente monitoreados), sin alertar a los intrusos o empleados aún no comprometidos.
En este caso, el gran día de restablecimiento de password fue programado para que coincida con el juego anual de baseball de la compañía, el cual había sido instituido para incrementar la moral de los empleados. Debido a esto, el proyecto fue llamado juego de baseball empresarial, con el nombre de la compañía cambiado aquí para proteger su identidad. A partir de ese momento en adelante, nadie mencionó APT o restablecimiento de password. Todo era acerca del juego de baseball.
Los sistemas de la compañía estaban totalmente comprometidos, así que se compraron nuevas laptops y routers inalámbricos. Todo el trabajo relativo a las APT fue realizado en esas laptops sobre una red inalámbrica segura, para prevenir cualquier filtración accidental de información acerca del proyecto, independientemente de la palabra código utilizada.
Una de las facetas del proyecto era hacer frente a la sobreabundancia de administradores de dominio en la empresa. Eran demasiados -en total, más de mil. Establecimos el campamento en una de las salas ejecutivas de reuniones que utilizamos en el curso del proyecto y comenzamos a discutir qué hacer.
No podíamos decidir qué administradores de dominio eran en realidad necesarios y cuáles podíamos deshabilitar, así que decidimos deshabilitarlos todos el día del juego de baseball de la compañía, y forzar a aquellos que realmente necesitaban acceso de administrador de dominio a reafirmar su necesidad. Hicimos un borrador de un formulario de solicitud de acceso de administrador de dominio de uno de los proyectos en una de las laptops del proyecto.
Debíamos enviar los formularios justo antes del día del juego de baseball de la compañía, de modo que todas las personas que necesitaran una cuenta de administrador de dominio pudieran tener una a tiempo para ser preparada.
A la mañana siguiente, alrededor de las 7:30 am, entré a la misma sala ejecutiva de conferencias. El gerente de proyecto ya estaba ahí. Me miró y dijo: aquí están nuestras dos primeras solicitudes de administrador de dominio, y las volteó hacia mí.
¿Qué quiso decir con solicitudes de administrador de dominio? El formulario no estaba fuera de la fase de borrador y no estaba programado para salir en meses. Pero ahí estaban, dos formularios de solicitud de acceso de administrador rellenados. Tenían algunos errores pequeños pero notables, así que era obvio que no eran de nuestro borrador original. Cada uno fue llenado por miembros de equipo que pertenecían a subsidiarias extranjeras, que actualmente tenían acceso de administrador de dominio. ¿La razón por la que estaban solicitando la restitución del acceso de administrador de dominio? Porque el acceso actual iba a ser cortado el día del juego de baseball.
Hasta hoy no puedo creerlo. Estaba sosteniendo dos formularios que no deberían existir. Los únicos borradores estaban en una laptop en una red aislada. Nuestro precioso código de proyecto secreto había volado. El asombro pasó de miembro en miembro del equipo junto con los formularios mientras les dábamos las noticias.
Después de mucha investigación, averiguamos que la APT, liderada por gente interna, se había infiltrado en la sala de conferencias usando los proyectores de video y los sistemas de video conferencia. Estaban viendo y analizando todas nuestras reuniones supuestamente secretas. Su único error fue no entender que el formulario aún no existía en realidad y que no estaba sino programado para ser enviado hasta meses después. Gracias a Dios, por las barreras del idioma.
Lección: Si su equipo de la sala de conferencias está conectado a la red y tiene la capacidad de grabar voz o video, asegúrese de deshabilitarlos antes de efectuar reuniones.
Historia de guerra APT N° 2: No todas las APT son tan avanzadas como creen los expertos
Esta es la historia de un equipo de APT que había tomado control total de la red de una empresa. Estaban creando activamente conexiones en toda la red, de día o de noche, para cuando fui llamado. Ellos fueron más allá, cuidando si eran descubiertos.
Es casi seguro que las APT superen todos los hashes de passwords y usen herramientas de tipo pass the hash (PtH) para apoderarse del resto de una red de una organización. En este caso, el cliente decidió que era tiempo de deshabilitar esos débiles passwords hashes de administrador de LAN (LM) que Microsoft había estado recomendando deshabilitar por diez años, e intentando deshabilitar por defecto al menos desde el 2008. Esta APT en particular estaba usando los hashes de password de LM para hacer el trabajo sucio.
Le dije al cliente que el propósito no funcionaría porque, por defecto, existían al menos dos tipos de hashes de password de Windows en la base de datos de autenticación de Microsoft: los hashes de LM y NT. Los atacantes habían descargado ambos tipos, y la herramienta PtH con la que estaban trabajando podía usar ambas. Inclusive le mostré al cliente cómo la herramienta del atacante tenía la sintaxis incorporada para cambiar entre hashes LM y NT, una característica muy común de las herramientas de ataque PtH. Peor, aunque deshabilite el almacenamiento de hashes LM, aún son creados en memoria cuando alguien se loguea. Suena loco, pero es como funciona Windows.
El cliente no pudo ser disuadido. A pesar de mi protesta, se deshabilitó los hashes LM y se resetearon los passwords. Ahora las bases de datos locales y el Active Directory contenían hashes de passwords LM no utilizables. ¿Ya se imagina lo bien que funcionó esto?
Bueno, funcionó -porque el equipo de APT nunca usó otro hash de password para ejecutar sus ataques. La verdad es que se movieron hacia otros métodos (ver abajo), pero los ataques PtH se detuvieron. Resultó que el equipo APT ni siquiera conocía sus propias herramientas. Ya puede imaginar la discusión que deben haber tenido internamente cuando desaparecieron todos los haches LM, incluyendo hombros encogidos, lluvia de ideas y nuevas estrategias.
Lección: Avanzado puede incluir el nombre de las APT, pero no todos los atacantes de APT son tan avanzados. Además, a veces los expertos se equivocan. Técnicamente, yo no estaba equivocado, pero eso no evitó que el resultado que esperaba el cliente fuera el mismo. Me humilló.
Historia de guerra APT No 3: El remedio puede ser el veneno
Como consultor de tiempo completo de Microsoft, frecuentemente me piden trabajar en proyectos de APT liderados por otras compañías; soy un recurso, no un líder de proyecto. Hay una compañía consultora de seguridad con la que he trabajado lo suficiente como para conocer a muchos de los miembros de su equipo informalmente, o hasta personalmente. Entendemos cuáles son nuestros roles -dependiendo de quién llega primero, se hace amigo del CIO, y asume el liderazgo. Nuestras asociaciones han sido siempre amigables, aunque competitivas. Después de todo, es mejor ser un líder que un seguidor.
Esta firma de consultoría de seguridad es bien conocida por combatir las APT, e inclusive vende software de detección para ayudar. Frecuentemente, en contratos, vende exitosamente su software y lo instala en todas las computadoras del ambiente. Estaba muy acostumbrado a ver su servicio ejecutándose en la barra de tareas de Windows.
En esta historia en particular, la firma consultora de seguridad llegó primero, salvó el día, y comenzó a trabajar. Tuvo éxito en instalar su software en toda la organización y no había estado en el lugar por casi un año. Hasta donde todos sabían, el cliente había estado libre de APT desde el remedio inicial. Al menos, nadie había detectado señales.
Soy un gran fan de los honeypots (olla de miel). Un honeypot es un software o un dispositivo que existe simplemente para ser atacado. Puede ser una computadora no utilizada, un router, o un servidor. Los honeypots pueden imitar cualquier cosa, y son geniales para detectar adversarios previamente no detectables, así que recomiendo este sistema frecuentemente. Este puede ser una computadora fuera de uso, a la cual ninguna persona o servicio debería conectarse. Cuando un hacker o un malware se conecta, el honeypot envía una alerta que puede disparar una respuesta inmediata a incidentes.
En este caso, pasé algunos días ayudando al cliente a desplegar algunos honeypots. La mayoría de clientes me preguntan cómo vamos a atraer a los hackers a los honeypots. Siempre me río y la respuesta es la misma. De hecho, cada honeypot que he configurado ha detectado actividad nefasta en uno o dos días. Estos nuevos honeypots no eran distintos.
Detectamos intentos de logueo a la red, procedentes de diversas estaciones de trabajo, ninguna de las cuales tenía una razón legítima para conectarse. Extrajimos algunas de esas estaciones de trabajo e hicimos un examen forense de sus discos duros. Encontramos que la APT había instalado un troyano de acceso remoto en cada una de ellas. ¿Cuál era el nombre del troyano? El mismo que el del software de detección anti APT. Los chicos malos habían reemplazado el software legítimo anti APT con un troyano, y resultó que lo hicieron en casi todas las computadoras.
Esto explicaba algunas cosas, como por qué no había sido detectado ninguna APT. Pero la pregunta más grande era cómo se instaló en primer lugar. Resultó que el brillante desarrollo del cliente había sido comprometido en su ambiente de desarrollo, y el troyano era parte del build.
Lecciones: Primero, verifique la integridad de sus builds; evite modificaciones no autorizadas o invente alguna forma de detectarlas. En segundo lugar, los honeypots son una gran manera de detectar actividad maliciosa. Tercero, siempre busque e investigue conexiones de red extrañas desde lugares inesperados.
Historia de guerra APT No 4: Toda su base PKI nos pertenece
Los ataques APT sobre servidores de infraestructura de llave pública (PKI – Public Key Infraestructure) solían ser raros. De hecho, hasta hace dos años, personalmente nunca había tratado una APT donde estuvieran involucrados los servidores PKI. Ahora, es algo bastante común. Pero la historia más relevante es una donde el PKI se convirtió en un acceso físico en un área confidencial.
Este cliente en particular usaba sus servidores de PKI para crear tarjetas inteligentes para empleados, que eran usadas no solo para loguearse a las computadoras, sino para tener acceso físico a los edificios de la compañía y otras infraestructuras.
El servidor raíz de CA (certification authority) del cliente era una instancia virtual establecida, deshabilitada en un servidor host VMware. Los chicos malos la habían encontrado, lo copiaron fuera del sitio, crackearon el password (débil) local de administrador, y generaron su propio CA subordinado de confianza. Usaron este CA para emitir ellos mismos su acceso de PKI a todo lo que pudieron.
Lo que más me sorprendió fue el video que mi cliente me mostró de dos hombres desconocidos haciéndose pasar como empleados. Usaban las tarjetas inteligentes falsas que habían creado, habían estacionado sus autos dentro del parqueo seguro de la compañía, caminaron hasta el edificio, hasta la entrada de empleados, y fueron hasta el piso donde se guarda información confidencial.
Mi cliente pudo decirme qué ocurrió después de eso, o qué se llevaron, pero estoy seguro de que no estaban felices. Había mucha tensión en la sala. Fui invitado para ayudarlos a crear una nueva PKI, y a migrar a la compañía a un ambiente de PKI con mejor seguridad.
Lección: Proteja sus servidores de PKI CA. Los CA fuera de línea deberían estar así: fuera de línea. No deberían ser deshabilitados o puestos en la red con sus tarjetas de red deshabilitadas, sino que deberían estar fuera de la red, almacenados en un lugar seguro y no deberían ser fáciles de comprometer. Las claves privadas de CA deberían ser protegidas por un appliance Hardware Storage Module, y todos los passwords relacionados deberían ser muy largos (15 caracteres o más) y complejos. Además no hace daño buscar y monitorear si otros CA no autorizados son agregados como CA confiables.
Historia de guerra APT No 5: No olvide las cuentas que se supone que no debería tocar
Como se mencionó arriba, la mayoría de eventos de recuperación de APT implican resetear passwords. Si va a reestablecer los passwords, reestablezca todas las cuentas, aunque esto es más fácil de decir que de hacer. Todos mis clientes se alistan a reestablecer todos los passwords, pero cuando descubren cuánto interrumpirá esto en el negocio, rápidamente retroceden en sus objetivos. Es mucho más fácil ser despedido por causar una interrupción significativa en el negocio que por no echar a todos los hackers.
Este cliente en particular estaba listo y era increíblemente minucioso. El plan era no solo reestablecer todos los usuarios y cuentas de servicio, sino también las cuentas de computadora. Casi ninguna empresa hace esto, especialmente cuando se trata de resetear el servicio y las cuentas de computadora. Rayos, me mareo si reestablecen todas las cuentas de usuarios elevadas, porque es difícil. Se reirá sólo si no ha pasado por esta tarea.
El día del restablecimiento de password llegó y pasó. Hubo interrupciones de servicio significativas, algunas de las cuales fueron lo suficientemente molestas que tuvimos que informar al CEO. Sin embargo, para el final de la semana, habíamos reestablecido todos los passwords.
En unos cuantos días, la APT poseía todo de nuevo, tomando todos los e-mails, controlando todas esas cuentas elevadas, incluyendo las cuentas de seguridad de TI. Era como si el restablecimiento de contraseñas nunca hubiera ocurrido. Estábamos perplejos. Como mejor sabíamos, habíamos removido los huecos fáciles, educado a los empleados, y no pudimos ver ninguna evidencia de puertas traseras de troyanos.
Por desgracia, hay una cuenta integrada de Windows llamada krbtgt que es usada para la autenticación de Kerberos. No debería tocarla, removerla, o según sabíamos previamente, cambiar su password. En realidad no debería ser una cuenta de usuario que se muestre en las herramientas de administración de cuentas, y este equipo de APT lo sabía.
Como aprendí en proyectos sucesivos, la krbtgt es una técnica go-to. Después de que un equipo APT compromete un ambiente, agregan la cuenta krbtgt a otro grupo elevado. Debido a que los clientes usualmente la abandonan, inclusive durante un restablecimiento de contraseñas, puede ser explotada como una cuenta backdoor go-to. Gran idea, si es un hacker malicioso.
Mi cliente reestableció los passwords de sus cuentas krbtggt y todo lo demás (de nuevo). Por lo que yo sé, no ha detectado ningún otro problema. Tenga cuidado de que al resetear las cuentas krbtg ocasionará de todas maneras problemas de autenticación. Es molesto. Pero si tiene que hacerlo, también tendrá que pasar por ello.
Lección: Si va a resetear todas las cuentas, asegúrese de que sabe lo que significa ¨todas¨.
Historia de guerra APT No 6: La sobrecarga de información estimula la innovación APT también
Mi última historia no es sobre un solo cliente, y muestra la evolución de las APT con los años. Los primeros practicantes de las APT debían recolectar inmediatamente todo lo que pudieran tan pronto irrumpían. Absorbían como sifón viejos e-mails e instalaban bots para que se les envíe los nuevos correos. Muchas veces debían instalar troyanos para monitorear la red y las bases de datos, y si se creaba un contenido nuevo, debían copiarlo.
En otras palabras, muchas compañías tenían servicios de backup por los cuales no estaban pagando.
Eso fue en los viejos días. En el mundo en el que las bases de datos de terabytes ya no nos sorprenden, las APT tienen un problema. Cuando obtienen acceso total a una red y aprenden dónde está almacenada toda la información, tienen que ser más selectivos. Si bien antes debían recoger todo, lo que vemos ahora es una selección muy discreta. Las APT más avanzadas construyen sus propios motores de búsqueda, a veces con sus propias API o tomando prestadas API de otros conocidos motores de búsqueda, para buscar datos específicos. Solo pueden salir con gigabytes de datos al día, pero lo que tienen es altamente selectivo.
Lección: Las APT tienen los mismos problemas para encontrar y administrar datos que usted. No les permita indexar su base de datos mejor que usted.
Roger A. Grimes, InfoWorld (EE.UU.)