CN113839938B

CN113839938B - Method and device for detecting domain name takeover vulnerability

Info

Publication number: CN113839938B
Application number: CN202111085914.9A
Authority: CN
Inventors: 侯贺明
Original assignee: Wuhan Greenet Information Service Co Ltd
Current assignee: Wuhan Greenet Information Service Co Ltd
Priority date: 2021-09-16
Filing date: 2021-09-16
Publication date: 2022-07-08
Anticipated expiration: 2041-09-16
Also published as: CN113839938A; WO2023040070A1

Abstract

The invention relates to the technical field of internet, and provides a method and a device for detecting a domain name takeover vulnerability. The method comprises querying a recursive resolution server for a target domain name DNS A record; acquiring a DNS response message, and inquiring a target domain name DNS A record from an NS server when checking that a DNS response state code is SERVFAIL; and querying a DNS (DOMAIN name server) record of DOMAIN _1 from an NS _1 server, comparing the obtained DNS record with NS _1, and if the obtained DNS record is not matched with NS _1, determining that a DOMAIN name take-over vulnerability exists. According to the invention, the problem of domain name takeover vulnerability is analyzed under the condition that the target domain name DNS A record analysis fails through the current stage NS server and respective data maintenance characteristics of the superior stage NS server.

Description

Method and device for detecting domain name takeover vulnerability

[ technical field ] A method for producing a semiconductor device

The invention relates to the technical field of internet, in particular to a method and a device for detecting a domain name takeover vulnerability.

[ background of the invention ]

With the continuous development and maturity of cloud computing technology, various network facilities are gradually migrating to the cloud, and the traditional network architecture has undergone a great revolution. Under the traditional technical framework, if a company needs to deploy a website, the company usually needs to purchase a domain name, configure DNS resolution, and purchase an IP address or a network space service, if the website needs data storage, the company needs to build a database service, and if a large number of concurrent accesses need to be processed, a load balancing or CDN network needs to be built. With the development of virtualization technology, cloud computing companies provide various services, and almost all application scenarios are covered, for example, amazon cloud computing companies provide cloud server services, DNS resolution services, load balancing services, CDN services, database services, bucket services, and the like, so that IT becomes very flexible and simple to construct complex IT facilities. On one hand, after the IT infrastructure is migrated to the cloud, the IT infrastructure is more convenient and faster to use, easier to expand and better in robustness; on the other hand, as various basic components are modularized more and more, the interaction among various components is more and more, and the probability of configuration errors is higher and higher.

The domain name takeover itself is a vulnerability that is similar to domain name hijacking, but also has a significant difference.

Domain hijacking, generally translated into domain hijack, means that when a user accesses a domain, an attacker redirects the access to the domain to a false server by using the control of the attacker on the network. The most common situation is that the domain name is hijacked in the DNS resolution layer, for example, the real server IP address of the domain name is a, and after hijacking, the server IP address corresponding to the domain name is changed to B. Domain name hijacking is generally realized by hijacking a DNS resolution process, such as DNS cache poisoning, DNS resolution hijacking, and the like.

Domain takeover, generally translated as domain takeover, refers to some errors in the configuration of an attacker using a target domain name DNS to direct access to the target domain name to a false server. The domain name takeover is a vulnerability, and the reason for the vulnerability is that the DNS system configuration of the target domain name is in a problem, so that the vulnerability can be attacked to achieve the purpose of controlling the domain name; the domain name hijacking is an attack, the attack is not based on a certain bug, but based on that an attacker has a certain control authority on a network, for example, the attacker has a network equipment control authority, the DNS flow message can be modified, and a false DNS analysis record is returned to a victim; or the attacker has the control authority of the DNS recursive resolution server, and the DNS cache record can be modified.

The similarity between domain name hijacking and domain name takeover is that the final expressed effect is that the target domain name is resolved to the IP address controlled by an attacker; the difference is that domain name hijacking usually uses the control authority of an attacker on network equipment, such as a gateway, a router, a DNS recursive resolution server and the like, domain name takeover does not depend on the control authority on the network, but depends on the DNS configuration of a target domain name to generate errors. If the domain name hijacking is not carried out on the target domain name, the target domain name does not have any resolution error and problem, and DNS resolution and access are normal; if the domain name taking over is not carried out on the target domain name, the target domain name itself can not be resolved normally due to the configuration error of DNS resolution, and only the target domain name can not be resolved above the IP address controlled by an attacker maliciously.

