TL;DR
We exploited an information disclosure in the mobile app to get an RCE on internal server which was leveraged to the prod environment.

Let's call the organisation "Redacted Inc.".
Their in-scope apps and URL's are their Android apps, and two URL endpoints -

  • api.redacted.com
  • app.redacted.com

Any static analysis of the android application starts with decompiling the app and I use MobSF for doing that.
One of the most eye-catching section of a MobSF Report is the section which lists the files that might contain hardcoded sensitive informations like usernames, constants, keys, passwords, etc which looks somewhat like this.

The file I'm most concerned about here is the Global.java.

After opening the link it turns out that the file contains tons of hard-coded information used by the application some of which are API Keys, URL's to the application API's and few other IP Addresses which seem unusual.

The part that got my attention is this (shown below) as it's evident from the parameter names that these are some internal server URL's and IP's.

Since most of them were AWS Public IP addresses, I ran a Port scan in the background and started browsing them one by one to see if I find anything useful on the server - 80/443.
Surprisingly one of them had an open directory on the Webroot and an interesting path. Let's call that admsystem.

From the name and the contents it looked like a directory listing for the admin panel of the website. This is in itself a serious issue but I thought of probing deeper to see if I can leverage anything inside to get more access on the server.

Browsing the directory and it's contents an interesting file caught my attention - /tools/cron/html/cron.html

This page had a title of Redacted Internal Cron Job UI and looked like an internal admin panel to create Cron Jobs.

To do a quick check if the commands are actually being executed on the server, I tried a simple curl instead of getting a full shell in their restricted environment which was out of scope.
curl http://my-server/test?out=`whoami` and got a response on my server as www-data.

This is were I stopped all my attempts and the issue was reported. It should be noted that we are still in the internal domain of the application and this was not in-scope.

This is where my teammate Selvie (@FetaSelvie) helped.

The next day when we were carrying out this Pentest, we were testing app.redacted.com and Selvie found a call to api.redacted.com/admsystem/provider.php which was vulnerable to an IDOR.

Seeing the path admsystem we remembered it appearing in the internal server as well.
So she tried to reach the internal Cron portal and send the same request to api.redacted.com/tools/cron/html/cron.html

And there we have it, RCE on the production server.