Hey hunters!

Another write-up talking about my mindset while hunting on a program with a new vulnerability in another big program. Before we start let’s see what we gonna discussing in this write-up:

• My mindset while hunting in Yandex
• Thinking dynamically
• Some google dorking
• Intro to SSRF’s
• Code reviewing
• HTTP Header Based SSRF
• HTTP Interactions

Note: I got the permission from Yandex team to write this write-up, so It’s totally legal:

So let’s start…

Fixed mentality in penetration testing field makes you thinking less, because you always need to bee creative, for example every target should have It’s own method in recon, testing …etc. Because every target get It’s own functionalities services and workflows. In my target here which is Yandex first i started my Information gathering about it, and according to my researches I’ve found that Yandex providing the following services:

• Search Engine
• Cloud Services
• Mail Services
• E-Commerce
• Advertising
• And other Internet-related products and services

So It’s not a regular target, It’s a really huge target, now after performing my Recon — I mentioned It In previous write-ups and In my Github Repo — So I Started with GHDB in order to finding some secrets, but because the huge services that this target provides If I typed some dork like this:

site:*.yandex.* intext:"access_token"

First of all what this dork do ? this dork will give me the whole results with all the subdomains and Tob-Level-Domains (TLD) for Yandex In order to make my hunting scope wider, So after typing this dork you will get the following results:

For the first time you will be very happy because you think that you’ve found an access_tokens, but hold up kid, It’s just a documentations because as I said Yandex provides cloud services.

So what to do if you face something like this, If you got a fixed mind you should search for another secret but that’s wrong, you should craft a dork in order to exclude the Cloud subdomains from the search results, So I’ve crafted the following dork:

site:*.yandex.* intext:"access_token" -site:cloud.*

This dork will exclude any —sub domain — for cloud service, so you will not see any cloud service subdomains anywhere:

You can also exclude the cloud phrase from the URL only, by using the dork which i craft:

site:*.yandex.* intext:"access_token" -inurl:cloud

So I think this will be good too, but as you can see another docs and docs!, so what can I do now hmm.

I got an idea, what if i started searching about an exposed server indexes, so i can start digging for any new secrets, so that i crafted the dork:

site:*.yandex.* intitle:"index of"

And i get the result:

So before talking about this if you’re familiar to hunting in some bug companies like Facebook, so you know that every company got it’s mirrors to store It’s software, operating system that they use and another files may not be sensitive but some times we can gather some Info’s about the internal infrastructure of this company, so in my case all the results was like a mirrors only, so i tried to search more advanced using the dork:

site:*.yandex.* intitle:"index of" intext:"passwd"

So let me explain something now, analyzing the results before entering the results is very important because you get a background about what did they host handles, so here as you can see all the extensions was like:

• tar.xz = Compressed file
• deb = Debian package
• apk = android package

Plus if you take a look about about the paths they will be like:

So all of these path’s stored the base file for a distribution or Linux libraries, but let’s enter any of these targets:

Lets’ try downloading any file let’s say the file:

libauthen-simple-passwd-perl_0.6-4.1.dsc

And starting our analysis on it:

So this is just a file for verifying the signature for every lib file, in our case we got the lib: libauthen and as we can see their web app was:

https://metacpan.org/dist/Authen-Simple-Passwd

After reviewing this lib It’s just a library for authenticating the passwd file:

Then I think this will not benefit us a lot because these are mirrors just store some libs and Linux distros for the public use, now let’s jump back and start specifying our result by crafting a new dork:

site:*.yandex.* intext:"id_rsa" -inurl:cloud|mirror AND intitle:"index of"

This will search for any id_rsa file and excluding and cloud or mirror from the URL and finally searching for any HTTP title get the word index of , somebody will ask why I excluded cloud from this while searching about id_rsa ? simply because this will appear in every cloud domain/service because when you gonna make a host and for example will connect using the SSH for controlling the Server you should have two files:

• id_rsa.pub => public key for encryption
• id_rsa => private key for decryption

And in most cases, this will appear a lot in the docs, Note: the id_rsa may not exist but instead of this you can search for id_dsa according to the encryption that your target uses, so after crafting my dork, i got the result:

So i decided to stop dorking for now and automate the dorking process after i knew what are the Infrastructure for this target so I knew what are the dorks should I craft and Jumped into the next step, Before starting the next step which is exploiting and finding let’s talk a little about SSRF — Server Side Request Forgery —, Take a look about the following code:

Now to explain how the SSRF happened I’ve coded this simple Web Page, now let’s try reviewing every block of code:

First here this is a simple PHP code doing the following in the Back-End system:

• It stores the GET parameter: Proxy-Host in a variable name: host
• Then it checks if the parameter: Proxy-Host Is exists in the request and If this parameter Isn’t got a False value.
• After this it read a remote host and start Crawling It’s contents using While loop in order to still Crawling It’s content till the transmission ends.
• Final It’s close the fopen session.

Now the second part:

Finally because of my Global Variable which is in my PHP code, now this HTML code will import the CSS sheets and JS Scripts from the remote host, and the response of the requested host will be showed in the innerContent div.

Now let’s see how the server will perform this:

So as you can see when the client accessing a URL like: https://vulnerable.com/File.php?Proxy-Host=https://example.com the server will take this request and the back-end coded will make — Server — Send a request to the host specified in the Proxy-Host parameter, so now the vulnerable server send a request to another request.

Now let’s see how can the attacker attack this functionality:

Now the attacker know that the server doing the requesting operation with It’s self, so he thought of requesting internal resource like: http://localhost and If the server is vulnerable It will give you a response with internal server contents.

Tip: some times when you type common things like: http://localhost, the server will block it because It Is in the server black-listed chars, so you can seek for any host refers to localhost or endpoint while you’re hunting. for example in one of my hunting trips i was turned the apache2 server opened in my device locally, so when I’m gonna accessing the remote target URL such as: http://target.com, i see my localhost is being viewd. So this means that this host is refers to localhost then save it to use when seeking for SSRF in this target or another target.

So now there is also SSRF happened because of Injecting HTTP headers such as: X-Forwarded-Host and X-Forwarded-Host , so in my case the SSRF was in HTTP header, So how i was able to find it? There is tow ways of automation to perform this:

1. Using burp intruder with a good HTTP headers list, with giving this headers a value with Burp Collaborator or a server for getting the Request into it to check the SSRF.
2. Using Nuclei template scanner to perform this using the template: ~/nuclei-templates/extra_templates/header-blind-ssrf.yaml , as you can see the template says this SSRF is a blind SSRF but this Isn’t always because in my case It was a Basic SSRF, Before using this template let’s identify how it works:

So let’s try analyzing this:

1. payload section:

• header: here are the HTTP headers wordlist which being used in brute forcing the HTTP request.

2. raw section:

• /?&header&It sets the HTTP header in GET request in order to make the user aware of what HTTP header is used now.
• &header& It sets the headers is being used now in the request
• {{interactsh-url}} the URL which used to identify the interactions

Finally after doing my automation using nuclei i was able to find the SSRF in Yandex using the request:

GET / HTTP/1.1
Host: example.vulnYandex.tld
User-Agent: someDevice
Accept: text/html
Accept-Encoding: gzip, deflate
Proxy-Host: burpcollaporator-url.net
Connection: close

So as you can see the exploit was in the header: Proxy-Host and i get an HTTP interaction like this:

Then i wanted to make sure that this interaction happened from the Yandex servers, so i did a Reverse DNS using the command:

host -t PTR 1.1.1.1

Instead of 1.1.1.1 put the IP that identified by the Collaborator, then i set the result:

I though of accessing internal resources in order to escalate the impact, but when i took a look to Yandex’s policy I find:

Note: I was able to perform Internal Port Scanning, but due to the Yandex Policies I should ask them before accessing Internal Data, so I send the report then asked them to made me escalate the impact but they confirmed the SSRF and will do this Internally:

So i report this vulnerability and wait for the team, and wait for them if they wanna me continue exploiting it or they will review it internally, and they did continued it internally.

Finally: