Thread by @Jhaddix

🐻 Hacking a Search / Cloud Company 🐻

I once took over a MAJOR foreign search/cloud company.

I had full access to every employees email & full source code for all their apps.

Here's how it did it (legally)… ⬇️🧵

⚠️ This one is from the archives and mobile tools change fast (well… not that fast tbh) so I will attempt to give modern analogs for tools, for those following along at home. ⚠️

📳 I started by downloading all their mobile apps.

The bug bounty scope allowed me to analyze any of their assets.

I noticed that they had several mobile apps, each covering a different software product. I downloaded these to my jailbroken iPad.

My jailbroken iPad had many security analysis tools installed.

📜 My abbreviated work-flow for hacking mobile applications usually is:

1⃣ Decrypt the binary (IPA) with frida

github.com/AloneMonkey/fr…

2⃣ Run the decrypted app through strings analysis looking for the lack of security related classes

3⃣ Run the app while instrumentation tools are monitoring these:

🔦 Protocol handlers
🔦 Web traffic
🔦 Logs
🔦 Keychain
🔦 File writes

4⃣ Fuzz protocol handlers

5⃣ Web test on the backend (usually an API)

What I did notice was some naming in files in the app directory.

It looked like the company had 📤 outsourced 📤 the development of the app to 3rd party.

This is good for a security tester as many of these outsourcing agencies do not have any security engineers or staff.

They tend to make more security errors than if the companies teams had build them and worked with internal security teams to review the app.

During the authentication of the app a web path was logged to the system logs. On iOS you an view system logs by tailing:

#⃣ tail -f /var/log/system.log | grep TheApp

You can also use libimobiledevice and Mac's console app.

the path was

#⃣ /authint/

Prob would have never appeared in any content discovery wordlists.

I ended up doing file and directory bruteforce (content discovery) on that path.

I found

#⃣ /authint/auth.js

Opening up this JavaScript file revealed it was some helper for debugging of their Google Drive type product.

In the JavaScript I noticed a username & password in a request url:

😬 sadDev:sadDevPassword

Normal regex search for passwords would not have found this. There was no variable declarations like “user” & “password”. It had to be 👀 with-your-eyes 👀 JavaScript review.

I proceeded to go to their app from the web and used these credentials, just adding their company domain after:

sadDev@sadCloudSearchTarget{.}com

❗️ Pro tip ❗️

For red teamers and bug hunters, always use usernames and passwords in different places.

In bug hunting, many times bug hunters find some sort of creds.

Often the creds don't work on the API, endpoint, or whatever anymore.

Or the the whole backend is down.

❗️ Pro tip ❗️

SAVE THOSE CREDENTIALS.

Use them on OWA/Azure, Google, cloud panel logins, SaaS services, any login form you find. I promise, they will hit somewhere.

So sadDev’s credentials worked on the main file storage app. I had access.

Since it was also a package deal, like Google’s services, I had access to his company email, photos, etc.

After looking him up on LinkedIn he was a lead developer. Very high in the company.

I sifted through his email and found what code repository they used, as he was getting email alerts for things related tot it.

I used the same cred on the website of that SaaS code repository. It worked again.

I also saw that for a portion of their team they used Slack.

His creds worked there too, but with a twist.

His original creds did not satisfy the password requirements for Slack.

I tried the current year at the end and !!! at the end (which are the most common additions to meet password complexity).

!!! worked.

#⃣ sadDev:sadDevPassword!!!

Rummaging through Slack I found several pinned credentials in Slack that gave me direct access to their cloud infrastructure.

This is not uncommon for developer Slacks that I have previously compromised.

⚠️ People pin passwords and API keys all the time.

📰 When preparing the report, I was getting chatted by his dev friends through the cloud chat (not Slack).

So I went back. I happened to notice he had Admin privs to the corporate cloud accounts.

I navigated to the direct link to the management center.

🦸‍♂️ I could create users, deletes users, and take over accounts via password resets. 🦸‍♂️

So… I had:

🧩 Complete control of all emails and drives for the company
🧩 Access to Slack
🧩 Access to infrastructure
🧩 Access to source code

Game over.

📕 Lessons for security testers pt 1:

🧩 Mobile apps are a goldmine. Learn at least the very basics of doing some mobile testing

🧩 Content discovery on everything

🧩 Manual review (noy just tools) for JavaScript is necessary

📕 Lessons for security testers pt 2:

🧩 Re-use credentials on everything you know the target used, especially SaaS

🧩 Create permutations on any discovered creds and use them for password spraying

🧩 Explore your access thoroughly before reporting

📘 Lessons for security defenders pt 1:

🧩 3rd party app app development sometimes misses security standards by a lot (in this case forgetting to remove debug logs)

🧩 Don’t leave integration scripts up on the internet

🧩 Don’t hardcode credentials in JavaScript (or anywhere)

📘 Lessons for security defenders pt 2:

🧩 2FA everywhere, especially on all SaaS

🧩 Impossible travel alert might have caught me but tbh I wasn't attempting to be stealthy

🧩 Don’t share passwords on Slack

That’s it, hope you enjoyed!

Follow, retweet, and like if you want to hear more hacking stories in the future!