22 de enero de 2020

A finales del año pasado, usando la función de cambios en el área del sistema, se registró un cambio del archivo de sistemas /system/lib/libc.so de algunos de nuestros usuarios. Es una de las bibliotecas básicas de sistemas operativos a base de Linux que se encarga de las llamadas de sistema y las funciones básicas. Una investigación detallada de este caso permitió detectar nuevas muestras de la familia de troyanos Android.Xiny, conocido para nosotros a partir del año 2015. Sus representantes tenían el atributo «no variable» para archivos, lo cual dificultaba bastante la eliminación de los troyanos de dispositivos. Todo parecía bastante curioso: el atributo indicado se usaba para el archivo apk de la aplicación instalada, un intento de eliminar esta aplicación parecía correcto, sus datos se eliminaban, pero el archivo apk mismo se quedaba intacto. Una vez reiniciado el dispositivo, la aplicación volvía a «aparecer». Sobre uno de estos troyanos informamos en el año 2016. Para afrontar amenazas similares, hemos añadido a nuestro antivirus la función de restablecer atributos para archivos que funciona si el usuario concede permisos root al antivirus.

En este artículo vamos a ver otro método de autoprotección interesante aplicado por las nuevas versiones de Android.Xiny.

¿Android 5.1? ¿En el año 2019?

El troyano analizado en este artículo funciona en SO Android hasta la versión 5.1 inclusive. Puede parecer raro que el software creado para las versiones tan antiguas de Android sigue siendo activo (la versión 5.1 fue lanzada en el año 2015). Pero, a pesar de la antigüedad, las antiguas versiones siguen siendo usadas. Según los datos de la corporación Google, a fecha de 7 de mayo del año 2019, un 25.2% de dispositivos funcionan en Android 5.1 o inferior. Las estadísticas por nuestros usuarios visualizan un número ligeramente más alto - unos 26%. Significa que cerca de un cuarto de todos los dispositivos en Android son objetivos potenciales, lo cual no es poco. Tomando en cuenta que los dispositivos indicados se someten a las vulnerabilidades que nunca serán corregidas, no es de extrañar que las antiguas versiones del SO Android aun sean de interés para los creadores de virus. Es que los permisos root que uno puede tener al usar las vulnerabilidades mencionadas permiten a los creadores de virus actuar, usando los mismos, se puede hacer cualquier cosa en el dispositivo. Aunque con mayor frecuencia solo se trata de una simple instalación de aplicaciones.

Funciones básicas del troyano

Desde las versiones más recientes, la función principal del troyano Android.Xiny es instalar en el dispositivo las aplicaciones aleatorias sin permiso del usuario. De esta forma, los malintencionados pueden ganar dinero al participar en los programas socio que pagan por instalación. Parece que sea una de las fuentes de ingresos básicas para los creadores de esta familia. Una vez iniciados algunos representantes del mismo, en unos minutos el dispositivo puede casi dejar de funcionar, y en el mismo serán instaladas y lanzadas múltiples aplicaciones no nocivas, pero no necesarias para el usuario. Además, estos troyanos pueden instalar el software nocivo, todo depende del comando recibido del servidor de control.

La peculiaridad más destacada de las nuevas versiones del troyano Android.Xiny - es la protección contra la eliminación. Lo realizan dos componentes. Vamos a verlos con más detalle.

Instalador

• sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
• detect: Android.Xiny.5261

Este componente se inicia una vez recibidos los permisos root. Suplanta por sí mismo los archivos de sistema /system/bin/debuggerd y /system/bin/ddexe, para asegurar su propio inicio automático, y guarda los originales con nombres con sufijo _server, actúa como un virus compañero clásico. Así mismo, copia al área del sistema varios archivos ejecutables más de la carpeta transferida en las opciones de la línea de comandos. Además, el troyano puede actualizar los componentes que instaló en el área del sistema, en caso de ser iniciado con opciones particulares e indicar la carpeta de las nuevas versiones.

Android.Xiny.5261 contiene una lista importante de archivos para eliminación Incluye rutas características para los representantes más antiguos de la familia, así como para las familias de troyanos de competencia que se instalan en el área del sistema. Tales como, por ejemplo, Triada.

Además, Android.Xiny.5261 elimina algunas aplicaciones preinstaladas, posiblemente, para liberar espacio. Finalmente, elimina las aplicaciones conocidas para administrar los permisos root – tales como SuperSU, KingRoot y otras. De esta forma, no le permite al usuario usar los permisos root y, por lo tanto, eliminar los componentes troyano instalados en el área del sistema.

Biblioteca del sistema modificada libc.so

• sha1: 171dba383d562bec235156f101879223bf7b32c7
• detect: Android.Xiny.5260

Es el archivo que más nos interesó, y con el mismo empezamos esta investigación. Al verlo rápido en hiew, se puede notar un código ejecutable al final de la sección .data, lo cual es sospechoso.

Abrimos el archivo en IDA y vemos qué código es.

