OVH NEWS | ACTUALIDAD, INNOVACIÓN Y TENDENCIAS IT


Descubrir, entender y adelantarse









31/05/2017
Compartir

Artículo redactado por Sébastien Mériot & Hugo Bonnaffé


WannaCry: enjúguese las lágrimas… ¡y permanezca alerta!


Aunque la pandemia WannaCry ha afectado principalmente a los sistemas informáticos de las empresas, no ha perdonado a los servidores que utilizaban antiguas versiones de Windows no actualizadas. Ante un fenómeno de estas características, ¿qué medidas debe tomar un proveedor de alojamiento? La respuesta no es sencilla, ya que la responsabilidad recae esencialmente en los usuarios, que son los únicos que pueden mantener sus sistemas actualizados. No obstante, OVH ha hecho cuanto estaba en su mano para frenar la aparición de WannaCry en los servidores vulnerables de sus clientes y para contener esta epidemia especialmente virulenta. Aprovechamos para recordar algunas medidas de seguridad informática muy útiles para luchar contra este tipo de amenazas, que no parece que vayan a desaparecer.



Nuestras estimaciones


Probablemente haya que vivir en una cueva (o tener la mente demasiado ocupada en la actualidad política) para no haber oído hablar estos últimos días de WannaCrypt0r. Este ransomware, que explota una vulnerabilidad en el sistema de recursos compartidos de Windows, se ha extendido como la pólvora en todo el mundo. Los medios de comunicación se han hecho eco del asunto, divulgando prolijamente los sinsabores de empresas como Telefónica en España, FedEx en Estados Unidos o Renault en Francia, o las desventuras de los hospitales públicos ingleses, que se han visto obligados a aplazar operaciones por no poder acceder a los expedientes de los pacientes. ¿Cómo se ha localizado esta ola de ransomware en OVH y qué medidas se han tomado? Les contamos por qué el equipo de seguridad se ha perdido la investidura del nuevo presidente de la república francesa en televisión y no ha dormido mucho esta semana.



WannaCry (como se ha bautizado a este ransomware, sin duda en referencia a la reacción de las víctimas) podría haber infectado entre 200 000 y 400 000 máquinas de todo el mundo. Y esta cifra, desafortunadamente, no deja de aumentar, ya que la epidemia no se ha extinguido. Incluso tenemos razones —más adelante volveremos sobre ello— para temer un recrudecimiento de las infecciones, debido a la aparición de variantes de WannaCry en los últimos días. Sin embargo, el fenómeno sigue siendo relativamente marginal en OVH, ya que solo habría afectado a 5000 direcciones IP, de las más de dos millones que gestionamos. Estas son nuestras últimas estimaciones, basadas en nuestra red de honeypots —máquinas que pertenecen a OVH, gestionadas por el equipo SOC (Security Operations Center), expuestas voluntariamente en la red con el objetivo de atraer amenazas de todo tipo (malware, black hat hackers, phishing…) que circulan en la red, para así poder hacerse una idea de su peligrosidad y su velocidad de propagación—. Aunque el número de máquinas infectadas dentro de la red de OVH parece escaso con respecto al tamaño de nuestro parque de servidores, eso no ha impedido que nos movilicemos para evitar la contaminación de más máquinas vulnerables —nos referimos a las máquinas que OVH pone a disposición de sus clientes, que son vulnerables por no haber sido actualizadas por sus responsables; WannaCry no ha afectado a los servidores del sistema de información de OVH, como detallaremos más adelante—.



Pero ¿qué es WannaCry exactamente?


Para empezar, recordemos qué es WannaCry. Se trata de un ransomware o «programa de secuestro». Este tipo de malware secuestra los datos de sus víctimas, por lo general cifrándolos, para a continuación reclamar una cantidad de dinero a cambio de permitir recuperarlos. En la mayoría de los casos el rescate debe pagarse en bitcoins para dificultar la trazabilidad de los flujos financieros. Este procedimiento no es nuevo y no ha dejado de proliferar desde 2005, ya que se trata de un «negocio» muy lucrativo: el FBI ha estimado el mercado del ransomware en algo más de 830 millones de dólares en 2016. Para que se haga una idea, ese era el tamaño del mercado inglés del SVOD (vídeo bajo demanda con suscripción) en 2015… o el equivalente a las pérdidas de Uber en el tercer trimestre de 2016 —elija la comparación que más le guste, no hemos encontrado ninguna mejor…—.