The CNAME record is a resource record in the DNS protocol, also called an alias record, which stores an alias of the current domain name, and the most common usage scenario of this record is to direct traffic to a third party service. The CNAME has a plurality of use scenes, two types of applications are most common, the first type is network basic service and products, such as CDN, load balance, a WEB application firewall based on a cloud architecture, a DDoS attack prevention product based on the cloud architecture and the like; the second type is some third party SaaS services, such as the main domain name is example.com, and it wants to use the third party chat service chat.com, then it can apply for a service entry example.chat.com at the third party service provider, and at the same time add an alias record to its own sub-domain name, example.com, using the DNS CNAME record, pointing to example.chat.com, so that all traffic accessing the example. The CNAME points the original domain name to another domain name, which means that the resolution authority of the IP address is given to a new domain name at the same time, the CNAME is an adapter of two domain name systems, and once the problem of the connection occurs, the domain name takes over the loophole. The most typical vulnerability scenario is that the target domain name uses a third-party service, so the CNAME record points to the domain name of the third-party service, but later the third-party service expires and terminates, but the target domain name forgets to modify the alias record in time in its own DNS system, which results in a suspended CNAME record. The suspended CNAME records can cause domain name takeover loopholes, the expression form of the loopholes is directly related to the services of third parties, after the services of the third parties are expired, some third party services can directly not analyze related domain names, and some third party services can select to analyze default error pages.

The traditional detection idea for domain name takeover loopholes is generally based on CNAME keywords and default error page keywords of a third-party service manufacturer, namely, CNAME domain name keyword lists of third-party services are collected, and whether the target domain name uses related third-party services is judged according to whether CNAME alias records of the target domain name are matched with the keyword lists; and meanwhile, collecting display information of a default error page of a third-party service manufacturer to form an error information keyword list, and judging whether the third-party service of the target domain name is unavailable according to whether the default webpage content of the target domain name is matched with the error information keyword list. The traditional detection method based on CNAME has a defect that the method can only detect the condition that DNS resolution is normal, and if the domain name cannot be resolved, the method fails. Specifically, since the method matches the CNAME keyword with the error message keyword of the third party, it requires that the target domain name must be able to resolve to the IP address, and then obtain the web page file from the target IP address, so as to further match the keyword. If the DNS resolution is unsuccessful, no matter the domain name does not exist, or the domain name resolution process is wrong, this method cannot handle. Aiming at the situation, the invention provides a new detection method, which does not depend on CNAME keywords and error information keywords of third-party services, and detects domain name takeover loopholes by detecting DNS NS records and response status codes of DNS interaction protocols.

The NS record is one of DNS resource records, and is an abbreviation for name server, and represents an authoritative domain name server of a domain name, and is a server which is responsible for storing DNS resource records and is really responsible for domain name resolution. The NS record is typically configured at the domain name service provider and must itself be a domain name, not an IP address. The NS service can be built by itself, or can use the service of a third party, for example, the domestic DNSPod is a professional DNS resolution service provider. With the development of cloud computing, more and more manufacturers provide DNS resolution services externally, Router53 service of amazon cloud computing manufacturers, Azure DNS service of microsoft cloud service, and the like. When a DNS resolution service of a third party is used, DNS records are stored on a third party platform, and the DNS records form a record file which is called a DNS Zone file; when the user does not use the third-party DNS resolution service any more, the third-party platform deletes the DNS Zone file corresponding to the domain name, and if the NS record of the target domain name is not updated in time at the moment, a domain name taking-over bug occurs, so that the DNS resolution authority of the whole domain of the target domain name is taken over. After the DNS resolution authority of the entire domain is taken over, the damage is very large because not only an independent domain name but also the resolution authority of the entire domain is taken over here, and an attacker can resolve all sub-domain names below the domain, so that an attack behavior such as spoofing a certificate, receiving and sending an email related to the domain name, and the like can be implemented.

In view of the above, overcoming the drawbacks of the prior art is an urgent problem in the art.

[ summary of the invention ]

The invention aims to solve the technical problem of how to realize the detection of the domain name takeover vulnerability.

The invention adopts the following technical scheme:

in a first aspect, the present invention provides a method for detecting a domain name takeover vulnerability, including:

querying a recursive resolution server for a target domain name DNS A record;

acquiring a DNS response message, and inquiring a target domain name DNS A record from an NS server when checking that a DNS response state code is SERVFAIL;

acquiring a result of querying a target domain name DNS A record returned by a first NS server, and recording the first NS server as NS _ 1; recording the DOMAIN responsible for the NS _1 server as DOMAIN _ 1; recording an NS server at a higher level than the first NS server as NS _ 0;

wherein DOMAIN _1 and NS _1 appear in the DNS response content of NS _0 server, and the DNS response content of NS _0 is an NS record, indicating that the NS server of DOMAIN _1 is NS _ 1;

and querying a DNS (DOMAIN name server) record of DOMAIN _1 from an NS _1 server, comparing the obtained DNS record with NS _1, and if the obtained DNS record is not matched with NS _1, determining that a DOMAIN name take-over vulnerability exists.

Preferably, the DNS NS record of DOMAIN _1 is queried for the NS _1 server, and if the returned DNS response status code is unfused, it is determined that a DOMAIN name takeover vulnerability exists.

Preferably, the method further comprises:

querying a DNS A record of NS _1 from NS _0, and recording the DNS A record as IP _ 0;

querying a DNS A record of NS _1 from NS _1, and recording the DNS A record as IP _ 1;

checking whether IP _0 is equal to IP _1 or not, and if so, indicating no leak; if the domain name is inconsistent with the domain name, the domain name taking-over vulnerability exists.

Preferably, the querying the NS server for the target domain name DNS a record specifically includes:

if the queried NS server is the NS server responsible for the resolution of the target domain name DNS A, the queried NS server is used as a result of querying the target domain name DNS A record returned by the first NS server;

if the queried NS server is not the NS server responsible for the DNS a resolution of the target domain name, but a root server or a top-level domain name server, the NS record is returned, so that the DNS request client sends the NS record to the next-level NS server according to the NS record.

Preferably, the NS servers are obtained step by step in a recursive manner until the first NS server is reached, and the obtaining of the result of querying the target domain name DNS a record returned by the first NS server specifically includes: if the domain name is normally resolved, returning the IP address obtained by resolving the DNS A record with the target domain name as a result.

Preferably, the method further comprises: if the analysis fails, the returned result is NXDOMAIN or SERVFAIL status code.

Preferably, when the status code is servail, the status code specifically includes: the recursive resolution server is unable to network, the DNSSEC check fails, the NS server is not reachable, and the DNS ZONE file of the corresponding domain name on the NS server is not available.

Preferably, the query of the target domain name DNS a record to the recursive resolution server is initiated by the domain name takeover vulnerability detection device.

Preferably, the domain name takeover vulnerability detection device collects DNS records in the network, and completes detection of the domain name takeover vulnerability by periodically querying the DNS records item by item from the recursive resolution server.

In a second aspect, the present invention further provides a device for detecting a domain name takeover vulnerability, which is used to implement the method for detecting a domain name takeover vulnerability in the first aspect, where the device includes:

at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to perform the method for detecting a domain name takeover vulnerability according to the first aspect.

In a third aspect, the present invention further provides a non-volatile computer storage medium, where the computer storage medium stores computer-executable instructions, and the computer-executable instructions are executed by one or more processors, and are used to complete the method for detecting a domain name takeover vulnerability according to the first aspect.

According to the invention, through the current stage NS server and respective data maintenance characteristics of the superior stage NS server, the problem of domain name takeover vulnerability is analyzed under the condition that the target domain name DNS A record analysis fails; the problem that the situation is usually missed when the problem occurs in the prior art is solved.

[ description of the drawings ]

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments of the present invention will be briefly described below. It is obvious that the drawings described below are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

FIG. 1 is a schematic diagram of a domain name architecture according to an embodiment of the present invention;

fig. 2 is a schematic flowchart of a method for detecting a domain name takeover vulnerability according to an embodiment of the present invention;

fig. 3 is a schematic flowchart of a method for detecting a domain name takeover vulnerability according to an embodiment of the present invention;

FIG. 4 is a diagram illustrating an upper NS glue record code according to an embodiment of the present invention;

fig. 5 is a schematic structural diagram of a detection apparatus for a domain name takeover vulnerability provided in an embodiment of the present invention.

[ detailed description ] embodiments

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

In the DNS resolution process, numerous roles are involved, including: DNS client, forwarding DNS, recursive DNS, and authoritative DNS.

The DNS client is the role, such as a browser, that initiates the DNS request.

Forwarding the DNS, wherein the DNS request is forwarded to a recursive DNS for query without performing DNS recursive query; a typical forwarding DNS, such as a home router, has an IP address of 192.168.1.1.

The recursive DNS, also called DNS resolver, is responsible for recursively querying the DNS tree structure.

Generally, a computer is provided with a DNS server, and the DNS server is not properly called as recursive DNS or forwarding DNS.

An authoritative DNS server, also called NS server, is a node in a DNS tree structure, and is responsible for DNS records for a certain domain name area.

In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

In an authoritative domain name server, all DNS resolution records in the domain name area in which the authoritative domain name server is responsible for are recorded, and the most common record types are: record A, IP address of domain name; NS records, authoritative domain name server addresses for domain names; MX records, the mail server address of the domain name; TXT record, text record of domain name.

For example, your website domain name is www.testqqsg.tk, and the DNS recursive request flow is as follows:

finding out NS servers of root domain names, wherein the root domain names are so as to obtain 13 root domain name servers, and selecting a first a.root-servers.net;

initiating an A record request of a target domain name www.testqqsg.tk to a.root-servers.net, and returning NS records of a top-level domain name tk. as c.ns.tk;

initiating an A record request of a target domain name www.testqqsg.tk to c.ns.tk, and returning NS record ns.testqsg.tk of the domain name testqsg.tk;

an a record request of the target domain name www.testqqsg.tk is initiated to ns.testqsg.tk, resulting in an IP address of www.testqqsg.tk.

As shown in fig. 1, one node in each layer represents a DNS zone and is responsible for resolving all sub-domain names in the zone, and if there is a next-level node in the layer, the node in the next level is responsible for resolving the corresponding sub-domain name. For example, if the target domain name is www.example.com, then it is responsible for resolving its node instance. If the target domain name is www.test.example.com, then it is the fourth level node test.example.com that is responsible for resolving it; if the target domain name is abc.test2.test.example.com, it is the fifth level node test2.test.example.com that is responsible for resolving it. In other words, example.com is responsible for parsing of × example.com unless there is a lower node that explicitly undertakes a part of the sub-domain name resolution work, e.g., there is a lower node test. If the NS record for a domain name is a sub-domain name of the domain name, the recursive server may be stuck in a loop when resolving the domain name. For example, the domain name is example.com, and the corresponding NS server is ns.example.com, then in the process of recursive resolution of example.com by the recursive resolution server, it will first ask the NS server corresponding to com, at this time, the NS server corresponding to com tells the recursive resolution server that the NS server corresponding to example.com is ns.example.com, and then the recursive resolution server will go to this step again when locating the IP address of ns.example.com, thus forming a loop. To solve this problem, a glue record is generated, which is a special DNS resource record that exists to break the cyclic deadlock that occurs when the NS record for a domain is a child of itself. For example, a glue record is a record in the NS server corresponding to the com, which directly records the IP address of ns.example.com, and when the recursive resolution server queries the NS server corresponding to the com, the NS server of the com not only returns that the NS of example.com is ns.example.com, but also returns the IP address of ns.example.com. The NS records are connected with the upper level and the lower level nodes of the DNS tree structure and are closely related to the glue records, the NS records of example.com can be simultaneously stored in the NS server of example.com and the NS server of com, the two are kept consistent under normal conditions, and if the NS records are not consistent, only the records in the NS server of com can play a role in the DNS recursive resolution process.

The detection method provided by the invention mainly comprises the following steps. Firstly, initiating DNS query to a recursive resolution server, querying a DNS A record of a target domain name, observing a state code field in a DNS response message at the moment, and checking whether the DNS record is SERVFAIL or not; secondly, positioning the domain name of the level in a DNS tree system, and finding an authoritative domain name server of the domain name of the level; then, a DNS request is sent to an authoritative domain name server of the domain name of the level, and a DNS NS record with the target of the domain name of the level is inquired; and finally, checking the received DNS response message, on one hand, checking whether the DNS response state code is REFUSED, on the other hand, comparing an NS record and an A record returned by the NS server of the target domain name, and an NS record and an A record returned from the upper-level node, and comprehensively judging whether the domain name takeover vulnerability exists. For example, if the target domain name to be checked is test2.test. example. com, a recursive resolution server, which is a so-called DNS server such as public 114.114.114.114, google's 8.8.8.8, or a default DNS server provided by each large operator, needs to be queried first for the DNS a record of the target domain name. Then checking the response message of DNS, observing whether the DNS response status code is SERVFAIL, if yes, starting to locate the local level domain name of the target domain name in the DNS tree system. Specifically, a DNS a record query for a target domain name is initiated to a root server, the root server returns an NS record of a com domain name, which is denoted as NS _ com, then an query is initiated to NS _ com, an NS record of example.com is returned, and NS _ example.com is recorded, then an query is initiated to NS _ example.com, an NS record of test.example.com is returned, which is denoted as NS _ test.example.com, then an query is initiated to NS _ test.example.com, and if all is normal, an IP address of test2.test.example.com is returned, and if there is a DNS configuration error in the target domain name, a DNS error message such as a redesed may be returned here. In all queries, the DNS request is an a record requesting a target domain name test2.test.example.com, and when the whole query process is finished, the following information is obtained, in the DNS tree system, the node domain name of the target domain name test2.test.example.com in the DNS tree structure of the DNS system is test.example.com, or called as DNS Zone of test.example.com, the NS of the present node domain name is NS _ test.example.com, the upper domain name is example.com, and the upper domain name NS is NS _ example.com. Next, querying a DNS NS record of test.example.com from NS _ test.example.com, checking whether a DNS response status code in a returned result is unfused, and if so, indicating that a domain name takeover vulnerability exists; if not, further comparing whether the value of the DNS response content is NS _ test.example.com, if not, indicating that the values of NS recorded in the upper and lower nodes in the DNS tree structure are inconsistent, indicating that configuration errors exist and domain name takeover bugs exist; otherwise, the glue record is further checked. And checking the glue record, namely firstly acquiring the NS server domain name of the target domain name and the DNS ZONE domain name responsible for resolution, then checking whether the NS domain name is a sub-domain name of the DNS ZONE domain name, and if so, further checking the glue record. The method comprises the steps of obtaining glue records from a superior NS node, then obtaining an A record of an NS domain name from the current NS node, comparing the glue records and the A record, if the glue records and the A record are consistent, indicating no problem, otherwise, indicating that DNS configuration errors exist and domain name takeover loopholes exist.

Compared with the traditional detection method, the detection method provided by the invention has the following characteristics that the detection is carried out based on the NS record of DNS (domain name system) instead of the CNAME record. The traditional detection method based on CNAME is from the angle of a DNS client, only a simple request is made to a recursive resolution server to resolve a domain name to an IP address, the specific recursive resolution process is completed by the recursive resolution server, and the specific recursive resolution process is not directly related to a DNS tree structure; the method is characterized in that a station can directly initiate query to a DNS tree structure system from the perspective of a recursive resolution server, and a large amount of NS records can be involved. In the traditional method for checking domain name takeover loophole, there is a checking method aiming at the NS record, which checks the validity of the NS domain name, whether the domain name is out of date or not and can be registered, if the NS domain name can be maliciously registered by an attacker, the corresponding domain name can be taken over naturally, but the method is essentially different from the using method of the NS record in the invention. Secondly, the situation that the DNS can not be normally analyzed is detected, and the traditional method only detects the situation that the DNS can not be normally analyzed. The DNS response status codes are four, NXDOMAIN indicates that the domain name does not exist, NOERROR indicates that the resolution is normal, SERVFAIL indicates that the server is wrong, REFUSELD indicates that the service is rejected, the traditional detection mode can only process the condition of normal resolution, and if the DNS resolution is wrong, the DNS response status codes cannot be processed; the method further distinguishes the detailed types of errors aiming at the condition that DNS analysis has errors, and then detects whether a domain name takeover vulnerability exists; thirdly, understanding and using glue records and NS records. The glue record is a special record, and the glue record exists only when the NS record of the domain name is the own sub-domain name; more important than the glue record is the NS record, which connects the upper and lower level nodes of the DNS tree structure. For the NS record and the glue record, two parts exist at the same time, one part is on the authoritative domain name server of the node domain name at the current level, the other part is on the authoritative domain name server of the node domain name at the upper level, and the configuration in the authoritative domain name server of the node domain name at the upper level really plays a role, although the configuration of the authoritative domain name server of the node domain name at the current level exists, the configuration can be inquired, but the configuration does not play a role in the normal DNS resolution process. In the normal DNS resolution process, the NS record of the current-level domain name is not queried for the NS server of the current-level domain name, which is a popular example, the normal DNS resolution process is that you ask the upper level of zhang san for "who is zhang san", but do not ask the zhang san for "who is zhang san", but the record of "who is zhang san" exists in the record files of zhang san and the upper level of zhang san at the same time. In the detection process, the upper level of Zusanyi and the principal of Zusanyi are inquired, and if the answers are not consistent, the DNS configuration is wrong, and the risk of domain name takeover exists.

Example 1:

embodiment 1 of the present invention provides a method for detecting a domain name takeover vulnerability, which, as shown in fig. 2, includes:

in step 201, the recursive resolution server is queried for a DNS a record for the target domain name.

In step 202, a response packet of the DNS is obtained, and when it is checked that the DNS response status code is servail, a DNS a record of the target domain name is queried for the NS server.

Wherein the status code is SERVFAIL, which indicates that the recursive resolution server can not be networked, the DNSSEC check fails, the NS server is not reachable, and the DNS ZONE file with the corresponding domain name on the NS server does not exist.

In step 203, a result of querying a DNS a record of a target domain name, which is returned by a first NS server, is obtained, and the first NS server is denoted as NS _ 1; recording a DOMAIN responsible for the NS _1 server as DOMAIN _ 1; an NS server at the upper stage of the first NS server is denoted as NS _ 0.

Where DOMAIN _1 and NS _1 appear in the DNS response content of NS _0 server, the DNS response content of NS _0 is an NS record indicating that the NS server of DOMAIN _1 is NS _ 1.

In step 204, a DNS record of DOMAIN _1 is queried for the NS _1 server, and a comparison is performed according to the obtained DNS record and NS _1, and if not, it is determined that a DOMAIN name takeover vulnerability exists.

And querying a DNS NS record of DOMAIN _1 from an NS _1 server, and if the returned DNS response status code is REFUSED, determining that a DOMAIN name takeover vulnerability exists.

According to the invention, through the current stage NS server and respective data maintenance characteristics of the superior stage NS server, the problem of domain name takeover vulnerability is analyzed under the condition that DNS A record analysis of a target domain name fails; the problem that the situation is usually missed when the problem occurs in the prior art is solved.

The prior art depends on matching of CNAME keywords and webpage information keywords, and has the premise that the domain name is required to be resolved normally, and if the domain name cannot be resolved, the processing cannot be continued. The prior art needs to acquire a DNS CNAME record of a target domain name and a DNS A record of the target domain name, and needs to acquire the two records, wherein the DNS response status code needs to be NOERROR but not NXDOMAIN, SERVFAIL, REFUSED and the like. Only when the DNS response status code is NOERROR means that the domain name can be resolved normally, otherwise means that the domain name resolution is erroneous. In the traditional detection technology, the domain name resolution part is completed by a recursive resolution server and can not be directly interacted with a DNS tree structure system.

In the embodiment of the present invention, the querying the DNS server for the DNS record of the target domain name specifically includes two cases:

first, if the queried NS server is the NS server responsible for DNS a resolution of the target domain name, then it is the result of the DNS a record of the query to the target domain name that is returned by the first NS server.

Secondly, if the queried NS server is not the NS server responsible for the DNS a resolution of the target domain name, but a root server or a top-level domain name server, the NS record is returned, so that the DNS request client sends the NS record to the next-level NS server according to the NS record.

In an embodiment of the present invention, generally, the NS servers are obtained step by step in a recursive manner until the first NS server is reached, and the obtaining of the result of querying the DNS a record of the target domain name returned by the first NS server specifically includes: if the domain name is normally resolved, returning the IP address obtained by the DNS A record resolution with the result of the target domain name; if the analysis fails, the returned result is status codes such as NXDOMAIN, SERVFAIL and the like.

