Various SSRF conditions on KeyCDN tools
Hi There,
It is common to find websites/tools on the internet which performs speed test, loading third party images, load external JavaScript files etc. to be vulnerable to Server Side Request Forgery. I've found a couple of them, reported but some of them did not take it seriously. I've recently ran into KeyCDN tools website, a site owned and operated by KeyCDN, a CDN company and reported to be one of the best solution according to the TechRadar info. After looking at some functionalities presented on the web site I've found a few SSRF conditions. Here it goes:
1) Using the Trace Route utility to discovery some Internal IP Address
When I used the Trace Route functionality there was an internal IP address 10.0.10.1 (which seems no longer there) belonging to the Frankfurt POP.
2) Using the Ping utility to confirm the above finding (and maybe Brute Force some hosts?)
I will discuss the FQDN you are seeing there soon!
3) Using the Performance Test utility to verify Frankfurt web server as a PoC:
As you can notice, when requesting http://test.10.0.10.1.nip.io/robots.txt there is an HTTP 200 Status Code :)
4) Using the Website Speed Test utility to render Frankfurt web server response as a PoC:
What was interesting here is the URL field always required a FQDN, so it was not possible to simple load http://10.0.10.1/robots.txt. In order to bypass this the nip.io service was used. The way it works:
NIP.IO allows you to map any IP address in the following DNS wildcard entries:
10.0.0.1.nip.io maps to 10.0.0.1
test.10.0.10.1.nip.io maps to 10.0.10.1
Pretty handy, no?
5) Verifying some files using HTTP Header Check utility:
The URL parameter was accepting file:// as an URI scheme. Apparently under the hood curl is being used and as it also supports file URI scheme, I am just fine :)
The above example shows the request to file:///etc/passwd. The HTTP Response Header section was presenting the result.
Responsible Disclosure
I've reported all the details using their Security Bounty Program, however, after 3 days later they responded to my report telling me they were aware of the SSRF problems. That's OK.
Interesting tough they fixed everything 3-4 days later :) Mission accomplished.
Initial Report: 10/20/18
Vendor Response: 10/23/18
Vendor Fixed: 10/24/18
It is common to find websites/tools on the internet which performs speed test, loading third party images, load external JavaScript files etc. to be vulnerable to Server Side Request Forgery. I've found a couple of them, reported but some of them did not take it seriously. I've recently ran into KeyCDN tools website, a site owned and operated by KeyCDN, a CDN company and reported to be one of the best solution according to the TechRadar info. After looking at some functionalities presented on the web site I've found a few SSRF conditions. Here it goes:
1) Using the Trace Route utility to discovery some Internal IP Address
When I used the Trace Route functionality there was an internal IP address 10.0.10.1 (which seems no longer there) belonging to the Frankfurt POP.
2) Using the Ping utility to confirm the above finding (and maybe Brute Force some hosts?)
I will discuss the FQDN you are seeing there soon!
3) Using the Performance Test utility to verify Frankfurt web server as a PoC:
4) Using the Website Speed Test utility to render Frankfurt web server response as a PoC:
NIP.IO allows you to map any IP address in the following DNS wildcard entries:
10.0.0.1.nip.io maps to 10.0.0.1
test.10.0.10.1.nip.io maps to 10.0.10.1
Pretty handy, no?
5) Verifying some files using HTTP Header Check utility:
The above example shows the request to file:///etc/passwd. The HTTP Response Header section was presenting the result.
Responsible Disclosure
I've reported all the details using their Security Bounty Program, however, after 3 days later they responded to my report telling me they were aware of the SSRF problems. That's OK.
Interesting tough they fixed everything 3-4 days later :) Mission accomplished.
Initial Report: 10/20/18
Vendor Response: 10/23/18
Vendor Fixed: 10/24/18
Comments
Post a Comment