Mostrando entradas con la etiqueta virus de la policía. Mostrar todas las entradas
Mostrando entradas con la etiqueta virus de la policía. Mostrar todas las entradas

miércoles, 17 de mayo de 2017

WannaCry y las lecciones que nunca aprendemos

Ya pasó la resaca del famoso ransomware WannaCry del pasado viernes, sin embargo siguen las amenazas de una nueva versión. Cuando ya sabemos casi todo del malware, llega el momento de recapacitar y ver si de una vez somos capaces de aprender algo de estos casos.

Como el coyote. No
aprendemos de los errores
En los últimos días hemos visto noticias sobre el ciberataque mundial que ha "colapsado el mundo”, con frases como que estamos ante "el mayor ciberataque de todos los tiempos" o que "estamos ante el inicio de una guerra"... Desde Hispasec queremos poner un poco de orden en toda la información que ha estado circulando estos días.

Es cierto que hacía tiempo que no se veía un ataque que fuera tan grave, global y problemático. Sin embargo los que tenemos algo de memoria, y si no basta con recurrir a Google, podemos recordar más de un ataque similar hace ya muchos años. Podemos recordar casos como el LoveLetter, Slammer, Nimda, Conficker o muchos similares. Después de cada caso de estos tendemos a recapacitar, ver los errores, se corrige, se parchea y se olvida todo. Sin embargo vemos como después de cada caso de este tipo en vez de aprender algo tendemos a olvidar rápidamente lo ocurrido.

Se ha hablado de un ataque global de gran escala con muchos infectados. La prensa se ha hecho eco de la gravedad del problema y la propagación que ha tenido. Se ha hablado de cifras de infección de en torno a 100.000 equipos, como algunas de las más elevadas. Sin embargo podemos recordar los números de infectados por otros malware a lo largo de la historia, por citar algunos representativos:
  • CIH (1998) 60 millones de equipos infectados.
  • I Love You o Loveletter (2000) fueron 50 millones infectados.
  • Slammer (2003) con más de 75.000 servidores infectados en los primeros 10 minutos.
  • Sasser (2004) más de 1 millón de equipos infectados.
  • Conficker (2009) unos 7 millones infectados.
Los datos hablan por sí solos y las comparaciones son odiosas. En cualquier caso, ¿se aprendió algo de estos otros malware con infecciones masivas? Todo indica que no.

Y si hablamos de ransomware aunque no hay cifras concretas, estamos seguros de que el famoso virus de la policía ha infectado a mucha más gente que WannaCry. En un periodo de tiempo más extenso, sí, pero esa muestra de malware dio grandes quebraderos de cabeza a miles de usuarios.

¿Podremos aprender algo de una vez?
"de nuevo un gusano que aprovecha
una vulnerabilidad en un producto de
Microsoft provoca el colapso en Internet.
"
"Vulnerabilidades tienen todos los sistemas, no es un problema en exclusiva de Microsoft, pero este caso viene a poner el dedo en la llaga. Cuando... Microsoft intenta disminuir el tiempo que transcurre desde que es descubierta la vulnerabilidad hasta que el sistema del cliente es actualizado."
Parece que se trata de algo reciente, escrito justo después del ataque del viernes, sin embargo aunque parezca sorprendente estos párrafos tienen más de 14 años (27 de enero de 2003). En una-al-día posterior al caso SQL-Slammer Aquella noticia se titulaba "Lecciones del gusano MS-SQL, y la verdad es que prácticamente todo el artículo sigue siendo vigente. Y es muy recomendable su lectura con los ojos puestos en la actualidad, para comprobar lo poquito que han cambiado muchas cosas.

Las conclusiones y lecciones después de cada caso son muy similares. Nada nuevo.

