In the past few months, I have been seriously preparing for the 2017 America the Black Hat hacker conference and DEF CON 25 lecture content, and become a Black Hat and DEFCON speaker has always been in my life a very important goal. In addition, this is also my first time in such a formal occasion under English speech, this is definitely one worth remembering and be able to brag for a lifetime! In this article, I will give you a brief introduction of my speech content. Here the use of technology, although not what new technology, but these old technologies are still very powerful. If you're on my presentation interested, you can click【here】to obtain the slides. Note: slide describes a lot about SSRF(Server-Side Request Forgery:server side request forgery) is a powerful new method. Went straight to the theme In this article, I will tell you how the four vulnerability in series and the final on GitHub to achieve remote code execution. It is worth mentioning that this vulnerability report was also awarded the GitHub of the third session of the vulnerability rewards anniversary of the award in the best vulnerability report. In my last article, I mentioned a new goal - GitHub Enterprise Service GitHub Enterprise Edition, and I also describes how anti-aliasing GitHub Ruby code and how to find out which the presence of theSQL injectionvulnerabilities. After that, I found that there were many Bounty Hunters also begin to turn your attention to the GitHub Enterprise Service of the body, and also found a lot of interesting security vulnerabilities [reference vulnerability a】【reference vulnerability the second button. Saw these It after, I'm very irritable, and why I had not found these vulnerabilities?? Therefore, my own dark mind to, I have to find a high-risk vulnerability! Vulnerability description In I check the GitHub Enterprise Service architecture before, my intuition tells me, GitHub Enterprise, there is also a lot of internal services. If I can take advantage of these internal services, I believe that I can definitely find a lot of interesting things. Next, all the attention I will put in the SSRF(Server-Side Request Forgery:server side request forgery) vulnerability of the body. The first vulnerability-harmless SSRF Looking for GitHub Enterprise vulnerabilities in the process, I discovered a man named WebHook functionality. This feature is very interesting, when there is a specific GIT command, it allows us to set a custom HTTP callback. You can use the below given URL address to create an HTTP callback:
https://///settings/hooks/new Then by submitting the file to trigger the callback. Next, GitHub Enterprise will be via a HTTP request to notify the user. Given below Payload and HTTP request sample: Payload URL:
http://orange.tw/foo.php Callback request: POST /foo.php HTTP/1.1 Host: orange. tw Accept: / User-Agent: GitHub-Hookshot/54651ac X-GitHub-Event: ping X-GitHub-Delivery: f4c41980-e17e-11e6-8a10-c8158631728f content-type: application/x-www-form-urlencoded Content-Length: 8972 payload=... GitHub Enterprise uses the RubyGems faraday to obtain external resources and prevents the user through the Gem faraday-restrict-ip-addresses to request the internal services. Here, the Gem is like a blacklist as much as we can through RFC 3986 defined rare IP address formats, Rare IP Address Formats to circumvent this blacklist. In Linux system, The"0"stands for"localhost". PoC: the
http://0/ Very good, now we've got a SSRF vulnerability. However, we still can't do anything, why is this? Because of this SSRF with the following restrictions: 1. Supports only the POST method; 2. Only running HTTP and HTTPS mode; 3. There is no 302 redirect; 4. faraday did not CR-LF command injection; 5. Can't control the POST data and the HTTP header; The only thing we can control is which Path section. But it is worth mentioning that the SSRF vulnerability can cause a denial of service attack DoS is. On GitHub Enterprise, the port 9200 bind a elastic Search service in the background using the shutdown command, the service does not care where the POST data is exactly what content. Therefore, we can freely to it's REST-ful API to operate! A denial of service attack PoC of:
http://0:9200/_shutdown/ A second vulnerability-the internal Graphite in SSRF We've got a SSRF vulnerability, but this vulnerability is to limit so much, and want to directly use it to estimate can be difficult, so next I intend to find out whether there are other internal services can be we use. It's a big project, because in the GitHub Enterprise, there are a lot of HTTP services, and each services is likely to are using a different programming language, such as C/C++, Go, Python, and Ruby, and so on. In the study several days after, I found a man named Graphite a service, the service binding port number is 8000 of. Graphite is a highly scalable real-time graphics system, and GitHub is required to use this system to give the user a display of some graphical statistics. Graphite the use of Python language development, and it itself is also an open source project, you can click【here】to obtain Graphite project source code. Read the Graphite source code, I quickly found another SSRF。 The second SSRF is relatively simple, this vulnerability exists in the webapps/graphite/composer/views. py file: def send_email(request): try: recipients = request. GET['to']. split(',') url = request. GET['url'] proto, server, path, query, frag = urlsplit(url) if query: path += '?' + query conn = HTTPConnection(server) conn. request('GET',path) resp = conn. getresponse() ... You can see that Graphite would accept user input the url address, and then direct the resource request! So, we can use the first SSRF vulnerability to trigger a second SSRF vulnerability, and they are the two vulnerabilities are combined into a SSRF implementation chain. SSRF execution chain Payload: http://0:8000/composer/send_email? to=orange@nogg& url=http://orange. tw:12345/foo The second SSRF request: $ nc-vvlp 12345 ...
GET /foo HTTP/1.1