参考[ vulnhub靶机通关篇 ] 渗透测试综合靶场 DC-2 通关详解 (附靶机搭建教程)_vnlubun靶场-CSDN博客

Vulnhub-dc2 | ckcsec

DC-2靶场搭建及渗透实战详细过程（DC靶场系列）-CSDN博客

总结一波，提权可以尝试

sudo -l和find / -user root -perm -4000 -print 2>/dev/null

搭建靶场第一篇有，就不重复了。

还是先找存活ip

这里攻击机是192.168.176.132

靶机是192.168.176.129

要是找不到的话可以把靶机改成nat模式后再重启。

看端口和服务

nmap -A -p- -v 192.168.176.129

PORT     STATE SERVICE VERSION
80/tcp   open  http    Apache httpd 2.4.10 ((Debian))
|_http-server-header: Apache/2.4.10 (Debian)
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to http://dc-2/
7744/tcp open  ssh     OpenSSH 6.7p1 Debian 5+deb8u7 (protocol 2.0)
| ssh-hostkey: 
|   1024 52:51:7b:6e:70:a4:33:7a:d2:4b:e1:0b:5a:0f:9e:d7 (DSA)
|   2048 59:11:d8:af:38:51:8f:41:a7:44:b3:28:03:80:99:42 (RSA)
|   256 df:18:1d:74:26:ce:c1:4f:6f:2f:c1:26:54:31:51:91 (ECDSA)
|_  256 d9:38:5f:99:7c:0d:64:7e:1d:46:f6:e9:7c:c6:37:17 (ED25519)
 

一、扫描基本信息

• 扫描工具：Nmap 7.95
• 扫描时间：2025-10-26 17:40 CST
• 扫描目标：192.168.176.132（单 IP）
• 总耗时：22.80 秒
• 扫描类型：ARP Ping 扫描 + SYN Stealth 全端口扫描（65535 端口） + 服务探测 + OS 探测

二、目标主机状态

• 主机状态：在线（Host is up）
• 网络延迟：0.0010 秒（低延迟，推测为局域网内设备）
• MAC 地址：00:0C:29:84:98:40（设备厂商：VMware，确认是虚拟机）

三、开放端口与服务详情

共发现 2 个开放 TCP 端口，具体信息如下表：

端口号	状态	服务类型	服务版本	关键补充信息
80/tcp	open	http	Apache httpd 2.4.10 (Debian)	1. 支持 HTTP 方法：GET、HEAD、POST、OPTIONS2. 访问时会重定向到 http://dc-2/
7744/tcp	open	ssh	OpenSSH 6.7p1 Debian 5+deb8u7 (protocol 2.0)	1. 提供 4 种 SSH 主机密钥（DSA、RSA、ECDSA、ED25519）2. 无明显漏洞提示，符合 Debian 系统默认配置

四、操作系统探测结果

• 系统类型：Linux（通用用途，general purpose）
• 内核版本：Linux 3.X ~ 4.X（具体范围：3.2-4.14，大概率为 Debian 8 系统，匹配 Apache/SSH 版本）
• 系统 CPE：cpe:/o:linux:linux_kernel:3、cpe:/o:linux:linux_kernel:4
• 开机时长（猜测）：约 199.6 天（自 2025 年 4 月 10 日起）

五、网络信息

• 网络距离：1 跳（与扫描设备在同一网段）
• 路由追踪：仅 1 跳，直接到达目标主机（192.168.176.132）

ssh可以尝试爆破,然后先看80web服务吧。

访问http://192.168.176.132:80变成http://dc-2/了,

一、为什么访问不了 Web 服务？

1. 重定向机制：从之前的 Nmap 扫描可知，靶机 80 端口的 Apache 服务配置了 “自动重定向”—— 访问其 IP（如 192.168.233.178）时，会强制跳转到域名http://dc-2/。
2. 域名解析失败：本地设备默认没有dc-2这个域名的解析记录（即不知道dc-2对应哪个 IP），所以浏览器会提示 “无法访问” 或 “域名不存在”。
3. hosts文件的作用：hosts文件是本地设备的 “优先域名解析表”，会先于 DNS 服务器生效。手动添加IP+域名映射后，设备就能直接识别dc-2对应的靶机 IP，从而正常访问。

