【技术分享】利用Falco检测MITRE ATT&CK框架中的提权攻击

MITRE ATT&CK框架中的提权攻击涵盖了攻击者可以用来提升自己在系统中的权限的多种技术。熟悉这些技术将有助于防御方更好地保护自己的基础设施。

       众所周知，MITRE ATT&CK框架是一个非常全面的安全知识库，可用于分析高级威胁参与者在攻击过程中可能用到的所有战术、技术和流程（TTP）。然而，MITRE ATT&CK并不是一个合规性的标准，而是作为一个威胁模型和方法论基础的框架推出的。概括来说，这些攻击技术被分为14大类。

        在本文中，我们将为读者介绍一些可以归类为MITRE提权的技术。同时，我们还将以Falco这样的开源工具为例，详细介绍如何检测这类容器安全攻击。

       利用某些安全漏洞，权限提升攻击不仅可以让攻击者获得更多的权限，甚至能够获得更高的系统级访问权限。

        这些类型的漏洞对攻击者来说是非常有价值的，因为它们是完整的攻击链中不可或缺的一部分，不过，由于这类漏洞在严重性方面的评分较低，因此，很多时候容易被防御者或开发者所忽视。

       人们通常认为，安全缺陷往往存在于缺乏足够的安全技术和机制的地方。然而，实现提权的主要途径之一，就是利用主机内部应用程序的错误配置。

        一种非常常见的情况是，在对主机进行设置的时候，或者在安装新软件的时候，相关人员往往会开放相关的权限。但是，在安装完成后，人们很容易忘记关闭相关的权限。

        又比如，在发生事故时，为了尽快解决问题，可能会授予某些高级别的权限，但事后却常常忘记收回这些权限。

        因此，我们的结论是，安全工具不应该只限于检测异常行为。我们可以通过检查错误的配置，从源头上防止这类攻击的发生。例如，使用支持检测多种安全情况的多功能安全工具，如Falco，或者严格遵守映像扫描（image scanning）的最佳实践。

        权限提升类别包含攻击者可用来获得更多、更高权限的12种提权技术，它是完整的漏洞利用链中的一个组成部分。

        这些技术包括：滥用权限提升的控制机制，在启动或登录时自动启动执行，创建或修改系统进程，或劫持执行流程，等等。

        有时候，攻击者能够绕过权限提升的控制机制，以获得更高级别的权限。

        在本节中，我们将介绍其中的三种技术：

        我们在最近发表的“Detecting MITRE ATT&CK: Defense evasion”一文中，已经对SUID和GUID位进行了相应的介绍。

        在Linux系统中，如果启用了SUID和SGID位，那么，非root用户就可以利用某些二进制文件和命令来获取root访问权限。下面是一些常用于提升用户权限的Linux/Unix命令：bash、cat、cp、echo、find、less、more、nano与vim，等等。

        同样的行为也存在于文件或目录中。通过改变文件或目录中的SUID和SGID位，其他用户就能够以文件属主（如root用户）的相同访问权限来运行这些文件，使得普通用户也可以编辑隶属于系统管理员的密码文件。

        一旦攻击者获得了对主机的本地访问权限，他们往往会首先检查文件中的权限配置错误，并利用这些权限来修改相应的文件，从而获取更高的权限。对于攻击者来说，可以通过以下命令找到所有设置了SUID位的文件和二进制文件：

find / -perm -u=s -type f 2>/dev/null

在Linux系统中，我们可以使用同一个userID来创建多个用户，因为Unix系统和Linux通常不会反对在/etc/passwd文件中使用重复的userID。实际上，这个文件的用途，只是将符号用户名映射到真实的用户ID，并指定用户登录时将获得什么样的shell。

        有权在系统上创建新用户的用户，通常也有权通过重新使用root用户ID来创建一个早已存在的root用户。如果他们以这个克隆用户的身份登录，他们将获得root用户相应的权限。

        如果这样的用户被黑客入侵，攻击者就可以利用这个途径来获取系统级别的权限。

        为了考察无特权用户可以在系统中执行哪些操作，攻击者可以使用sudo -l命令来检查该用户所拥有的权限。如下图所示，该用户对二进制文件adduser具有某些特权。

在Linux系统中，所谓的“全局可写”文件，就是允许所有人对其执行写操作的文件。

        当向可能需要对系统进行某些修改的非特权用户授予对文件或文件夹的特殊权限时，就可以使用这种配置。

        在任何人都可以写的情况下，把这个权限授予某个文件的确是一个非常危险的举动，尤其是对于那些隶属于root用户的文件。如果全局可写的文件是可以由root用户手动执行的脚本，或者是通过crontab作业自动执行的脚本，那就更危险了。

        一旦攻击者获得了对主机的本地访问权限，他们就可以检查文件中的权限配置错误，以利用它们来修改文件并提升自己的权限。

        对于攻击者来说，可以通过find命令来查找系统中所有可写的文件和文件夹。

find / ! -path "/proc/*" -perm -2 -type f 2>/dev/null

下面的Falco规则可以用来检测SUID和GUID位的变化。我们在近期发表的文章中已经介绍过这个问题，所以这里就不再赘述了，若有疑问，请参阅之前的那篇文章。

- rule: Set Setuid or Setgid bit

  desc: >

    When the setuid or setgid bits are set for an application,

    this means that the application will run with the privileges of the owning user or group respectively.

    Detect setuid or setgid bits set via chmod

  condition: >

    consider_all_chmods and chmod and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID")

    and not proc.name in (user_known_chmod_applications)

    and not exe_running_docker_save

    and not user_known_set_setuid_or_setgid_bit_conditions

  output: >

    Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode user=%user.name user_loginuid=%user.loginuid process=%proc.name

    command=%proc.cmdline container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)

  priority:

    NOTICE

  tags: [process, mitre_persistence]

        前面介绍这种攻击时，我们演示过攻击者是如何利用adduser来创建一个与root用户ID相同的新用户的例子。

        下面的Falco规则可以用来检测执行adduser或useradd命令时使用的特定标志，如-o或-u 0。具体的规则如下所示：

- rule: Creating a root like user

  desc: using the command useradd or adduser with the flag -o -u0 it is possible to create a user with the same root userID and get user access to the machine with the new user

  condition: spawned_process and proc.exe in (useradd,adduser) and proc.args contains -o and proc.args contains -u and proc.args contains 0 

  output: "Created user with the same root userID. (user=%user.name userID=%user.uid %container.info parent=%proc.pname cmdline=%proc.cmdline)"

  priority: WARNING

  tags: [users,host]

正如我们之前所看到的，全局可写文件可以用来实现本地提权。

        以下Falco规则可用于检测特权用户修改文件或文件夹的权限，从而向所有人授予可写访问权限的事件：

- rule: Set world-writable Access

  desc: >

    When writable access to anyone is set for file and folder,

    This means that anyone in the system can edit those, even if owned by root. This might cause privilege escalation in case the files are run by root via crontab or manually.

    Detect writable access to anyone set via chmod

  condition: >

    consider_all_chmods and chmod and (evt.arg.mode contains "S_IWOTH")

    and not proc.name in (user_known_chmod_applications)

    and not exe_running_docker_save

  output: >

    Writable access to anyone is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode user=%user.name user_loginuid=%user.loginuid process=%proc.name

    command=%proc.cmdline container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)

  priority: NOTICE

  tags: [process, host]