This post describes three vulnerabilities found by me on bug bounty programs along with an overview about how it was found and the performed steps. The main goal of this post is to show how to find critical/high vulnerabilities without touching the company’s assets or tampering with the requests. I hope you like it and find something useful!

Reports:

1. The exposed endpoint containing the invitation URL of enterprise accounts allows attackers to join the company as an employee.
2. Able to claim the ownership of Calendly third party service from [redacted] due to an unused calendar being mapped on the Contact page, which leads to managing scheduled client’s calls with the support team.
3. Source code leaked and sensitive information disclosure on public [redacted] company IP with an uncommon opened port found via Shodan analysis.

1. Exposed endpoint containing the invitation URL of enterprise accounts allows to join to the company as an employee.

During the OSINT analysis, one of the first steps that I take is to retrieve the target endpoints and URLs crawled by third parties, this can be done with open-source tools such as gau and the command below:

printf target.com | gau

After that, I start to MANUALY analyze the endpoints and URLs from the output, paying particular attention to some sensitive keywords:

invoice, discount, promo-code, redirect, reset_password, reset-password, password, TrackOrder, token, invite

And for this one, the invite keyword suddenly took my attention on the target’s endpoints:

I just clicked on the suspicious URL and it took me to a SIGN-UP page, and after creating a new account with a personal email (@gmail.com) then I just were redirected to the company’s page inside the target application, containing all the invited employees and sensitive information as well:

Impact:

Any user could sign-up as an employee on the target app service using the URLs being mapped on different crawlers, which would disclosure PII and sensitive information about the company for the attackers.

Steps were taken to find this vulnerability:

1. Searched for all company assets available under scope using open-source tools (subfinder, amass…)
2. Used gau tool to retrieve a list of URLs and endpoints from the discovered domains
3. Grepped the results containing sensitive keywords, which in this case it was ‘invite’ grep -r "invite"
4. Manually accessed the URLs to see their content, and followed the page instructions, which lead me to Sign-up as an employee for many different companies registered under the affected target app.

2. Able to claim the ownership of Calendly third party service from [redacted] due to an unused calendar being mapped on the Contact page, which leads to managing the scheduled client’s calls with the support team.

Upon accessing the target for the first time, I generally like to analyze the whole structure of the application before attacking it. After just like 5 minutes of interacting with the different pages, I clicked on a calendar icon on the bottom left side of a Contact page and it ended opening up a blank page with an error from Calendly’s service:

By inspecting the page, I was able to see a GET request to target-v2/call which comes to be the registered calendar name from the third-party service Calendly. I immediately signed up a new account there, created a new calendar, and then it asked me for a unique name that would be attached to the URL, so I automatically thought about takeovers attacks.

I provided target-v2 as the name of the Calendar, proceeded with the creation and boom!

My newly created calendar were displaying at the contact page from the target’s domain, so if anyone scheduled a call with the support team, they would be actually scheduling with me (attacker).

Impact:

Any user could takeover the third party service calendar being used to schedule support calls to the target company, this allowed attackers to easily perform phishing attacks and manage all the scheduled calls with target’s clients.

Steps taken to find this vulnerability:

1. First I manually analyzed the application functionalities and pages as a normal user
2. Then I found on the Contact page, a third party integrated app as a scheduling calendar (Calendly service)
3. Finally I thought about a possible takeover of calendars from this platform. For this, I signed up a new account, studied the creation of calendars, and then I registered the name used by the target app as my new calendar.
4. Instantly my calendar got linked to the Contact page from the target app, and then scheduled calls with the target support team were now totally managed by me (attacker).

3. Source code leak and sensitive information disclosure on public [redacted] IP with an uncommon opened port found via Shodan analysis.

This last one was found during a manual Shodan analysis of the target app. I started with the below Dork just to grab more info about the target:

ssl:target.com

and manually looked for uncommon opened ports by accessing the “View Report” option. Suddenly there was one host with the port “9869” opened, which I instantly tried to access and it lead me to a password protected page in order to access the content from the page:

Then I did a bruteforce attack to find directories and endpoints using ffuf tool, which gave me good results:

After getting a response for the share endpoint, I access it and from there it was possible to access the source code from company’s project in a directory listing:

Impact:

Any user on the web could find this service exposing sensitive company files such as projects data and source code.

Steps taken to find this vulnerability:

1. Started with a simple Shodan dork to filter all domains matching the company SSL certificate name
2. Manually searched for uncommon open ports
3. Accessed them and there was one host which lead me to a password protected page (highly suspicious)
4. Started a brute force attack using ffuf tool to discover possible hidden endpoints/directories to bypass the password page and found one
5. Accessed the endpoint share and the sensitive files were there.

Takeaways:

Always perform a passive analysis over the target app using as much tools/research/dorks as possible, and there are a lot of them actually on the github, bb tips and so. One thing I learned was that as bigger the company is, the more OSINT results you`ll get, and of course, the more chances you’ll have to find a critical vulnerability such as the ones here on this article.

Daniel_v

Vendetta team

Twitter | BugCrowd Profile | H1 Profile | Linkedin

The Infosec Writeups team just completed our first Virtual Cybersecurity Conference and Networking event. We had 16 amazing speakers who conducted super valuable and inspiring sessions. To check the list of speakers and topics, and to get lifelong access to recorded versions of all 16 talks, click here.