In combination with the embodiment of the present invention, there is also a preferred embodiment, where the method further includes:

The query of the DNS A record of the target domain name to the recursive resolution server is initiated by domain name takeover vulnerability detection equipment; the domain name takeover vulnerability detection device collects DNS records in a network, and completes domain name takeover vulnerability detection in a mode of periodically querying the DNS records one by one from a recursive analysis server.

Example 2:

based on the solution proposed in embodiment 1, the embodiment of the present invention centralizes several possible domain name takeover vulnerabilities into a complete analysis logic from a complete analysis logic, and as shown in fig. 3, includes the following steps:

step S101, inquiring DNS A record of a target domain name from a recursive resolution server;

the recursive resolution server here refers to DNS Resolver, such as public 114.114.114.114, google's 8.8.8.8, or a default DNS resolution server provided by each large operator.

To clarify the concept and noun, we usually surf the internet to a DNS Server configured for a computer, although it is also called "DNS Server", this calling is strictly wrong, and according to the DNS specification, it should be called a recursive resolution Server (or called DNS Resolver), and an authoritative domain name Server in the DNS system is called a DNS Server (also called NS Server) in the DNS system specification. Therefore, in the embodiment of the present invention, the recursive resolution Server is referred to as DNS Resolver, and the authoritative domain name Server is referred to as NS Server, which is also called DNS Server.

Step S102, obtaining a DNS response message, checking whether the DNS response state code is SERVFAIL, if so, indicating that an error occurs when the recursive analysis server inquires the DNS tree system, and entering the step S103, otherwise, directly returning to the state without vulnerability.

In this step, in step S101, DNS response contents returned by the recursive resolution server are checked, where one item in the DNS response contents is a status code, where it is to be checked whether the status code is servfile, and this status code indicates that an error occurs when the recursive resolution server queries the DNS system, and there are many cases that may cause such an error, for example, the recursive resolution server cannot network, the DNSSEC check fails, the NS server is not reachable, and there is no DNS ZONE file corresponding to the domain name on the NS server.

Step S103, queries the root domain name server for a DNS a record of the target domain name.

In this step, a DNS query request is directly sent to a root domain name server of the DNS system to query a DNS a record of a target domain name, that is, the target domain name is resolved to an IP address. The root domain name server is a root node in a tree structure of the DNS system and is essentially an NS server.

The DNS system is in a tree structure, wherein each node is an NS server which is also called an authoritative domain name server, the first layer of nodes are called root servers and root name servers, and the second layer of nodes are called top-level domain name servers and top level domain name servers. For example, the domain that the root domain name server is responsible for resolving is a point ". the domain that the top level domain name server is responsible for resolving is" com. "," net. ", and so on.

Step S104, it is checked whether the DNS response is an NS record.

Checking a DNS response returned by the NS server, wherein if the NS server is an authoritative domain name server responsible for the resolution of the target domain name, the content of the returned DNS response is an answer to the A record request; if the queried NS server is not the NS server for the target domain name, but is the root server, or the top-level domain name server, etc., then an NS record is returned in order to tell the DNS requesting client who should go to find out who to query next. If the DNS response returns an NS record, step S105 is entered, otherwise step S107 is entered, which indicates that the current-level NS server is the NS server to which the target domain name DNS a record belongs.

Step S105, a next-level NS server is acquired.

This step is to resolve the DNS response content in step S104, and if the response content is an NS record, it indicates that the current NS server is not the NS server of the target domain name, and the current NS server directs to the next-level NS server, which is to acquire the next-level NS server.

Step S106, inquiring DNS A record of the target domain name from the next-level NS server.

In this step, a DNS request is sent to the NS server acquired in step S105, and a DNS a record of the target domain name is queried, that is, the target domain name is resolved to an IP address. Step S106 and step S105 constitute a process of recursive resolution.

Step S107, acquiring a current NS server and recording the current NS server as NS _ 1; recording the DOMAIN responsible for the NS _1 server as DOMAIN _ 1; the NS server at the upper stage is denoted as NS _ 0. This step can be entered to indicate that the DNS response content is not an NS record, and at this time, the responding NS server is an authoritative DNS server for the target DOMAIN name, that is, the NS server, and this value is denoted as NS _1, and the DOMAIN for which this NS server is responsible is denoted as DOMAIN _1, and the NS server of the upper node is denoted as NS _ 0. DOMAIN _1 and NS _1 will appear in the DNS response content of NS _0 server, which is an NS record for NS _0 indicating that the NS server for DOMAIN _1 is NS _ 1.

Step S108, inquiring DNS NS record of DOMAIN _1 from NS _1 server. Here, NS _1 refers to the NS server of the target DOMAIN name acquired in step S107, that is, the authoritative DNS server of the target DOMAIN name, and at this time, the DNS record of DOMAIN _1 is queried for NS _1, which is to query the NS server of the target DOMAIN name for the NS record of the DNS ZONE DOMAIN name, and in the normal DNS recursive resolution process, this query step does not occur, and in the normal query flow, the NS server of the DNS ZONE name is notified by the NS server of the previous stage.