Captura de pantalla de la ventana que aparece en el monitor de las víctimas cuando la máquina ha sido infectada por WannaCry.


Por lo general, el ransomware se propaga mediante mensajes de correo electrónico maliciosos que incluyen algún documento adjunto, como una falsa factura, que suele ser un archivo de Word o un PDF. Una vez abierto, el documento adjunto ejecuta un código maligno (JavaScript, macro, VBScript…) que descarga de un servidor la carga activa, que será la que se encargue de cifrar los datos de la víctima.

En el caso de la reciente epidemia de WannaCrypt0r, es importante destacar que se trataba de la versión 2.0 del ransomware. Lógicamente, los diseñadores del programa no publican release notes pero, para resumir, la versión inicial del malware, cuya propagación se realizaba mediante emails maliciosos, no tuvo el éxito esperado por sus creadores. La versión 2.0, más eficaz, se basa en la explotación de una vulnerabilidad en el bloque de mensajes del servidor (SMB) de Windows, utilizado para compartir recursos dentro de una misma red. Este fallo, corregido por Microsoft el 14 de marzo de 2017 en el boletín MS17-010, permite ejecutar código arbitrariamente en una máquina remota que exponga públicamente el servicio de recursos compartidos de Windows. Así es como ha conseguido infectar máquinas desactualizadas, en su mayoría con Windows Server 2008 y versiones anteriores del sistema operativo de Microsoft. Recordemos que desde Windows Server 2012 y Windows 10, Microsoft configuró el cortafuegos de modo que este servicio no estuviera expuesto por defecto, lo que explica que el número de víctimas no haya sido mayor. Para entender la continuación de la historia debe saber que el servicio de recursos compartidos se expone a través del puerto TCP/445.

En la familia de los programas malignos o «malware», distinguimos varios subtipos. Acabamos de abordar el ransomware, cuyo objetivo es secuestrar el equipo cifrando sus datos. Pero, en el caso de WannaCry, se explota una vulnerabilidad para propagar un ransomware. Ahora bien, la explotación de vulnerabilidades es propia de los gusanos (worm). De modo que WannaCry es un híbrido, que combina un gusano y un ransomware.



Flashback: Blaster


¿Se acuerda del gusano Blaster? En agosto de 2003, este gusano infectó varios cientos de miles de ordenadores con Windows 2000 y Windows XP explotando una vulnerabilidad que Microsoft tardó semanas en parchear, forzando al ordenador a reiniciarse al cabo de 60 segundos. Blaster escaneaba entonces internet buscando otros ordenadores a los que infectar. Así, su propagación se basaba, como en el caso de WannaCry, en un vector de infección mediante peer-to-peer (P2P).



Cuando nuestros tarros de miel empiezan a zumbar


El viernes 12 de mayo ya circulaban unos tuits del usuario @MalwareHunterTeam relativos a una nueva amenaza llamada WannaCry que se extendía rápidamente. Por la tarde, empezaron a publicarse artículos que mencionaban la explotación del fallo ya corregido por Microsoft. Luego, alrededor de las 9 de la noche, nuestro equipo de soporte técnico de Canadá se sorprendió al recibir un número extraordinariamente elevado de tíquets relacionados con ransomware.

Aunque nosotros, desde nuestra posición de proveedor cloud, luchamos contra la proliferación del ransomware y el malware, se trata de un arduo combate, discretamente disputado por el equipo SOC de OVH, que requiere complejas investigaciones para llegar hasta las organizaciones criminales que los originan y denunciarlas ante las autoridades para que sean desmanteladas. Con todo y con eso, en el día a día es imposible erradicar el fenómeno mediante otras acciones que la prevención para reducir el principal riesgo, que es el factor humano. En la práctica —los responsables informáticos lo saben— es necesario mantener el parque informático actualizado, con todas las dificultades que ello conlleva, ya que hay que tener en cuenta la posible incompatibilidad de las aplicaciones utilizadas con la nueva versión del sistema operativo —razón por la que no es tan sorprendente[1] ver todavía tantas máquinas que funcionan con versiones de Windows anteriores a 2008—. Paralelamente, hay que sensibilizar continuamente a los trabajadores sobre un segundo vector de infección que son los archivos adjuntos a los mensajes de correo electrónico que reciben, e incluso realizar, como hacemos en OVH, campañas de prueba mediante emails trampa para medir la vulnerabilidad de los trabajadores y seguir dando formación a los imprudentes sobre buenos hábitos informáticos. Por último, frente al ransomware, como ante la mayoría de las catástrofes informáticas que afectan a los datos, existe una medida elemental pero increíblemente eficaz: ¡tener una copia de seguridad de los datos!

