Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to carry out the case study of HackerOne vulnerabilities. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

In the public vulnerability push Hacktivity message of HackerOne real-time update, we can find that the subdomain name hijacking vulnerability (Subdomain Takeover) accounts for a large proportion. Since Detectify Labs released a series of articles on the posture of sub-domain hijacking attacks in 2014, there have been a large number of reporting vulnerabilities related to such problems in the public testing industry.

The basic premise of the subdomain name hijacking vulnerability can be roughly explained as that a misconfiguration has occurred and the corresponding host points to a specific service that is not currently in use, so that the attacker can declare the takeover rights to the subdomain by registering an account in that particular third-party service, thus deploying network services on the subdomain to achieve the purposeful use of the subdomain.

Today, I'm going to talk to you about the understanding, mining, exploitation and reporting of subdomain name hijacking vulnerabilities caused by misconfiguration of subdomain names. This article assumes that readers have some knowledge of DNS and the basis of subdomain name settings.

Introduction to hijacking vulnerabilities of subdomain names

If you can't solve the subdomain name hijacking vulnerability before, and you want to start with the basic principles, I have designed a simple example scenario here. In this scenario, suppose example.com is the target website where you participate in vulnerability testing. After enumerating all the subdomains of example.com, you find one of the subdomains, subdomain.example.com, which is misconfigured and points to a GitHub page. Therefore, we can first take a look at the DNS record of the subdomain name. Here, it is assumed that there are multiple A records pointing to the specific IP address of GitHub on the GitHub page to which the subdomain name belongs:

$host subdomain.example.comsubdomain.example.com has address 192.30.252.153subdomain.example.com has address 192.30.252.154$ whois 192.30.252.153 | grep "OrgName" OrgName: GitHub, Inc.

After the web page visits subdomain.example.com, we can find the following 404 response pages:

When you see this, most white hats may feel hopeful. This 404 page indicates that no web content has been registered and deployed under the top-level root of the domain name corresponding website, so we can try to register and take over the subdomain name as our personal GitHub library. However, please note that this does not mean that all corresponding domain names have hijacking vulnerabilities. Because some domain name applications may also need to check the specific HTTP and HTTPS responses to determine the domain name control permissions, while other domain names do not have hijacking vulnerabilities.

Here, suppose there is a subdomain name hijacking vulnerability. When we add this subdomain to our personal GitHub project, we can deploy it to our own Web content, that is, we can take over the subdomain as our own. You can have subdomain.example.com point to any web content you deploy as follows:

Hijacking vulnerability of second-order subdomain name

The second-level subdomain name hijacking vulnerability mentioned here is a bit like expired bad chain hijacking (Broken Link Hijacking). In this case, the subdomain name is not owned by the target website, but it is used to run the web content of the target website. That is, if a resource in the page content of the target site needs to be imported from an external third-party resource, for example, like a js file, then an attacker can import it through the Blob object type of JavaScript, thus declaring control over the relevant subdomain names of the target site.

This kind of host hijacking in web pages can lead to storage cross-site vulnerabilities, and attackers can use this mode to load arbitrary client code for the pages of the target website. I put forward this threat here in the hope that our imagination will not be limited to sub-domain names, but can also be extended to code review and host mapping of target sites.

For example, in the website shown below, there is an imported third-party resource http://subdomain.example.com/script.js, so can subdomain.example.com be hijacked so that I can transform script.js to indirectly hijack example.com?

Of course, it is also important to note that if you want to hijack the domain name of a subsite, you can take some time to see if the third-party imported resources on the various pages of the site can be hijacked.

Subdomain name enumeration and probe

Now that we have a general idea of how to deploy our own web content on misconfigured subdomains, I'll introduce the techniques, techniques, and tools for finding leaky subdomains.

Before going any further, we need to distinguish between Scraping and Brute Forcing, because both methods can help you find subdomains, but the final results are different. Retrieval is a passive detection method that uses external services and resources such as DNS Dumpster and VirusTotal to collect subdomains belonging to a particular host. This method can quickly retrieve the previously loaded subdomain records in external service resources, which can be regarded as a way of subdomain name discovery without much effort. Such as the reddit.com subdomain name recorded on the following DNS Dumpster website:

Scraping not only contains index pages, but can also be added to the target site's GIT library, content security policy headers, source code, and vulnerability tracking messages. As you can imagine, the search list is very large. I often update my own search list repository, anyway, the more technologies you use, the more strange you will find, and eventually you will find different results. Therefore, from this point of view, when doing loophole testing, we must have the spirit of innovation.

Sublist3r is a simple subdomain name discovery tool for Scraping. It uses lightweight Python scripts to collect target subdomain names from various search engines, SSL certificates, and DNS record sites. The specific installation and application are shown below:

$git clone https://github.com/aboul3la/Sublist3r.git$ cd Sublist3r$ sudo pip install-r requirements.txt

When we violently guess the sub-domain name, we can rely on the dictionary to make an iterative request attempt, and then judge the validity of the sub-domain name according to its response. However, please note that if the target website opens an account in Wildcard mode, you may get a lot of false positives during subdomain brute force guessing.

