利用 Bifrost 渗透域环境中的 Mac 主机

利用 Bifrost 渗透域环境中的 Mac 主机
2019-11-29 10:18:38 Author: www.4hou.com(查看原文) 阅读量:237 收藏

Kirbi 使用 Bifrost 步行到活动目录的世界

针对 macOS 的红队

苹果公司每次发布新版本的 Macintosh 操作系统时，都会向前迈进一大步。每一次更改都会使一整套攻击性工具失效，或者是增加了多个额外的障碍。正因为如此，由于 Python 和 shell 的稳定性，红队成员和渗透测试人员历史性地倾向于使用 Python 和 shell 命令。然而，随着苹果公司的新方向的发展，不能保证外部语言如 Python、 Ruby 或 Perl 默认存在于 macOS 端点上。

这将新功能的开发推向操作系统或苹果专用的编程语言。毕竟，如果 Python 不在讨论范围内，那么像 Empire、 Impacket 或 Responder 这样的通用工具也不不可能在讨论范围内。甚至苹果自己的一些脚本语言版本，如自动化Javascript (JXA) ，也维护得很差，功能也不完整。

作为红队，假设你能够在 macOS 端点上执行命令，两个最大的痛点就是证书访问和横向移动。但是有一件事人们经常忘记，那就是证书有很多种形式。 MacOS 端点上有比用户密码哈希或明文密码更多的凭据。具体来说，就是 Kerberos 的票证。这在活动目录(AD)连接的计算机上更有用，但是这到底有多常见呢？

在 Twitter 上进行的关于加入到了域环境的 macOS 的调查

从快速的民意调查结果来看，至少有30%的人在至少25%的时间里遇到过加入了域环境的 Mac 主机。为了帮助处理 macOS 端点上的 Kerberos 票证，我发布了一个新的名为 Bifrost 的开源工具。 Bifrost是一个 Objective C 库，它使用较低级别的 Kerberos API 和手动 Kerberos 网络流量，允许收集、操作、过滤和发现 macOS 上的 Kerberos 相关信息。

这篇文章的其余部分主要关注 macOS 特定的背景知识、 Kerberos 的滥用以及防御方面的考虑。

活动目录不仅仅是 Windows

当谈到活动目录(AD)时，大多数人最初想到的是微软、 Windows，有时候还有 Kerberos。正因为如此，有大量的研究和工具致力于这些攻击面的滥用和防御。像 Bloodhound 这样的工具试图用图论来说明 AD 攻击路径，而像 Rubeus 和 Kekeo 这样的工具则旨在强调 Kerberos 在 Windows 上的特定弊端。这篇文章将从 macOS 的角度来看一些相同的滥用技术，如超越哈希传递攻击，kerberoasting和票证传递攻击。

然而，随着企业的成长，除了 Windows 之外，还有更多的系统需要管理、保护和维护。解决这个问题有两种主要的方法: 要么将这些新系统加入到当前的活动目录环境中，要么找到其他一些集中管理它们的方法。虽然不一定是每天都会发生的情况，但 macOS 端点加入到 Windows 活动目录环境的情况正变得越来越常见。大多数 macOS 上的终端安全或服务提供商仍然在寻找 python 实例、恶意命令行二进制文件或直接的 keychain 访问，这使得对 Kerberos 的 API 访问从攻击性的角度来看非常有吸引力。

Kerberos

由于活动目录可以归结为用于组织用户、组、策略和容器的管理工具，因此需要有处理身份验证和授权的辅助组件。当涉及到网络级别的身份验证时，Kerberos 就是行业标准安全协议; 然而，Kerberos 不是微软创造的。

Kerberos 是由 MIT 创建的，用于解决这些网络安全问题。 Kerberos 协议使用强加密技术，以便客户端能够通过不安全的网络连接向服务器证明自己的身份(反之亦然)。

因为 Kerberos 是开源的，并且由 MIT 免费提供，所以现在有一些主要的变体在使用。

· 最真实的形式是各种 *nix 应用程序使用的由 MIT 实际实现的 Kerberos。

· 最常见的实现是微软改编过的协议，它与 Windows 中的活动目录一起使用——这个版本不是开源的

· Heimdal 是Kerberos 版本 5 标准的另一种免费的开源实现。这是 macOS 端点中包含的实现。

一般来说，基于 Kerberos 版本5规范构建的所有框架都具有一定程度的互操作性，但是实现和攻击面差异很大。本博客的其余部分将集中讨论 macOS 上的 Heimdal 实现。

对于那些不熟悉 Kerberos 的人来说，下面的图片是一个很好的高层次概述：

Kerberos 简而言之的概述