Todo esto para explicar que es bastante inusual tener que cancelar una cena romántica un viernes por la noche por una campaña de ransomware. Pero esta vez era un caso especial. Teníamos la información de que WannaCry se propagaba mediante EternalBlue, la explotación de una vulnerabilidad atacando el puerto TCP/445. Ahora bien, usted probablemente no lo supiera, pero hace muchos años que el puerto TCP/445, utilizado para compartir recursos en Windows (CIFS), es filtrado en los routers de borde de la red de OVH por motivos de seguridad[2]: está demostrado que el puerto TCP/445 (SMB) es un vector de propagación de malware y OVH consideró que este puerto solo debería estar abierto en redes privadas, de modo que si un usuario quiere comunicar mediante este puerto de forma remota, debe pasar por una VPN (red privada virtual). Por consiguiente, es imposible conectarse a una máquina alojada en OVH a través del puerto TCP/445, a menos que se haga desde una IP perteneciente a OVH —el filtrado del puerto no se aplica dentro de la red de OVH para que el sistema de recursos compartidos puede ser utilizado por los clientes con fines legítimos—. Así pues, OVH estaba a salvo de la contaminación de las máquinas de su red…

Sin embargo, durante la noche del viernes al sábado, nuestros honeypots hicieron saltar las alarmas debido al aumento repentino del número de escaneos procedentes de direcciones IP pertenecientes a la red de OVH. Entonces abrimos inmediatamente varias líneas de trabajo paralelas: la búsqueda metódica del «paciente cero» —el equipo desde el que WannaCry había conseguido penetrar en la red de OVH para propagar la infección—; la ingeniería inversa del ransomware para entender su funcionamiento; la implementación de medidas para impedir el contagio a otras máquinas vulnerables y, por supuesto, la comprobación exhaustiva de las máquinas de nuestro sistema interno.



¿Cómo funciona WannaCry y por qué ha afectado más a las empresas que a los particulares?


Con la ingeniería inversa de WannaCry, nuestra prioridad era averiguar cómo se propaga el gusano y cuál es su estrategia para recorrer internet en búsqueda de máquinas vulnerables que contaminar. Hemos observado que WannaCry abre dos métodos de escaneo, que después ejecuta de manera concurrente (multithreading). El primero consiste en escanear la red local para infectar las máquinas que están conectadas a ella. Para evitar ser detectado por las herramientas de detección de intrusiones (IDS), el código no excede el límite de diez intentos de intrusión simultáneos; una precaución que parece indicar que el ataque estaba especialmente dirigido a las redes internas de las empresas.

El segundo método permite escanear internet creando una IPv4 válida de manera aleatoria, generando uno a uno los cuatro octetos que componen la dirección y eliminando las IP que empiezan por 127 o por un octeto mayor o igual que 224. Un hecho interesante: cuando se detecta una IP vulnerable, parece que el gusano intenta escanear el rango entero (lo que corresponde a las 254 IP vecinas). Según nuestras observaciones, las máquinas infectadas son capaces de escanear aproximadamente 30 direcciones IP por segundo.



Monitorización de un VPS infectado por WannaCry el 15 de mayo de 2017: el cifrado consume muchos recursos de procesador y memoria, y luego el escaneo de internet mantiene una ligera actividad de CPU.


Otro hecho interesante: el plazo de expiración del intento de intrusión. Una técnica utilizada por los expertos en seguridad para ralentizar la propagación de este tipo de malware es monopolizar voluntariamente la conexión para impedir que uno de los hilos escanee —haciendo que se quede esperando la respuesta del servidor—. Estadísticamente, así sería posible detener todos los hilos e interrumpir los escaneos. Esta técnica se llama «tarpit». En este caso, parece que el creador del gusano se ha tomado la molestia de establecer un plazo de expiración de una hora para abandonar la conexión si el servidor no responde. Un último elemento revelado por la autopsia del código: las máquinas comprometidas también son infectadas por DoublePulsar, un backdoor (puerta trasera) posiblemente utilizado por el Equation Group para inyectar malware en la víctima. Por el código de WannaCry, parece que este backdoor podría reutilizarse para volver a infectar una máquina posteriormente.

¿Qué conclusiones extraemos del funcionamiento de WannaCry? En primer lugar, que su código convierte a las empresas en los principales vectores de contagio. Algunas elecciones en los algoritmos parecen apuntar a eso: los parques informáticos de las empresas suelen ser relativamente homogéneos y hay muchas probabilidades de encontrar rápidamente máquinas vulnerables en una red local, mientras que el escaneo de todo internet es estadísticamente menos eficaz. Dicho esto, si bien la infección de servidores es menos masiva que la de equipos de trabajo de empresas, no por ello es menos crítica desde el punto de vista de la propagación del ransomware, ya que un servidor tiene más recursos y un mayor ancho de banda, lo que multiplica su capacidad de alcanzar máquinas vulnerables en internet.



La caridad bien entendida empieza por uno mismo


La buena lavandera, su camisa la primera. O, dicho de otra forma, antes de querer salvar al mundo de WannaCry, era indispensable comprobar las máquinas de nuestro sistema interno para asegurarnos de que ninguna había sido comprometida.

Naturalmente, tenemos una política interna de actualización de las máquinas muy estricta que consiste en aplicar a cada una de nuestras máquinas los parches y actualizaciones en cuanto son publicados. No obstante, nadie está a salvo de un fallo: la seguridad informática requiere buenos hábitos, pero también una cierta dosis de modestia. Nunca hay que creerse invulnerable. Lo que nos preocupaba no era tanto la infección de una máquina en producción de nuestro sistema interno —pocas se basan en Windows, y estas se vigilan muy de cerca—, sino que alguna máquina virtual utilizada para pruebas no hubiera sido correctamente destruida. El problema, pues, no era el cifrado de datos por el ransomware, ya que estos servidores no suelen tener contenido interesante, sino que el backdoor DoublePulsar pudiera permitir una intrusión en nuestros sistemas y que ese servidor infectase otras máquinas vulnerables escaneando los puertos TCP/445 abiertos dentro de la red de OVH. Y aunque la prensa se centra en los exploits de WannaCry, no olvidemos que no es el único malware capaz de explotar estas vulnerabilidades.



Retrato robot de las máquinas infectadas y vulnerables


No habiendo encontrado nada reseñable en las máquinas internas, pasamos a elaborar el retrato robot de los servidores susceptibles de ser infectados por WannaCry basándonos en los datos recogidos por nuestra red de honeypots. Así identificamos varias tipologías de servidores equipados con sistemas operativos Windows vulnerables: VPS —comercializados directamente o a través de revendedores—, servidores dedicados y máquinas virtuales de Private Cloud con Windows 2008 o versiones anteriores.



Distribución de sistemas operativos que escaneaban internet y han caído en nuestra red de honeypots —cuando las máquinas infectadas contactan con el honeypot, anuncian cuál es la versión de su sistema operativo en las primeras comunicaciones—. Podemos ver que se trata mayoritariamente de Windows Server 2008.


Esto nos condujo a pasar revista a las imágenes que proporciona OVH para la preinstalación y reinstalación de sistemas operativos. Entonces nos dimos cuenta de que alguna de estas imágenes no incluía el parche de seguridad de Microsoft que corregía el fallo explotado por EternalBlue. Las imágenes de Windows que OVH pone a disposición se entregan configuradas para realizar cada día las actualizaciones automáticas que ofrece Microsoft, pero en el caso de Windows Server 2008, como el puerto estaba abierto al público al arrancar el sistema operativo, el servidor podía infectarse incluso antes de tener tiempo para actualizarse. Así que teníamos que contener el riesgo corrigiendo sin demora las imágenes de Windows ofrecidas. Entonces pudimos constatar, viendo la reducida tasa de transferencia de la plataforma Microsoft Update, que no éramos los únicos que buscábamos el famoso parche…



Las plantillas Windows tardaron en actualizarse el sábado 13 de mayo… y tardaron mucho, debido a que la tasa de transferencia en la plataforma Microsoft Update era inferior a 100 B/s.


