Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to use XML and ZIP format parsing loopholes to realize RCE

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

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

Today, I will talk to you about how to use XML and ZIP format parsing vulnerabilities to achieve RCE, many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

In this Writeup, the author successfully creates Webshell in the target Web application system and implements remote code execution (RCE) by taking advantage of XXE and ZIP file directory traversal vulnerabilities.

Target Web application

In the course of participating in a public testing project, I came across a Web application that can perform the processing of a common file type. Here, let's call this file type .xyz. Through Google search, I found that this .xyz file type is actually a ZIP package file containing XML and other multimedia content, in which the XML file is equivalent to a manifest to describe the contents in the package.

This is the packaging mode we usually use, for example, if you unpack a .docx file with the unzip command, after running the unzip Document.docx command, we can see the following:

Archive: Document.docx inflating: [Content_Types]. Xml inflating: _ rels/.rels inflating: word/_rels/document.xml.rels inflating: word/document.xml inflating: word/theme/theme1.xml inflating: word/settings.xml inflating: docProps/core.xml inflating: word/fontTable.xml inflating: word/webSettings.xml inflating: word/styles.xml inflating: docProps/app.xml

Another common way to package and unpack is the .apk file, which is actually a ZIP package file that contains an AndroidManifest.xml and other content. However, if the developer is inexperienced in the application deployment process, then the packaging mechanism mentioned above can cause security problems. In essence, these "problems" or "vulnerabilities" are actually caused by XML and ZIP build format features, and the key is if XML and ZIP parsers deal with features that manipulate different formats. Unfortunately, vulnerabilities occur from time to time, especially when developers are using the default configuration. Here, let's take a look at the "features" of XML and ZIP formats that can lead to vulnerabilities.

XML External Entities XML external entity injection vulnerability

XML files support external entities (external entity), which allow XML files to load extracted files from other local or remote source addresses, which is useful in some cases because it is easy to import data from different source addresses. However, if the XML parser is improperly configured to allow the user to declare and define external entity input, a serious attacker can obtain sensitive data locally or internally on the current server, or perform malicious operations. We call it an XXE external entity injection attack, but to put it bluntly, it is still a problem of default configuration.

OWASP defines XXE attacks as follows:

XML external entity attacks are one of the types of attacks against parsing XML format applications that occur when improperly configured XML parsers process documents pointing to external entities and can lead to sensitive file disclosure, denial of service attacks, server-side request forgery, port scanning (domain where the parser resides), and other system impacts. JAVA applications with XML libraries usually have a default XML parsing configuration, so they are vulnerable to XXE attacks. To use such parsers safely, you can disable the XXE feature in some parsing mechanisms.

ZIP directory traversal vulnerability

Due to problems with ZIP format, the ZIP directory traversal vulnerability was exploited in the early days, but the Zip Slip vulnerability disclosed by Snyk in 2018 is of particular concern. Zip Slip vulnerability may cause arbitrary files to be overwritten, and many popular ZIP parsing libraries and JAVA projects are affected by this vulnerability.

An attacker can take advantage of this vulnerability to construct a special ZIP compressed file that contains a file name that can traverse the directory, such as.. / evil1/evil2/evil.sh. When the vulnerable ZIP library unzip unpacks the special ZIP package, it will not only extract the evil.sh to a temporary directory, but also extract it to a location specified by the attacker (such as / evil1/evil2 here). Can cause malicious files to be written to disk or sensitive files to be overwritten. If the scheduled task script cron job is overwritten or the root directory is implanted into webshell, the end result is remote code execution. Similar to XXE injection vulnerabilities, ZIP directory traversal vulnerabilities are also common in JAVA applications.

Zip Slip vulnerabilities affect a variety of development ecosystems, including JavaScript, Ruby, .NET, and Go, as well as some JAVA projects that lack the processing of advanced ZIP central libraries, such as zip. The lack of such ZIP processing libraries has caused some vulnerability code fragments to be shared and circulated among development communities such as StackOverflow.

XXE injection vulnerabilities found

Now, with the above understanding, let's go back to the actual vulnerability testing. The target Web application receives upload, decompression, and XML manifest parsing of common type files, and then returns a confirmation page containing XML manifest information. For example, if the ZIP file mypackage.xyz contains the following manifest.xml manifest file:

My Awesome Package John Doe https://google.com 4.2

After uploading mypackage.xyz to the target Web application, I will get the following confirmation page:

Here, the first thing I test is the XSS vulnerability. It is important to note that because tags are parsed as XML nodes, XSS injection in the form of XML is not supported and must be escaped in the XML file, such as "& amplt;htmltags>", but unfortunately, the output of this escape is filtered by the target Web application.

Let's try the XXE injection vulnerability. I introduced a remote external entity in the XML file below:

My Awesome Package&xxe; John Doe https://google.com 4.2

I didn't return any echoes in my Burp Collaborator instance, and at first I wondered if the XXE vulnerability was blocked. But it's not. XXE Payload related non-system external entities, local files, remote files we need to try one by one to prove the existence of XXE vulnerabilities. After all, if the target Web application deploys a firewall, its standard firewall rules block outgoing network connections, causing remote external entity resolution to fail, but we can try to see if the external entity can successfully parse and read the local file.

Fortunately, I used an external entity to construct the following XML to read the local file, and the / etc/hosts command was successfully echoed on the confirmation page:

My Awesome Package&xxe; John Doe https://google.com 4.2

Test RCE

In the usual white hat testing, we may stop here. Using the above XXE vulnerabilities, we can obtain local data files and other sensitive configuration information, including administrative passwords, on the target Web system, which is enough to write a vulnerability report.

But then I want to test another vulnerability: the ZIP parsing vulnerability. Now that we have these conditions: the target Web application will extract the ZIP package, parse and read the manifest.xml manifest file in it, and then return a confirmation page, and there is also a XXE vulnerability, could there be other unknown vulnerabilities?

Let's first test the ZIP directory traversal vulnerability, here I used the directory traversal Payload generation tool-evilarc, which is a simple Python script. What I want to make sure is to put the directory traversal Payload to a specific location in the local file system, but the XXE vulnerability can help here, and external entities can read local files not only from files, but also from directories. So I constructed an external entity such as file:///nameofdirectory and used it to read the contents of the directory list.

After studying the directory list, I found the file / home/web/resources/templates/sitemap.jsp in the target Web application system, which is very similar to the target Web application https://vulnapp.com/sitemap. So I put the webshell content in it and packaged it, and in order to prevent it from being discovered by ordinary users, I set access restrictions on it. The webshell content is as follows:

After uploading the package containing Webshell to the target Web application, I tried to use https://vulnapp.com/sitemap?spaceraccooon=ls to access Webshell. Nothing echoed. The page is the same as https://vulnapp.com/sitemap. But as the saying goes: to look forward to the same thing is madness.

Latency, caching, and other network features can cause different outputs to the same input. In this case, because the target Web server caches the contents before the page https://vulnapp.com/sitemap, my built-in webshell is not accessible at first, but after several refreshes, I can finally access webshell, where the command ls is successfully executed, returning the Web root directory and other site page information. RCE did it!

Convention first principle (Convention over Configuration)

For many projects, following existing conventions or using reasonable default options is probably the most reasonable and simple thing to do. The target Web application in this Writeup is JAVA architecture. Combining the vulnerability disclosure of OWASP and Snyk, we can see that JAVA has defects in XML and ZIP format processing, coupled with some default parsing mechanisms and third-party libraries, the vulnerability is thus formed.

In addition to the JAVA architecture, almost most programming languages and frameworks have XML and ZIP format handling problems. Developers should pay attention to the format when configuring such frameworks and applications. A small configuration error can lead to fatal vulnerabilities.

After reading the above, do you have any further understanding of how to use XML and ZIP format parsing vulnerabilities to implement RCE? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report