Step S109, check whether the DNS response is a relised. Here, the DNS response content in step S108 is checked to see whether its DNS status code is a resured, and if so, a high risk is directly returned; otherwise, the process proceeds to step S110. The technical principle behind this step is that each domain's NS server has a DNS ZONE file for that domain, and if the NS server is queried for DNS records for domains it is not responsible for resolving, a release is returned indicating denial of service.

If this step is reached, it is stated that in the DNS system, the tree node is still at the node of the previous level, but the configuration of the target domain has been deleted inside the node of the current level. This is essentially a configuration error, in which the record pointing to the current level by the upper level node is stored in the upper level node, the configuration information is configured at the domain name provider, that is, the NS record of the domain name is configured, and the specific DNS resource record is configured in the NS server, and the NS record points to the domain name of the NS server.

Step S110, obtain the value of NS in the DNS response, and record it as NS _ 2. Here, the DNS response content in step S108 is resolved, and since step S108 is the NS record of the query, the DNS response content is also the NS record, and this NS value is denoted as NS _ 2.

The principle behind this step is that the NS records for a domain name will exist in duplicate in the DNS tree system, one in the top NS server and one in the local level NS server. For example, the target domain name is www.example.com, the corresponding domain is example.com, the corresponding NS is ns.example.com; com, the responsible domain is com, then this NS record "example.com IN ns.example.com" would appear IN both the NS server configuration of ns.com and the NS server configuration of ns.example.com. NS _1, which we obtain, is the NS record obtained from ns.com, and NS _2, which is the NS record obtained from ns.example.com, the command executed by the dig tool is as follows:

obtain NS _1: dig example. com NS @ NS

Obtaining NS _2 dig example. com NS @ NS

In some English technical documents, NS _1 is called parent NS, and NS _2 is called local NS. Where the NS _2 record is a very special record that must be configured and maintained consistent with NS _1, but does not function in the normal DNS resolution process, i.e., if NS _2 and NS _1 are not consistent, then NS _1 is the standard for DNS resolution.

And step S111, checking whether the NS _1 and the NS _2 are the same, if so, entering step S112, otherwise, returning to medium risk. Here, NS _1 and NS _2 both represent an authoritative DNS server for the target domain name, that is, an NS server, but NS _1 is obtained by querying an upper node while recursively querying in the DNS system tree structure, and NS _2 is obtained by directly querying the NS server for the target domain name. If the two values are the same, it indicates that there is no problem in configuring the NS record, and the process proceeds to step S112 to continue other checks, otherwise, it indicates that there is a configuration error, where normally, NS _1 and NS _2 are consistent, and if not, it indicates that there is a configuration error, NS _1 is the NS record configured at the domain name service provider, and NS _2 is the NS record configured in the NS server in its own responsibility.

Step S112, check whether NS _1 is a sub-DOMAIN name of DOMAIN _1, this step is to determine whether the NS server DOMAIN name of the target DOMAIN name is a sub-DOMAIN name of the DNS ZONE DOMAIN for which the NS server is responsible. This is the case, for example, if the NS record of example.com is ns.example.com, and not if the NS record of example.com is ns.nowhere.com. If so, go to step S113 to continue checking, otherwise return to no risk. The principle behind this is that if the NS record of a domain name is its own sub-domain name, then a glue record is introduced, and it is checked whether the configurations of the glue record in the upper node and the current node are consistent, and if not, it indicates that there is a configuration error, and there is a domain name to take over the vulnerability.

For example, the NS server domain name corresponding to the target domain name www.example.com is ns.example.com, the IP address of the NS server is 1.1.1.1, the responsible domain is example.com, the superior NS is ns.com, and the responsible domain is com.

In step S113, NS _0 is queried for the DNS a record of NS _1, which is denoted as IP _ 0. This step is to query the glue record of the superordinate node, for example, if the NS record of example.com is ns.example.com, and the NS record of superordinate node com is ns.com, the operation performed here is to query ns.com for the IP address of ns.example.com, and the command using the dig tool is "dig ns.example.com @ ns.com".

Step S114, query NS _1 for the DNS a record of NS _1, denoted as IP _ 1. This step is to query the present level node for the IP address of the present level node, for example, if the NS record of example.com is ns.example.com, the operation performed here is to query ns.example.com for the IP address of ns.example.com. In step S113, IP _0 is actually a glue record, and IP _1 is actually a glue record queried in the present-level NS server, and the query is "dig NS. It should be noted that querying the current level NS for the DNS a record of the target domain name of the NS automatically carries the glue record of the upper level NS in the returned result, which is referred to as the code shown in fig. 4, because there is a recursive query process in determining the IP address of the NS, which queries the upper level NS server.