Actualizaciones. En esto somos muy pesados, todos los días hablando de parche para x o para y, hoy es Windows, mañana Apple, al otro el navegador... Pero es que nuestra experiencia en auditorías nos dice que mantener los equipos y servidores actualizados nos libra de más de un 90% de los problemas. De hecho los equipos actualizados no se verían afectados por este ataque.
"La disponibilidad de un parche no asegura la protección de los sistemas, es necesario que los administradores o usuarios lo apliquen. Si bien es cierto que en algunos casos puede ser un problema por dejadez, falta de tiempo o simple desconocimiento, existe también ciertas reticencias a su instalación inmediata en ambientes en producción. No es que los administradores tengan manías, sino todo lo contrario, es por experiencia propia: parches que se superponen, regresiones de vulnerabilidades, problemas de estabilidad o incompatibilidad con otros componentes."
Otro párrafo que no es nuevo, también tiene 14 años... Pero el problema parece que ha sido el mismo, la falta de una actualización que llevaba un par de meses publicada.
"Los usuarios deben ser conscientes de que, cada vez que no instalan un parche crítico, están dejando una puerta abierta para que un intruso pueda controlar totalmente su sistema, sustraer su información más sensible, borrar sus discos duros, o espiar todo lo que hacen con su ordenador. Y esto ocurre con mucha más frecuencia de la que se cree, con el agravante de que suele pasar desapercibido, al contrario de lo que ocurre con los gusanos."
También formaba parte de las conclusiones de Hispasec tras el gusano Sasser en 2004. 13 años después podemos comprobar que los problemas siguen siendo los mismos.

Pero si los casos anteriores se han cobrado muchas víctimas "civiles", destaca de esta campaña los nombres de las empresas afectadas. Dejando aparte el caso de Telefónica y otras grandes empresas, el ransomware se ha cobrado victimas entre corporaciones y organismos de todo el mundo, afectando a servicios tan críticos como el Servicio Nacional de Salud de Reino Unido, u organismos estatales y servicios de transporte en Rusia. WannaCry ha demostrado que las infraestructuras siguen siendo tan frágiles como hace años y que, en cuanto a gestión de riesgo, en ocasiones la ganancia de flexibilidad en las operaciones sigue priorizándose sobre la seguridad del sistema, unida en algunos casos a la desidia en el mantenimiento.

Copias de seguridad. Posiblemente siga siendo el gran olvidado, pero la realización de copias de seguridad periódicas diarias, semanales... Con una adecuada política, manteniendo las copias en un entorno diferente, etc. puede salvar de un problema de este tipo. Si hay una copia de seguridad de todos los datos del día anterior ante un problema similar podemos estar seguros que la pérdida no será tan significativa.

Pagar o no pagar. Hay que recordar que en muchos casos de ransomware aunque se ha llegado a producir el pago no se ha podido recuperar la información. La recomendación siempre es no pagar. Por lo que se sabe la cantidad recaudada en los tres monederos que recaudaban los fondos de este malware apenas sobrepasa los 70.000 dólares. Cantidad que se puede considerar baja teniendo en cuenta el impacto que ha tenido.

Indicadores de compromiso. Esta muy bien disponer de un firewall, detector de intrusos y un buen número de medidas de seguridad activas y proactivas, pero de nada sirven si no se mantienen al día. Los indicadores de compromiso es el medio empleado en la actualidad para alimentar sistemas de seguridad. En Hispasec ofrecemos IOCFlow que permite aportar a los mecanismos de protección datos en tiempo real, incluyendo malware, documentos maliciosos de Office e incluso URLs maliciosas.

De todas formas no estamos libres de problemas, siempre puede surgir un 0day que cause estragos. Vulnerabilidad no conocida, sin parche, y si quieres redondearlo para sistemas Windows actualizados, con ejecución remota de código. Aunque actualmente este tipo de problemas suelen estar tan bien cotizados en el mercado negro que no se emplean en ataques a gran escala sino para ataques muy muy dirigidos.

Cosas positivas, la comunicación e información es mucho más rápida (que antaño), así como la colaboración entre empresas de seguridad, antivirus, proveedores, telcos, organismos gubernamentales, etc. colaboran de forma activa y mucho más cuando hay que enfrentarse a casos como este. La seguridad de la red es algo que nos atañe a todos. En este caso cabe señalar la colaboración de telefónica con otras compañías compartiendo toda la información que disponía, medidas, etc. 

