Al igual que en la infección de WannaCry, el atacante ha unido un ransomware bastante conocido, como es Petya, y lo ha unido a la vulnerabilidad de Microsoft Windows EternalBlue, que fue utilizada en el caso de WannaCry. Es decir, un ransonmware más un exploit para crear un gusano y viralizar las infecciones.
En este caso, el ransomware actúa de forma distinta a WannaCry, ya que Petya cifra el MBR (Master Boot Record) del disco duro al estilo de los Bootkits,
lo que hace que aunque tengas los documentos protegidos en carpetas
seguras, o bajo contenedores cifrados, tus documentos siguen
desapareciendo. Lo que no le hace ninguna gracia a los dueños de los
equipos. El resultado es el que puede verse en esta foto, de un
supermercado de Ucrania que ha circulado por las redes sociales.
 |
| Figura 2: Equipos infectados por Petya en un supermercado de Ucrania |
Este ataque utiliza otra vez una versión evolucionada de EternalBlue, el mismo fallo de seguridad de Microsoft Windows que utilizó WannaCry
para la distribución, así que los equipos que se parchearon durante el
ataque del mismo, deberían estar a salvo de posibles infecciones de este
ataque. Y la pregunta que surge a muchos... ¿todavía quedan empresas u
organizaciones que no se hayan parcheado?
La pregunta tiene toda la lógica del mundo, especialmente después de WannaCry, pero.. vamos a pensar en un mundo nuevo, en el que después de WannaCry todo el mundo comienza a parchear al día siguiente de que salgan las vulnerabilidades. Es decir, que desaparecen los tiempos de QA en los parches. De hecho, Microsoft se "atrevía" a denominar a los equipos no parcheados aún como "Out-Of-Dated", algo que no era del todo cierto. Podían ser equipos en proceso de validación del parche.
La pregunta tiene toda la lógica del mundo, especialmente después de WannaCry, pero.. vamos a pensar en un mundo nuevo, en el que después de WannaCry todo el mundo comienza a parchear al día siguiente de que salgan las vulnerabilidades. Es decir, que desaparecen los tiempos de QA en los parches. De hecho, Microsoft se "atrevía" a denominar a los equipos no parcheados aún como "Out-Of-Dated", algo que no era del todo cierto. Podían ser equipos en proceso de validación del parche.
 |
| Figura 3: WannaCry afecta a "out-of.-date" systems |
Esto querría decir que no se prueba el software en los sistemas antes de poner en producción el parche y eso no es una buena idea. Microsoft, cuando saca un parche, lo prueba con su software soportado, pero no con el software que no es suyo. Miento, es cierto que Microsoft,
debido a la notoriedad e importancia de algunos software, tiene el
compromiso de probar el software con algunos otros fabricantes, para
garantizar que sistemas críticos no fallan, para lo que firmaron
acuerdos de colaboración en los procesos de QA. Pero estas son excepciones, y no lo hacen con el software hecho a medida en las empresas.
¿Puede fallar de verdad tu programa si se aplica un parche de Microsoft?
Con estos fallos en las actualizaciones de seguridad, es la propia Microsoft la que "incentiva" de manera involuntaria, a que se extiendan los tiempos en los procesos de QA, porque puede llegar a ser más costoso para una organización con cientos de miles de equipos el costo de repararlos todos - si se aplica masivamente un parche defectuoso - que detectar y responder contra un ataque que aproveche un fallo de seguridad durante la ventana de tiempo de los procesos de QA.
 |
| Figura 4: Problemas conocidos de las actualizaciones de seguridad de junio de 2017 en Outlook |
Es decir, al final es una gestión del riesgo que debe balancear adecuadamente los procesos para garantizar integridad, privacidad y disponibilidad del negocio. Y por supuesto, cuanto más calidad tengan los parches, mejor que mejor, pues los tests de QA de las empresas no necesitarán ser tan exhaustivos y largos en todos los casos. No hay magia, solo trabajo.