• Linux（如 Ubuntu）：sudo nano /etc/hosts

点击flag找到第一个flag

Flag 1 翻译

通常用的字典（wordlists）可能不好使，所以换个思路，或许你只需要用 cewl 就行。

密码越多总归越好，但有时候你未必能把所有密码都拿到。

登录其中一个用户就能看到下一个 Flag。要是没找到，就登录另一个用户试试。

提示要登录，但是没看到登录口，目录爆破一下

找到http://dc-2/wp-admin/ 

提示并发现有个标题为Flag，点击查看，成功发现第一个Flag，并提示我们用CeWL（CeWL是一款以爬虫模式在指定URL上收集单词的工具，可以将它收集到的单词纳入密码字典，以提高密码破解工具的成功率。）

根据前面的提示（要使用cewl工具），这里直接开始扫描并生成字典：pass.dic

cewl http://dc-2/ -w pass.dic

判断wordpress

WordPress 有多个 “自带且无法轻易删除” 的默认目录 / 文件，访问这些路径能快速判断是否为 WordPress 框架，操作简单且准确率高：

1. 1. 访问后台登录页（核心路径）在浏览器输入 http://dc-2/wp-admin（dc-2 是已通过 hosts 映射的靶机域名），如果出现类似 “Username”“Password”+“WordPress” 字样的登录页（通常顶部会有 WordPress 标识），直接确认是 WordPress。
      • 原理：/wp-admin 是 WordPress 后台管理的固定入口，所有 WordPress 站点默认都有这个路径，且页面样式有明显框架特征。
   2. 访问默认静态资源目录尝试访问 http://dc-2/wp-content/ 或 http://dc-2/wp-includes/：
      • 若出现 “目录列表”（显示里面的子文件夹，如 themes（主题）、plugins（插件）），或提示 “403 Forbidden”（禁止访问，但路径存在），说明框架是 WordPress；
      • 原理：这两个目录是 WordPress 存放主题、插件、核心代码的固定位置，不存在则大概率不是 WordPress。

WPScan 是一款专门针对 WordPress 框架的开源安全扫描工具，由开源社区维护，主要用于检测 WordPress 站点的安全漏洞、枚举敏感信息（如用户名、插件 / 主题版本），并支持密码爆破等渗透测试操作，是 Web 安全领域分析 WordPress 站点的核心工具之一。

 wpscan --url http://dc-2
找到

[+] WordPress version 4.7.10 identified (Insecure, released on 2018-04-03).
 | Found By: Rss Generator (Passive Detection)
 |  - http://dc-2/index.php/feed/, <generator>https://wordpress.org/?v=4.7.10</generator>
 |  - http://dc-2/index.php/comments/feed/, <generator>https://wordpress.org/?v=4.7.10</generator>

存在用户名枚举

用这个枚举

wpscan --url http://dc-2 --enumerate u

执行 wpscan --url http://dc-2 --enumerate u 命令的核心目的是枚举 DC-2 靶机 WordPress 站点的注册用户名，这是后续密码爆破的关键前提（有了用户名才能结合密码字典尝试登录）。以下是该命令的详细解读、预期结果及后续操作建议：

一、命令作用与原理

• --enumerate u 参数：u 是 users 的缩写，该参数指示 WPScan 通过 WordPress 的特征接口（如用户 ID 页面、作者存档页）探测站点的注册用户。

之前用cewl http://dc-2/ -w pass.dic根据网站生成密码字典了。

wpscan --url http://dc-2/ -U user.dic -P pass.dic

爆破账户密码

+] Performing password attack on Xmlrpc against 4 user/s
[SUCCESS] - jerry / adipiscing                                                                                                                                                                                    
[SUCCESS] - tom / parturient  

如果无法利用 WordPress 漏洞走捷径，那还有另一种方法。希望你已经找到了另一个入口点。

