目录
本文通过《webug4靶场第30关 SSRF》来进行渗透实战,不过本关卡有点小bug,通过修复靶场的bug使具有SSRF关卡功能,并完成获取敏感文件与内网服务探测的渗透。
一、SSRF简介
1.SSRF原理
SSRF(Server-Side Request Forgery:服务器端请求伪造):服务器对用户提供的可控URL过于信任,没有对攻击者提供的URL进行地址限制和足够的检测,导致攻击者可以以此为跳板攻击内网或者其它服务器。其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制,导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据。
- 攻击利用点:服务器端应用程序通常会根据用户的输入或其他业务逻辑发起对外部资源的请求,如获取图片、下载文件、调用其他 API 等。如果服务器在构建这些请求时,没有对目标地址进行充分的验证和过滤,就可能被攻击者利用。
- 攻击过程:攻击者通过构造特殊的 URL 或参数,将恶意的目标地址传递给服务器端应用程序。服务器端应用程序会按照攻击者指定的地址发起请求,而这个请求可能会绕过防火墙等安全机制,访问到内部网络中的敏感资源或执行恶意操作。
2.渗透方法
- (1)可以对外网、服务器所在内网、本地进行端口扫描,获取一些服务的 banner 信息;
- (2)攻击运行在内网或本地的应用程序(比如溢出);
- (3)对内网Web应用进行指纹识别,通过访问默认文件实现;
- (4)攻击内外网的web应用,主要是使用get参数就可以实现的攻击;
- (5)利用 file 协议读取本地文件等;
二、第30关SSRF渗透实战
1.打开靶场
本文通过《webug4靶场第30关 SSRF》来进行渗透实战,不过这个关卡有点小bug。
http://192.168.71.1/webug4/control/more/ssrf.php?url=localhost/control/xss/xss_1.php?id=1
不过无论是windows下的靶场,还是docker安装的webug靶场都是打不开,如下所示。
2.渗透实战
(1)Windows靶场修复
注意当前url如下所示。
?url=localhost/control/xss/xss_1.php?id=1
很明显URL的绝对路径出现异常,访问地址应该如下所示。
?url=localhost/webug4/control/xss/xss_1.php?id=1
于是网址修正为如下所示。
http://192.168.71.1/webug4/control/more/ssrf.php?url=localhost/webug4/control/xss/xss_1.php?id=1
如下所示,访问成功,通过url参数可以访问到内网资源,如下所示。
(2)Docker靶场修复
Docker环境中的webug靶场需要 安装扩展curl库php5-curl才可以正常打开此关卡。
1)通过sudo docker ps -a查看webbug对应的容器Id。
2)获取到Id后,通过如下命令进入webbug的容器环境。
sudo docker exec -it 98b33e502d8b bash
通过这个命令进入到docker环境, 数字部分大家需填写自己的容器id, 这里98b33e502d8b即为上图中红框中查询到的webug靶场对应的容器id,如上所示
3)进入容器环境后,执行sudo apt-get install php5-curl 安装扩展curl库。具体执行过程见下图。
4)执行完后大家重启下kali。
可以通过重启kaili 或者sudo docker stop 容器id, sudo docker start 容器id来完成服务的重置
5)重新进入靶场。
如下所示配置完毕后,再次打开此关卡后可以正常打开靶场。
(3)获取敏感文件信息
url=file:///c:/windows/win.ini
SSRF的地址如下所示。
http://192.168.71.1/webug4/control/more/ssrf.php?url=file:///c:/windows/win.ini
如下所示渗透成功。
(4)内网端口与服务扫描
http://192.168.71.1/webug4/control/more/ssrf.php?url=localhost:3306
如下所示3306端口处于打开状态,渗透成功。
三、防范方法
- 严格验证目标地址:对用户输入的目标地址进行严格的验证,限制只能访问合法的、预期的地址,禁止访问内部网络地址和其他敏感地址。
- 使用白名单机制:建立允许访问的地址白名单,只有在白名单中的地址才能被服务器访问,其他地址一律拒绝。
- 限制协议和端口:只允许使用必要的协议(如 HTTP、HTTPS)和端口,禁止使用其他可能存在风险的协议和端口。
- 对请求进行代理:通过代理服务器来发送请求,在代理服务器上进行地址验证和过滤,防止恶意请求到达目标服务器。
- 及时更新和打补丁:保持服务器软件和应用程序的更新,及时修复可能存在的 SSRF 风险。