WannaCry: séquese las lágrimas… ¡pero sea prudente!

La pandemia WannaCry ha afectado fundamentalmente el sistema informático de las empresas, pero tampoco ha dejado escapar los servidores que utilizaban antiguas versiones de Windows no actualizadas. ¿Qué medidas debe tomar un proveedor de alojamiento ante un fenómeno de tal envergadura?, La respuesta no es simple, ya que la responsabilidad es en esencia de los usuarios, que son los únicos encargados de mantener sus sistemas actualizados. A pesar de ello, OVH ha hecho todo lo posible para frenar la aparición de WannaCry en los servidores vulnerables de sus clientes y para contener esta epidemia particularmente virulenta. En esta ocasión, recordamos algunas medidas de seguridad informática muy útiles para luchar contra amenazas de este tipo, que están lejos de desaparecer.

Nuestras estimaciones

En los últimos días, habría sido necesario probablemente vivir en una cueva (o tener la mente demasiado ocupada en la actualidad política) para no haber oído hablar de WannaCrypt0r. Este ransomware, que explota una vulnerabilidad en el sistema de elementos compartidos de Windows, se ha propagado como pólvora por todo el mundo. Los medios de difusión se han apoderado del asunto, revelando de forma exhaustiva los contratiempos de empresas como FedEx en Estados Unidos, o incluso las desventuras de hospitales públicos en Inglaterra, forzados a aplazar intervenciones quirúrgicas por no poder acceder al historial clínico de los pacientes. ¿Cómo ha sido detectada y afrontada esta ola de ransomware en OVH? A continuación le contaremos por qué nuestro equipo de seguridad se ha perdido la actualidad política en la televisión y no ha dormido mucho esta última semana.

WannaCry (es así como los anglófonos han bautizado a este ransomware, sin duda haciendo alusión a la reacción de las víctimas) podría haber infectado entre 150 mil y 300 mil máquinas en todo el mundo. Desafortunadamente, esta cifra no deja de aumentar, ya que la epidemia no se ha exterminado. Incluso tenemos razones poderosas —más adelante volveremos al tema— 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 continúa siendo relativamente marginal en OVH, ya que solo podría haber afectado 5000 direcciones IP, de las más de dos millones a nuestro cargo. Estas son nuestras últimas estimaciones, basadas en nuestra red de honeypots, máquinas que pertenecen a OVH, son gestionadas por el equipo SOC (Security Operations Center), y están expuestas voluntariamente en la red con el objetivo de atraer amenazas de todo tipo (malware, hackers, phishing…) que circulan en la red. Estas honeypots nos permiten formarnos una idea de la peligrosidad y velocidad de propagación de tales amenazas. Si bien el número de máquinas infectadas dentro de la red de OVH parece bajo en comparación con el tamaño de nuestro parque de servidores, no podemos dejar de movilizarnos para evitar la contaminación de otras máquinas vulnerables, específicamente aquellas máquinas que OVH ha puesto a disposición de sus clientes y que no han sido actualizadas por quienes tienen esta responsabilidad. Los servidores del sistema de información de OVH, por su parte, no han sido afectados por WannaCry.

WannaCry: el precio de la fama

Ante todo, recordemos qué es WannaCry. Se trata de un ransomware o programa malicioso, que secuestra los datos de sus víctimas y los encripta, para luego reclamar una suma de dinero a cambio de la recuperación de los mismos. Este rescate suele pedirse en bitcoins, lo cual dificulta la trazabilidad de los flujos financieros. El procedimiento no es nuevo y ha ganado auge desde 2005, ya que se trata de un negocio muy lucrativo. El FBI ha estimado el mercado del ransomware en más de 830 millones de dólares durante el año pasado. Para ofrecer una idea, ese era el tamaño del mercado inglés del SVOD (suscripción de video bajo demanda) en 2015… o el equivalente a las pérdidas de Uber en el tercer trimestre de 2016 —elija usted la comparación que desee, 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.

El ransomware suele propagarse a través de mensajes de correo electrónico maliciosos que incluyen algún documento adjunto, una factura falsa, por ejemplo, generalmente un documento 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, la cual se encargará de encriptar los datos de la víctima.

En el caso de la reciente epidemia de WannaCrypt0r, es importante señalar que se trataba de la versión 2.0 del ransomware. Por razones obvias, los diseñadores del programa no publicaron su lanzamiento, pero en resumen, la versión inicial del malware, cuya propagación se realizaba a través de 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 como sistema de elementos compartidos en 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 al público el servicio de elementos compartidos de Windows. Es de esta forma que se han podido infectar máquinas desactualizadas, en su mayoría con Windows Server 2008 y versiones anteriores del sistema operativo de Microsoft. Cabe destacar que desde Windows Server 2012 y Windows 10, el firewall fue configurado de forma tal que este servicio no estuviera expuesto por defecto, lo cual explica que el bajo número de víctimas. Para entender el resto de la historia hay que tener en cuenta que el servicio de elementos compartidos se expone a través del puerto TCP/445.

En la familia de los programas malignos o malware, se distinguen varios subtipos. Acabamos de abordar el ransomware, cuyo objetivo es secuestrar el equipo mediante el encriptado de sus datos. Pero en el caso de WannaCry, se explota una vulnerabilidad para propagar un ransomware. Ahora bien, la explotación de la vulnerabilidad está asociada a los gusanos informáticos (worm). WannaCry es por tanto un híbrido, una combinación de gusano con ransomware, evidentemente dirigida a cobrarle a Microsoft el precio de la fama.

Blaster en retrospectiva

¿Recuerda el gusano informático Blaster? Este gusano infectó varios cientos de miles de máquinas con Windows 2000 y Windows XP en agosto de 2003, mediante la explotación de una vulnerabilidad que Microsoft tardó semanas en parchear, forzando el reinicio de la máquina al cabo de 60 segundos. Blaster escaneaba la red en busca de otras máquinas que infectar. Su propagación se basaba, como en el caso de WannaCry, en un vector de infección mediante peer-to-peer (P2P).

Cuando nuestros honeypots comenzaron a zumbar

El viernes 12 de mayo ya circulaban unos tweets del usuario @MalwareHunterTeam asociados a una nueva amenaza llamada WannaCry que se extendía rápidamente. Esa misma tarde, comenzaron a aparecer artículos mencionando 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 una cantidad anormal de tickets relacionados con ransomware.

Como proveedor de cloud, OVH lucha contra la proliferación del ransomware y el malware, pero se trata de una ardua batalla discretamente llevada a cabo por el equipo SOC de OVH, que requiere investigaciones complejas para llegar hasta las organizaciones criminales que originan estos programas maliciosos, y denunciarlas ante las autoridades a fin de desmantelarlas. Aún así, es imposible erradicar el fenómeno a diario, mediante otras acciones que no sean la prevención para reducir el riesgo principal, que es el factor humano. En la práctica, —los responsables informáticos lo saben bien— es necesario mantener el parque informático actualizado, con todas las dificultades que esto implica, pues hay que tomar en cuenta la posible incompatibilidad de las aplicaciones utilizadas con la nueva versión del sistema operativo —razón por la cual no es tan sorprendente (1) ver todavía tantas máquinas que funcionan con versiones de Windows anteriores a 2008—. Paralelamente, hay que sensibilizar de forma continua a los trabajadores sobre un segundo vector de infección: los archivos adjuntos a los mensajes de correo electrónico que reciben; e incluso organizar, 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 la higiene informática. Ante un ataque de 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: ¡el backup de los datos!

Todo esto para explicar que es bastante raro 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, puede que usted no lo supiera, pero hace muchos años que el puerto TCP/445, utilizado para compartir elementos en Windows (CIFS), es filtrado en los routers de borde de la red de OVH por razones de seguridad (2). Se ha comprobado efectivamente 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 desea establecer comunicación remota mediante este puerto, 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 elementos compartidos pueda ser utilizado por los clientes con fines legítimos—. De este modo, las máquinas de la red de OVH estaban a salvo de la contaminación.

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. Inmediatamente abrimos varias líneas de trabajo paralelas: la búsqueda metódica del «paciente cero» —el que WannaCry había utilizado para 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 verificación minuciosa 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 determinar cómo se propaga el gusano y cuál es su estrategia para recorrer internet en busca de máquinas vulnerables que contaminar. En este sentido, observamos que WannaCry abre dos métodos de escaneo, y a continuación los ejecuta de manera concurrente (multithreading). El primero de estos métodos 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 dirigido específicamente a las redes internas de las empresas.

El segundo método permite escanear la red creando una IPv4 válida de manera aleatoria, generando así, uno a uno, los cuatro octetos que componen la dirección y eliminando las IP que comienzan 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 todo el rango (lo que corresponde a las 253 IP vecinas). Según nuestras observaciones, las máquinas infectadas son capaces de escanear aproximadamente 30 IP por segundo.

Monitoreo de un VPS infectado por WannaCry el 15 de mayo de 2017: el encriptado es altamente consumidor de recursos como procesador y memoria, y después 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, consiste en monopolizar voluntariamente la conexión para impedir que uno de los hilos escanee, o sea, que se quede esperando la respuesta del servidor. Estadísticamente, también es posible detener todos los hilos e interrumpir los escaneos. Esta técnica se llama «tarpit». En este caso, parece que el diseñador del gusano se tomó la molestia de establecer un plazo de expiración de una hora para abandonar la conexión si el servidor no responde. Finalmente, la autopsia del código reveló un último elemento: una máquina comprometida es igualmente infectada por DoublePulsar, un backdoor (puerta trasera) posiblemente utilizado por el Equation Group para inyectar malware en su objetivo. Según el código de WannaCry, este backdoor se podría reutilizar para volver a infectar una máquina más adelante.

¿Qué debemos recordar del funcionamiento de WannaCry? Primeramente, que su código hace de las empresas los principales vectores de contagio. Algunas elecciones en los algoritmos apuntan en esta dirección. En efecto, los parques informáticos de las empresas suelen ser relativamente homogéneos y hay grandes probabilidades de encontrar rápidamente máquinas vulnerables en una red local, mientras que el escaneo de toda la red es estadísticamente menos eficaz. Dicho esto, aunque la infección de servidores es menos masiva que la de los puestos de trabajo de empresas, es igual de 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 empieza en casa

Antes de querer salvar al mundo de WannaCry, era indispensable verificar 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. Sin embargo, nadie está a salvo de un fallo: la seguridad informática requiere cierta higiene, pero también una cierta dosis de modestia. Nunca hay que creerse invulnerable. No nos preocupaba tanto la infección de una máquina en producción de nuestro sistema interno —pocas se basan en Windows, y están bien monitoreadas—. Más bien nos interesaba detectar si alguna máquina virtual utilizada para pruebas no hubiera sido correctamente destruida. El problema, entonces, no era el encriptado 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 este servidor pudiera infectar otras máquinas vulnerables escaneando los puertos TCP/445 abiertos dentro de la red de OVH. Incluso si la prensa destaca los exploits de WannaCry, no olvidemos que no es el único malware capaz de explotar estas vulnerabilidades.

Retrato modelo de las máquinas infectadas y vulnerables

Al no haber encontrado nada a señalar en las máquinas internas, nos dimos a la tarea de diseñar el retrato modelo de los servidores susceptibles de ser infectados por WannaCry. Para ello, nos basamos en los datos recogidos por nuestra red de honeypots. De esta forma 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 [i]honeypots[/i] —cuando las máquinas infectadas contactan con el [i]honeypot[/i], anuncian cuál es la versión de su sistema operativo en los primeros intercambios—. En su mayoría, se trata de Windows Server 2008.

Esto nos condujo a revisar las imágenes que proporciona OVH para la preinstalación y reinstalación de sistemas operativos. Entonces nos dimos cuenta de que algunas de estas imágenes no incluían el parche de seguridad de Microsoft que corregía el fallo explotado por EternalBlue. Las imágenes de Windows que OVH ofrece, se entregan configuradas para efectuar a diario las actualizaciones automáticas de Microsoft, pero en el caso de Windows Server 2008, el puerto estaba abierto al público al iniciar el sistema operativo, de modo que el servidor podía infectarse incluso antes de tener tiempo para actualizarse. Era necesario contener este riesgo corrigiendo sin demora las imágenes de Windows ofrecidas. Pudimos constatar, dada la reducida tasa de transferencia de la plataforma Microsoft Update, que no éramos los únicos que buscábamos el famoso parche…

La actualización de las plantillas Windows tardó mucho el sábado 13 de mayo… debido a que la tasa de transferencia en la plataforma Microsoft Update era inferior a 100 B/s.

OVH ha publicado en tiempo real las intervenciones llevadas a cabo, relatando la actualización de las imágenes de Windows, y se ha decidido crear un robot con la finalidad de automatizar la actualización y la integración de los parches de seguridad asociados a las plantillas de Windows en el futuro. Por otra parte, hemos detectado todas las IP de las máquinas que habían intentado comprometer nuestros honeypots y hemos suspendido los servidores en cuestión inmediatamente después de informar a los clientes afectados —un procedimiento vigente actualmente—. Estuvimos contemplando 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 elementos compartidos de Windows y que habían aplicado el parche de seguridad de Microsoft dos meses atrás, así que tomamos la decisión de cortar el servicio a los usuarios cuyo servidor había sido comprometido, enviándoles el siguiente mensaje informativo:

«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, dado 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 se han podido llevar a cabo dentro de nuestra red escaneos del puerto TCP/445 de máquinas alojadas en OVH si bloqueamos el puerto de entrada a nuestro backbone?, fue la pregunta que se impuso. Obviamente, nuestro primer reflejo fue comprobar las reglas de los routers, en vano: el filtrado estaba operativo. Entonces nos remontamos en el tiempo, analizando minuciosamente 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 varias PC infectadas conectadas a internet mediante accesos xDSL suministrados por OVH. Observamos que, de forma independiente, varias IP tras las que se encontraban accesos xDSL comenzaron a escanear internet durante varias horas en búsqueda de máquinas vulnerables en la mañana del viernes 12 de mayo. Estas IP empezaron a infectar progresivamente VPS y luego servidores dedicados, como muestra la siguiente gráfica. Con respecto al ancho de banda, sabemos que una conexión xDSL no tiene la misma fuerza de ataque que un servidor dedicado, así que desde la primera infección de un servidor dedicado, observamos una verdadera explosión de los escaneos lanzados por máquinas infectadas: la reacción en cadena se había desatado.

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 ligero salto 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 8:00 PM, un servicio de VPN multiplica el número de direcciones IP que escanean la red, antes de ser parcialmente bloqueado. Al día siguiente, alrededor de las 3:00 PM, un servicio de VPN dirige un inmenso número de escaneos a nuestra red mientras aplicamos contramedidas desde las 12:00. La situación se controla el sábado 13 de mayo desde las 8:00 PM, y el 14 de mayo a las 5:00 AM vuelve a la normalidad.

Como era previsible, a continuación entraron en juego los VPN. Al crear un túnel seguro entre el exterior y una máquina OVH, el VPN 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 comenzaron a enviar un tráfico muy denso, ya que, por lo general, las IP que se utilizan en un servicio de este tipo son compartidas. Nuestra detección automática de escaneo de puertos se activó en múltiples ocasiones, sacando de la red las máquinas afectadas y reiniciándolas en modo de rescate.

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

Killswitch: el último truco del malware para esquivar el radar de los equipos de seguridad

Sin dudas habrá 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. Contrariamente a las apariencias, el killswitch no sirve para neutralizar el ransomware, sino que se trata más bien de un mecanismo de defensa destinado a obstaculizar su análisis por los equipos de seguridad. Una vez capturado el ransomware —estamos hablando 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 y comprender así su funcionamiento. Es ahí donde interviene el killswitch: efectuando una llamada de red, que consiste por ejemplo en comprobar que un dominio no existe —casi siempre generado de forma aleatoria—, 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 a njestras herramientas cartografiar su funcionamiento. Por otra parte, la instalación de las VMware Tools —por lo general presentes en las máquinas virtuales— en sus equipos informáticos, puede quitarle de encima parte del malware, 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 su registro pudiera frenar la propagación. Cabe también señalar que esta propagación podría reanudarse si el dominio fuese liberado o si, como está sucediendo, aparecieran variantes de WannaCry con un código similar pero un mecanismo de killswitch algo diferente.

¿Ha sido infectado? ¡No pague!

Pagar contribuye a financiar las redes criminales y por consiguiente, a dar más medios a estos grupos para que desarrollen malware cada vez más maligno. Aunque la «reputación» de los autores depende de la devolución de los datos tras el pago —de la que presumen en el mensaje que envían a sus víctimas, insuficientes en su opinión—, recuerde que hay personas con muchos menos escrúpulos que no desperdician la oportunidad de conseguir dinero fácil… Así, los hay que copiado la interfaz gráfica de WannaCrypt0r, propagando un ransomware que exige el pago, cuando los archivos ni siquiera han sido encriptados. ¡Cuidado con estas estafas!

Por el momento, reinstalar los sistemas Windows con la última versión disponible y los parches de seguridad proporcionados por Microsoft es la mejor forma de poner freno a WannaCry. Tenga en cuenta que, si tiene suerte, ya existen algunas herramientas que le permiten desencriptar sus datos, entre las que podemos mencionar el proyecto francés WannaKiwi, que inspecciona la memoria de su máquina para encontrar la clave. Con carácter más amplio, Karpersky Lab ha creado una plataforma que recopila distintos programas que le permiten salir del atasco si ha sido víctima de un ransomware.

También puede acudir a la policía para denunciar el ataque u obtener información sobre la respuesta penal posible en estos casos. Finalmente —no nos cansamos de repetirlo—, no olvide hacer copias de seguridad de sus datos sensibles.

Durante este ataque, muchos usuarios reportaron la existencia de sitios web completamente fuera de servicio. Si el suyo estuvo entre ellos, le recomendamos que cambie todas las contraseñas, ¡sin excepción! ¿Por qué? Pues porque sus archivos, incluso encriptados, podían ser descargados por cualquiera. Así pues, si su actividad o sus datos son lo suficientemente útiles, ¿por qué no entretenerse desencriptando su «config.php» para obtener un acceso privilegiado a su base de datos? ¡No espere más!

La amenaza no ha desaparecido. Aproveche la mediatización de esta epidemia para hacer de la seguridad informática una prioridad en su empresa

Aunque los medios de comunicación ya hayan desviado su atención de 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. Esto se debe a que han aparecido variantes de WannaCry que siguen contaminando más máquinas vulnerables. 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 pequeños primos 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 en septiembre pasado.

Ejemplo de un VPS infectado por Adylkuzz en torno a las 8 PM. 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. De este modo, 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, aún tiene camino por delante, puesto que habrá más máquinas vulnerables en internet para infectar, como ha ocurrido con el fallo en el servicio NTP revelado en 2013 que actualmente se sigue utilizando para realizar ataques por denegación de servicio.

En este sentido, 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 reto. 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 sus ojos 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 un mensaje enviado a 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. El mensaje explicaba que el bloqueo se realizaba desde hacía 11 años y que siempre se aplicaría. De cierta manera, 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.

Mi cuenta de clienteContact SalesWebmail OVHcloud Blog

¡Bienvenido/a a OVHcloud!

Identifíquese para contratar una solución, gestionar sus productos y servicios, y consultar sus pedidos

Conectar