ssh登录

尝试用之前得到的用户名和密码登录ssh（7744），最终Tom登录成功

ssh tom@192.168.176.132 -p 7744

parturient  

这里登录后是rbash，没有cat命令可以用vi绕过直接读取内容

得到

Poor old Tom is always running after Jerry. Perhaps he should su for all the stress he causes.

发现是一个受限的rbash, rbash是受限的shell的一种此外还有rbash、rksh和rsh，为什么要对shell进行限制呢，有以下几个原因:

1. 提高安全性，防止黑客和渗透测试人员的入侵
2. 限制一些会对系统造成危害的危险命令
3. 为了提高渗透测试人员的个人能力，在一些靶机上设置受限的shell让测试人员绕过拿flag

直接rbash绕过获取到flag3.txt内容

运行

tom@DC-2:~$ BASH_CMDS[a]=/bin/sh;a # 赋值给a
$ export PATH=$PATH:/bin/ # 导入环境变量
$ export PATH=$PATH:/usr/bin
$ ls
flag3.txt  usr
$ cat flag3.txt
Poor old Tom is always running after Jerry. Perhaps he should su for all the stress he causes.

BASH_CMDS[a]=/bin/sh; a 是 rbash（受限 Bash）环境下的经典逃逸命令，核心作用是 “绕开 rbash 的限制，偷偷启动一个完整的/bin/sh shell”。这条命令的每一部分都有明确的设计，我们拆解来看：

一、先搞懂BASH_CMDS：Bash 的 “命令映射表”

BASH_CMDS 是 Bash 内置的一个关联数组（类似字典），作用是 “存储命令名与对应可执行文件路径的映射关系”。比如：

• 当你输入 ls 时，Bash 会查 BASH_CMDS["ls"]，找到它对应的路径（比如 /bin/ls），然后执行该文件；
• 系统默认会给常用命令（ls、cd、cat 等）预填映射关系，你也可以手动修改这个数组，自定义命令的映射。

二、命令拆解：每部分的作用

1. BASH_CMDS[a]=/bin/sh

• 给 BASH_CMDS 数组添加一个键值对：
  • 键（key）：a（自定义的命令名，用任何字母 / 符号都可以，比如 x、123 都行）；
  • 值（value）：/bin/sh（指向系统中的 Bourne shell，是一个功能完整的基础 shell，不受 rbash 限制）。
• 效果：相当于 “把 a 这个‘假命令’绑定到 bin/sh 这个‘真 shell’上”，后续输入 a 就等于输入 /bin/sh。

2. ;（分号）

在 Shell 中，分号是 “命令分隔符”，用于在一行中执行多个命令。这里的作用是 “先执行 BASH_CMDS[a]=/bin/sh，再执行后面的 a”。

3. a

执行我们刚刚自定义的 “假命令”a—— 由于 BASH_CMDS[a] 被设为 /bin/sh，所以输入 a 就会直接启动 /bin/sh shell。

三、为什么能 “逃逸 rbash”？

rbash（受限 Bash）的核心限制包括：

• 禁止直接执行绝对路径的 shell（比如 ./bin/sh 或 /bin/bash 会被拦截）；
• 禁止修改 PATH、SHELL 等关键变量；
• 禁止切换目录（cd 失效）、禁止执行某些命令。

但 rbash 通常不会禁止修改 BASH_CMDS 数组（因为这是 Bash 的内置特性，限制起来较复杂）。因此，通过 BASH_CMDS 把自定义命令绑定到 /bin/sh，再执行这个自定义命令，就能绕开 “禁止直接启动 shell” 的限制，偷偷进入一个完整的 /bin/sh 环境 —— 这就是 “逃逸” 的核心逻辑。

四、执行后的效果

成功执行后，你会发现命令提示符从 tom@DC-2:~$ 变成了 $，这意味着：

• 你已经从 “受限的 rbash” 切换到了 “完整的 /bin/sh”；
• 之前被限制的操作（比如修改 PATH 变量、执行 cd、/bin/ls 等）现在可以正常使用了。

