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

This article mainly introduces the case study of system rights enhancement from Blind XXE vulnerabilities to reading Root files, which has a certain reference value, and interested friends can refer to it. I hope you can learn a lot after reading this article.

* the relevant vulnerabilities involved in this article have been reported to the manufacturer and repaired. This article is limited to technical research and discussion, and illegal use is strictly prohibited, otherwise all consequences will be borne by ourselves.

During the recent public testing of vulnerabilities, the author encountered an interesting XML server when testing XXE vulnerabilities. The server has few records and references online, and the only thing that can be found is a post that a developer asked for help when he encountered difficulties using the server in early 2016. In the following article, the author shares some ideas when testing the server. Finally, the author makes use of the Blind XXE of a medium-risk vulnerability, finds a high-risk vulnerability that can read root-level files, and successfully implements the system rights enhancement.

This paper deliberately describes all kinds of error messages encountered in the testing process, hoping to enlighten and help the readers. In addition, because it is an invitation test, all the identifiable information involving the server has been hidden for the sake of confidentiality.

The initial discovery

At first, what caught my attention was a server that responded to the XML format message and the 404 status, as follows:

But when I changed the request method to POST and added a header such as Content-Type: application/xml and an invalid XML content, there were some interesting changes in the response message, which seemed to be a bit XXE:

However, when a normally structured XML document is added, the response message changes further:

Note that the server obviously wants to provide password or credential information in order to interact with it properly, unfortunately, the current project does not have any documentation to mention the specific form of credentials, and I did not find any valid credential information. Indeed, some of the XXE leverages I've done before require some form of "effective" interaction with the target server to be successful. So, it seems that without credentials, it is very difficult to exploit XXE vulnerabilities in depth.

But even so, we should not be discouraged. Since the XML document structure includes XML declarations, DTD document type definitions, and document element information, we can test the DOCTYPE definition to see if the server completely disables the application of external entities, or try any other responses. So, I went on to construct the following request that contains DOCTYPE and uses the Collaborator module for out-of-band testing, and has a corresponding response:

The server was unable to respond to your request in a timely manner.!? After that, I carefully checked the relevant interaction in Burp Collaborator, hoping to find an incoming HTTP request, but only saw the following picture:

Unfortunately, the server seems to be able to resolve my burpcollaborator.net proxy domain name, but there is no HTTP request, and the server has a timeout response status of 500 after a few seconds.

This seems to be the role of the server firewall, I continued to test outbound HTTP requests for other ports, but to no avail. All ports will show timeout, that is, the firewall deployed on the target server can successfully block all abnormal outbound traffic, and the security protection is not bad.

Implement Blind XXE

Based on the above findings, I messed around, and the test found a problem, but I was not sure yet. I could only prove that it could be a medium-risk vulnerability by trying to access some local files, internal networks, or related services.

The impact of this vulnerability is that I can use it to successfully detect the existence of some files on the target server, as follows:

The response message indicates that the file exists and can be opened and read normally by the server's XML parser, but because the file content is not a valid XML document type definition, the parser fails and throws an error. In other words, the server side does not disable the loading of external entities, but we do not see any output, so from this point of view, this appears to be a Blind XXE vulnerability.

In addition, we can assume that the parser running on the server side is Java's SAX parser, because in terms of responding to error messages, it seems to be related to the Java error class org.xml.sax.SAXParseExceptionpublicId, which is interesting because Java has a lot of features in XXE, which we'll explain later.

When the file we constructed to access does not exist on the server, the response is as follows:

OK, this seems to be useful, but it's not telling enough. I was wondering if we could use this Blind XXE vulnerability to scan the original port of the target server. As follows:

This method is good, if feasible, it proves that we can enumerate the internal services of the target server, which can reflect some problems, but it is not the effect I want. Such Blind XXE vulnerabilities seem to be somewhat the same as Blind SSRF vulnerabilities: HTTP requests to internal services can be initiated, but the response cannot be read.

Therefore, I wonder if other SSRF-related techniques can be used to indirectly exploit this Blind XXE vulnerability. The first thing you can do is to check the usage of other protocols on the server side, such as https, gopher, ftp, jar, scp and so on. Although the final test of these protocols has no substantial effect, you can get a lot of useful information from the error response messages on the server side. Such as:

Isn't it interesting that the server can identify the usage protocol we provide and respond incorrectly? You can write down this point for later use.

Because of its similarity to Blind SSRF vulnerabilities, it can be used to probe some internal Web services. Because the company works with a wide variety of development teams, and a large number of x.company.internal-style internal mainframe descriptions are involved in its Github development documents, I found that the target company deployed some of the following internal service resources:

Wiki.company.internal

Jira.company.internal

Confluence.company.internal

Since the previous firewall blocked my outbound traffic, here, I want to verify whether it blocks the traffic of internal services, or whether these internal services really exist.

