Blind SSRF on Google Cloud Acquisition (Apigee)

What Exactly SSRF is :

Yeah i know for everyone this theoretical introduction is boring but we just need to know what exactly it is. Let me define in our own terminology. For suppose i wanna scan some target but don’t wanna detected by their poor firewall/waf or their forensic investigation team. What exactly we do for that either we use some sort of ip spoofing or some other masking techniques right. But how far we are secure. Even those proxies that we are using are exposed at some level. The best way to do this is using advantage of SSRF – Server Side Request Forgery. 

SSRF – Leveraging a vulnerable end point in some middle application to scan our target on behalf of us.

Initial Request from Attacker ——–> Vulnerable Application ——-> Target Application

[Hey please scan 22 port of Target]——> [Ok boss i’ll do it] ————> [Ohh sorry port is closed]

[It’s ok look for other ports] <————– [Sorry boss port is closed] <—— [I’ve some error msg for you]

In the above scenario Attacker masked his ip as request logged in Target Application is of Vulnerable Application. In this way we can perform Server Side Request Forgery Attack.

How you started with Google VRP [Vulnerability Reward Program]:

This is the first question i got from so many hunters around. So decided to give a quick intro. After 5 months of my bug hunting experience with several hall of fames and rewards thought of hitting bit targets such as Twitter, Google and Yahoo. Started hunting twitter but no luck ended up with duplicated reports and no use. Later i decided to switch to some other big target such as Google and came to know it is already running VRP program and bunch of security researchers benefited from this program.

Just checked with their rules, reward classification at Google VRP and decided to take a look. Whenever i start hunting i’ll look for their acquisitions or subdomains. My favorite Crunchbase given me full list of Google Acquisitions and started with their cloud service Apigee

Within an hour based on their login and Oauth methodology identified an Open Redirection. My bad it’s actually out of scope for Google VRP Program. Looking around the application and after sometime thought of looking for some URL endpoints which actually disclose local files and read remote files or some other SSRF related vulnerability.

Without much delay identified API Proxy configuration settings which will actually load WSDL file from URL.

Whenever i see some URL endpoint below things will blink on my mind.

1. Local File Inclusion (LFI)
2. Remote File Inclusion (RFI)
3. Server Side Request Forgery (SSRF)
4. XSS via Data URI and so on.

Tried quickly with http://mytestserver:4444/test.wsdl

And below error message from Apigee Server told me that there exists an open port on this IP but there is no wsdl file exists.

Fetch WSDL Error: Could not download resource.

Again for confirmation tried with http://mytestserver:closedport/test.wsdl now there is different error message from server.

Fetch WSDL Error: Could not download resource. Connection to http://mytestserver:closedport refused.

Then my reaction is like

Reported to Google Security Team and the response was.

Hi,

Thanks for your report. It looks to me like internal addresses are always refused, even if a public domain resolves to an internal IP. So, I think this can only be used to scan the internet, which is out of scope for the VRP. Please let me know if you were able to access any internal IP.

Regards,
 Gabor, Google Security Team

After that i tried to see their internal ports whether same thing is possible or not. But my bad luck there exists mitigations in place.

http://localhost:allports ———-> blocked
http://127.0.0.1:allports ———-> blocked
http://0.0.0.0:allports ———-> blocked

 

Long Long ago read about SSRF Bible Cheat Sheet by oNSec Labs. So tried to bypass their mitigations.

Tried again with

Dotted Decimal — Failed

Dottless Decimal — Failed

Dotted Octal — Failed

Dottless Octal — Failed

Dotted Hex — Failed

Dottless Hex — Success

Bingo ! Server forgot to block my input at this time with Dottless Hex formatted ip and port combination.

http://0x7f.1:22 ——–> Connection Reset – SSH Port Open

http://0x7f.1:111 ——-> Connection Reset – RPC Bind

http://0x7f.1: 8301 —–> Couldn’t able to download file – Amberon

http://0x7f.1:9000 ——> Couldn’t able to download file – Cslistner etc etc.

But not really happy with just port scanning it’s clearly describing very low impact as Bug Bounty Programs will resolve reports based on impact level. Thought to do something more here. Digging around and Found some other misconfigurations.

  1. Internal File Existence Detection
  2. Denial of Service via Service Pool Consumption with help of External Service Interaction

At first glance i tried to retrieve the file:///etc/passwd but no useful information retrieved except an error message. Then thought of taking a look on it and able to identify the existing files/folders in server with this error message.

file:///etc/passwd ————> Unexpected character ‘#’ (code 35) in prolog; expected ‘<‘\n at [row,col {unknown-source}]: [1,1]

file:///nomore/exists ———-> There was an error processing the WSDL

Based on above error messages i came to know it’s possible to identify certain files/folders existence in server.

It seems that apigee servers have VERY long timeout for their WSDL Requests. An attacker can use iptables’ TARPIT target to block requests for a prolonged time and http:// protocol which never timeouts.

An attacker can keep server’s port listen on his own port.

https://apigee.com/ws/bughunter5672-trial/wsdl?uri=http://[attackerhost]:[anyport]

In this case, apigee will open an HTTP connection from its servers (apparently due to retries) and keep it open for a long time (more than 5min’s). An attacker can initiate lots of url requests to exhaust apigee servers’ resources.

Reported again and Team Responded like

Hi Mr.R3boot,

Nice catch! I've filed a bug based on your report. The panel will evaluate it at the next VRP panel meeting and we'll update you once we've got more information. All you need to do now is wait. If you don't hear back from us in 2-3 weeks or have additional information about the vulnerability, let us know!

Regards,
Michael J., Google Security Team

After two weeks they’ve replied with acknowledgement and got listed in Google Hall of Fame.

Hope you loved the post and learned something from this.

2 Comments

Leave A Comment

Your email address will not be published. Required fields are marked *