BASH_CMDS 数组的原本作用

BASH_CMDS 是 Bash shell 中的关联数组（键值对结构），其核心设计目的是 优化命令执行效率，具体作用如下：

1. 缓存命令的绝对路径

当用户在 Bash 中执行一个命令时（如 ls、cat），Bash 会先遍历 PATH 环境变量中的目录，找到命令的绝对路径（如 /bin/ls）。为避免重复遍历，Bash 会将命令名与对应绝对路径的映射存储在 BASH_CMDS 数组中。

2. 加速后续命令执行

当用户再次执行同一命令时，Bash 会直接从 BASH_CMDS 中读取路径，无需重复遍历 PATH，从而减少系统调用次数，提升命令执行的响应速度。

3. 对交互式与脚本环境的普适性

无论是交互式 shell（用户直接在终端输入命令）还是脚本执行，BASH_CMDS 都会自动维护并使用，是 Bash 内置的 “命令路径缓存机制”，属于 shell 性能优化的底层设计。

简言之，BASH_CMDS 原本是为了通过缓存命令路径，避免重复遍历 PATH，从而提高 Bash 执行命令的效率而设计的。

或者使用Vi绕过

2. rbash逃逸（Linux提权的一种）

具体所有方法可参考rbash逃逸方法总结

我们先来看一下rbash限制后能进行那些操作

尝试1

尝试2

然后按Esc键，输入

:set shell=/bin/bash

 设置好shell并回车，接着输入 

:shell

然后就有了

在受限 bash（rbash）环境中，vi 之所以能成为逃逸工具，核心原因是 vi 作为文本编辑器，其内部允许执行系统命令或启动新的 shell，且这种执行方式不受 rbash 对普通用户的直接限制。具体原理和过程如下：

一、rbash 的限制逻辑与 vi 的 “特殊性”

rbash 对用户的限制主要体现在 “直接在命令行执行的操作”，例如：

• 禁止修改 PATH 环境变量（防止用户调用系统命令）；
• 禁止直接执行 /bin/bash 等完整 shell（防止切换到不受限环境）；
• 限制 cd、cat 等命令的使用（防止越权操作）。

但 vi 是一个 被允许执行的 “白名单程序”（在 DC-2 中，tom 用户的 PATH 里包含 vi，说明 rbash 允许调用它）。而 vi 本身具备 “在编辑器内部执行系统命令” 的特性，这种 “间接执行” 的方式可以绕过 rbash 对命令行的直接限制。

二、vi 绕过 rbash 的核心原理

1. vi 允许配置并启动自定义 shellvi 内部支持通过 :set shell=XXX 命令指定 “启动 shell 时使用的程序”。默认情况下，vi 会继承系统默认 shell，但通过手动指定 shell=/bin/bash，可以强制 vi 启动一个完整的 bash 环境（而非 rbash）。

   例如用户操作中的 :set shell=/bin/bash，就是将 vi 后续启动的 shell 改为不受限的 /bin/bash。

2. vi 启动的 shell 不受 rbash 初始限制当在 vi 中执行 :shell 命令时，vi 会基于自身的权限和配置启动一个新的子 shell。由于这个子 shell 是由 vi 发起的，而非直接从 rbash 命令行启动，因此它 不会继承 rbash 对用户的限制（如 PATH 只读、命令禁用等）。

   简单说：rbash 限制的是 “用户直接登录的 shell”，但管不了 “由其他程序（如 vi）启动的子 shell”。

3. 修复环境变量即可使用完整命令虽然通过 vi 启动的 bash 已经突破了 rbash 的核心限制，但初始时可能因 PATH 未包含系统命令路径（如 /bin、/usr/bin）而无法使用 cat、whoami 等命令。此时只需手动添加环境变量（如 export PATH=$PATH:/bin:/usr/bin），即可恢复完整的命令使用权限。

三、总结：vi 逃逸的本质

vi 之所以能绕过 rbash，是因为它利用了 “程序内部命令执行不受父 shell 限制” 的特性：