From the above response results, it is interesting to see that the error message indicates that the internal resource we requested has been read by the server and is only identified as the wrong format. In other words, the reading of internal resources is allowed, and our request is valid.

This is where the Blind XXE vulnerability can be used to initiate requests for Web services within the target system, enumerate the possibility of files, and enumerate all possible running services. Based on these hazards, I reported the loophole. But when I travel on weekends, I keep thinking about this loophole and think that there should be other possibilities for further discovery.

In the land of the blind, one eye is king.

After a weekend of recuperation and thinking adjustment, I decided to dig deeper into this Blind XXE loophole. In particular, I realized that if I could find a host with a similar proxy role inside the target server, I could route unfiltered internal service traffic to the outside.

Generally speaking, it is quite difficult to find vulnerabilities in Web applications that cannot read responses, but fortunately, a SSRF vulnerability for Jira applications has been disclosed by the community earlier, and specific methods of exploitation have been mentioned in several articles.

To this end, I am eager to use this method to map the target company's Jira application: jira.company.internal, which I found on Github. The constructed request and corresponding response are as follows:

As you can see from the response message, the problem with the HTTPS request may be caused by an error in the SSL authentication method. In addition, the usual Jira instances are running on port 8080, so let's change it to HTTP and add port 8080 to try:

Then, I looked at the interaction information of the Burp Collaborator module and found nothing. Maybe the server-side Jira instance was patched or the vulnerable plug-in was disabled. After that, I aimlessly searched wiki.company.internal for SSRF vulnerabilities. Finally, I decided to try the same test method as jira.company.internal on confluence.company.internal, but I changed the test port to the default port 8090 of the confluence application:

Wait, what is this? One more HTTP request has been added:

Succeed! In this way, through the confluence instance, you can bypass the firewall restrictions and direct the internal traffic to the outside indirectly. That means we can do some classic XXE attacks on it. First of all, we construct a malicious file evil.xml with the following contents and host it on the attacker's server, hoping to eventually trigger useful information.

Let's take a closer look at the specific definition of the above file:

1. Load the external reference (here is the system / directory) into the variable% file

2. Define a% ent variable, which just acts as an interspersing function to compile the third entity definition

3. Try to access the resource at% file and load the contents of that location into the entity's data.

Note that we want the definition in aspect 3 above to fail, because the content at% file will not point to a valid resource location, but will only contain the complete directory content.

Now, use the internal instance of confluence.company.internal to point to our malicious file evil.xml and make sure that% ent and & data are accessible to trigger directory access. Great, the response finally lists all the directory information on the server side:

Interestingly, this shows another way to get an error response from the server, which is to specify a missing "missing" protocol instead of the invalid protocol we saw earlier. This can also help us resolve the problems encountered when reading files that contain colons, such as the following errors when reading / etc/passwd using the above method:

In other words, the file can be read before the colon for the first time, but what is after the colon can no longer be read. How do you bypass this and display the contents of the specific file in the response message? That is to precede the contents of the file with a colon, which results in a "no protocol" error because the field before the first colon is empty, such as no style defined. Therefore, our managed file evil.xml on the attacker's server can be constructed as follows:

The final results are as follows:

The result of reading the / root directory file:

In this way, for the target company's system, through the abuse of improper network isolation measures, unpatched internal application services, unconfigured Web servers and incorrect responses with information disclosure, we can raise rights from medium-risk vulnerabilities in Blind XXE to high-risk vulnerabilities that can read root-level files, and achieve control over the target system.

Experience summary

Red team:

If you find something interesting, keep digging.

In the way Java SAX parsers deal with URL patterns, there are some new ways to extract useful information. The current popular Java version does not allow multi-line files to be stolen and exported through external HTTP requests (such as http://attacker.org/?&file), but it is possible to obtain some multi-line response information related to the target system from some error response messages or even URL protocols.

Blue team:

Actively patch the vulnerabilities existing in the internal service system

The internal network should not be simply regarded as secure, and different levels of trust should be divided.

Error messages should be passed into the error log, not in the HTTP response

Authentication does not effectively alleviate security problems that protect against vulnerabilities such as XXE.

Vulnerability reporting process

Interesting XML servers found on November 26, 2018

Report Blind XXE vulnerability on November 28, 2018.The risk is that files, directories, internal network locations and service ports can be enumerated.

On December 3, 2018, a vulnerable internal Confluence application server was found, and the test PoC video was reported, demonstrating reading the root directory file.

2018.12.4 the company fixes vulnerabilities and issues bug bounties.

2018.12.6 articles applying for the test are disclosed

Approved on December 12, 2018

Thank you for reading this article carefully. I hope the article "from Blind XXE vulnerabilities to the case study of system rights enhancement for reading Root files" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.