Hello luvs, this article is about one of my very recent private security assessments on a gigantic service provider, to keep them safe we use REDACTED whenever we talk about them. Please note that this is in no way a complete security assessment, and my main goal of testing found at least one critical vulnerability to illustrate they are vulnerable to further attack in case of someone really trying.

Recon

Here is what I did. I went to their google store and check for their app and amount of installs. By checking their applications and websites, I found out REDACTED (with over 10 million installs !) seems to be the most critical asset because it's where vital pieces of information are stored.

- user personal data

- user points

- payments

Just like any other project, I started gathering subdomains, endpoints, tech stacks, etc. I don't want to bore you with details of how I mapped the attack surface because there are tones of tutorials out there. But in short, here is what I found.

- The authentication is centralized amount all of the websites - Most of the web is written in the express framework (javascript) or PHP (code igniter) - PHP sites seem to are being re-written in express as well - They use incapsulate WAF for critical assets

Discoveries

Now we have an attack surface, we can start poking for vulnerabilities to see what we can find. Note that there is always a chance to miss some assets during the initial recon.

Reverse Engineering

There are around 50 apps developed by REDACTED, so I could not analyze them all. I just did a brief summary of REDACTED and REDACTED, which due to the number of installs, are most used. I usually prefer to work on the android version of apps because I find reversing android apps a lot less painful than IOS apps generally, and not to my surprise, REDACTED apps are just slightly obfuscated, which will allow us to extract almost the whole code from apps. Unfortunately, apps store all the secret keys and API keys in plain text so they are acceptable and can lead to further vulnerabilities.

For example, the following URLs are leaked information about the app firebase database, and some of them are totally open!

https://REDACTED.firebaseio.com/.json

There is a lot more juicy information on the apps, and there should be so many ways to exploit this leaked info, but as I'm impatient, I only focus on the leaked endpoints to find a critical vulnerability.

Most notably, during my analysis on apps, I found out apps are actually just the web apps in disguise, so my recon already revealed a big chunk of the attack surface, yet still, I found some more information here and there.

Vulnerability Discovery

As we already find out in our reversing process, almost every asset in our target is a web asset, so we can move on to test for web vulnerabilities, and as a web and mobile developer, I can find these vulnerabilities faster than other vulnerability types. But it doesn't mean that's all we should look for. We should always try our best to find at least one critical vulnerability, or that's what I do.

Low Hanging Fruits

I found PHP info files, debug versions of apps, cross-domain misconfigurations, open git directory, accessible firebase databases, free s3 buckets, etc. here and there, but I'm not satisfied till I find at least one critical vulnerability.

REDACTED identity takes over

While analyzing both apps and web apps, as I already mentioned, all the sub-apps and web apps use a centralized login, so whenever any user of apps wants to login into his/her portal, they will be redirected to accounts.REDACTED.net which will send a request to auth.REDACTED.net and authenticate users. I started by looking at headers to make sense of what we are dealing with.

Missing CSP, HSTS, and most notably allowing framing the critical assets. This looks like attackers heaven any XSS vulnerability on *.REDACTED.net can lead to whole identity takeover. Finding an XSS in such scope is not hard, but finding a useful XSS might be, and by helpful XSS, I mean something that can on every modern browser, and it won't need any exclusive privilege. During my content discovery phase, I found a new directory called redirect, which will respond with 200, and that's it. But the name was new redirect! So I start fuzzing it for parameters and not so spuriously the URL parameter exists there.

Open Redirect vulnerability

Next, I just tried to add a website in the parameter I found, and let's see what will happen. http://auth.REDACTED.net/param?param=https://0xsha.io, and it did work! It redirected me to 0xsha.io fantastic! I was happy at this point because I thought I can use this open redirect and chain it with an SSRF or something later to gain more vulnerability. But wait, what if we can redirect it to javascript protocol?

Open Redirect to XSS

So I simply redirect it to javascript http://auth.REDACTED.net/param?param=javascript:alert(1337) and boom! No kidding XSS on the auth domain itself, and due to its natures, this bug already bypassed both WAF and browser XSS protections leet indeed.

XSS to account takeover

Now we have an XSS vulnerability; its time to write a PoC exploit for it and call it a day. I tried payloads like the ones in XSShunter, and I see they won't work after a bit of playing more with it. I found out both quotes and double quotes are filtered! Which will make our job harder. So I spend time to figure out a quote less payload we have at least two options I'm aware of. Backticks and char codes. Here is how you can generate your payload.

var s = "I\'m the XSS Exploit"; for (var i =0; i<s.length;i++) { console.log(s.charCodeAt(i)); } alert`1337`

We also need a server that can send cookies to, and we need to set proper access handling headers there. Something like this.

class CORSRequestHandler (SimpleHTTPRequestHandler): def end_headers (self): self.send_header('Access-Control-Allow-Origin', '*') SimpleHTTPRequestHandler.end_headers(self)

Now we are finally ready to develop our exploit remember the security headers? It allows us to make a hidden iframe from this vulnerable domain, which makes this exploit crazy stealthy. My proof of concept exploit will steal all the cookies from *.REDACTED.net and send them to my server. Finally, it redirects the user back to some REDACTED sites. I can't share full exploit, but it's straightforward to develop. So here is a summary :

1- We found an open redirect in a hidden endpoint by fuzzing for parameters 2- Because of the lack of sanitization we could use it to make an XSS 3- Because of lack of security headers CSP / HSTS we can run ability javascript code 4- Because of lack of proper sanitization only filtering quotes we can develop an exploit 5- Because of lack of x-frame-option we can create a hidden iframe and make it stealthy 6- Because of the nature of vulnerability it will bypass both browser protections and used WAF 7- We can take over ~30 million accounts. !

At this point, I already felt I did what I was looking for I found a straightforward vulnerability and escalate it to stealthy weaponized exploit.

When better recon means RCE

Even though I already found an interesting vulnerability, I didn't stop there I tried to look into founded assets here and there, so after a little digging, I found a very obvious subdomain in some other domain README.MD file, which all my recon scrips surpassingly missed. jenkins.REDACTED.net and surprisingly, it's ancient. We can bypass authentication by merely adding securityRealm/user/admin/ to the path!

And if you are familiar with Jenkins, you will know this old Jenkins means nothing but RCE! The worse thing about this Jenkins instant is it's used to deploy back office! Which is another critical asset in the infrastructure? A malicious actor can simply infect deployment and infect every single instance deployed using this Jenkins. So I downloaded orange exploit.

Set up a burp collaborator again and ran this command

And here is the result! OMG RCE!

Now we can probably compromise the whole network, and that's where I stop digging and start reporting my findings. What a journey! Due to criticality of target I stopped right here reported all my findings to REDACTED .

Conclusion

As we can see when it comes to security, even though REDACTED did a reasonably great job when it comes to safety, but they are not immune to attacks yet, no one is. Big companies should allocate a lot more resources for security. All the vulnerabilities mentioned here are reported to the REDACTED company to minimize any future damage.

PS : my professor asked me to do this one, I hope he is proud, and it was an exciting journey.