Cosas negativas. Como siempre en muchos casos la información de algunos medios más pensando en una noticia mediática que en la propia noticia y en lo que importa. Algo que cada vez es más frecuente en Internet, especialmente con el uso y abuso de redes sociales, es el hacer leña del árbol caído. En este caso muchas de las informaciones se centraban en Telefónica, sencillamente porque fue la primera afectada y la que reconoció el problema, le podía haber tocado a cualquiera. De hecho otras actuaron de forma proactiva al saber lo que ya había pasado. A las pocas horas vimos como el problema era global. Empezamos a conocer noticias del sistema de salud inglés, de Latinoamérica, y otras compañías afectadas de todo el mundo.

Microsoft también saca sus propias conclusiones, también interesantes incidiendo igualmente en la importancia de mantener los sistemas actualizados y de la coordinación entre todos los actores para luchar contra estos ataques.
"Debemos tomar de este reciente ataque una renovada determinación para una acción colectiva más urgente. Necesitamos que el sector tecnológico, los clientes y los gobiernos trabajen juntos para protegerse contra los ataques cibernéticos. Se necesita más acción, y se necesita ahora. En este sentido, el ataque WannaCrypt es una llamada de atención para todos nosotros. Reconocemos nuestra responsabilidad de ayudar a responder a esta llamada, y Microsoft se compromete a hacer su parte."
Las lecciones que debemos aprender están expuestas desde hace mucho, solo nos queda ser realmente conscientes de que debemos aprenderlas y tomarnos el problema en serio. Esperemos que esta vez haya sido la definitiva.

Más información:

una-al-dia (12/05/2017) Un ransomware ataca a múltiples compañías
http://unaaldia.hispasec.com/2017/05/un-ransomware-ataca-multiples-companias.html

una-al-dia (25/4/1999) El virus CIH se activa mañana
http://unaaldia.hispasec.com/1999/04/el-virus-cih-se-activa-manana.html

una-al-dia (04/05/2000) Consideraciones sobre VBS.LoveLetter, un gusano muy simple

una-al-dia (27/01/2003) Lecciones del gusano MS-SQL

una-al-dia (03/05/2005) Lecciones aprendidas con Bagle/Beagle

una-al-dia (22/01/2007) El mediático troyano de la tormenta y las lecciones no aprendidas

una-al-dia (03/05/2004) Gusano Sasser: un mal menor que evidencia la falta de seguridad

una-al-dia (02/04/2009) Éxitos y fracasos de Conficker

The need for urgent collective action to keep people safe online: Lessons from last week’s cyberattack


Antonio Ropero
Twitter: @aropero

miércoles, 14 de mayo de 2014

Virus de la Policía en Android: Técnicas usadas para bloquear el movil y como eliminarlo

Conocemos el Virus de la Policía que afecta a los ordenadores bloqueando la pantalla y pidiendo dinero para desbloquear el sistema, el comportamiento típico de cualquier "ransomware". Recientemente se ha descubierto una versión para Android. Vamos a mostrar las técnicas usadas por el atacante para forzar que el malware permanezca en primer plano y persista al reinicio del dispositivo. Por último, ofreceremos una forma para eliminarlo del dispositivo.

Si ejecutamos el Virus de la Policía en el emulador de Android, vemos una página web en la que nos pide dinero para desinstalar la aplicación. Al igual que ocurre con la versión de escritorio, sin pagar, es imposible de salir de la aplicación porque siempre vuelve al primer plano y no nos deja suficiente tiempo para desinstalarla a partir del menú "Ajustes" de Android.


Hemos usado "jd-gui" para decompilar la aplicación. Sin embargo, con la ofuscación y las técnicas de anti-decompilación, el decompilador no puede decompilar todas las partes del programa por lo que tenemos que usar Eclipse para depurar la aplicación. Es importante observar que las partes de código mostradas en esta entrada han sido convenientemente tratadas.

Para empezar, analizamos el archivo de configuración de la aplicación "AndroidManifest.xml", que contiene actividades, servicios, permisos usados, identificador de la aplicación (package name), etc. Vemos que el malware tiene el nombre de paquete "com.android". Con el filtro "MAIN", podemos comprobar que la actividad "MainActivity" es la primera que se ejecuta cuando el usuario ejecuta la aplicación. Después, se definen dos receptores "ScheduleLockReceiver" y "ScheduleUnlockReceiver" para ejecutarse en procesos diferentes por la etiqueta ":remote" (se explicarán más detalladamente). Por último el "BootstrapReceiver" es un clase que va a registrarse al evento "BOOT_COMPLETED" del móvil y que se llama durante la inicialización del móvil con la prioridad mas alta "999". De esta forma permite la persistencia al reinicio del móvil. Al tener la prioridad más alta, será una de las primeras clases llamadas durante la inicialización del móvil.


