I have 1% chance to hack this company
Today I will share with you the first vulnerability I found on SerpApi, LLC.
I found this vulnerability right after I finished my onboarding process at SerpApi, LLC.
Table of Contents
— The Target.
— Weaponizing the vulnerability.
— Exploitation.
— Impact and severity.
— Report timeline.
— Ending.
The Target
SerpApi is a real-time API to access Google search results and other search engines. They handle proxies, solve captchas, and parse all rich structured data, SerpApi is number 1 in this business in the entire world.
I was really desperate to find a vulnerability, a critical one!.. Yes, I have access to the code of the company, but the code was pretty huge and I just onboarded so I decided to start with the black-box approach first (testing without looking at the code).
I have noticed their API URLs…
For Yahoo API : https://serpapi.com/search?engine=yahoo&p=Coffee&yahoo_domain=be
For Google API: https://serpapi.com/search.json?engine=google&q=Coffee&google_domain=google.com
and so on...
I have decided to go through the domains for each API and try to replace the domain with another hostname, but unfortunately, every time I do that, I get an error stating the domain is not supported!
I started to get desperate and I’m about to give up, tested more than 5 or 6 API’s that using xx_domain parameter but no luck.
Until I got across Yandex!
Looks like there is no protection on the parameter yandex_domain . Now I started to get really excited!
Let’s start to analyze the target a little bit, so we can exploit this vulnerability in the right way.
Weaponizing the vulnerability
Let’s forget the HTML for now and focus on the JSON output, it looks like very rich with useful information:
If you take a look at the yandex_url you will notice several things:
- The URL protocol schema is
https://— and we cannot control nor change it. - The URL always ends with
/search/?text=a.
I’ve tried to bypass the URL with # but it didn’t work so I tried to encode it and send it directly to the playground, but didn’t work, looks like the Playground is escaping it!
So I tried to request the API directly using the search.html endpoint
I used urlencode with / the final result will be %23/ guess what?
Yes, it worked perfectly. :D Now we own a full SSRF on SerpApi, LLC.
We used # to bypass the hardcoded endpoint /search/?test=a .
The issue, we cannot bypass the protocol https:// , if we bypassed that we could use file:/// to read local files, or any other protocol to exploit it as a proper SSRF.
All that I was thinking about is to escalate it to Remote code execution…
how is it possible to escalate an SSRF to RCE with just a request?
Exploitation
Well, I had multiple steps to go through.
- Escalate it to XSS and then Account takeover.
- Try to find the real server IP and hope it’s hosted on a cloud such as AWS or Digitalocean.
I have noticed that every request I do, for any page gets cached on the local servers of the company so when I requested my page from the JSON, I will get a cached HTML copy of the page.
It was the exact HTML page cached.
At this point, I could cache any page with XSS, and JS payloads and simply send the link to any admin to hijack his account.
However, this is not my goal I wanted more so I went ahead and did some digging, I found out by using Shodan.io that https://serpapi.com is using Digitalocean :D which means I can access the magic link and have full access to the metadata.
I didn’t go ahead with it, since it was too obvious, I went ahead to read the code, and see how it was working.
So when I request any URL, the SerpApi engine will try to use private proxies to access the URL (not Digitalocean) at least this is what I thought:
by taking a look at that, I realized when the request is sent, the application will use external commercial proxies to send the request for most of the requests of course, except for (1%) direct which means only one from Digitalocean.
so by doing a simple calculation :
5 + 5 + 20 + 1 + 5 + 25 + 1 = 62
1/62=0.016
Direct = 0.0016 Approximately we have 1% or less to get the correct request.
Fortunately, SerpApi is doing circulation on the proxies despite the percentage until the targeted URL will work or it will continue repeating the requests.
Impact and severity
This vulnerability has high availability and low complexity.
Due to these facts, I can consider the severity critical.
The impact here is unauthenticated SSRF, that could be escalated to ATO by chaining it with XSS — The attacker can exploit the SSRF to send internal requests to access the Digitalocean metadata API.
Report Timeline
-Reported on March 4, 2021- at 4:18 AM.
-Triaged on March 4, 2021- at 6:37 AM.
-Fixed on March 4, 2021- at 7:24 AM.
-Fix confirmation on March 4, 2021- at 9:00 AM.
Ending
Follow me on Twitter to be posted about my latest articles: @alaa0x2
You can also follow SerpApi, LLC. on Twitter: @serp_api
To report a security vulnerability you can send it to contact@serpapi.com
