Durante los últimos días se ha difundido en diversos medios la noticia de la operación "Ransomware" que ha llevado a cabo la Policía Nacional. Puesto que ya existe mucha información en la Red sobre toda la operación nos vamos a centrar en el proceso que se está llevando a cabo para que los usuarios afectados puedan securizar sus equipos que, como ya se comentó en alguna fuente, son un total de 1525 máquinas y varias versiones del sistema operativo Windows (XP, 7, 2003 y 2008) con el servicio de escritorio remoto habilitado y credenciales débiles (o inexistentes), fácilmente deducibles con un ataque de diccionario.
El primer paso que ha seguido la Unidad Central de Investigación Tecnológica del Cuerpo Nacional de Policía es obtener autorización judicial para la cesión de los datos de las víctimas afectadas al CERT nacional encargado de ello, en este caso INTECO-CERT. Así mismo, la orden judicial fija el procedimiento de notificación en el que INTECO debe informar a los correspondientes ISP españoles de cuáles de sus direcciones IP están implicadas, para que puedan comunicar a sus clientes que sus credenciales han sido comprometidas y que sus equipos pueden todavía ser potencialmente vulnerables.
El proceso de gestión de este incidente no dista mucho de otros gestionados por INTECO-CERT. Para abordar este tipo de casos el equipo de gestión de incidencias del CERT ha ido desarrollando a lo largo del tiempo herramientas que automatizan procesos y facilitan determinadas tareas.
Para mostrar cómo se lleva a cabo la gestión de las notificaciones utilizaremos un ejemplo. En este caso, en lugar de usar el archivo con las 1525 direcciones afectadas, usaremos las direcciones IP de 4 servidores DNS públicos: Jazztel, Google, Google y Telefónica. Para ello generamos un archivo de texto plano (de nombre “ips”) con el siguiente contenido:
Con este archivo de 1525 4 direcciones IP afectadas, se hace una llamada a un servicio propio de whois desarrollado por INTECO que proporciona información personalizada sobre dominios o direcciones IP. En el caso de las direcciones IP, este servicio hace uso de los servicios whois REST disponibles de cada uno de los RIR, combinado con otras fuentes de información sobre AS, CIDR de cada uno de los AS, etc. Adicionalmente se complementa con la información del CERT nacional de cada uno de los países para una gestión coordinada en caso de incidente con alcance internacional.
En la salida podemos ver el AS, dirección IP, CIDR, País, RIR y las diferentes direcciones de correo electrónico asociadas a las direcciones IP que hemos consultado. Ahora estamos en condiciones de agrupar la información como más interese (por país, RIR, AS...), lo más útil para realizar las notificaciones a los ISP será agrupar automáticamente toda la lista por el contacto que corresponda en cada caso, con lo que generaremos un archivo de texto con las direcciones IP que se enviarán a cada ISP. En el caso de Google se enviaría -al contacto correspondiente- el siguiente archivo adjunto:
Una vez generados todos los documentos que se deben enviar adjuntos a cada ISP se debe proceder a realizar el registro del incidente en la herramienta de ticketing correspondiente; en este caso se hace sobre RTIR. RTIR permite la comunicación a través de una API RESTful, fundamental para automatizar tareas como la creación de incidentes, y sus correspondientes notificaciones, en los que hay implicados múltiples agentes y direcciones IP.
A través de otro proceso, también automatizado, se creará un incidente global (a.k.a. "Incidente" en RTIR) y se enviará una notificación a cada ISP (a.k.a. "Investigación" en RTIR).
En cada notificación se adjunta un fichero de texto con las direcciones IP de las que son propietarios junto con el mandamiento judicial. A partir de este momento los ISP disponen de 15 días para realizar la comunicación a sus usuarios afectados.
En cada notificación se adjunta un fichero de texto con las direcciones IP de las que son propietarios junto con el mandamiento judicial. A partir de este momento los ISP disponen de 15 días para realizar la comunicación a sus usuarios afectados.
Cualquier usuario afectado por este incidente, y que requiera de asistencia, puede ponerse en contacto con la dirección incidencias (@) cert.inteco.es. No obstante, algunas recomendaciones a seguir en este caso son las siguientes:
- Aplicar los parches de Microsoft.
- Comprobar las diferentes cuentas de acceso al sistema y eliminar o deshabilitar aquellas que no sean necesarias.
- Establecer contraseñas robustas (números, mayúsculas, minúsculas y símbolos con una longitud de 12 caracteres como mínimo), principalmente sobre las cuentas que tengan acceso a través del servicio de escritorio remoto.
- Aplicar políticas de seguridad que bloqueen las cuentas tras varios intentos fallidos de acceso.
- Utilizar un servidor de salto para que los administradores no accedan directamente desde la red interna a las máquinas con puerto de Terminal Service publicado en internet.
- Evitar publicar el puerto del servicio de escritorio remoto y utilizar servicios de VPN (SSL VPN/IPSec/etc.).
Este es el flujo de trabajo que se ha seguido. Dado que la generación de ficheros y notificaciones está altamente automatizada, todo el proceso se puede completar en un corto periodo de tiempo con el fin de hacer llegar la información a los afectados lo más rápidamente posible.
Artículo cortesía de Francisco Losada
2 comments :
Un sistema no actualizado, con contraseñas débiles, y con RDP expuesto a internet, merece ser atacado y owneado. Falta de responsabilidad del administrador.
Si claro Arturo, explicale tú a mis padres qué es el RDP, por qué tienen que usar una contraseña super complicada (cuando apenas saben poner una @) en vez de usar el nombre del perro o la fecha de su boda...
Y mejor no hablar de las actualizaciones, que no las aplican "por si se rompe algo"
La mayoría de los usuarios "básicos" no suele mirar más allá del icono del navegador, las fotos/música/películas y poco más.
Publicar un comentario