2020.01.22

• Doctor Web公司博客,
• 信息安全,
• 反病毒保护

去年年末我公司的设备系统区域更改侦测机制发现有些用户设备的系统文件/system/lib/libc.so出现了更改。这一文件是一个基于Linux的操作系统主库，负责系统调用和系统主要功能。我公司技术人员对此文件的更改作出详细分析，发现了木马家族Android.Xiny的新样本。 此木马家族的最早样本是2015被我们侦测到的。

此木马家族首次对文件使用了«不可更改»属性 ，大大增加了将木马从设备删除的难度。

这种防删除机制的工作原理是这样的：应用的安装文件apk具备这一属性，试图删除应用时看起来像是成功删除，但其实删除的只是应用的数据，而apk文件仍然还在设备上。2016年我公司就曾parlato过一个此类木马。为了应对此类木马，我们的反病毒软件添加了取消文件属性的功能，此功能运行的前提是用户向我们的反病毒软件提供了root全权。

这里我们要介绍的是Android.Xiny新样本中采用的另一个自我保护机制。

Android 5.1? 2019年?

本文所介绍的木马针对的是Android 5.1以及更低版本设备。看起来可能会有些奇怪，为什么新木马针对的会是年代如此“久远”的操作系统，要知道安卓5.1是 2015年问世的。但实际上尽管历时已久，老版本操作系统的安卓设备依然相当常见。2019年5月7日Google公司发布的数据显示，有25.2% 的安卓设备使用的是Android 5.1及更低版本，我公司用户统计数据略高，为26%。这也就意味着，有四分之一的安卓设备用户可能成为不法分子的进攻对象，这并不是个小数目。由于上述设备的漏洞不可弥补，这些安卓老版本一眼会是病毒编写者十分感兴趣的进攻对象，利用存在的漏洞可以获得设备root权限，而获得权限就会让病毒编写者放开手脚：利用root权限可以在设备上执行任何功能，虽然实际上不法分子主要想实现的功能就是任意安装应用。

木马主要功能

从最早出现的样本到最新样本，Android.Xiny的主要功能都是在没有得到用户允许的情况下将任何应用安装到设备。不法分子利用这种手段参与各种合作推广，依靠应用安装量获取酬金。这应该是此木马家族编写者的主要取利渠道。某些样本在设备启动后会在几分钟之内让设备失去运行能力：设备上会安装运行大量用户根本不需要的应用。此外，这些木马完全可以安装其他恶意软件，这只取决于木马从控制服务器接收到的是什么指令。

Android.Xiny木马新样本的“新颖”之处是其采用了新的防删除保护机制，由两个组件来完成。下面我们就来详细介绍一下。

安装器

• sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
• 侦测对象名称： Android.Xiny.5261

此组件在获取root权限后启用，将自身文件替换系统文件/system/bin/debuggerd和/system/bin/ddexe，目的是保证自启动，而原系统文件另存为名称加后缀_server的文件，这是典型的病毒功能。此外，安装器还会将命令行参数中给出的文件夹中的几个执行文件拷贝到设备系统区域。木马可以对已安装到系统区域的组件进行更新，只要给出特殊的启动参数并指定组件新版所在文件夹名称。

Android.Xiny.5261 中有一个很长的删除文件列表，其中有此木马家族老样本的典型路径，还有其“竞争对手”的路径，也就是安装到设备系统区域的其他木马家族，比如Triada.

此外，Android.Xiny.5261还会删除一些预置应用，目的可能是释放可用空间。最后会删除常用的root权限管理应用，如SuperSU、KingRoot等等。这样，用户就失去了自己使用root权限的可能性，也就无法删除安装到系统区域的木马组件了。

系统库libc.so变种

• sha1: 171dba383d562bec235156f101879223bf7b32c7
• 侦测对象名称： Android.Xiny.5260

我们对新样本的研究就是从这一文件开始的。在hiew中进行粗略的观察就会发现.data部分的结尾处出现可执行代码，令人可疑。

再在IDA中 打开文件，看一看这是什么代码。

原来，库中被替换了一系列功能： mount、execve、execv、execvp、execle、execl、execlp。

变化后的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;
}

这里一开始是检查参数mountflags是否有一个“口令” 0x7A3DC594。如果接收到这一口令，会启动真正的mount功能。之后会检查是否要对/system区域进行写入更改和操作系统是否完成加载 ，如果发现会不再调用mount功能并反馈错误。这样。被木马更改后的mount功能会阻止任何其他进程更改系统区域 ，只有木马本身利用特殊“口令”调用才可以对系统区域进行更改。

变化后的execve功能代码（其他exec*功能变化类似）：

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;
}

这里检查的是可执行文件路径一开始是否是"/data/"并是否包含 "/sdcard"，发现满足一个条件就会阻止启动。路径 /data/data/是应用所在目录，这样就会阻止从任何正常应用文件所在目录启动执行文件。

木马对系统库libc.so进行的更改能够阻止可获得root权限的应用正常运行。exec*功能发生更改后这样的应用就无法启动反漏洞攻击来提高在系统中的优先权，因为反漏洞攻击属于执行文件，从网络下载到应用所在目录后启动。即便是成功提高了在系统中的优先权，被木马更改后的mount功能也会阻止写入系统区域，也就是说无法对系统区域进行更改。

这样，木马的自我保护由两部分组成：其安装器删除可以管理root权限的应用，而更改后的libc.so会让用户无法再次安装这类应用。这种保护还针对木马的“竞争对手”，也就是其他可获得root权限并可安装到系统区域的木马，因为其安装机制与获得root权限的“好”应用并没有区别。

如何抵御这种木马？

可以通过重新安装操作系统来摆脱掉Android.Xiny.5260，前提是可以得到相应的设备操作系统固件。是否有可能用其他方式来删除这种木马呢？比较困难，但可能性是有的，有几种方式可以选择。一种是以so库形式的反漏洞攻击来获取root权限，与执行文件不同，库的加载不受木马控制。还可以利用木马本身为其他组件提供root权限的组件。这一组件通过路径为/dev/socket/hs_linux_work201908091350的套接字获取指令 （不同木马样本这一路径会有所区别）。至于如何绕过mount的阻止，可以使用mountflags参数的“口令”, 或者直接调用相应的syscall。

当然，我不会将此付诸实施。

如果您的设备已遭受感染，建议使用官方操作系统镜像替换现有的操作系统。需要注意的是，更换操作系统时所有用户文件和应用都会被删除，因此要事先进行备份。

#Android.Xiny #trojan #antivirus #antivirus