Medium_Socnet
- 写写打靶记录。
- 靶机地址：https://www.vulnhub.com/entry/boredhackerblog-social-network,454/
- Vulnhub 的靶机都有一个特点，通常导入到 VMware Workstation 时都会获取不到 IP 地址，虽然可以进紧急模式中修改，但是太麻烦了，还是将 Kali 和靶机桥接吧。
信息收集
- 由于将 Kali 与 VulnHub 使用 Virtual Box 仅主机网卡进行了桥接，所以使用 Kali 去扫描靶机。
- 首先查看 Kali IP 地址：
1 | ┌──(root㉿kali)-[~] |
- 扫描当前网段，发现靶机 IP 地址：
1 | ┌──(root㉿kali)-[~] |
- 继续使用 Nmap 扫描端口、开放服务等信息：
1 | ──(root㉿kali)-[~] |
- 扫描出 5000 端口的 Web 服务，通常情况下不考虑 SSH 爆破，访问一下 Web 服务：
- 只有一个输入框，没啥多余的东西，简单测一测 XSS：
1 | <script>alert(1)</script> |
- 并没有什么用，改变思路，使用 dirb 爆破一下网站目录：
1 | ┌──(root㉿kali)-[~] |
- 扫描出一个 admin 目录，访问一下：
Shell 反弹
- 也是一个输入框，根据页面提示，会将输入代码交给 exec() 函数去执行，并且根据前期的信息收集发现，对方是 Python 的 Web 站点，尝试执行 Python 的反弹 Shell 代码（此处可能会出现错误，要多重启几遍和多次尝试）。
1 | 现在 Kali 上开启 NC 监听 |
- 先进行简单的信息收集工作：
1 | /app # ls |
发现目录下出现了
Dockerfile文件，并且查看 IP 时发现了172.17.0.0/16网段的地址，有理由怀疑当前是在 Docker 环境中。再尝试判断一下：
1 | / # ls -al |
- 已经百分百确定，当前是在 Docker 环境中了。
内网信息收集
- 上传 fscan 扫描一下内网的网段信息：
1 | 判断靶机上是否有 wget、curl 程序 |
- 输入如下命令开始扫描：
1 | 修改文件权限 |
- 得到
172.17.0.1、172.17.0.2、172.17.0.3三个地址，其中172.17.0.3是当前靶机地址。
内网代理
- 使用 frp 进行内网代理：
1 | frps.ini 配置 |
- 连接成功~！
- 修改
proxychains配置文件：
1 | vim /etc/proxychains4.conf |
- 使用 nmap 扫描如上三个 IP 地址：
1 | ┌──(root㉿kali)-[~] |
- 在 firefox 上配置代理访问 Web 服务：
- 发现
172.17.0.1和172.17.0.3服务几乎一致，看来要向172.17.0.2出手了，细致的扫描一下9200端口的服务：
1 | ┌──(root㉿kali)-[~] |
漏洞利用
- 发现了
Elasticsearch服务，使用 Kali 上的 searchsploit 模块进行漏洞查找：
1 | searchsploit -t Elasticsearch |
- 发现两个 RCE，一个一个尝试，将其复制到当前路径下查看使用说明：
1 | ┌──(root㉿kali)-[/tmp] |
- 使用
Python2编写，尝试运行一下：
1 | ┌──(root㉿kali)-[/tmp] |
- 脚本运行成功~，而后在根目录下发现了一个
passwords文件，查看一下：
1 | [proxychains] Strict chain ... 127.0.0.1:6000 ... 172.17.0.2:9200 ... OK |
SSH 连接
- 发现账号密码，在线解密一下：
得到结果：
1337hack，直接 SSH 登录开放了 SSH 服务的 IP 地址：192.168.56.106172.17.0.1
1 | ssh john@192.168.56.106 |
- 查看一下当前权限：
1 | john@socnet:~$ id |
内核提权
- 普通用户权限，需要进行提权，查看一下当前内核版本：
1 | john@socnet:~$ cat /proc/version |
- 目前最新的内核是 6.1，3.13 内核版本太老了，应该存在内核漏洞，Kali 上找找漏洞：
1 | searchsploit -t 3.13 |
- 复制到当前路径，查看下用法：
1 | searchsploit -m linux/local/37292.c |
- 由于是 C 文件，需要使用 gcc 进行编译，但是查看发现靶机上没有 gcc：
1 | john@socnet:~$ gcc -v |
- 这时就需要在 Kali 机上进行编译，而后在靶机上下载执行。
- 但是在 37292.c 文件看到这样一行代码，它使用 system 函数调用了 gcc 命令并且它会去找到这个 ofs-lib.c 这个库文件并编译成对应的 so 文件。
- 这明显在靶机上运行会出现问题，需要修改现有 exp 代码：
- 接下来进行编译：
1 | gcc 37292.c -o exp |
- 报错没事儿，都是告警信息，接下去寻找上述的辅助文件 ofs-lib.so：
1 | locate ofs-lib.so |
- 将文件复制到和 exp 文件同一目录下：
1 | cp /usr/share/metasploit-framework/data/exploits/CVE-2015-1328/ofs-lib.so . |
- 在靶机上下载（进入 tmp 目录操作）：
1 | cd /tmp |
- 赋权执行：
1 | chmod +x exp |
- 坑来了，由于 GLIBC 版本差异，导致执行失败，需要用同等版本的 gcc 来编译，这里我使用 Ubuntu 14.04 去编译了 exp 文件就可以了。
- 提权成功，打靶结束。
注意事项
nmap 扫描开启的服务应当有两个，若是 Web 服务没扫到是内部容器没有启动成功，可以多重启几次。
Python 反弹脚本报错就多试几遍，多换几个端口，IP。
Elasticsearch 执行命令时会自动报错退出，正常现象。
IP 地址梳理（可能需要先了解一下 Docker Network）：
- 192.168.56.106 是宿主机的 IP 地址
- 172.17.0.2-3 都是 docker 容器
- 172.17.0.1 也是宿主机 IP 地址，其中 172.17.0.3 将其服务映射到宿主机上，所以 172.17.0.1 和 192.168.56.106 都出现了 5000 端口，而 22 端口是宿主机已经开放的，所以没有出现在 172.17.0.3 上。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Yongz丶！
