Monday, November 5, 2018

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














Thursday, September 27, 2018

Make-HtDigest - a tool to audit password files for WildFly / JBOSS / Apache

Hi there,

I've created a tool called Make-HtDigest which is able to generate username + password combination based on a word-list for HTTP Digest Authentication. This can be used to compare output with real password files such as mgmt-users.properties from WildFly and .digest_pw from Apache.

I hope it is useful and you enjoy it.

Tuesday, March 6, 2018

A tool to detect Slow HTTP DoS attacks on pcap files

Hello everybody,

I wrote a python tool to detect Slow HTTP DoS attacks on pcap files: slowdos_detector. This is ideal for post-mortem analysis on captured traffic (pcap files). If you are curious about how to test it, you could leverage slowhttptest to launch an HTTP DoS attack on your test server, capture the traffic and then use slowdos_detector to show offending HTTP transactions. Enjoy it and ping me if you have questions, issues or suggestions.

Thursday, January 11, 2018

Signing Requests to AWS on OWASP Zed Attack Proxy - ZAP

Hello All,

I've written a Help Add On Script for the OWASP Zed Attack Proxy to sign requests to Amazon AWS. You can check it here. Enjoy it!



Saturday, September 9, 2017

An introduction to HTTP Security Headers

Hello all,

It is being a while since my last post. March this year I had a talk at the Confraria0day conference about HTTP Security Headers. I made the slides available here. I hope it helps and let me know if you want to discuss it.

Monday, December 12, 2016

Cross-site Scripting (XSS) on Goodreads.com

Recently on an independent research I've found the Goodreads API was vulnerable to a Reflected Cross-site scripting.

The issue happens on their REST API on a callback function parameter. No sanitizing mechanism was found and the parameter is echoed back in the JSON payload, allowing a malicious user to
potentially launch XSS attacks.

I've submitted the issue to the Goodreads' security team and this was quickly fixed.
Goodreads is an Amazon company with  55 millions of users. Their site is ranked 139 in the USA and 336 globally, according to Alexa.

Proof Of Concept:




Vulnerable API calls with XSS payload:

https://www.goodreads.com/book/review_counts.json?callback=%3Chtml%3E%3Cbody%20onload=%22javascript:alert(%27XSS%27)%22%3E%3C/html%3E&isbns=0441172717

https://www.goodreads.com/book/isbn/0441172717?callback=%3Chtml%3E%3Cbody%20onload=%22javascript:alert(%27XSS%27)%22%3E%3C/html%3E&format=json

Vulnerability Disclosure Timeline:
2016-11-11: Goodreads notification
2016-11-11: Goodreads feedback
2016-11-15: Goodreads fix/patch
2016-12-12: Public disclosure