Pan-domain name mode (Wildcard) means that all subdomain name resolutions may correspond to the same IP address, for example, a.example.com and ctk.example.com will resolve to the same IP address. Using a pan-domain name, you can make the domain name support unlimited subdomains, or prevent users from entering the wrong subdomain name and not being able to access the website. Therefore, at this time, we can resolve a sub-domain name that cannot be used by the target website, and judge whether it can be resolved normally according to its response. If it can respond normally, it proves that it has turned on the pan-domain name mode. As follows:

$host randomifje8z193hf8jafvh7g4q79gh374.example.com

For violent guessing of sub-domain names, I personally think the best way is to create your own guessing dictionary based on your usual accumulated experience or ways of personal interest. For example, I often find a lot of vulnerabilities in Atlassian Jira systems and GIT use cases, so I add related keywords such as "jira" and "git" to the subdomain name guessing dictionary.

If you plan to create a personal subdomain name guessing dictionary, I strongly recommend that you refer to Jason Haddix's dictionary, which has put a lot of effort into merging different lists of sub-domain name discovery tools into an extensive dictionary list.

Fingerprint identification (Fingerprinting)

In order to increase the results of your subdomain name discovery, whether it's Scraping or Brute Forcing, you can use a technique called fingerprint Identification (Fingerprinting), which can be created through a general dictionary of the target site to show those assets that you cannot identify with the normal dictionary list.

Some classic subdomain name discovery tools

Here, I would like to introduce some useful subdomain name discovery tools:

Altdns

This is a subdomain name recursive violence guessing tool developed by Shubham Shah. You need to create a subdomain name dictionary subdomains.txt that exists in the target website, which is your general fingerprint dictionary, and then create a recursive replacement dictionary words.txt, and then use the Altdns command:

. / altdns.py-I subdomains.txt-o data_output-w words.txt-r-s results_output.txt

Make a subdomain generation discovery. I like to use Altdns to generate dictionary lists and then work with other tools to run discoveries.

Commonspeak

Commonspeak is also another tool developed by Shubham, it uses Google's BigQuery query records to generate a dictionary list, which contains the current daily updates of various sub-domain names, very timely and fast. You can learn about Commonspeak's dictionary collection and subdomain extraction mechanisms by viewing this article.

SubFinder

This is a subdomain discovery tool with both Scraping and Brute Forcing. Personally, I use SubFinder more than Sublist3r. SubFinder can find subdomains from various services, including API interface, and the final result is relatively good.

Massdns

Massdns is a very fast subdomain enumeration tool. Other tools may take 15 minutes to complete, but it only takes one minute to use Massdns. But if you want to use Massdns, you must first specify a valid DNS stub parser (Resolver), such as this https://public-dns.info/nameservers.txt, through which host is used for domain name resolution discovery. If you do not update this parser list for a long time, the result may also be false positives.

$. / scripts/subbrute.py lists/names.txt example.com |. / bin/massdns-r lists/resolvers.txt-t A-os-w results.txt process automation

Automation is critical in the process of exploiting subdomain name hijacking vulnerabilities. Top white hat hackers will always pay attention to any changes to the target site for a long time, or keep track of the status of the subdomain name of the target site. In this article, we won't talk about specific tracking methods. Instead, I'll introduce some simple techniques to save some mining and analysis time and achieve a certain degree of automation.

The first automation task I like to use is to filter out real-time valid subdomains from a list of hosts. Because in the subdomain name retrieval method, the final result may be that some subdomain names are expired and some are inaccessible, so we need to detect which host subdomains are valid in real time. Keep in mind that, as the example you will see later shows, although some hosts cannot be effectively resolved, there is also the possibility of hijacking. For automation here, let's use the host command. If a subdomain name does not survive and is invalid, an error message will be returned in response.

While read subdomain; doif host "$subdomain" > / dev/null; then# If host is live, print it into# a file called "live.txt" .echo "$subdomain" > > live.txtfidone < subdomain-list.txt

After abstracting all detection and discovery mechanisms, it can be represented as the following process:

Next, you need to have a general understanding of the sub-domain name. There are two display modes, one is to capture screenshots of all sub-domain websites for running the screenshot script of the sub-domain name, and the other is to store the display content of each sub-domain name website. To take a screenshot of a subdomain name, you can consider the tool EyeWitness, which can generate a HTML file containing screenshot, response header and header information for the target list subdomain.

$. / EyeWitness-f live.txt-d out-headless

Maybe sometimes EyeWitness seems a bit overqualified when you only need to store the content of a simple GET request response page for a subdomain site. At this point, I will use meg, a tool developed by Tom Hudson, which sends a simple request to the target subdomain and stores the response in clear text. Meg is lighter than EyeWitness.

$meg-d 10-c 200 / live.txt Special case

There is also a special case to note. Frans Rose é n mentioned in his speech "DNS hijacking using cloud providers-No verification needed" that if you encounter some dead DNS records (obsolete DNS records), don't ostensibly assume that there is no subdomain name hijacking vulnerability. According to Frans Rose é n, the host command may go wrong, but if you use the dig command, you may find some dead records.

Vulnerability exploitation

