Bughunting Weekdays: Another Facebook Vulnerability
December turned out to be the most successful for me in four years of participation in various bug bounty programs, and I would like to share information about one of the detected vulnerabilities. It will be about unsafe processing Request-URI ( Request Target ). This time, Facebook was pleased with the beautiful combination of vulnerabilities.
Developers are used to not trusting the data received from the user through the GET / POST / Cookie parameters, but often ignore the fact that dangerous data can be contained in other parts of the HTTP request, for example, in the script path or path_info. To automate the detection of such problems, a small plugin for Burp Suite was written, which listens to all Burp Proxy requests and, if the URL is in a certain scopa, repeats the original request, changing only the Request-URI.
That is, for the request:
GET /foo/bar.baz?param=value HTTP / 1.1
Such replays will be sent:
GET /3fb5e7a4f814d790'"<>/%2e%2e/foo/bar.baz?param=value HTTP / 1.1 GET /foo/3fb5e7a4f814d790'"<>/%2e%2e/bar.baz?param=value HTTP / 1.1 GET /foo/bar.baz/3fb5e7a4f814d790'"<>/%2e%2e/?param=value HTTP / 1.1 GET /foo/bar.baz/3fb5e7a4f814d790'"<>?param=value HTTP / 1.1
If the HTTP response contains a random string from the request or the text of any error, the request is added to the log, which is then manually parsed. As a list of errors, you can use a slightly modified list from fuzzdb .
')
It looks like this:
Like many other interesting and unexpected vulnerabilities, I discovered by chance on Facebook. When I participated in the bug bounty programs from Yandex and Mail.ru, on one of the visited pages was a request to the script
www.facebook.com/tr www.facebook.com/tr (script related to advertising for websites ). This request was successfully verified by the plugin and an entry was written to the log about the output of the Request-URI in the HTTP response.GET / test /% 2e% 2e / tr HTTP / 1.1 Host: www.facebook.com HTTP / 1.1 301 Moved Permanently Location: /test/../tr/
First of all, with this answer, you need to pay attention to the following points:
1) Request-URI is at the beginning of the link for redirection, it means you need to check Open Redirect via URL without specifying the http-scheme (for example,
Location: //evil.com/../tr ).2) The path was not normalized, but the points in the response passed URL-decoding, so there could be CRLF Injection by decoding the characters
%0d%0a .We check the following requests:
GET //////www.google.com/%2e%2e/tr HTTP / 1.1 Host: www.facebook.com HTTP / 1.1 301 Moved Permanently Location: /www.google.com/../tr/
Facebook successfully cuts the initial “/” to one, but since we have URL decoding, this is easy to do in the following way (many web servers extremely dislike using URL-coded “/” on the way, but this time they are lucky):
GET /%2fwww.google.com/%2e%2e/tr HTTP / 1.1 Host: www.facebook.com HTTP / 1.1 301 Moved Permanently Location: //www.google.com/../tr/
To prevent the browser from normalizing the path and cutting out the added construct when sending a request, it is necessary to encode the rest “/” as well. As a result, the first exploitation of the detected vulnerability was obtained.
Open Redirect:
www.facebook.com/%2fwww.google.com%2f%2e%2e/trWe check the assumption of the presence of CRLF Injection / HTTP Response Splitting and we are very surprised that on Facebook, exhausted by thousands of bug hunters, you can also find such.
GET /% 0aSet-Cookie: xxx = xxx% 0aX: /% 2e% 2e / tr HTTP / 1.1 Host: www.facebook.com HTTP / 1.1 301 Moved Permanently Location: / Set-Cookie: xxx = xxx X: /../tr/
CRLF Injection:
www.facebook.com/%0aSet-Cookie:xxx=xxx%0aX:%2f%2e%2e/trAt this point, I already wanted to write a report to Facebook, but the thought of getting the cherished alert ('XSS') did not give rest. The main problem was that despite the ability to rewrite the body of the HTTP response via CRLF Injection, the browser will not display it due to the fact that the injection is in the response with the code 301 and the correct Location header. The author of the article about XSS in Habrahabr faced a similar problem.
Of course, this CRLF Injection is not useless and you can try to use it in combination with other vulnerabilities such as Session Fixation or to bypass any checks of cookie values ... But I suddenly remembered that I already asked a similar question two years ago and even received some results. In some cases, it is possible to block the redirection and display the response body, spoiling the value of the Location header.
As you can see, all the methods found are based on controlling the start of the URL to redirect. That is, if the Location header starts with an absolute link
www.facebook.com www.facebook.com , it would completely kill the opportunity to exploit XSS.Let's unite all received ideas. Due to the Open Redirect described at the beginning, you can specify an incorrect port in the link without specifying the http scheme. This will block the redirection and Firefox will display the body of the HTTP response, which, in turn, can be changed via CRLF Injection. You also need to disable X-XSS-Protection and set the correct Content-Type and Content-Length values.
And the final exploit:
www.facebook.com/%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/script%3e%2F..%2F..%2F..%2F../tr
Information on similar topics:
Source: https://habr.com/ru/post/247709/
All Articles