En Status OVH se publicaron en tiempo real[3] las intervenciones relatando la actualización de las imágenes de Windows, y se decidió crear un robot para automatizar la actualización y la integración de los parches de seguridad asociados a las plantillas de Windows en el futuro. Por otro lado, identificamos todas las IP de las máquinas que habían intentado comprometer nuestros honeypots y suspendimos los servidores en cuestión inmediatamente tras informar a los clientes afectados —un procedimiento que continúa a día de hoy—. Durante un momento barajamos la posibilidad de interrumpir temporalmente las comunicaciones realizadas en el puerto TCP/445 de toda la red de OVH, pero esta medida era demasiado radical y podía afectar a clientes que utilizan el sistema de recursos compartidos de Windows y que sí aplicaron el parche de seguridad de Microsoft hace dos meses, así que tomamos la decisión de cortar el servicio a los usuarios cuyo servidor había sido comprometido, enviándoles un mensaje informativo. Este es el mensaje en cuestión:

«Your server is being used to conduct ransomware-spreading cyberattacks, we had to reboot it in rescue mode to stop the attack. If you have a Failover IP, we had to block it.»

La «buena noticia» es que ninguno de los servidores infectados ha podido contaminar al resto de internet, fuera de la red de OVH, puesto que el filtrado aplicado por OVH en el puerto TCP/445 impedía al gusano recibir la respuesta de su víctima potencial (como el SYN-ACK se rechaza en el borde, no puede recibirse, por lo que no es posible establecer la conexión TCP).



Principio de funcionamiento del filtrado en el router de borde en el caso de un intento de infección desde una máquina situada en la red de OVH.


En busca del paciente cero


¿Cómo han podido realizarse dentro de nuestra red escaneos del puerto TCP/445 de máquinas alojadas en OVH si bloqueamos el puerto de entrada a nuestro backbone?, nos preguntamos enseguida. Por supuesto, nuestro primer reflejo fue comprobar las reglas de los routers, aunque en vano: el filtrado estaba operativo. Entonces nos remontamos en el tiempo, analizando los eventos consignados en los NetFlows de nuestro sistema de protección anti-DDoS (VAC) para identificar la IP que había inoculado WannaCry en nuestra red. Tuvimos que remontarnos varios días atrás para encontrar el culpable. O más bien los culpables, ya que se trataba de varios ordenadores infectados conectados a internet mediante accesos xDSL suministrados por OVH[4]. Observamos que, de manera independiente, varias IP tras las que se encontraban accesos xDSL empezaron a escanear internet durante varias horas en búsqueda de máquinas vulnerables a lo largo de la mañana del viernes 12 de mayo. Estas IP empezaron a infectar progresivamente VPS y luego servidores dedicados, como muestra la gráfica de abajo. Lógicamente, una conexión xDSL no tiene la misma capacidad de ataque que un servidor dedicado, especialmente en lo que respecta al ancho de banda. Así, desde la primera infección de un servidor dedicado, tuvimos una auténtica explosión de los escaneos realizados por máquinas infectadas: la reacción en cadena había empezado.



Esta gráfica muestra el número de direcciones IP que utilizan el puerto TCP/445 (en azul) y el número de paquetes acumulados observados (en gris). Se puede ver un pequeño pico antes de las 12:00 del 12 de mayo, correspondiente a los accesos xDSL infectados, seguido de la infección de servidores entre las 15:00 y las 17:00, que provoca una verdadera reacción en cadena. A las 20:00 un servicio de VPN multiplica el número de direcciones IP que escanean la red antes de ser parcialmente bloqueado. Al día siguiente sobre las 15:00, un servicio de VPN dirige un inmenso número de escaneos a nuestra red mientras aplicamos contramedidas desde las 12:00. La situación queda bajo control el sábado 13 de mayo desde las 20:00, y el 14 de mayo a las 5:00 vuelve a la normalidad.


Como era previsible, a continuación entraron en juego las VPN. Una VPN, que crea un túnel seguro entre el exterior y una máquina OVH, permite saltarse las reglas de entrada a la red —y, por tanto, la famosa prohibición del puerto TCP/445—. Los servidores que alojaban servicios VPN empezaron a enviar un tráfico muy denso, dado que por lo general las IP que se utilizan en un servicio de este tipo son compartidas. Nuestro servicio de detección automática de escaneo de puertos se activó en múltiples ocasiones, sacando a las máquinas afectadas de la red —reiniciándolas en modo de rescate—.

Así, aunque las reglas de filtrado de entrada a nuestra red no fueron 100% eficaces frente a la epidemia, sí ralentizaron su propagación, dejándonos más tiempo para desplegar las medidas que permitieron contener el fenómeno a media tarde del sábado 13 de mayo.



Killswitch: la última artimaña del malware para no ser detectado por los equipos de seguridad


Probablemente haya leído la historia del experto en seguridad que detuvo la propagación de WannaCry registrando un dominio que permitía neutralizar el ransomware. Muchos se preguntaron sobre este mecanismo de urgencia, también llamado «killswitch», presente en el propio código del ransomware, que permitía neutralizar su propagación. En realidad, este «botón de emergencia» existe con frecuencia en el malware. En contra de lo que puede parecer, el killswitch no sirve para neutralizar el ransomware, sino que se trata más bien de un mecanismo de defensa destinado a dificultar su análisis por los especialistas en seguridad. Una vez se ha capturado el ransomware —hablamos entonces de muestra o «sample»—, los expertos ejecutan el archivo en un sandbox (un entorno seguro, aislado de la red) para proceder a la ingeniería inversa del código con el fin de entender su funcionamiento. Y es ahí donde interviene el killswitch: realizando una llamada de red, que consiste por ejemplo en comprobar que un dominio no existe —por lo general generado aleatoriamente—, el ransomware puede detectar si es ejecutado en un sandbox —al estar aislado de la red, el sandbox simulará una respuesta positiva a esta llamada, ya que debe estar preparado para otras llamadas de red que sí serán cruciales en el análisis de la muestra—. Si se ejecuta en un sandbox para ser analizado por una serie de herramientas de perfilado, el ransomware no se activará… impidiendo cartografiar su funcionamiento. De hecho, si instala las VMware Tools —por lo general presentes en las máquinas virtuales— en sus equipos informáticos, es posible que parte del malware le deje tranquilo, ya que muchos de ellos detectan este marcador.

En el caso de WannaCry y del mecanismo utilizado como killswitch, el dominio no era generado aleatoriamente, lo que explica que al registrarlo se pudiera frenar su propagación. No obstante, es importante señalar que esta podría reanudarse si por alguna razón se liberase el dominio o si, como está ocurriendo, aparecieran variantes de WannaCry con un código similar pero un mecanismo de killswitch un poco diferente.



¿Su sistema ha sido infectado? ¡No pague!


Pagar contribuye a financiar las redes criminales y dar más medios a estos grupos para que desarrollen malware cada vez más maligno. Aunque la «reputación» de los autores depende en última instancia de la devolución de los datos tras el pago —algo de lo que presumen en el mensaje que envían a las víctimas, que, en su opinión, no deben haber sido suficientes—, recuerde que hay personas con muchos menos escrúpulos que no dudan en aprovechar la ocasión para conseguir dinero fácil… Hay, por ejemplo, quien ha copiado la interfaz gráfica de WannaCrypt0r, propagando un ransomware que exige el pago, cuando los archivos ni siquiera han sido cifrados. ¡Así que cuidado con estas estafas!

Por ahora, reinstalar sus sistemas Windows con la última versión disponible y los parches de seguridad proporcionados por Microsoft es la mejor forma de frenar WannaCry. Tenga en cuenta que, si tiene suerte, ya existen algunas herramientas que le permiten descifrar sus datos. Entre ellos, cabe destacar el proyecto de Telefónica WannaCry File Restorer, que recupera y restaura los archivos y extensiones de los ficheros afectados. Con carácter más general, Karpersky Lab ha creado una plataforma que recopila distintos programas que le permiten salir del atolladero si ha sido víctima de un ransomware.

También puede acudir a la comisaría más cercana para denunciar el ataque o informarse sobre la respuesta penal posible en estos casos. Y, una vez más —no nos cansamos de repetirlo—, recuerde hacer copia de seguridad de sus datos sensibles.