Now, suppose you can control a subdomain to which the target site belongs, so what should you do next? When you want to use this misconfigured subdomain to implement some possible attack scenarios, the most important thing is to understand how the subdomain interacts with the core service of the target site.

Cookies

Taking advantage of the subdomain name hijacking vulnerability, the web service is deployed for the controllable subdomain name subdomain.example.com, which can steal the Cookie of the user belonging to the example.com, so as to achieve the purpose of hijacking the victim's session.

Using the online front-end editing site output.jsbin.com, we can edit the settings for cookie. If you make sure that there is a session ID on the target website is the constant attack risk (Session Fixation) https://en.wikipedia.org/wiki/Session_fixation, and you use the cookie of HTTPOnly class, then you can set the cookie, when the victim launches the browser, because of the order of the cookie, your malicious cookie here will take precedence over the other party's newly generated cookie, thus indirectly realizing the hijacking of the victim's identity.

CORS cross-domain resource sharing

Cross-domain resource sharing, Cross-Origin Resource Sharing (CORS), allows Web application servers to control cross-domain web access. In a domain created by the Web application, some websites are allowed to access and extract data information including authentication data according to a set of rules. On the premise that some subdomain names are trusted domain names, some Web applications also allow subdomain names to execute cross-domain HTTP requests. When you dig for subdomain name hijacking vulnerabilities, you can pay attention to the COSR header information, which is available in Burp Suite Pro Professional Edition. In addition, you can see whether the Web application has put the subdomain name on the whitelist. These settings may realize data theft from Web authorized users.

Oauth authorized white name singling

With cross-domain resource sharing, the Oauth authorization process also has a whitelist mechanism, whereby Web developers can specify which callback URIs is acceptable. The risk here is that when a subdomain name with a hijacking vulnerability is included in the whitelist, an attacker can steal the user's Oauth authorization information by redirecting the user's session to the previous subdomain name with the hijacking vulnerability during the Oauth authorization process.

Content Security Policy (Content-Security Policies)

It can be said that the content security policy is another list of hosts trusted by Web applications, and the purpose of CSP is to limit which hosts can execute client code in the application. This is useful if you want to minimize the impact of cross-site scripting. If you can hijack and control subdomains that are included in the whitelist, you can bypass CSP restrictions and execute malicious client code in Web applications.

$curl-sI https://hackerone.com | grep-I "content-security-policy" content-security-policy: default-src 'none'; base-uri' self'; block-all-mixed-content; child-src www.youtube-nocookie.com; connect-src 'self' www.google-analytics.com errors.hackerone.net; font-src' self'; form-action 'self'; frame-ancestors' none' Img-src 'self' data: cover-photos.hackerone-user-content.com hackathon-photos.hackerone-user-content.com profile-photos.hackerone-user-content.com hackerone-us-west-2-production-attachments.s3-us-west-2.amazonaws.com; media-src' self' hackerone-us-west-2-production-attachments.s3-us-west-2.amazonaws.com; script-src 'self' www.google-analytics.com;style-src' self' 'unsafe-inline' Report-uri https://errors.hackerone.net/api/30/csp-report/?sentry_key=61c1e2f50d21487c97a071737701f598 Click hijacking (ClickJacking)

As mentioned in "Cure53 Browser Security White Paper", in the X-Frame-Options header, IE, Edge and Safari all support the ALLOW-FROM uri mechanism, which means that the page can be displayed in the frame of the specified source, that is, if the subdomain name that you can hijack control is in the whitelist of the mechanism, then you can build a spoofing page in the target web application and execute a click hijacking (ClickJacking) attack.

Password information disclosure of password manager

This may not be considered in the reporting of some loopholes, but it is also an aspect that we should pay attention to. Some password managers, such as LastPass, perform automatic password filling in the sub-domain name sites to which some main websites belong, which is equivalent to allowing the site to set up a non-httponly-like cookie containing plaintext passwords, which can be used in depth after sub-domain name hijacking.

Intercept email

Rojan Rijal, a security researcher, discovered a hijackable subdomain name of Uber based on SendGrid services, and then used it to block corporate email communications within Uber.

Notes on hijacking vulnerabilities of sub-domain names in the report

Before you try to report a subdomain name hijacking vulnerability, you should pay attention to the following:

Make sure that your own Web content is deployed on the subdomain that you can hijack and control.

The deployed Web content is as simple and clean as possible, preferably a logo such as a sentence, and don't even put a picture.

The best way is to include a secret message in the comments of your deployed Web content HTML file, which is sufficient to prove the vulnerability when contacting and coordinating with the vendor.

If the manufacturer authorizes you, in order to illustrate the overall threat impact, you can further test this seed domain name hijacking vulnerability.

In most cases, if your vulnerability report contains steps to exploit a subdomain name hijacking vulnerability, the vendor will recognize the vulnerability.

Sub-domain name hijacking vulnerabilities are high-risk vulnerabilities. When writing a vulnerability report, please be careful. If the vulnerability is true and does not belong to double reporting, then congratulations, you can win the manufacturer's prize in the end.

The above is the editor for you to share how to carry out HackerOne loophole case analysis, if there happen to be similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.