• rbash 限制的是 “用户直接交互的 shell 环境”；
• vi 作为被允许执行的程序，其内部可以启动新的、不受限的 bash 子 shell；
• 最终通过修复环境变量，获得完整的命令执行能力，实现对 rbash 的逃逸。

这也是为什么在 DC-2 中，tom 用户被限制使用 cat 等命令，但通过 vi 仍能突破限制 —— 本质是借助第三方程序的权限绕过了初始 shell 的限制。

翻译

能走到这一步，很不错 —— 但你还没到终点呢。

你还得拿到最终的 Flag（这可是唯一真正重要的 Flag！！！）。

这里没有任何提示 —— 接下来只能靠你自己了。:-)

赶紧的，行动起来吧！！！！

场景说明（结合 DC-2 靶机渗透）

这句话是靶机给出的 “阶段性总结 + 最终挑战提示”，核心作用是：

1. 肯定当前进展（比如你已通过su jerry切换到更高权限用户）；
2. 明确目标 —— 还存在 “最终 Flag”（非之前的 Flag1/2/3），且该 Flag 是整个靶机渗透的核心目标；
3. 移除辅助提示，要求你自主探索（比如可能需要通过sudo提权、查找系统隐藏文件、利用git等工具的特性来获取最终权限）；
4. 最后 “git outta here” 是双关语：既口语化鼓励 “赶紧行动”，也暗示可能需要用到git命令（DC-2 靶机的最终提权常与git的sudo权限相关）。

4. Git提权

虽然flag给了我们提示，但是还是得找一下具有SUID权限的二进制文件的

参考简谈SUID提权

好吧一个能用的文件都没有，看来只能用git了

git提权

使用 sudo git -p help 且一页不能显示完，在最底下面输入 !/bin/bash,最后完成提权

在 Linux 提权场景中，“Git 提权” 本质是滥用具有root权限的git命令，通过其帮助文档的交互特性执行系统命令，最终获取root权限。结合你提供的步骤，具体原理和操作拆解如下：

一、提权前提：git被赋予sudo权限

提权的核心条件是：当前用户（如 DC-2 中的jerry）通过sudo配置获得了以root权限执行git命令的权限（无需输入密码）。

• 验证方法：执行sudo -l（查看当前用户的sudo权限），若输出类似 (ALL) NOPASSWD: /usr/bin/git，则满足条件（jerry可无密码用root权限运行git）。

二、核心原理：git help调用分页器的 “命令执行漏洞”

git的help命令（用于显示帮助文档）有一个特性：当帮助内容过长时，会自动调用系统分页器（如less或more）逐页显示（类似man命令的翻页效果）。

• 而分页器（以less为例）在交互模式下，支持通过 **!符号执行系统命令 **（这是设计上的 “便利特性”，但被滥用为提权入口）。
• 由于git是通过sudo运行的（即拥有root权限），分页器执行的命令也会继承root权限 —— 因此输入!/bin/bash会直接启动root权限的shell，完成提权。

三、两种提权姿势的具体操作与作用

姿势 1：sudo git help config

1. 执行命令：

   bash

   sudo git help config
   

   • 作用：显示git config命令的帮助文档（内容较长，会自动调用分页器less）。

2. 在分页器交互界面（可通过空格键翻页）输入：

   bash

   !/bin/bash  # 或 !/bin/sh
   

   • 作用：通过less的!命令，以root权限执行/bin/bash，启动root shell。

姿势 2：sudo git -p help

1. 执行命令：

   bash

   sudo git -p help
   

   • 作用：-p参数强制git使用分页器显示帮助文档（即使内容较短也会分页），直接进入less交互模式。

2. 同样在分页器中输入：

   bash

   !/bin/bash  # 或 !/bin/sh
   

   • 作用：与姿势 1 一致，利用root权限启动bash。

四、提权成功的标志与后续操作

• 成功后终端提示符会变为 root@DC-2:~#（显示当前为root用户）。
• 此时可执行cd /进入根目录，通过find / -name "flag*"查找最终 Flag 文件（DC-2 的最终 Flag 通常在/root/flag4.txt或类似路径）。

