In this post, I will chronicle a remote operation that was executed. The operation took many weeks to achieve its target, I went from minimal information about the corporate into the total compromise of all customer’s users private information. The target is a large corporate with a sizable security program. For purposes of this blog, I will call them Target Corporate.

Target Corporate is a big E-commerce company that works in multiple countries. In this operation, I needed to do Web application Recon, source code review, exploitation, lateral movement and social engineering.

Let’s start

When I began this operation, I typically know nothing about their infrastructure operations. I needed to research the corporate and learn as much about their internal operations as possible.

I needed to look for outdated softwares and services that can be exploited. Maybe some applications with default passwords or custom web applications that might be vulnerable, looking for any resources that may be useful to gain more information.

Recon Phase

I spent hours doing recon at the target external systems. There were no obvious exploitable vulnerabilities on any of the applications that have been discovered. I found numerous web services and spent time investigating them. There was nothing in these tiny services.

I used Google search engine in addition to multiple tools to enumerate any reachable subdomains regarding Target Corporate, the most interesting subdomains were:

• management.target.com (A software to Control customer data and transactions)
• gmail.target.com (A software that is supported by google mail to provide a secure email login)
• wordpress.target.com (WordPress software installed)

(Those are not the real names of the subdomains)

At management.target.com, the application requests login credentials as it is only allowed to the stuff to login and control customers and transaction data. the application replies with a redirect to gmail.target.com once it is opened, which asks for stuff email credentials and after successful login, another redirect is sent back to management.target.com.

That means if I am able to access one of the stuff credentials who is authorized to access the management area then I am in.

Planning Phase

I created a small phishing email campaign on the emails that have been discovered during the Recon Phase.

I bought a domain and created a phishing email campaign with a Gmail phishing login page (because they use Gmail service as their main email service through gmail.target.com).

I sent few phishing emails not more than 20 email and the results were quite awful.

The domain that was used in my phishing campaign was reported by the employees and then blacklisted by Google chrome and Mozilla Firefox browsers!

I didn’t want to raise any alarms within the organization, It is a big known organization they have a security team that is aware of these types of attacks. I needed everybody to operate normally. As such, I wanted to limit my contact with the employees.

I noticed that management.target.com doesn’t use SAML authentication during logging in through gmail.target.com, instead, the employees receive “*.target.com” session after authentication that is used by management.target.com to verify if the session is valid and that the user is authorized to access the employees’ restricted area.

If I am able somehow to access any subdomain related to Target Corporate, then I can use this subdomain to hijack the “*.target.com” management session through a client-side attack.

Here was the written plan:

Hijacking the stuff session through XSS will not fit my situation because “*.target.com” session is protected by HttpOnly and Secure parameters.

Meaning I will need to hijack the session through a server-side page and to do this I will need to access any subdomain either by subdomain takeover or Remote Code Execution.

I chose the WordPress subdomain as a good target initiator for the mentioned attack. my goal was to upload a shell and gain an RCE through the WordPress script.

WordPress Assessment

I executed wpscan tool over the WordPress domain and noticed that the WordPress script is outdated, that was good news.

Also, many plugins have been discovered, one of them was outdated and vulnerable:

Based on wpscan results, the UserPro plugin was outdated and should be vulnerable, the following reflected XSS regarding CVE 2019-1447 was the only finding that is exploitable from my side.

The exploit is written in exploit-db:

https://www.exploit-db.com/exploits/47304

OK, now there is a reflected XSS but still not useful as long as I didn’t gain Remote Code Execution over the application.

My plan was to find a way to send the malicious URL to one of the WordPress admins and trigger the XSS exploit that adds a malicious plugin to the WordPress application so that I can gain RCE using the malicious installed plugin, but this was plan B because it needs user interaction through social engineering.

Back to plan A, I decided to manually do a source code review on these plugins each one by one.

I downloaded the theme as well named pierce theme and started to check the source code for any stuff that looks suspicious.

I decided to keep attention to the server-side findings, first I discovered three local file include vulnerabilities that effects piercetheme.

In file function.php:

Three IF conditions contain similar code but different parameter names (payment_response_listing, payment_response, pay_for_item) all are vulnerable to Local File Include, only one will be exploited at once because function die is added by the end of each if condition.

The previous piece of code that is vulnerable to Local File Include is located in a function called PricerrTheme_template_redirect.

If I am able to control the application behavior to run the mentioned function, then LFI will be exploitable.

On the beginning of the functions.php, there is a hook to the vulnerable function:

WordPress defined filter hooks as follows:

I will simplify it, a hook is creating a function that will execute instead of another WordPress core function, In my case, it is template_redirect function.

After more tests, I observed that function template_redirect executes automatically by WordPress as it is included in wp-includes/template-loader.php file which means the code path will go through the vulnerable function.

To exploit the Local File Include, I needed to add any of the three vulnerable GET request inputs, for example wordpress.target.com/?payment_response=Page_name

The main issue was that, I am not controlling the included files extension meaning I can only exploit the local file include by including PHP files only!

Also, I am not controlling the wrapper through the user-input meaning I can’t use php:// wrapper to read the files source code, for this, the local file include was still useless!

SQL INJECTION

I started to read many and many files for hours until I reached file lib/gateways/paypal_response.php:

A user-input is sent on line 8 then decomposed using function explode into many parameters:

The following three parameters $pid, $uid and $datemade are then sent to a SQL statement without any filters or sanitization:

It is a SQL injection, but which type of SQL injection is it?

To answer this question I read the remaining source code:

After the injection, The code goes through an IF condition if the query didn’t return any true result.

In the IF condition in lines 144 and 155, an email is sent to the WordPress admin. That means If I executed SQL injection attacks then the application will flood the admin email. This is not a stealth attack at all!

There was only one option which is to prevent the application path from entering through the following IF condition:

This means the injected payloads should always return at least one raw otherwise the application path will enter the IF condition and thus, the admin will be notified about my actions, also the SQL injection will be time-based because the application path will end as long as the if condition is false.

The vulnerable file doesn’t include the wp-config.php file (it is a file in the WordPress scripts that contains the database configurations). furthermore, there are few WordPress functions used that will not be clarified if I directly access the vulnerable page.

This page should be included by another file that includes the “wp-config.php” and the WordPress core functions otherwise the page will always through an error and the SQL injection will be unexploitable.

Now I can use the discovered Local File Include to include the paypal_response.php page that is vulnerable to time-based SQL injection using the following request.

I tested the time-based SQL injection payloads but for the first few requests the application replies without time delay, I installed the vulnerable theme on my machine localhost and counted the number of columns in table job_orders, it was 33 columns. Next, I changed the payload by adding “or 1=1” to always return true and a union select that contains the number of columns and function sleep(10) that if executed the database host will go to the idle mode for 10 seconds, thus, the following request was crafted:

The application replied after 11 seconds. I really like this final scene that contains the proof of concept regarding the SQL injection.

In part 2. I will outline how I went from a time-based SQL injection in a subdomain into having full access to the target Corporate’s management area.