Ayer un nuevo ataque de ransomware ha comenzado a copar las portadas de todos los medios de comunicación, y también las redes sociales. No es nada nuevo, y son "solo" dos viejos amigos que se han juntado para volver a intentar hacer un WannaCry. 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.
 |
| Figura 1: Petya con Eternalblue, el miedo a un nuevo WannaCry
y el incentivo a no parchear inmediatamente de Microsoft
|
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.
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?
Pues la realidad es que puede que hasta falle el software del propio Microsoft cuando se aplica un parche de Microsoft. Sí, así son los procesos de QA de complicados, ya que hay que probar todas y cada una de las características en todos los entornos. Y que no lo hagas. En estos mismos y recientes parches de Junio de Microsoft, Outlook se ha visto afectado por una buena cantidad de fallos que hace que malfuncione cuando se aplican las actualizaciones.
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.
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.
Saludos Malignos!
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.
Saludos Malignos!
Gracias como siempre Chema.
ResponderEliminarA pesar de los procesos indicados para aplicar un parche, totalmente entendible porque cada uno tiene "sus circunstancias", no es normal que viendo cómo muchos malware usan técnicas "similares" que pueden ser mitigadas de otras formas que parece que ni se exploran, si bien obviamente muchas de ellas, y dependiendo de las circunstancias de cada uno, pueden ayudar o retrasar más las pruebas.
Sigo sin explicarme cómo empresas con recursos no tienen las redes segmentadas, cómo los equipos no tienen un firewall levantado que impida el acceso salvo con las excepciones necesarias.
Cómo no se usan reglas de applocker/srp bastionando el entorno (es decir, letyendo cómo se hace bypass de ello y aplicando las contramedidas necesarias que las hay), o se prevenga la ejecución de un simple CMD o powershell (dudo que en una empresa de 5000 empleados los 5000 necesiten acceder a ello), o no tengan un antivirus de los de nueva generación (no pongo nombres, pero no me refiero a los tradicionales) que "perse" está demostrado que paran este tipo de ataques.
Y tampoco entiendo cómo en todos los blogs de seguridad se escibe precisamente de cómo se ataca, pero nunca se ponga de manifiesto posibles medidas para paliarlo. Obviamente muchas podrán ser o no útiles dependiendo de nuestras circunstancias, pero siempre se agradece que se comparta ese conocimiento para ya al menos conocerlo, y ver si lo podemos adaptar a nuestras necesidades.
Gracias como siempre por compartir el conocimiento.
Gracias Chema,
ResponderEliminarPara evitar la propagación vía SMB se puede o bien aplicar el parche de Microsoft o bien desactivar SMBv1:
http://www.sysadmit.com/2017/05/windows-deshabilitar-smb-10.html
No se entiende que después de meses, haya gente que no haya implementado una opción u otra para evitar la propagación dentro de la LAN.
No estoy de acuerdo en que no "se confié" en los parches de Microsoft, la mejor política en este escenario de ataques masivos, repito en este escenario, es desplegar los parches a los equipos clientes lo antes posible, es preferible tener algún que otro cliente con problemas por el parche, perfectamente reversible, a que esperemos bajo el riesgo de sufrir un ataque masivo. Para los servidores se justifica cierta reserva para instalar los parches.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarMi pregunta es ... la vulnerabilidad de microsoft afecta aunque se tenga un antivirus bueno... por que si no afecta, pues el parche se puede omitir o no
ResponderEliminarGracias por sus comentario
Juan Pablo,
ResponderEliminardepende del AV; los hay que por defecto paran este y otro tipo de ataques (ejemplo: SentinelOne, Traps,Cylance, etc..)
Sin tener un AV, si se tiene bastaionado un pc para evitar que se ejecute por un usuario un CMD, u npowershell y muchas otras medidas, también es efectivo aunque no se tenga el parche.
Ese tipo de contramedidas que se pueden hacer -no siempre obviamente, cada uno tiene su entorno y sabrá qué puede o no hacer en él- son las que precisamente nunca se ven reflejadas en los documentos que desengranan el cómo funciona el bicho, qué obviamente están muy bien y son fundamentales, y el si lo entiendes, puedes pensar tú en hacer ciertas cosas en base a ello; pero si no lo entiendes, como le puede pasar a muchas pymes, entonces de poco sirve.
Un saludo
Buen día
ResponderEliminarHe visto que en algunos foros se comenta que una forma de evitar la encriptación que produce este virus es mediante la colocación de un archivo llamado perfc en la carpeta Windows dentro del disco C. ¿Qué hay de cierto en esto?. Teoricamente, este archivo funciona como un switch-off para el malware, de tal forma que, al ejecutarse escanea si este archivo está presente. Si es así procede a la encriptación, caso contrario no afectaría al equipo aunque si sería vector de transmisión.
Muchas gracias desde ya y gracias por los buenos aportes. Saludos