En ocasiones, desde el lado de la investigación usamos componentes maliciosos en nuestros entornos de prueba, como por ejemplo un APK malicioso creado específicamente. Para hacerlo, se requiere algo de personalización: modificar el icono de la aplicación, el nombre de la aplicación, la lista de permisos peticionados, alguna funcionalidad que posee un bug o que necesita ajustarse a determinada plataforma o dispositivo, entre otras cosas.
Cuando se trata de una operación de única vez, uno puede arreglárselas en el momento con una consola y algunos comandos, pero cuando se trata de una tarea repetitiva, la automatización se vuelve necesaria.
En particular, me encontraba preparando una demostración que incluía la generación de un APK malicioso con msfvenom para generar una conexión TCP inversa. Según el escenario planteado, era fundamental que el icono y el nombre de la aplicación concordasen con los de la aplicación explotada. Para complicar las cosas, la IP de conexión no podía ser estática, por lo que necesitaría generar el APK malicioso una y otra vez antes de cada evento.
Se ha confirmado un problema en Chrome y Firefox que podría permitir la realización de ataques de phishing mediante el uso de caracteres Unicode. Conocidos como ataques homográficos, representan un problema que los navegadores intentan evitar, pero se ha descubierto una forma para evitar los controles actuales. Se puede visitarhttps://www.аррӏе.com/ para entender las implicaciones.
Ahora bien, las implicaciones en el mundo de la seguridad que pueden representar estos dominios son grandes, ya que muchos caracteres Unicode pueden ser difíciles de distinguir de los caracteres ASCII normales. De esta forma, es posible registrar dominios como “xn--pple-43d.com”, equivalente a “аpple.com” por el uso de la a en cirílico “а” (U+0430) en vez de la “a” en ASCII (U+0041). Este tipo de ataques son conocidos como homográficos.Con el uso de Punycode se pueden representar caracteres Unicode mediante el subconjunto de caracteres ASCII empleado para los nombres en Internet. De esta forma se pueden registrar dominios que hagan uso de caracteres no permitidos, por ejemplo podríamos registrar un dominio como España.com que quedaría como xn--espaa-rta.com. Evidentemente no es muy empleado porque para temas como el SEO, promoción y marca, no es muy eficiente. Queda raro que haya que escribir algo como xn--espaa-rta.com.Los navegadores modernos tienen mecanismos para evitar o limitar este tipo de ataques. En Chrome y Firefox la forma Unicode se esconde si un dominio contiene caracteres de varios lenguajes diferentes. De esta forma, por ejemplo el dominio “xn--pple-43d.com” aparecerá como tal (en vez de “аpple.com”) al contar con caracteres de dos lenguajes, de esta forma se evita la confusión con el dominio real.
Pero el sistema de protección ante ataques homográficos falla si todos los caracteres son sustituidos con un carácter similar del mismo lenguaje. El dominio “аррӏе.com” registrado como “xn--80ak6aa92e.com” evita el filtro al emplear únicamente caracteres cirílicos. Esta forma de evitar la protección afecta a Chrome y Firefox, mientras que Internet Explorer, Microsoft Edge y Safari se libran del problema.
El desarrollador Xudong Zheng (@Xudong_Zheng) reportó el fallo a Chrome y Firefox el 20 de enero de 2017 y confirma que ha quedado corregido en la rama de Chrome 59, aunque finalmente se incluirá en Chrome 58 que estará disponible en torno a la semana que viene. Por ahora sigue sin corregir en Firefox ya que no han decidido si está dentro de su alcance.
Como contramedida en Firefox se puede configurar desde about:config y asignar network.IDN_show_punycode a true. Esto fuerza a Firefox a mostrar siempre los dominios IDN en su forma Punycode, lo que permite identificar los dominios maliciosos.
¿Se puede robar a una sesión de usuario de Windows usando sólo el Administrador de Tareas y/o el CMD? Parece que sí. Eso es lo que ha redescubierto el investigador en seguridad Alexander Korznikov y ha despertado todo tipo de discusiones.
El método tiene varias limitaciones.
Se requiere privilegios de administración sobre el sistema.
La cuenta a secuestrar debe haber iniciado sesión.
La cuenta a secuestrar no debería haber cerrado su sesión (solo la ha bloqueado)
Se requiere acceso físico al PC en el que se encuentra la cuenta objetivo, (parece) que no se puede realizar de forma remota.
Que utilicemos la palabra “redescubierto” no es casual. El “truco” es posible gracias a un bug que ya tiene seis años de antigüedad pero que, al parecer, Microsoft todavía no ha solucionado. Se puede ver el error en funcionamiento en el siguiente vídeo (via Task Manager, via CMD, via servicio)
Según se puede observar en el vídeo, para poder explotar el bug hay que acceder al sistema con una cuenta cualquiera que tenga privilegios de administración. Antes de eso, la cuenta objetivo debe haber iniciado sesión en el sistema y estar operativa. Además, el usuario debe haber usado “Cambiar usuario” o “Bloquear” en lugar de “Cerrar sesión” para abandonar el PC.
En este caso no es necesario usar ningún tipo de malware, ni tener conocimientos avanzados de cualquiera de las materias que citamos al principio del artículo. Es decir, cualquiera con conocimientos básicos de informática podría aprovecharse del bug si sabe cómo.
Este “bug o funcionalidad” está presente en todas las versiones a partir de Windows 7 y hasta Windows 2016.
Actualización: existe una gran discusión de si este hallazgo corresponde realmente a un bug o al diseño de Windows, el cual que sería menospreciado por ser necesario acceso local al sistema. Por eso, Kevin Beaumont realizó una PoC y demostró cómo se puede utilizar este “truco” para lograr un RDP session hijacking, dando lugar a que efectivamente este sería un vector real de ataque.
Hasta ahora existen estas formas de llevar a cabo el ataque y seguramente irán apareciendo más con el pasar de los días:
La condición de carrera o race condition es un tipo de vulnerabilidad bastante frecuente.
Estos errores son producidos en situaciones de concurrencias de varios hilos en las que se compite por los recursos que proporciona el sistema operativo.
Bajo estas condiciones hay ocasiones en las que se presentan situaciones en las que dos o más procesos tienen que leer o escribir en un área común que comparten.
En estos casos se deberían tomar las precauciones necesarias para que las acciones llevadas a cabo por cada recurso fuesen atómicas, sin embargo, hay ocasiones en las que no los son, ocasionando datos inconsistentes o dejando en ocasiones abierto un intervalo de tiempo en el que un atacante podría obtener privilegios, leer y escribir sobre ficheros protegidos.
Un ejemplo muy sencillo de lo que es una condición de carrera lo vemos ilustrado en el siguiente listado:
Var x=10
Sub decrementar {
if (x>0) {
X -
}
}
Si tenemos una rutina como la anterior, donde X es una variante global compartida, si un único proceso es el que la ejecuta, la variable no tomara nunca un valor negativo, sin embargo en un entorno concurrente, en el que varios procesos ejecutan la misma rutina compitiendo por el tiempo de CPU, si un proceso no iniciase la ejecución de la misma hasta que otro no finalice su ejecución no habría problemas.
Pero podría darse la situación en la que un proceso P1 inicie la ejecución de la rutina para un valor de x=1, P1 realiza la comprobación x>0 también se cumple y se ejecuta el código contenido en la comprobación, con lo que X toma el valor 0.
El proceso P2 termina su ejecución en el mismo punto en el que se paró, es decir, decrementando la variable X, ya que la comprobación la realizo anteriormente, con lo que el final de esta rutina devuelve un valor negativo en la variable X.
Este es un ejemplo muy básico para entender que es una vulnerabilidad de condición de carrera pero los hay mucho más complejos y que pueden producir daños irreparables en los ficheros del ordenador que se encuentra vulnerable.
Todos nos hemos topado con la palabra ransomware alguna vez, ya que es algo que da que hablar constantemente. Para aquellos que no lo conocen, se trata de un tipo de malware que se encarga de secuestrar un dispositivo con un método característico: cifrando los archivos con una clave secreta. Una extorsión que obliga al usuario a pagar un rescate económico para desbloquearlo; habitualmente mediante una criptomoneda. Incluso pagando el rescate existen casos en los que no puede recuperarse la información, ya que o nunca llegan a proporcionar la clave una vez hecho el pago o esta es inservible.
A pesar de ello, no se le muestra suficiente atención en Android, siendo aun el ordenador de sobremesa o servidor el objetivo habitual, posiblemente por razones estrictamente achacables al retorno de inversión. En este breve estudio, veremos si deberíamos, o no, preocuparnos por este tipo de malware en dispositivos móviles. Y constataremos como se está consolidando como una plataforma lucrativa para los creadores de ransomware. Continue reading →
Cuando se trata de malware, Android tiene un mecanismo de defensa muy bueno (el sistema de permisos de aplicaciones). Este sistema define una serie de acciones que una aplicación tiene permitidas (o no) para funcionar. Por defecto, todas las aplicaciones de Android funcionan en aislamiento de procesos (un entorno aislado). Si quieren acceder, editar o borrar información fuera de dicho aislamiento, necesitarán los permisos del sistema.
Los permisos se dividen en varias categorías, pero hablaremos solo de dos: normal y peligroso. Los permisos normales cubren acciones como el acceso a Internet, la creación de iconos, conexión Bluetooth, etc. Estos permisos se conceden por defecto y la aprobación del usuario no es necesaria.
Si una aplicación necesita uno de los permisos “peligrosos”, se requiere la confirmación del usuario. Entonces, ¿por qué se considera que algunos permisos son peligrosos? ¿De verdad son por naturaleza peligrosos? ¿En qué casos deberías permitirlos?
Permisos peligrosos
La categoría “peligrosa” incluye nueve grupos de permisos en los que las aplicaciones están, de algún modo, conectadas con la privacidad o seguridad del usuario. Cada grupo contiene varios permisos que una aplicación puede requerir.
En la era del ransomware, plagada de familias que cifran archivos o bloquean dispositivos con el objetivo de que las víctimas paguen un rescate por ellos, era de esperar que algunas amenazas empiecen a querer diferenciarse del resto. Fue así como nació Spora, detectada por las soluciones de ESET como Win32/Filecoder.Spora.A; entre las varias peculiaridades que tiene, la que más llama la atención es la creación de un servicio de atención al cliente disponible en ruso y en inglés.
Desde su descubrimiento el mes pasado, las detecciones fueron en aumento especialmente en Rusia, que reúne el 71%. Un detalle: “spora” es “espora” en ruso, y fue en ese idioma que las primeras versiones de la amenaza exigían el pago de un rescate.
Los cibercriminales realmente se han esforzado en este caso y se consideran “profesionales”, aunque podemos discernir a la hora de concederles que la creación y operación de malware es una profesión… De cualquier manera, Spora tiene una gran estructura detrás, la capacidad de trabajar offline, un portal de pago de rescates bastante desarrollado y, lo más sorprendente, una ventana de chat en tiempo real para que las víctimas se pongan en contacto con los operadores.
Este servicio de atención al cliente está disponible en ruso y en inglés, y busca fomentar la imagen “confiable” que pretenden dar estos ciberdelincuentes, prometiendo restituir archivos y accesos ni bien se pague el rescate, y ofreciendo extender los plazos a quienes no logren reunir el dinero. Además, piden con insistencia que los usuarios afectados les dejen críticas favorables una vez que ellos cumplan su palabra. Estamos de acuerdo en que por más cumplidores que sean, esta no deja de ser una actividad criminal y extorsiva, ¿verdad?
Estos son algunos ejemplos de las conversaciones que recogió Bleeping Computer:
Es cierto que solemos decir que pagar no asegura la devolución de los archivos y en este caso parecería que hay más garantías, pero aun así, siempre es mejor prevenir que lamentar y tener que remediar una infección.
La forma más común de propagación es a través de spam de correos electrónicos que pretenden ser facturas de 1C, un popular software contable en Rusia y países cercanos. Esta técnica también había sido implementada por el ransomware Locky. Las supuestas facturas llegan en forma de archivos .ZIP que, a su vez, alojan archivos HTA (HTML Application) con doble extensión oculta (PDF.HTA o DOC.HTA), con el objetivo de pasar desapercibidos. Así, en los equipos Windows donde se oculte la extensión del archivo, el usuario solo vería la primera extensión ficticia.
Una vez que infecta el equipo, Spora despliega una complicada rutina que involucra la creación de un archivo .KEY y de una llave para cifrar los archivos de la víctima. “Spora está escrito en C y está empacado usando el packer ejecutable UPX. A diferencia de la mayoría de familias de ransomware, no renombra los archivos que cifra, por lo que no hay extensiones específicas asociadas. Al infectar un sistema, muestra una nota con el pedido de rescate basada en HTML y un archivo .KEY. El nombre base de ambos archivos es idéntico al ID que el ransomware le asigna a cada usuario”, explican desde Emsisoft. Es con este ID que las víctimas deben “hacer login” en un elegante sitio especialmente creado por los ciberdelincuentes para gestionar los pagos de rescate.
En síntesis, Spora se diferencia de otras familias de ransomware por las siguientes características:
Trabaja offline, por lo que no genera ningún tráfico de red a los servidores online.
Los archivos cifrados no cambian de nombre ni se les añade una extensión.
No tiene una lista demasiado grande de extensiones que desea cifrar, como sí tienen Locky, Cerber o CTB-Locker. Figuran las de ofimática, imágenes y archivos comprimidos.
Montó un atento servicio de atención al cliente y una desarrollada especie de tienda en línea que ofrece varias opciones de descifrado de archivos (dos sin cargo, uno por 30 dólares, restauración completa por 79). También ofrece “inmunidad” contra futuras infecciones y la remoción del malware.
Con tanta puesta en escena, probablemente Spora siga expandiéndose en los próximos meses, por lo que no sería de extrañar que deje de apuntar a usuarios de habla rusa y llegue a Latinoamérica. Para evitar ser víctima de este y otros ransomware, presta atención a este video:
El grupo No More Ransom ha estado trabajando en el desarrollo de herramientas para descifrar ciertos tipos de ransomware para ofrecerlo tanto a los ámbitos privados como públicos.
1. Rannoh Decrypter
Hecho por Kaspersky Lab, diseñado contra Rannoh y CryptXXX. Para éste último, funciona en las versiones 1, 2 y 3. Disponible en éste link.
2. Wildfire Decryptor
Diseñado por Kaspersky Labs e Intel Security, seguí este link para más información.
La última compañía que ha comprobado estos problemas ha sido LG, fabricante que ha comprobado cómo varias de sus televisiones inteligentes quedaban inservibles.
Tal y como se puede observar en la siguiente imagen, parece que el dispositivo ha sido infectado por una variante del “virus de la policía”, pero en vez de bloquear el equipo bloquea sus archivos. Esto ha provocado además problemas a la hora de que el televisor funcione de forma adecuada. Al proceder al bloqueo de archivos importantes el dispositivo ha mostrado problemas para funcionar de forma correcta, pudiendo decir que ha quedado parcialmente inservible en esa situación.
Con la adopción de Internet como parte de la vida moderna, muchos de los casos de acoso que sucedían en ámbitos como la escuela o el club se trasladaron a medios digitales como redes sociales, correo electrónico o sitios web. Para concientizar más sobre este tema y ayudar a niños y adultos a prevenirlo, ESET preparó este video.
Non static security 