Seal Writeup

概述 （Overview）

HOST: 10.10.10.250

OS: LINUX

发布时间: 2021-07-11

完成时间: 2021-11-13

机器作者: MrR3boot

困难程度: MEDIUM

机器状态: 退休

MACHINE TAGS: #Tomcat #DirectoryTraversal

攻击链 （Kiillchain）

1. 对目标服务器的开放端口进行扫描，发现存在可以进行任意注册的 GitBucket 服务。
2. 注册并登录 GitBucket，下载公开的项目并进行内容审计，发现 Web 服务反向代理之间存在路径穿越漏洞。
3. 利用在 git log 中找到的 Tomcat 管理账户，利用路径穿越漏洞上传反弹 shell 服务，获得立足点。
4. 对指定的用户组进行全盘搜索，发现可疑的 yaml 配置，并利用定时任务触发的文件备份脚本读取 luis 用户的 ssh 私钥。
5. 最后利用不安全的 sudo 配置滥用完成权限提升。

枚举（Enumeration）

老样子，使用 Nmap 对目标服务器开放端口进行识别：

PORT     STATE SERVICE    VERSION
22/tcp   open  ssh        OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 4b:89:47:39:67:3d:07:31:5e:3f:4c:27:41:1f:f9:67 (RSA)
|   256 04:a7:4f:39:95:65:c5:b0:8d:d5:49:2e:d8:44:00:36 (ECDSA)
|_  256 b4:5e:83:93:c5:42:49:de:71:25:92:71:23:b1:85:54 (ED25519)
443/tcp  open  ssl/http   nginx 1.18.0 (Ubuntu)
| http-methods:
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-title: Seal Market
| ssl-cert: Subject: commonName=seal.htb/organizationName=Seal Pvt Ltd/stateOrProvinceName=London/countryName=UK
| Issuer: commonName=seal.htb/organizationName=Seal Pvt Ltd/stateOrProvinceName=London/countryName=UK
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2021-05-05T10:24:03
| Not valid after:  2022-05-05T10:24:03
| MD5:   9c4f 991a bb97 192c df5a c513 057d 4d21
|_SHA-1: 0de4 6873 0ab7 3f90 c317 0f7b 872f 155b 305e 54ef
|_ssl-date: TLS randomness does not represent time
| tls-nextprotoneg:
|_  http/1.1
| tls-alpn:
|_  http/1.1
|_http-server-header: nginx/1.18.0 (Ubuntu)
8080/tcp open  http-proxy
| fingerprint-strings:
|   FourOhFourRequest:
|     HTTP/1.1 401 Unauthorized
|     Date: Sat, 13 Nov 2021 05:29:16 GMT
|     Set-Cookie: JSESSIONID=node0s1z5ay3tz8p0b0p7hl82alsq41.node0; Path=/; HttpOnly
|     Expires: Thu, 01 Jan 1970 00:00:00 GMT
|     Content-Type: text/html;charset=utf-8
|     Content-Length: 0
..snip...

通过查看扫描结果获知目标服务器暴漏三个端口，其中 443、8080 分别运行着 Nginx 服务，从 SSL 证书中可以得到一个 seal.htb 访问域名。而目标服务器大概率是 Ubuntu。

Port 8080 - GitBucket

通过浏览器预览目标服务器 8080 端口，发现运行有 GitBucket 服务。经过简单的测试后发现 /register 页面可以操作的，随后直接注册了一个账户登录至控制面板。

在面板中可以见两个项目，分别是 infra、seal_market，在项目的讨论信息中能找到一个存在用户 luis。其中 seal_market 项目保存有对 seal.htb 站点的部署配置：

$ tree -L 1
.
├── app
├── nginx
├── README.md
└── tomcat

使用 git 将项目拉至本地后进行预览，在 nginx 配置文件中存在一段反向配置， 当路径为 /admin/dashboard 时，会请求服务器本地监听端口 8000。前置存在一个 if 判断，当 ssl_client_verify 校验成功后才能访问。

立足点（Foothold）

从目录名称能够看出这是访问后台控制面板，相似的配置还有 /host-manager/html、/manager/html，而它常出现在 Tomcat 服务中，作用是对 Tomca 运行的服务进行管理。那么我们能否进行访问呢？

这块当时也找了好久，最终在 hacktricks 里找到蛛丝马迹。

https://www.acunetix.com/vulnerabilities/web/tomcat-path-traversal-via-reverse-proxy-mapping/

而关于这里路径穿越的具体详情信息，可以查看 Orange 大佬分享 议题PDF

当从 Nginx 中反代传递含有 /..;/ 路径给到 Tomcat，Tomcat 会将 /..;/ 清洗掉做为路由的根路径，从而导致目录穿越。

接下来需要找 Tomcat 的授权账户，在 git log 记录中能够找到一组 Tomcat 管理面板的授权账户：

继续构造请求，将授权账户加入 Header 中进行目录穿越，成功得到 Tomcat 管理信息：

接下来就比较常规了，使用 MSF 生成反向 shell 的 .war 部署包，将它上传并访问对应路径即可得到反连 shell，拿到立足点。

横向移动（Lateral Movement）

对 luis 组用户所能操作的文件及文件夹进行搜索，发现 /opt/backups 文件夹：

其中比较有意思的是 /opt/backups/playbook/run.yml 文件内容：

- hosts: localhost
  tasks:
  - name: Copy Files
    synchronize: src=/var/lib/tomcat9/webapps/ROOT/admin/dashboard dest=/opt/backups/files copy_links=yes
  - name: Server Backups
    archive:
      path: /opt/backups/files/
      dest: "/opt/backups/archives/backup-{{ansible_date_time.date}}-{{ansible_date_time.time}}.gz"
  - name: Clean
    file:
      state: absent
      path: /opt/backups/

通过名称和搜索google能够了解到，这是个文件同步模块，主要用到的是 synchronize 服务。synchronize 模块是对 rsync 的封装，实现数据同步。

• https://www.cnblogs.com/michael-xiang/p/10461518.html
• https://ansible-tran.readthedocs.io/en/latest/docs/intro.html
• https://hoxis.github.io/ansible-synchronise.html

可以看到有个很特殊的参数 copy_links=yes ，而它的解释是：复制符号链接时，它们所指向的项目（参照物）被复制，而不是符号链接。不难看懂，这里可以利用 linux 中的 ln 命令特性，将软链中的实践内容进行同步从而实现文件读取。

而在 Tomcat Web 目录中，我们可以对 uploads 文件夹进行读写操作，直接将 luis 用户的 .ssh 文件进行软链就能在同步后的压缩包中获得ssh密钥。

对自动同步的压缩包进行解压，成功得到SSH登录密钥：

使用该 SSH 密钥，成功已 luis 用户登录目标服务器，完善横移操作。

权限提升（Privilege Escalation）

提取就比较简单了，在执行 sudo -l 能够看的存在权限滥用，用户可以已 root 身份运行 ansible-playbook 服务。直接在 GTFOBins 找利用方式执行本地提权命令即可。

https://gtfobins.github.io/gtfobins/ansible-playbook/#sudo

这题里最大的 “功臣” 因该是定时任务了，它串联了关键的账户横移。

修复建议

以下内容来源于 ChatGPT 对攻击链中出现的安全问题，回复的详情列表，来感受下AI的强大吧～

为了更详细地防御和修复这个杀伤攻击链，我们可以采取如下措施：

1. 对目标服务器进行定期安全扫描，发现并修复漏洞。 这可以通过使用一种专业的安全扫描工具来实现，例如 Nexpose、Qualys 或 Tenable，这些工具可以检测多种漏洞，包括本地漏洞、配置问题和操作系统漏洞。对于每一个发现的漏洞，都应该采取适当的修复措施，例如安装补丁、修改配置或升级软件。
2. 对目标服务器上运行的 Web 服务及其反向代理进行审计，发现并修复路径穿越漏洞。 路径穿越漏洞是一种常见的 Web 应用漏洞，它允许攻击者在反向代理之间穿越，访问服务器上不应该被公开的文件和目录。要防范这种漏洞，首先要进行审计，找到可能存在路径穿越漏洞的 Web 应用和反向代理，然后采取相应的修复措施，例如重写 URL、限制访问权限或修改 Web 应用源代码。
3. 对目标服务器上的文件备份脚本进行审计，确保其不会被滥用。 在这个杀伤攻击链中，攻击者利用文件备份脚本读取了 ssh 私钥，从而获得了更高的权限。为了防止这种情况的发生，应该审计文件备份脚本的代码，确保其不存在安全漏洞，例如命令注入漏洞或权限提升漏洞。同时，应该为文件备份脚本设置较为严格的权限，只允许访问必要的文件和目录，并且在运行时只允许使用较低的权限。
4. 对目标服务器上的 sudo 配置进行审计，确保其不存在不安全的配置。 在这个杀伤攻击链中，攻击者利用不安全的 sudo 配置来完成权限提升。为了防止这种情况的发生，应该审计 sudo 配置文件，确保其不存在不安全的规则，例如允许所有用户执行任意命令或允许用户在不需要密码的情况下执行命令。同时，应该为 sudo 配置文件设置较为严格的权限，只允许系统管理员修改配置。
5. 为目标服务器上的关键文件和目录设置较为严格的权限，以防止未经授权的读写访问。 在这个杀伤攻击链中，攻击者在获得更高的权限之后，可能会尝试访问关键文件和目录，甚至篡改或删除文件，导致系统崩溃或数据丢失。为了防止这种情况的发生，应该为关键文件和目录设置较为严格的权限，只允许特定用户组或特定用户进行读写访问。同时，应该在文件系统层面实现文件完整性检查，以便及时发现文件被篡改的情况。
6. 为目标服务器上的用户账户设置安全的密码，并定期更换密码，以防止密码被猜测。 密码是保护用户账户的重要手段，如果密码不够安全，就有可能被攻击者猜测出来。为了防止这种情况的发生，应该为用户账户设置安全的密码，并且定期更换密码，以防止密码被攻击者暴力破解或字典攻击。同时，应该采用复杂的密码策略，例如密码长度不少于 8 位，包含大小写字母、数字和特殊字符，不能与用户名相同或类似。
7. 启用目标服务器上的安全日志功能，定期审计日志，以及时发现潜在的攻击行为。 安全日志是系统安全运行的重要依据，它能够记录系统中的各种操作，包括登录、退出、文件访问、网络连接等。通过审计安全日志，可以及时发现潜在的攻击行为，例如登录失败、文件被篡改、网络连接异常等。为了审计日志方便，应该启用日志收集工具，例如 rsyslog、syslog-ng 或 logstash，这些工具能够将日志实时地收集、分析、查询、存储，并且可以支持日志转发、归档、报警等功能。
8. 对目标服务器进行定期备份，并存储备份数据在安全的位置，以便在发生攻击时进行恢复。 （最后这个Bot抽筋了，没有回答完我的问题…）

参考

• https://www.acunetix.com/blog/articles/a-fresh-look-on-reverse-proxy-related-attacks/
• https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf