Blind SSRF in Skype (Microsoft)
Server Side Request Forgery is a vulnerability that allows attacker to make server request to attacker controlled network location/path.
While analyzing requests in Burp for Skype for Web, found a endpoint at *.*.skype.com/path?url=https://example.com , As the url param appeared interesting tried to change the url with my ngrok instance & got a hit !
Confirmed that it’s Skype which hit the url by looking at the ngrok inspect web console by verifying received User-Agent header(Skype)and IP address in who.is.
Although I was able to make the server hit arbitrary webpage, I couldn’t get full response. I could only get status code, content-type, content-length(size) of response and text content from few selected HTML tags. That’s, it’s not full SSRF as expected, but is a blind/partial SSRF.
Tried to access below paths —
- localhost/internal ip address -> Failed
- Tried to bypass localhost/internal ip address using url redirect/url shortner methods -> Failed
- External ip address/webpage -> Success
- Common Azure/AWS/DigitalOcean Meta data IP addresses -> Failed
- Not so commonly used, Azure related IP address (168.63.129.16) -> Success -> This IP can be used to determine VM’s health by using http://168.63.129.16/metadata/v1/maintenance endpoint, which should return OK (200 Status Code) if VM is functioning. (Refer this for more information)
Tried changing url param value to http://168.63.129.16/metadata/v1/maintenance , got 200 Ok response, with size of response as 2 bytes which confirms that response text probably contains OK in response.
Made a nice report mentioning all the details and sat back waiting for Microsoft to reproduce and fix the report.
Fortunately this was in scope for bounty under the M365 Bounty Program and got a nice $$$$ bounty !
Report Timeline:
- Reported — Sep 23, 2022
- Additional Details Updated — Oct 3, 2022
- Bounty Rewarded — Oct 8, 2022
- Fixed — Oct 12, 2022
