Appreciation and appreciation, thick and thin hair
The middleware vulnerability can be said to be the most vulnerable vulnerability to web administrators. The reason is very simple, because this is not a vulnerability in the application code, but is caused by improper configuration or improper use of an application deployment environment. From the actual situation, the biggest difficulty in preventing such a loophole is who is responsible for the security of middleware?
In addition, developers and operation and maintenance personnel are also an important factor in the lack of security awareness of middleware. Some developers may perform security testing on their own code, but it is not enough to only review the code. This article is used to record some common web middleware vulnerabilities and protection issues (only part of the record, not all), part of which is taken from Doug’s book “White Hat Saying Web Security”, which is considered as a reading note or a post-reading .
When talking about the security of middleware, I feel that it is necessary to sort out the above relationships and concepts. When I was exposed to these concepts, my mind was a mess, and the concepts of middleware, containers, servers, webservers, etc. felt very similar to each other, but they were different. Therefore, when writing this article, I deliberately searched some information, trying to sort out the relationship between these people, refer to the article: http://www.voidcn.com/blog/saoraozhe3hao/article/p-2428756. Html
Only the web middleware, web server, and web container are introduced here, because the concept can be extended to a database or the like in addition to the web.
The web server is used to provide the http service, that is, to return information to the client, which can process the HTTP protocol, respond to requests for static pages or pictures, control page jumps, or delegate dynamic requests to other programs (middleware programs).
Web middleware is used to provide a connection between system software and application software to facilitate communication between various components of the software, which can provide a container for one or more applications.
The web container is used to provide an environment for the application components (JSP, SERVLET) in it, which is an integral part of the middleware, which implements the parsing of dynamic languages. For example, tomcat can parse jsp because it has a jsp container inside.
Web server: 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: web middleware and web server overlap, because web middleware such as tomcat also has the function of web server.
The web server simply provides static web page parsing (such as apache) or a service that provides a jump. The web middleware (which contains the web container) can parse the 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 parses static resources not as fast as apache, so it is often used in combination.
Tomcat is a middleware software of apache, which can provide jsp or php parsing service. In order to facilitate remote management and deployment, after installing tomcat, there will be a management page by default. The administrator only needs to upload a file in WAR format remotely. The content can be published to the website. This feature is convenient for administrators and also opens the door for hackers. In addition, tomcat has some sample pages, which can lead to security problems if not handled properly.
The tomcat management address is usually:
Default account password:
Blasting is invalid when the default is not configured for tomcat, and it can be blasted if the account password is set. Tomcat authentication is weak, Base64 (username: password) encoding, if the request response code is not 401 (unauthorized: access is denied due to invalid credentials), indicating that the login is successful. After the login is successful, you can directly upload the war file, getshell (of course uploading the war file requires manager permission)
First package our .jsp shell file as a war file:
After logging in to the administration 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.
Used to set any session variable, malicious use can cause damage to the application.
- Upgrade tomcat version
- Delete the remote deployment page or restrict access to the page.
- Find /conf/tomcat-users.xml to change the username and password and permissions.
- Delete sample page file
JBoss is a JavaEE-based application server. Similar to tomcat, jboss also has a remote deployment platform, but does not require login. The exploit process is similar to tomcat, so there is no longer a screenshot. In addition to remote deployment vulnerabilities, jboss also has a deserialization vulnerability, which is not detailed here.
Default management background address:
Visit the administration page and view the JMX Console in the jboss configuration page. This is the JBoss management console program. After entering, find the Jboss.deployment package. The package has the flavor=URL.type=DeploymentSccanner option. 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 download 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 on invoke. In addition to the above methods, the BSH method provided by JMX-Console can also deploy the war package.
- Open jmx-console password authentication
- Remove jmx-console.war and web-console.war
Weblogic is a middleware based on JavaEE architecture. After installing weblogic, it will listen to port 7001 by default. The exploit process is similar to tomcat, so there is no longer a screenshot.
Default background address:
- Username and password are: weblogic
- Username and password are: system
- Username and password are: portaladmin
- Username and password are: guest
After successfully logging into the weblogic background, find the deployment button, click to select the installation, and then you can select the local upload war package or use the remote url to download. After the deployment is complete, weblogic will give the file address.
- Delete remote deployment page
Axis2 is also a project of apache, a new generation of SOAP engine with an arbitrary command execution vulnerability. (The vulnerability is from the Tiantian platform)
Default background address:
Default account password: admin and axis2
After login, the effect is as follows:
Execution system command poc
IIS is a web server from Microsoft. It is easy to generate webdav vulnerability if it is not properly configured. Webdav itself is an extension of iis. After opening, you can use some request types other than get and post, such as put. However, if it is not properly configured, it will lead to a file upload vulnerability. In addition to the webdav vulnerability, a remote command execution vulnerability has recently emerged, specifically: [IIS6.0 Remote Command Execution Vulnerability (CVE-2017-7269)] (http://thief.one/2017/03/29/ IIS6-0%E8%BF%9C%E7%A8%8B%E5%91%BD%E4%BB%A4%E6%89%A7%E8%A1%8C%E6%BC%8F%E6%B4% 9E-CVE-2017-7269/)
When testing a site for a webdav vulnerability, you can construct an OPTIONS request first. If you return 200, you can see which methods are included in the Allow parameter of the return header (can be requested).
If there is a PUT method, you can try to write a txt file.
If you return 200, the upload is successful. You can manually access this file to confirm whether it exists. Of course, it is also possible to return 403, which means that this directory does not have the permission to upload, you can try to upload to other directories.
Change the file suffix name by MOVE or COPY method.
- Turn off webdav function
There are also some vulnerabilities in Apache itself, such as the slowhttp vulnerability. Of course, the official believes that it is a feature of Apache and is not a loophole. However, it turns out that its harm is really great. In addition to the slowhttp vulnerability, its third-party moudle has many vulnerabilities in deserialization or remote command execution.
Please refer to the slowhttp vulnerability: [Talk about DDOS attacks and defenses] (http://thief.one/2017/05/10/1/)
The HPP vulnerability is a problem when the web container handles http parameters. The previous web servers have more or less such problems.
For example, access the URL:
At this point the page shows hello
But if you visit:
At this point, the page displays nmask, which overwrites the value of the previous parameter. This is the http parameter pollution.
Bypass WAF, such as:
Because WAF may check the first word of the value, if it is select, it will trigger, so that it can avoid being triggered.
In addition to these vulnerabilities, the web server has some vulnerabilities in parsing dynamic languages. Step by step: [Server Parsing Vulnerability | nMask’Blog] (http://thief.one/2016/09/21/%E6%9C %8D%E5%8A%A1%E5%99%A8%E8%A7%A3%E6%9E%90%E6%BC%8F%E6%B4%9E/)