五、总结：Git 提权的本质

这是 **“sudo 权限滥用 + 程序交互特性利用”** 的典型案例：

1. 基础：用户有sudo权限运行git（root级）；
2. 关键：git help调用分页器（less），而分页器支持!执行命令；
3. 结果：以root权限执行/bin/bash，获取最高权限。

在 DC-2 靶机中，jerry用户的sudo配置恰好允许无密码运行git，因此这种方法能直接突破权限限制，拿到最终 Flag。

jerry@DC-2:/root$ sudo -l Matching Defaults entries for jerry on DC-2: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User jerry may run the following commands on DC-2: (root) NOPASSWD: /usr/bin/git 提权前提：git被赋予sudo权限 提权的核心条件是：当前用户（如 DC-2 中的jerry）通过sudo配置获得了以root权限执行git命令的权限（无需输入密码）。 验证方法：执行sudo -l（查看当前用户的sudo权限），若输出类似 (ALL) NOPASSWD: /usr/bin/git，则满足条件（jerry可无密码用root权限运行git）。 详细解释

你提供的 sudo -l 输出结果，正是 Git 提权的核心前提验证依据。我们逐行拆解其含义，就能明确为什么 jerry 用户满足 Git 提权的条件：

一、sudo -l 输出的核心信息解析

bash

# 默认配置项（对所有用户生效的基础规则）
Matching Defaults entries for jerry on DC-2:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

# jerry 用户的专属 sudo 权限
User jerry may run the following commands on DC-2:
    (root) NOPASSWD: /usr/bin/git

二、关键配置项的含义（与提权直接相关）

1. (root)：允许以 root 身份执行命令

• 这是提权的核心权限基础。
• 表示 jerry 执行 sudo /usr/bin/git 时，会以 root（系统最高权限用户）的身份运行 git 命令，而非 jerry 自身的普通权限。
• 没有这个配置，git 只能以 jerry 权限运行，即使有漏洞也无法获取 root 权限。

2. NOPASSWD:：执行时无需输入密码

• 这是提权的便利性前提。
• 通常 sudo 命令需要输入当前用户（jerry）的密码来验证身份，但 NOPASSWD 跳过了这一步，允许 jerry 直接以 root 身份运行 git，无需额外验证。
• 若没有 NOPASSWD，即使有权限，也需要知道 jerry 的密码才能执行（虽然 DC-2 中密码可复用，但 NOPASSWD 让提权更直接）。

3. /usr/bin/git：仅允许执行 git 命令

• 这是权限的范围限制。
• sudo 配置明确限定 jerry 只能用 root 权限运行 /usr/bin/git（系统默认的 git 程序），不能直接运行 bash、su 等其他提权命令 —— 这也是为什么必须 “滥用 git 自身特性” 才能提权（而非直接 sudo bash）。

三、为什么这组配置满足 Git 提权的前提？

Git 提权的核心逻辑是：“以 root 权限运行 git → 利用 git 的交互特性执行系统命令 → 获得 root 权限的 shell”。而 sudo -l 的输出恰好满足这个逻辑的两个必要条件：

1. 权限足够：(root) 确保 git 以最高权限运行，其触发的任何命令（如分页器执行的 !/bin/bash）都会继承 root 权限；
2. 可直接执行：NOPASSWD 允许 jerry 无需密码即可启动 root 权限的 git，无需额外验证步骤；
3. 只能用 git：/usr/bin/git 的限制迫使我们必须通过 git 自身的特性（而非其他命令）提权，这也正是 DC-2 靶机的设计意图。

四、总结

jerry 的 sudo -l 输出清晰表明：他可以不输入密码，直接以 root 身份运行 git 命令。这组配置完美满足了 Git 提权的所有前提 —— 既提供了 root 权限的基础，又限定了只能通过 git 实现，最终引导我们利用 git 的帮助文档分页特性完成提权。