该过程接受用户的密码，并对其进行哈希，然后使用该密码获取所谓的票证授予票证(Ticket Granting Ticket，TGT)——步骤1和2。此时，不再需要用户的明文密码。这个 TGT 是用户的身份。当尝试访问网络资源(文件共享、 ssh 等)时，用户会使用这个 TGT 获得服务票证——步骤3和4。这是一个特定于用户和他们想要访问的服务的票证。最后一步是向实际的服务提供这个服务票证，以查看用户是否有权访问它，如果有权访问，则提供访问(比如远程挂载共享)——步骤5和6。

这里的关键是，用户的 TGT 或服务票证也是远程认证该用户的有效方法，而不是需要用户的纯文本密码或需要用户的哈希来传递哈希。

活动目录配置

从攻击者的角度来看，首先要发现的是加入了活动目录的 macOS 端点的配置。大多数情况下，/etc/krb5.conf 中有一个全局可读的文件。其中包含与活动目录环境交互的配置。但这并不是一个严格的要求。一台 macOS 计算机可以在没有这个文件的情况下加入到活动目录中，这种情况非常常见。此文件包含以下信息:

· 支持票证授予票证(TGTs)和服务票证(如 AES256、 AES128、 RC4-HMAC 和3DES)的加密类型

· 允许可转发、可代理和可更新的票证标志

· 票证生命期限

· 缺省域和密钥分发中心(KDC)的位置和端口

· 缺省票证存储选项

用户还可以通过进入系统参数设置–用户和组–登录选项–网络帐户服务器来查看他们已加入的域的 NETBIOS 短名称。

macOS 上的票证存储

下一步是确定 Kerberos 票证存储在哪里。根据所需的操作系统和安全级别，存储 Kerberos 凭证有许多不同的方法，但是默认情况下，macOS 使用带有 KCM (一种基于进程的凭证缓存)的凭证缓存 (ccache)条目。

Heimdal 实现了一个名为“ KCM”的凭据缓存类型，其中的操作被传输到一个管理实际缓存内容的守护进程。在 OS X 10.7或更高版本中，本地默认凭据缓存类型通过 Mach RPC 使用 KCM 协议。它通常通过“ API”缓存类型引用，以便与 Macintosh 的 Kerberos 保持连续性; API 和 KCM 缓存类型在本机 OS X Kerberos 中具有相同的名称空间。

查看凭据缓存有限子集的一种方法是打开 Keychain Access，单击顶部的 Keychain Access 并选择 Ticket Viewer。这是唯一一个用于查看当前用户票证信息的 GUI 版本。然而，这种方法看到的内容是极其有限的。如果使用 Ticket Viewer 来获取和存储 Kerberos 凭证，那么该信息将存储在 Keychain 中，并且可以通过提供登录密钥链密码来显示。下图中显示的 UUID 对应于与票据相关联的凭证缓存名称:

Kerberos 将凭证存储在密钥链中

用户通常使用以下内置的二进制文件与票据存储器和 macOS 凭证缓存进行交互，这些文件不会保存任何东西到票据查看器中:

· Kinit ——通过输入明文密码获得用户的初始票证授予票证(TGT)

· Klist —— 列出特定 ccache 中条目的一些元数据，或列出内存中所有可见的 ccache

· Ktutil ——处理 keytab 条目(稍后将详细介绍)

· kcc ——kerberos 凭证缓存操作

从攻击的角度来看，依赖命令行上的内置命令是一种容易被检测到的方法。默认情况下，macOS 中包含的 Kerberos 框架公开了一些较低级别的 API，用于与键标签（keytab）和缓存进行交互。要获得与 klist 类似的功能，只需在 Bifrost 中运行 list 操作：

Bifrost 列出了所有的凭据缓存条目

这将循环遍历所有可在内存中发现的凭证缓存，并显示有关缓存和内部所有票据的信息(注意: 这不需要提升的权限)。上面的示例显示 LAB\lab_admin 的默认缓存(用*表示)具有一种类型的 API，这意味着凭据实际上是位于 KCM 守护进程中的 KCM 凭据。该缓存有两个条目: 用户的 TGT 和另外一个条目，该条目描述了 KCM 如何访问这些数据的信息(krb5 vs gssapi)。不过，第一个条目实际上包含用户的 TGT，因此可以使用 -action dump -source tickets 命令转储它：

使用 Bifrost 导出凭证

关于上面的这张导出票证的截图中，我们有几件事需要注意。 Bifrost将首先描述它将要丢弃的票证。这包括主体、所使用的加密类型、过期时间、票据上的标志以及与票据相关的加密密钥等信息。接下来要注意的是一个标记为 Kirbi 的巨大 base64编码字符串。为方便 Bifrost 的操作，所有转储和导入的票证均采用 Kirbi 格式。这与 Mimikatz、 Kekeo 和 Rubeus 等工具使用的格式相同。这使得从 Bifrost 丢弃的票证可以立即导入到 windows 机器中，反之亦然。

票证传递

在 macOS 上导入票据类似于在 Windows 上导入票据。要考虑的关键问题是，每个凭据缓存都类似于窗口中的不同登录会话。单个凭据缓存中的所有凭据都应该具有相同的客户端主体名称。这将防止在相同的凭据缓存中为 Alice 提供 TGT，为 Bob 提供 TGT，但是它们可以各自拥有自己的凭据缓存，而不会发生冲突。假设你有一张来自另一台 macOS 机器或 Windows 机器的 base64编码的 Kirbi 票据，并且希望将其导入。下面的屏幕截图显示了将一个 CIFS 服务票证导入到当前用户的默认凭证缓存中(注意: 这个操作不需要提升权限) ，并将其导入到域控制器服务中。

导入 Kirbi 文件和凭证缓存

如果你不确定 Kirbi 票证的内容，想看看它实际上包含什么，可以通过 -action describe 参数查看：

Kirbi 票证的描述

超越哈希传递

Windows 中一个非常常见的场景是获取用户的哈希，但是需要将其扩展到 Kerberos 领域以获取完整的 TGT。类似于 Will (@harmj0y)的 Rubeus 项目和 post，Bifrost 可以手动构建 ASN1所需的 Kerberos 流量来获取用户哈希并恢复 TGT (注意: 这个操作不需要高权限)。如果在 Windows 计算机上收集 NTLM 哈希，则应选择 rc4加密类型。

此外，由于 Kerberos 流量是手动构造的，因此还有更多可用的选项。如果你有用户密码的 AES256 哈希值，但想要更容易破解(如 RC4) ，那么使用 -tgtEnctype rc4 标志指定它。

Kerberoasting

现在你可以获得有效的 TGT 并导入它们，下一步是使用这些 TGT 来访问服务。威尔在他的博客中非常详尽地报道了 Kerberoasting 攻击，所以这里不会进行深入的探讨，但是这也是可以通过 Bifrost 实现的。基本原则是，任何有效的 TGT 都可以用于请求到任何服务的票据。产生的票证有一部分是用相关服务的密码哈希加密的。因此，如果服务票证被迫使用较弱的加密算法，那么破解服务帐户密码就更容易了。

由于获得正常服务票证和 kerberoasting 之间的唯一区别是专门为最终票据请求较弱的加密类型，因此 Bifrost 的 asktgs 命令只需要一个额外的标志-kerberoast true 来请求服务票证是 RC4加密即可，而不是请求标准的 AES256。

使用 Bifrost 执行 Kerberoasting 攻击

只需逗号分隔 SPN，就可以同时指定多个服务。在 macOS 上，计算机账户上有四个默认的 SPN:

· afpserver/spooky.lab.local

· cifs/spooky.lab.local

· host/spooky.lab.local

· vnc/spooky.lab.local

计算机中带有$符的帐户

在 macOS 中充当域的本地计算机帐户与在 Windows 中有点不同。在 Windows 中，你可以注入 SYSTEM 进程并自动远程作为计算机 $account ——这就是为什么即使 SYSTEM 不是域帐户，你仍然可以查询活动目录。如果你能够解锁系统钥匙链(通常只需要本地管理员凭证) ，那么你可以读取计算机带有$符的账户的明文密码：

/Active Directory/LAB 的计算机上带有$符的帐户的密码

Bifrost可以使用这个密码和 -action askhash 命令来生成获取 TGT 和这台计算机的服务票证所需的密码哈希。这个密码和其他用户密码的字符可能会破坏或者导致出现命令行解析问题，所以如果是这种情况，只需使用 -bpassword 参数，并传入 base64版本的密码即可，如下图所示：

将明文密码转换为 kerberos 可用的哈希

在 macOS 上利用 Kerberos 票证

在你完成了一些 Kerberos 票据操作之后，如何在实际的环境中利用这些技术来访问环境中的资源？

要使用 kerberos 票据访问远程计算机的 SMB 共享，只需使用 mount 命令：

mount -t smbfs "//computer/share" /local/path

这个时候重要的是要记住，如果挂载了一个共享，本地 root 用户可以访问并遍历它。该计算机中的任何其他用户也可以运行 mount 命令查看所有当前挂载的共享(类似于 windows 上的net use 命令)。

Alice 用户看到了 lab_admin 用户挂在了一个共享

使用 mount 命令可能会遇到完全限定域名的问题，如果是这种情况，只需要计算机的名称就可以了。下面的视频显示了一个普通用户——Alice，使用域管理密码的哈希，然后挂载并遍历域控的 C$ 共享：

使用 over-pass-the-hash 访问一个 C$ 共享的演示视频

如果你将票据导入默认值以外的凭据缓存(用*表示) ，或者希望在磁盘上使用凭据缓存，则可以指定 KRB5CCNAME= 作为环境参数，并指定要使用的缓存。如果你正在使用内存中的文件，请确保使用完整的名称，包括主要的API:;如果在磁盘上使用文件，请确保将FILE:添加到路径中。

还可以将 SSH 配置为使用 Kerberos 票证，但这需要为 SSH 客户端和 SSH 服务器准备更多的配置参数。

键标签和保存的哈希

Keytab 文件类似于 SSH 密钥。它们存储用于对服务的用户进行身份验证的加密信息。更具体地说，keytab 文件包含用于 Kerberos 身份验证的加密密钥，并绑定到特定的服务主体名称（SPN）。主要的一点原因是因为它们可以提供一种跨多种应用程序的单点登录机制，并可用于所有主要的操作系统。虽然它们是以纯文本形式存储的，但它们并不完全包含密码的明文。

每个 macOS 设备上都有一个默认的 keytab 文件，无论它是否加入了位于 /etc/krb5.keytab 中的域(稍后将详细介绍)。但是用户可以在任何时候创建他们自己的 keytab。处理 keytab 的主要二进制文件是 ktutil。这个默认的 keytab 被锁定到 root 用户和 macOS 上具有640个权限的 keytabusers 组。当用户创建他们自己的 keytab 时，他们可以在上面设置不同的权限。

创建并转储一个新的 keytab

这里有一些重要的事情需要注意。因为这是一个 *nix 环境，所以大小写的敏感性很重要。一定要把域设置为大写所有字母，否则哈希将不起作用。此外，每个条目只有一个密钥和一种加密类型，但可能有重复条目。如果你从上面注意到，这里保存的哈希与使用明文密码时生成的 AES256 哈希相同。 Bifrost 还支持在从域请求 TGT 时指定 keytab 文件和加密类型。

关于 LKDC 的一个注意事项

自10.5 开始的每个 macOS 设备都包括自己的整个本地 kerberos 堆栈——包括唯一的域、 krbtgt 用户和密钥分发中心。添加本地密钥分发中心(LKDC)是为了支持两个 Apple 设备端点之间基于 kerberos 的身份验证，而不需要将它们连接到中央域和 KDC。当访问远程 macOS 端点上的共享服务(例如浏览文件系统)时，这就开始起作用了。

这个过程与基于 windows 的 Kerberos 有点不同，当你在挂载了一个共享文件夹后使用 Bifrost 转储票证时，这个过程非常明显：

LKDC 挂载共享文件夹

这篇博文不会详细介绍 LKDC 的所有细节以及它是如何工作的或者是它与其他活动目录的不同之处，但是从这些数据中可以“轻松地获得”一些信息。顶部突出显示的区域包含远程计算机的明文密码、用户名和主机名。当用Bifrost转储票据时，你会得到一个用于挂载共享的base64版本的明文密码。底部突出显示的部分显示了共享的挂载位置。

请记住，这是一个完全不同的Kerberos领域，其生成密钥的方法与本博客的其余部分不同，也与微软的实现不同。这里的钥匙可以在 /etc/krb5.keytab 文件中本地用户的 Open Directory 属性中的 dsAttrTypeNative: HeimdalSRPKey 和 dsAttrTypeNative: kerberos 属性中找到。你可以使用 dscl 实用程序或 Orchard 项目来读取这些文件，但必须提升你的权限才能访问其中的任何文件。这里存储的值是ASN1符号，所以如果你想要探索这些值，那么你应该使用ASN1解码器来解析这些片段。

防御方面的考虑

macOS 上没有太多原生的机会来深入研究这些 API，但 Heimdal Kerberos 确实提供了一种方法，至少可以在这些 API 调用上启用调试级日志记录:

sudo defaults write /Library/Preferences/com.apple.Kerberos logging -dict-add krb5 '0-/SYSLOG:'
sudo defaults write /Library/Preferences/com.apple.Kerberos logging -dict-add kcm '0-/SYSLOG:'
sudo defaults write com.apple.MITKerberosShim EnableDebugging -bool true
sudo defaults write /Library/Preferences/com.apple.Kerberos logging -dict-add kcm '1-/ASL:'

默认情况下，/Library/Preferences/com.apple.Kerberos.plist 文件并不存在，这个文件在创建时是一个全局可读的文件。攻击者可以通过读取这个文件来确定潜在的日志记录功能，并在权限提升后禁用日志记录。

此外，有了新的终端安全和服务框架(ESF) ，就有可能检测针对 Kerberos 的攻击行为。框架被实时加载到进程中。这将在很大程度上取决于特定的环境以及哪些进程通常利用这个框架。由于 Kerberos 确实为环境中的单点登录(Single-Sign-On，SSO)提供了一种很好的方式，因此可能会有一大堆第三方应用程序使用这些 API。