Used to bypass the posture formed SSRF acquiring India's biggest stock broker company AWS password credentials-vulnerability warning-the black bar safety net

2019-05-15T00:00:00
ID MYHACK58:62201994163
Type myhack58
Reporter 佚名
Modified 2019-05-15T00:00:00

Description

Hello everyone, today share of it is the author in response to India's biggest stock broker company for security testing, by different levels of the bypassing techniques Bypass, and eventually acquired the company AWS password credentials in the process. Where to WAF bypassing, as well as further Web Cache bypass, to achieve the SSRF attacks, and finally get to the target system AWS password credentials. This article published has been obtained the stock broker company license. ! Found WAF protection The test just started, I noticed that the target system of a service path to the Endpoint will be with some of the background of the file system interact, so next I would naturally test a local file inclusion vulnerabilities LFI, after discovery, the target system applied by the Cloudflare WAF firewall protection. As follows: ! CloudFlare is a DNS, WAF andDDOSprotection of cloud security vendors, which provide the security services may well hide the target website's real IP and play CloudFlare's security filter capability, the target site system play a protective role. Typically, the attacker does not know the server's real IP, it is difficult to directly on the target system to initiate the attack. However, the attacker also often to some indirect method of finding the target web site's real IP, in order to bypass the CloudFlare WAF more than the CloudFlare WAF bypassing the case please themselves Baidu to. Based on this deployment architecture, the Web application server, the client initiates the request to go through the CDN, WAF or load balancing, etc. of the intermediate layer proxy device, in order to really reach the back-end server. So, essentially, if you know the target system's real IP, I initiated the request is not in the back-end load balancing, or server filtering white list, then we can directly with the application back-end servers to interact, so that you can bypass the CloudFlare WAF. The logic is as follows: ! To bypass the WAF protection, but the case on the caching services Web Cache) Of course, here we want to first discover the target application system's real IP, I simply perform a “dig www.readacted.com” command, I find: ! After that, I was in the local hosts file, adds a real IP and a domain name corresponding to the entry, see the domain access changes, it is possible, then, we combine the above LFI vulnerability situation to try password read. When in the URL after the/etc/passwd command after the execution, actually lucky to get the following valid response: ! So, just like that, I'll easily bypass the CloudFlare WAF and implements LFI vulnerabilities. Next I Whois the IP after the discovery, it is an AWS service architecture. The idea here, I think the next goal is to see if you can achieve the SSRF and then read out one of the AWS account's password credentials. Because according to the AWS a specific page or URL function deployment point of view, it is possible to get to the appropriate account and password information, I hope so to. Not much long-winded, I flew to the target application system identity, in the URL after the link, for AWS official instances metadata instance – http://169.254.169.254/latest/meta-data/, initiated a GET request, as follows: ! The application back-end server to the request response is 200 ok but Response content is empty, as follows: HTTP/1.1 200 OK Server: nginx Date: Fri, 06 Apr 2019 14:32:48 GMT Content-Type: text/css;charset=UTF-8 Connection: close Vary: Accept-Encoding Strict-Transport-Security: max-age=15552000 X-Frame-Options: DENY X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block X-Proxy-Cache: HIT Content-Length: 0 This indicates that the interaction does occur, but why response is null? See the above response message, can be found, wherein the server header as“nginx”, in addition there is also a value for the HIT X-Proxy-Cache. That is, we initiate the request met the middle of the Nginx caching service and the caching service to our response to the empty message. Bypass the Web Cache to achieve the SSRF get AWS password credentials So, from this point of view, in order to get to the real application service end response, it is necessary to bypass the Nginx cache service. To this end, I further understand the Nginx cache is the URL of the page cache rules. https://www.digitalocean.com/community/tutorials/how-to-implement-browser-caching-with-nginx-s-header-module-on-centos-7 https://www.howtoforge.com/make-browsers-cache-static-files-on-nginx After learning, I learned the usual cache service is a URL-path routing as the basis, so, if the request URL is: https://somewebsite.com/a.html and with the caching rules in the routing path match, then, it will be the introduction of the caching service, from which to obtain a response. But if the request URL is: https://somewebsite.com/a.html?, the And with the caching rules in the routing path do not match, then the request will be via a caching service, but will directly from back-end application server to obtain the response. So, I read in the AWS official of the instance metadata of the request at the end also added a“?” Question mark, of course, other symbols can also be, and so - http://169.254.169.254/latest/meta-data?, the So this request would be inconsistent with the Nginx cache matching rules. Then we look at such a request, the backend application server will not give a response. http://169.254.169.254/latest/meta-data?为从运行实例内部查看所有类别的实例元数据请求 to:

[1] [2] next