Mirando el código decompilado de la clase "MainActivity", vemos que lanza la actividad "LockActivity" llamando a la función "startActivity". En la actividad lanzada hemos encontrado la función "dispatchKeyEvent" que permite al atacante monitorizar y anular los botones del dispositivo (como HOME, BACK, y MENU) y así evitar que el usuario salga de la aplicación fácilmente.















Esa misma clase va a lanzar en segundo plano el servicio "LockService", que va a programar dos tareas "ScheduleLockReceiver" y "ScheduleUnlockReceiver" a través del "AlarmManager". La primera tarea se ejecuta cada 2 segundos mientras que la segunda tarea se lanza cada 600 segundos. Como la segunda tarea no está implicada directamente en el bloqueo de la pantalla, nos concentramos en la primera tarea.



Cada vez que la tarea se ejecuta, se ejecuta la función "onReceive" y lanza el servicio "LockService" pasando el parámetro "start.event.type" a 2.










Llamando al servicio, se llama a la función "dispatchEvent". Con el tipo de evento 2, fuerza la actividad a lanzarse de nuevo. Y así no permite a otra aplicación pasar al primer plano.





Desinstalar el Virus de la Policía en Android

Como no tenemos acceso a la pantalla, no podemos desinstalar manualmente la aplicación desde el menú "Ajustes/Aplicaciones". Sin embargo, Google proporciona una herramienta llamada "adb" usada por desarrolladores de aplicaciones Android para instalar y desinstalar aplicaciones, grabar logs, etc. Antes de desinstalar una aplicación, necesitamos conocer el nombre del paquete que la identifica. Esta información se encuentra en el archivo de configuración "AndroidManifest.xml". Podemos ver que en este caso el nombre de paquete del ransomware es "com.android".

La utilidad "adb" se encuentra incluida dentro del Android SDK disponible para descarga desde:

Una vez instalado (descomprimirlo) será necesario conectar el dispositivo infectado al ordenador, localizar la herramienta "adb" en la carpeta "/sdk/platform-tools/" y ejecutar el comando:
adb uninstall com.android
con lo que conseguiremos desinstalar el malware.

Más información:

El virus de la policía "evoluciona" e impide el acceso en modo seguro

Nuevas variantes del “virus de la policía”. Ahora para Android

Police Locker land on Android Devices

Java decompiler

Depurar malware Android con Eclipse

Android Debug Bridge

Hash del ransomware:
2e1ca3a9f46748e0e4aebdea1afe84f1015e3e7ce667a91e4cfabd0db8557cbf

una-al-dia (21/06/2011) Vídeo: Troyano secuestra el ordenador en nombre de la policía nacional acusando al usuario de terrorista zoofílico

una-al-dia (28/02/2012) Vuelve el troyano que se hace pasar por la policía: Cómo protegerse (de verdad)

una-al-dia (02/03/2012) El virus de la policía "evoluciona" e impide el acceso en modo seguro

una-al-dia (06/03/2012) Más información sobre el virus de la policía

una-al-dia (09/03/2012) El malware de la policía aprovecha un exploit de Java "in-the-wild" y el secreto su "éxito"

una-al-dia (18/03/2012) WhitePaper: Estudio técnico del troyano de la policía

una-al-dia (24/05/2012) Nuevas versiones del malware de la policía y cómo eludirlas




Laurent Delosières


domingo, 28 de abril de 2013

Últimas versiones del virus de la policía y más ideas para protegerse

El virus de la policía continúa evolucionando, con altos niveles de infección y nuevas estrategias fundamentadas siempre en la misma premisa: el secuestro del ordenador con la excusa de que, ante la detección de actividad ilegal en el sistema, es necesario pagar una multa a la policía. Veremos qué ligeros cambios se han observado en las últimas versiones y una idea para protegernos.

Las últimas versiones aparecían en forma de DLL. Era necesario llamarlas conociendo el nombre de la función de entrada del binario para poder ejecutarlo. Esta estrategia podía estar orientada a intentar eludir los sistemas de ejecución automática y desatendida de los laboratorios, puesto que la DLL pasaría a veces inadvertida si no se llamaba a la función concreta. Estas muestras solían instalarse en la carpeta de inicio.

En los últimos tiempos se ha observado que el malware ha pasado a utilizar un archivo con extensión .DAT (y de nombre skype), que no es más que un ejecutable (cuyos dos primeros bytes son MZ). Esto no es un problema para que sea lanzado, pero sí podría confundir a usuarios y análisis. Además crea un skype.ini. También ha vuelto a los "orígenes", anclándose en una rama del registro donde se lanza el explorer.exe. Veamos cómo funciona.

El ejecutable, fundamentalmente, busca el %APPDATA% del usuario, puesto que en Windows 7, podrá escribir sin problemas en él. Ahí dejará el archivo skype.dat (ejecutable).


En el registro, acudirá a la rama de usuario (también porque puede escribir sin problemas en ella) donde se lanza explorer.exe (proceso encargado de dibujar el escritorio y delegar los tokens de seguridad). Ahí se añade como ejecutable que será lanzado al inicio. Es muy extraño que un usuario necesite modificar ese punto del registro, así que podría ser protegido por permisos. Esto ya lo hace la herramienta WinLockLess, negando por permisos de registro la escritura en los puntos habituales que utiliza el ramsonware.




Pero también es posible tocar los permisos NTFS de la máquina, para evitar que se escriba en un punto clave que están usando tanto los creadores del virus de la policía como el malware en general. %APPDATA% es una variable que apunta habitualmente a

C:\usuarios\nombreusuario\appdata\roaming

Ahí se almacena información de los programas del usuario y su configuración privada. En esta carpeta es muy extraño que se creen ficheros. No suele ser necesario. Normalmente son directorios que alojan archivos con datos. Todavía más extraño es que se necesite ejecutar código desde la raíz de %APPDATA%.

Por tanto, de nuevo, utilizar los permisos NTFS (siempre demasiado relajados por defecto) puede mitigar el problema. Podemos decirle a Windows que impida la ejecución de ficheros desde esta carpeta, pero que siga permitiendo crear carpetas e, incluso, archivos... pero que no los ejecute.

Gráficamente es muy simple. En las propiedades de la carpeta Roaming, Seguridad, Opciones Avanzadas, Cambiar Permisos, Agregar. Ahí añadimos que "Todos" no puedan explícitamente ejecutar archivos. Importante indicar que esto se aplica a "Solo archivos".



Con esto no se evita la infección, pero sí que en el siguiente reinicio se ejecute el fichero. Si se desea, también se puede evitar la escritura de ficheros en la raíz de Roaming.

Por línea de comando, se puede llamar a:

icacls %appdata% /deny *S-1-1-0:(OI)(IO)(X)

Donde "(OI)(IO)" indica el "Solo ficheros", el "X" la ejecución, y "S-1-1-0" es el SID del usuario "Todos" en los Windows.



Importante apreciar que en Windows XP, por implementar una versión ligeramente diferente de NTFS, es posible seguir estos pasos pero no tendrán exactamente el mismo comportamiento.

Más información:

Golpe policial a una de las mayores redes cibercriminales especializada en infectar millones de ordenadores de todo el mundo

una-al-dia (21/06/2011) Vídeo: Troyano secuestra el ordenador en nombre de la policía nacional acusando al usuario de terrorista zoofílico

una-al-dia (28/02/2012) Vuelve el troyano que se hace pasar por la policía: Cómo protegerse (de verdad)

una-al-dia (02/03/2012) El virus de la policía "evoluciona" e impide el acceso en modo seguro

una-al-dia (06/03/2012) Más información sobre el virus de la policía

una-al-dia (09/03/2012) El malware de la policía aprovecha un exploit de Java "in-the-wild" y el secreto su "éxito"

una-al-dia (18/03/2012) WhitePaper: Estudio técnico del troyano de la policía

una-al-dia (24/05/2012) Nuevas versiones del malware de la policía y cómo eludirlas


Sergio de los Santos
Twitter: @ssantosv