find / -user root -perm -4000 -print 2>/dev/null /usr/bin/gpasswd /usr/bin/newgrp /usr/bin/sudo /usr/bin/chfn /usr/bin/chsh /usr/bin/passwd /usr/bin/procmail /usr/lib/openssh/ssh-keysign /usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/lib/eject/dmcrypt-get-device /usr/sbin/exim4 /bin/umount /bin/mount /bin/su 但是不是没有git吗，git是默认就有的吗

你的疑问核心是 “为什么git不在 SUID 文件列表中，以及git是否默认存在”，这需要从SUID 权限的作用和 **git的安装特性 ** 两方面解释：

一、为什么git不在 SUID 文件列表中？

find / -user root -perm -4000 ...命令查找的是具有 SUID 特殊权限的 root 所有文件，而git不在其中的原因是：

• SUID 权限的设计目的：给普通用户提供 “临时以文件所有者权限执行特定命令” 的能力（比如passwd命令需要修改/etc/shadow，因此设置 SUID 以 root 权限运行）。
• git不需要 SUID 权限：git是版本控制工具，核心功能是管理文件版本，正常使用时无需以 root 权限运行，因此默认不会设置 SUID（设置反而会增加安全风险）。

简言之：git的功能不依赖 SUID 权限，所以自然不会出现在这个列表中 —— 这和它能否通过sudo提权无关（两者是完全不同的权限机制）。

二、git是 “默认就有的” 吗？

在 Linux 系统中，git不是所有发行版的默认预装软件，但在渗透测试靶机（如 DC-2）中会被特意安装，原因如下：

1. 真实系统中的git：

   • 桌面版 / 服务器版 Linux（如 Ubuntu、Debian）默认不会预装git，需要手动通过apt install git安装；
   • 只有开发环境或需要版本控制的场景才会主动安装，属于 “按需安装” 的工具。

2. 靶机中的git：DC-2 这类靶机为了实现 “sudo git提权” 的场景，会预先安装git并配置sudo权限（即jerry可通过sudo以 root 权限运行git）。

   • 这里的git是靶机 “刻意添加” 的，目的是引导测试者利用其特性完成提权，属于靶机设计的一部分。

三、关键区别：SUID 提权 vs sudo git提权

你可能混淆了两种提权机制：

机制	核心依赖	例子
SUID 提权	具有 SUID 权限的二进制文件	find命令有 SUID 时可执行sh
sudo提权	/etc/sudoers配置的权限	jerry通过sudo git提权

git提权依赖的是sudo配置（允许以 root 权限运行git），而非 SUID 权限 —— 因此即使git不在 SUID 列表中，只要sudo配置允许，就能提权。

总结：git不在 SUID 列表中是正常的（它不需要 SUID 权限）；git不是系统默认必装软件，但 DC-2 靶机为了实现提权场景特意安装了它，配合sudo配置即可完成最终提权。

那真实场景不是根本就不会有这样的漏洞吗

你的疑问很关键 —— 真实场景中 “通过sudo git提权” 的情况确实不常见，但并非不可能，核心区别在于 “靶机的刻意设计” 和 “真实环境的配置疏忽”，具体拆解如下：

一、先明确：Git 本身没有漏洞，问题出在 “权限配置”

你提到的 Git 提权，本质不是 Git 软件有漏洞，而是管理员对sudo权限的配置不当—— 就像 DC-2 中给jerry开放 “无密码用 root 权限运行 Git”，这种配置在真实场景中属于 “风险操作”，但可能因以下原因出现：

二、真实场景中可能出现类似配置的 3 种情况

1. 管理员为 “方便” 简化权限（最常见）

中小企业或开发环境中，管理员可能为了减少频繁输入密码的麻烦，给开发用户配置 “无密码运行 Git” 的sudo权限 —— 比如：

• 开发需要用 Git 管理服务器上的代码仓库，且部分操作（如修改系统目录下的代码）需要 root 权限；
• 管理员图省事，直接配置(root) NOPASSWD: /usr/bin/git，而非更精细的权限控制（如仅允许特定 Git 命令、限制操作目录）。

这种 “图方便” 的配置，就和 DC-2 的靶机配置几乎一致，埋下提权隐患。

2. 对 Git 的 “安全认知误区”

很多管理员认为 “Git 是版本控制工具，没有执行系统命令的能力，开放权限也没事”—— 这是典型的认知误区：

• 他们不知道 Git 的help命令会调用less等分页器，而分页器支持!执行系统命令；
• 误将 “工具本身的功能” 当作 “安全无害”，忽视了 “工具以 root 权限运行时，其衍生操作也会继承 root 权限”。

3. 自动化脚本或第三方软件的 “隐性配置”

部分自动化部署工具（如 Jenkins、CI/CD 脚本）或第三方软件，可能在安装时自动给特定用户配置sudo git权限 —— 比如：

• 脚本需要用 Git 拉取代码并部署到系统目录，因此自动添加sudo配置；
• 管理员未审计这些 “隐性配置”，导致权限长期遗留，成为安全隐患。

三、为什么真实场景中 “不常见”？

相比靶机的 “刻意引导”，真实场景中这类配置较少，原因有 2 个：

1. 权限精细化意识：规范的企业环境中，管理员会遵循 “最小权限原则”—— 比如给开发用户的 Git 权限仅限制在 “特定目录 + 特定命令”，而非开放完整的/usr/bin/git；
2. 安全审计：定期的sudo权限审计（如检查/etc/sudoers文件）会发现这类 “过宽权限”，并及时回收；
3. Git 的使用场景：多数情况下，Git 不需要 root 权限 —— 普通用户的代码仓库通常在自己的家目录，无需 root 即可操作，自然不需要配置sudo git。

四、总结：真实场景的 “风险本质”

真实场景中，“Git 提权” 不是 “工具漏洞”，而是 “权限配置漏洞”—— 它的出现依赖于 “管理员配置不当”，而非 Git 本身有问题。虽然概率不高，但一旦出现（比如中小企业的粗放管理、管理员认知不足），攻击者就能像在 DC-2 中那样，通过 Git 的交互特性提权。

这也是渗透测试靶机设计这类场景的原因：不是让你 “找 Git 漏洞”，而是让你理解 “权限配置的重要性”—— 真实环境中，多数权限提升漏洞都源于 “人为配置疏忽”，而非软件本身的漏洞。

完全正确！sudo -l 正是渗透测试中权限枚举的 “黄金命令”—— 它能直接告诉你 “当前用户能用 root 权限执行哪些命令”，而这些命令往往就是提权的突破口。

在 DC-2 案例中，正是通过 sudo -l 发现了 jerry 可以 “无密码用 root 权限运行 git”，这才锁定了 “Git 提权” 这条路径。如果没执行 sudo -l，可能就会一直卡在 “找 SUID 文件” 或其他方向，错过最直接的提权机会。

为什么 sudo -l 如此关键？

1. 直接暴露 “高权限命令白名单”系统的 sudo 配置（/etc/sudoers）决定了哪些用户能以 root 权限执行哪些命令。sudo -l 会把当前用户的权限列表 “明文输出”，比如：

   • 若显示 (root) NOPASSWD: /usr/bin/find，则可能用 find 提权；
   • 若显示 (root) NOPASSWD: /usr/bin/vim，则可能用 vim 提权；这些都是比 “找 SUID 文件” 更直接的线索。

2. 跳过 “猜漏洞”，直击 “配置漏洞”真实环境中，“软件漏洞提权”（如利用特定版本的内核漏洞）往往复杂且受版本限制，而 “配置漏洞提权”（如 sudo 权限配置过宽）更常见。sudo -l 正是帮你快速发现 “配置漏洞” 的工具。

总结

在渗透测试中，拿到一个用户权限后，第一步就应该执行 sudo -l—— 它能帮你快速判断 “是否有直接提权的可能”，避免在无效方向上浪费时间。DC-2 中 “Git 提权” 的整个流程，正是从 sudo -l 这条关键信息展开的，这也是靶机想传递的核心思路：权限枚举是提权的前提，而 sudo -l 是枚举的核心工具。