Resulta que en esta biblioteca han sido cambiadas las funciones siguientes: mount, execve, execv, execvp, execle, execl, execlp.

Código de la función cambiada mount:

int __fastcall mount(const char *source, const char *target, const char *filesystemtype, unsigned int mountflags, const void *data)
{
  unsigned __int8 systemPath[19]; // [sp+18h] [bp-1Ch]
  bool receivedMagicFlags; // [sp+2Bh] [bp-9h]
  int v13; // [sp+2Ch] [bp-8h]
  v13 = MAGIC_MOUNTFLAGS; // 0x7A3DC594
  receivedMagicFlags = mountflags == MAGIC_MOUNTFLAGS;
  if ( mountflags == MAGIC_MOUNTFLAGS )
    mountflags = 0x20;                          // MS_REMOUNT
  if ( receivedMagicFlags )
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  if ( mountflags & 1 )                         // MS_RDONLY
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  if ( getuid_() )                              // not root
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  memCopy(systemPath, (unsigned __int8 *)off_73210 + 471424, 8);// /system
  decrypt(systemPath, 8);
  if ( memCompare((unsigned __int8 *)target, systemPath, 8) || !isBootCompete() )
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  *(_DWORD *)errno_() = 13;
  return -1;
}

Al principio, se comprueba la opción mountflags en busca del valor particular 0x7A3DC594. Si este valor ha sido transferido a la función, la administración se asigna enseguida a la función actual mount. Luego se comprueba si se produce un intento de volver a montar la sección /system para la escritura y si el inicio del SO ha sido finalizado. Si estos requisitos se cumplen, la función actual mount no se llama y se devuelve un error. De esta forma, la función mount modificada por el troyano no permite volver a montar el área del sistema para la escritura a nadie, excepto el mismo troyano que la llama con una opción particular.

Código de la función execve modificada (en las demás funciones exec* todo es similar):

int __fastcall execve(const char *filename, char *const argv[], char *const envp[])
{
  int v3; // r3
  if ( targetInDataOrSdcard(filename) >= 0 )    // returns -1 if true
  {
    sub_7383C();
    v3 = call_real_execve(filename, argv, envp);
  }
  else
  {
    *(_DWORD *)errno_() = 13;
    v3 = -1;
  }
  return v3;
}

int __fastcall targetInDataOrSdcard(const char *path)
{
  char buf[516]; // [sp+8h] [bp-204h]
  if ( isDataOrSdcard(path) )
    return -1;
  if ( *path == '.' && getcwd_(buf, 0x200u) && isDataOrSdcard(buf) )
    return -1;
  return 0;
}

Aquí se comprueba si la ruta al archivo iniciado empieza con "/data/" y contiene "/sdcard". Si uno de estos requisitos se cumple, el inicio se bloquea. Recordamos que en la ruta /data/data/ hay directorios de aplicaciones. De esta forma, se bloquea el inicio de los archivos ejecutables de todos los directorios donde una aplicación ordinaria puede crear un archivo.

Los cambios realizados en la biblioteca de sistema libc.so, dañan el funcionamiento de las aplicaciones destinadas para tener permisos root. Por causa de cambios en las funciones exec* esta aplicación no podrá iniciar exploits para mejorar los privilegios en el sistema, porque normalmente los exploits son archivos ejecutables que se descargan de la red al directorio de la aplicación y se inician. Pero en caso de conseguir mejorar los privilegios, la función cambiada mount no permitirá volver a montar el área del sistema para la escritura y, por lo tanto, realizar algún cambio en el mismo.

Como resultado, la autoprotección del troyano consiste en dos partes: su instalador elimina las aplicaciones para administrar los permisos root, y la biblioteca libc.so modificada no permite volver a instalarlas. Además, esta protección funciona en caso de «competidores», otros troyanos que tienen permisos root y se instalan en el área del sistema, porque funcionan de la misma forma que las aplicaciones no nocivas para obtener permisos root.

¿Cómo afrontar un troyano de este tipo?

Para deshacerse de Android.Xiny.5260, se puede cambiar el firmware del dispositivo, si hay firmware para el mismo en acceso libre. Pero ¿será posible eliminar el programa nocivo de otra forma? Es complicado, pero se puede, hay varios modos. Para tener los permisos root, se puede usar exploits como bibliotecas so. A diferencia de archivos ejecutables, el troyano no bloqueará la carga de los mismos. Así mismo, se puede usar un componente del troyano mismo que sirve para otorgar permisos root a otras partes del mismo. Recibe los comandos a través del socket por la ruta /dev/socket/hs_linux_work201908091350 (en varias modificaciones puede ser distinto). En cuanto a lo de esquivar el bloqueo mount, se puede usar el valor particular de la opción mountflags, o llamar directamente syscall correspondiente.

Si su dispositivo se infecta con un troyano de este tipo, recomendamos cambiar el firmware y usar el firmware oficial. Pero no olvide que de esta forma se eliminan todos los archivos y programas de usuario, por lo tanto, cree las copias de seguridad con antelación.