vulnhub-vulnix通过技巧

这里我们扫描到了靶机156

nmap 192.168.135.0/24 -sP

这里开放的端口有点多，但是nfs文件挂载是这个靶机的主要思路，同时还开放smtp25,ssh22，finger79，rpcbind111,

nmap 192.168.135.156

NFS 本身仅根据用户的 UID/GID 对用户进行身份验证；这比适当的身份验证系统（如 kerberos）是非常不安全的, 一旦NFS文件系统被远程主机以读/写权限成功挂载，每个共享文件的唯一保护就是它的权限。此权限绑定到用户的用户 ID。如果共享相同用户ID的两个用户挂载相同的 NFS 文件系统，可以修改彼此的文件。

nmap 192.168.135.156 -p- -sV -sC -T5 -A

我们使用这个字典来枚举smtp存活用户的信息，想办法获取用户的gid，uid来挂载nfs文件来获取shell

locate unix_users.txt

这里显示存活用户和服务

smtp-user-enum -M VRFY -U /usr/share/metasploit-framework/data/wordlists/unix_users.txt -t 192.168.135.156

这里我们发现存在root和user，这个估计就是我们的突破口了，我们挂载user的共享文件，登录和user相同的uid,gid用户就能访问挂载文件，里面的服务估计以root权限运行，拿下就是root的shell

finger命令用于查找并显示用户信息。包括本地与远端主机的用户皆可,帐号名称没有大小写的差别。

Finger root@192.168.135.156

Finger user@192.168.135.156

看到两个用户都是有效的，用户user具有devenull的登录名和名为Dovecot的名称，这边只确认了用户的存在，密码还需要继续获得,这里我们用hydra来获取用户user的密码，爆破出来letmein

hydra -l user -P /usr/share/wordlists/rockyou.txt 192.168.135.156 ssh -t 4

登录进来后我们发现有两个用户，嗯？是不是有两个挂载文件啊，先不管他，我们记下他们的uid和gid,和他们的文件目录，在kali挂载看看

Ssh user@192.168.135.156

Cat /etc/passwd

我们创建挂载的目录，按照路径和挂载文件nfs进行挂载,发现成功挂载上去

Mkdir -p /tmp/yang

Mount -t nfs 192.168.135.156 : /home/vulnix /tmp/yang

Df

我们发现我们自己创建的文件自己没有权限进去？这个就是挂载文件的魅力了，原理就是我们将vlunix的nfs挂载到了yang上面，这两文件是共享的只有同一uid，gid的用户才能访问到，访问yang就是访问了nfs被挂载的文件

我们创建一个uid，gid用户名一样的用户，看看能否访问挂载目录

Useradd -u 2008 vulnix

Useradd -u 2008 vulnix -g vulnix

发现我们成功访问了，这个就是因为nfs挂载只校验uid,gid和用户是否相同，在这个漏洞中我们访问了我们创建的yang，其实就是在访问挂载的nfs文件，虽然此时的vulnix并不是靶机真正的vulnix用户，但是yang确实是nfs挂载文件

这时候我们在kali登录yang挂载文件，就能真正登录到靶机的vulnix用户，因为nfs（等同于yang）是运行在vulnix用户上的，我们登录就是真正的vulnixshell，这个解释不知道是不是很清楚了，而此时我们创建的vulnix只是用着一样的uid和sid代替我们访问到yang(nfs)里面罢了。要登陆我们可以使用公钥加密钥的方式登录，理论成立接下来尝试用密钥登录vulnix

Ssh-keygen -t rsa

指定生成rsa密钥，在新版kali中要指定生成

查看生成的公钥，将公钥放到nfs共享文件夹（yang）上，我们用密钥登录

Cat id_rsa

我们在同样的位置生成.ssh文件放置公钥

Mkdir .ssh

Cd .ssh

echo "" > authorized_keys 这里我就给框架，自己粘贴公钥吧方便一点，很好理解吧这个命令，将公钥输入到authorized_keys里就行

我们赋权给.ssh和公钥

这里密钥我们不能给太高的权限，这里我们竟然登录失败了？按理来说直接登录进去了的，他还叫我们输入密码，这不对。如果你也是上网看了教程，一定一定会这样，核心原因新版 Kali OpenSSH 客户端默认不再支持旧 ssh-rsa 签名算法。教程好多都是旧版kali，遇到的问题也都是权限过高的问题，我遇到这个问题也卡了不久。

我们强制使用旧的rsa密钥登录

成功拿到靶机vlunix的shell

Linux提权的方法有很多，打靶时最常用的就是内核提权，除了内核提权，我之前的帖子还提到了sudo提权，SUID提权，计划任务提权，数据库udf提权，命令写入文件，后续还遇到了lxd容器提权，这些估计也够用来打靶了。

我们发现这个环境变量/etc/export竟然是root权限的，那我们修改它

如果no_root_squash使用，远程 root 用户可以更改共享文件系统上的任何文件，并留下被木马感染的应用程序，让其他用户无意中执行。

那我们就进来修改

这里修改完后要重启靶机，配置才会生效，但是reboot只有root权限才能使用，我们手动将他重启，这个有点烧心了啊，现实中谁会给你手动重启别人电脑。但是这靶机就是练习挂载漏洞的，不然我早内核exp了。

我们要重新挂载共享文件，应为修改配置重启后，我们重新挂载kali就有权限访问共享文件了，这里记得退出挂载用户。

删除上一个没有权限的挂载文件

Umount /tmp/yang

重新挂载修改过配置的共享文件，这样kali也能访问yang（nfs）这个共享文件

Mount -t nfs 192.168.135.156 /home/vulnix /tmp/yang

df

Kali成功访问挂载共享文件yang

这里有意思的是我们kali创建目录，靶机上的共享目录也会同时创建，因为这个是共享目录，我们挂载到kali后就是同一个目录。本来kali是访问不到的，只有kali创建的vulnix才能访问。但是我们修改了规则让kali也能访问，我们就用kali的root运行在靶机上来提权。

这里我第二次打到这里时发现没有办法提权，又看了下别人的帖子，发现kali生成的bash是root权限了，但是呢靶机是32位，那我们在靶机生成bash到kali，kali再生成一个yang来执行bash。（呜呜呜，才过去多少天第二次竟卡在这，第二次我是在kali生成的bash，虽然都是root可以共享，但是这个是64位，在靶机生成的是32位，才能在靶机运行提权）

这里要在靶机生成一个bash，此时的bash还没有root权限（这张图是我完成时补截的，执行cp /bin/bash .时忘记截图了，现在是没有yang这个文件的，不要在意这些细节>_<）

Cp /bin/bash .

然后kali的yang下也有了bash，这个bash是32位的，因为是靶机生成的，此时还没有root权限。我们将他复制到yang文件里，赋值4777理解4777吗?4suid,2guid,1粘滞位。此时yang=bash=root=32位，靶机也有yang。

Cat bash > yang

Chmod 4777 yang

ls

提权成功好吧，有一点点逆向思维，稍不注意连我都用64位bash了。

解释的很详细了，没什么好解释的了，看个flag结束了吧