In step S115, it is checked whether IP _0 is equal to IP _1, here, IP _0 obtained in step S113 and IP _1 in step S114 are compared to each other. IP _0 is derived from glue records of the upper NS node, IP _1 is derived from configuration records of the present NS node, and if the number of IP _0 and IP _1 is multiple, set comparison is performed, i.e. whether the two sets are equal or not is compared. Under normal conditions, the two should be consistent, and no leak is returned; if the two are not consistent, the DNS configuration error is shown, and a domain name taking-over vulnerability exists.

Example 3:

fig. 5 is a schematic structural diagram of a domain name takeover vulnerability detection apparatus according to an embodiment of the present invention. The detection apparatus for taking over a domain name vulnerability of the present embodiment includes one or more processors 21 and a memory 22. In fig. 5, one processor 21 is taken as an example.

The processor 21 and the memory 22 may be connected by a bus or other means, and fig. 5 illustrates the connection by a bus as an example.

The memory 22, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs and non-volatile computer-executable programs, such as the domain name takeover vulnerability detection method in embodiment 1. The processor 21 performs a domain name takeover vulnerability detection method by running non-volatile software programs and instructions stored in the memory 22.

The memory 22 may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory 22 may optionally include memory located remotely from the processor 21, and these remote memories may be connected to the processor 21 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The program instructions/modules are stored in the memory 22, and when executed by the one or more processors 21, perform the method for detecting a domain name takeover vulnerability in embodiment 1, for example, perform the steps shown in fig. 2 and 3 described above.

It should be noted that, because the contents of information interaction, execution process, and the like between modules and units in the apparatus and the system are based on the same concept as the processing method embodiment of the present invention, specific contents may refer to the description in the method embodiment of the present invention, and are not described herein again.

Those of ordinary skill in the art will appreciate that all or part of the steps of the various methods of the embodiments may be performed by associated hardware as instructed by a program, which may be stored on a computer-readable storage medium, which may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.

Claims

1. A method for detecting a domain name takeover vulnerability is characterized by comprising the following steps:

querying a recursive resolution server for a DNS A record of a target domain name;

acquiring a response message of a Domain Name System (DNS), and inquiring a DNS A record of a target domain name from a domain name NS server when checking that a DNS response state code is SERVFAIL;

acquiring a result of querying a DNS A record of a target domain name returned by a first NS server, and recording the first NS server as NS _ 1; recording the DOMAIN responsible for the NS _1 server as DOMAIN _ 1; recording an NS server at a higher level than the first NS server as NS _ 0;

wherein, DOMAIN _1 and NS _1 will appear in the DNS response content of NS _0 server, the DNS response content of NS _0 is a NS record, which indicates that the NS server of DOMAIN _1 is NS _ 1;

and querying a DNSNS record of DOMAIN _1 from an NS _1 server, comparing the obtained DNSNS record with NS _1, and determining that a DOMAIN name takeover vulnerability exists if the DNSNS record is not matched with the NS _ 1.

2. The method for detecting the DOMAIN name takeover vulnerability of claim 1, wherein a DNSNS record of DOMAIN _1 is queried for the NS _1 server, and if the returned DNS response status code is REFUSED, the DOMAIN name takeover vulnerability is determined to exist.

3. The method for detecting the domain name takeover vulnerability of claim 1, wherein the method further comprises:

4. The method for detecting a domain name takeover vulnerability according to claim 1, wherein the querying the NS server for the DNS a record of the target domain name specifically comprises:

if the queried NS server is the NS server responsible for the resolution of the DNS A record of the target domain name, the queried NS server is used as a result of querying the DNS A record returned by the first NS server;

if the queried NS server is not the NS server responsible for resolution of the DNS a record of the target domain name, but the root server, or the top-level domain name server, the NS record is returned, so that the DNS request client sends a request for querying the DNS a record of the target domain name to the next-level NS server according to the NS record.

5. The method for detecting a domain name takeover vulnerability according to claim 4, wherein the NS servers are obtained step by step in a recursive manner until the first NS server is reached, and the obtaining of the result of querying the DNS A record returned by the first NS server specifically comprises: if the domain name is normally resolved, returning the IP address obtained by resolving the DNS A record with the target domain name as the result.

6. The method for detecting the domain name takeover vulnerability of claim 5, wherein the method further comprises: if the analysis fails, the returned result is NXDOMAIN or SERVFAIL status code.

7. The method for detecting a domain name takeover vulnerability according to any one of claims 1 to 6, wherein when the state code is SERVFAIL, the method specifically comprises: the recursive resolution server is unable to network, the DNSSEC check fails, the NS server is not reachable, and there are no DNS ZONE files on the NS server for the corresponding domain name.

8. The method for detecting the domain name takeover vulnerability according to any one of claims 1-6, wherein the query of the recursive resolution server for the DNS A record is initiated by a domain name takeover vulnerability detection device.

9. The method for detecting the domain name taking over vulnerability according to claim 8, wherein the domain name taking over vulnerability detection device collects DNS records in a network, and completes the detection of the domain name taking over vulnerability by periodically inquiring the DNS records item by item from a recursive resolution server.

10. A device for detecting a domain name takeover vulnerability, the device comprising:

at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor for performing the method of domain name takeover vulnerability detection of any of claims 1-9.