Asimismo, en este ataque muchos usuarios han reportado la existencia de sitios web completamente fuera de servicio. Si el suyo ha podido ser uno de ellos, le recomendamos que cambie todas las contraseñas, ¡sin excepción! ¿Por qué? Pues porque sus archivos, incluso si estaban cifrados, podían ser descargados por cualquiera. Así pues, si su actividad o sus datos son lo suficientemente jugosos, ¿por qué no iba alguien a entretenerse descifrando su «config.php» para conseguir acceder a su base de datos? ¡No espere más!



La amenaza continúa; aproveche la mediatización de la epidemia para hacer de la seguridad informática una prioridad en su empresa



« Conoce a tu enemigo y conócete a ti mismo; en cien batallas, nunca saldrás derrotado. –El arte de la guerra, Sun Tzu. »





Aunque los focos de los medios de comunicación ya no estén puestos en WannaCry, la amenaza sigue presente. La gráfica anterior mostraba un recrudecimiento de los intentos de intrusión en estos últimos días, realizados por máquinas infectadas, y la razón es la siguiente: han aparecido variantes de WannaCry que siguen contaminando más máquinas vulnerables. De hecho, WannaCry no ha sido el primero en explotar el fallo de los sistemas Windows. Mucho antes, Adylkuzz ya aprovechaba estas vulnerabilidades con el fin de comprometer la máquina para minar Monero, una criptomoneda alternativa al bitcoin. En la actualidad, existen programas de malware en circulación basados en EternalBlue, pero también en sus primos pequeños EternalSynergy, EternalChampion y EternalRomance. Es más que probable que en las próximas horas aparezca una botnet que utilice esta misma vulnerabilidad para propagarse y después lanzar grandes ataques DDoS, como Mirai el pasado mes de septiembre.



Ejemplo de un VPS infectado por Adylkuzz en torno a las 20:00. La minería consume una gran cantidad de CPU y de ancho de banda, mientras que la interrupción del servicio Samba libera memoria.


Tampoco debe olvidar que, si su máquina ha sido comprometida, se habrá instalado el backdoor DoublePulsar. Así pues, aunque haya aplicado el parche Microsoft MS17-010, su máquina seguirá siendo vulnerable en internet. Existen diversas herramientas que permiten saber si este es su caso, como la del editor de la conocida herramienta de exploración de red «Nmap».

En OVH sabemos que es utópico pensar que la amenaza va a desaparecer en los próximos días. Por el contrario, parece que aún tiene trayectoria por delante, puesto que seguirá habiendo máquinas vulnerables en internet a las que infectar, como ha ocurrido con el fallo en el servicio NTP revelado en 2013 que, a día de hoy, se sigue utilizando para realizar ataques de denegación de servicio.

Así que, cuando haya parcheado hasta la última máquina de su red, piense que no hay mal que por bien no venga. La cobertura mediática de WannaCry ha abierto los ojos a todo el mundo sobre la necesidad de invertir todavía más en seguridad informática, ya que se trata de un gran desafío. El capital de una empresa no solo lo forman sus activos inmobiliarios, sus recursos humanos o su reputación. Los datos y, por extensión, el sistema de información también son valiosos activos en cualquier empresa. ¿Sus compañeros y los miembros del Comité de Empresa han puesto la mirada en usted? Aproveche antes de que dejen de prestarle atención… hasta la próxima epidemia.



Notas:


[1] Bancos del mundo pagan a Microsoft para que siga dando soporte a Windows XP, publicado en microsoftinsider.es el 15 de marzo de 2014.

[2] En la lista de correo sd-pro@ml.ovh.net el 27 de junio de 2016, Octave Klaba, fundador y CEO de OVH, recordó la razón del bloqueo del puerto TCP/445 en el borde de la red de OVH por motivos de seguridad. En el mensaje explicaba que el bloqueo se realizaba desde hacía 11 años y que siempre se aplicaría. En cierto modo, la actualización de Microsoft a su sistema operativo va en este sentido, ya que consiste en dejar de exponer por defecto este puerto, cuyo uso fue diseñado para intercambiar archivos dentro de una red local.

[3] Intervenciones publicadas:
http://travaux.ovh.net/?do=details&id=24741
http://travaux.ovh.net/?do=details&id=24738
http://travaux.ovh.net/?do=details&id=24740
http://travaux.ovh.net/?do=details&id=24742
http://travaux.ovh.net/?do=details&id=24743

[4] En Francia OVH también es operador de telecomunicaciones.