[DNS Security] DNS rebinding attack

I have understood this attack for a long time and do not understand what it means to "rebind. After A little understanding, I found that the attack principle is literal. Refresh the DNS A record and bind it to another address.

In the following section, I reference the note of a fairy

"To mount a DNS rebinding attack, the attacker need only
Register a domain name, such as attacker.com, and attract
Web tra defaults c, for example by running an advertisement. In
The basic DNS rebinding attack, the attacker answers DNS
Queries for attacker.com with the IP address of his or her
Own server with a short time-to-live (TTL) and serves vis-
Iting clients malicious JavaScript. To circumvent a temporary rewall,
When the script issues a second request to attacker.com,
Attacker rebinds the host name to the IP address of a tar-
Get server that is inaccessible from the public Internet.
Browser believes the two servers belong to the same origin
Because they share a host name, and it allows the script
Read back the response.

"

"

Same-origin rules

This rule is designed to ensure that cross-site calls are not performed under the same domain name. However, I personally think it is a problem now. I will explain it later. This rule requires that things under the same domain do not reference the content of other domains. If there is an http://www.example.com/dir/directory, the same source rule is interpreted as follows:

Address                             Explanation

Http://www.example.com/dir2      The directories are different, but the domain is the same, so they comply with the same-source rules,

                                  Resources can be referenced by each other

Http://www.example.com: 82/dir/   Different ports do not comply with same-source rules.

Http://www.anotherone.com/       Different domain names, so do not comply with the same source rules

 

But !! This rule does not apply to the SRC attributes of tags such as <script>, <link>, <iframe>, and . This is why same-origin rules cannot prevent Trojans .... That's too embarrassing... However, the biggest help of the same-origin rule is to help us separate the cookies of various websites. The cookie information of different sources will be saved to different domain name files.

 

Now, with these concepts, we can start to talk about DNS redirection.

 

In fact, the re-binding of DNS is to steal the dragon and turn the wind into a prince. Use fraudulent means to introduce your resources on Site A to Site B, and then call these resources as you like to do bad things. How can this problem be solved? The method is simple (see http://ha.ckers.org/blog/20091116/session-fixation-via-dns-rebinding)

1) Get a domain name like http://www.badguy.com/

2) aim at a target, such as http://www.victim.com/

3) set the ttlregistration of http://www.badguy.com/to a very short time, for example, 1 second.

4) then, after registering an account number at http://www.victim.com/, deliver some bad things (such as Trojans, but the scenario is hypothetical, so it may fail. I advise you not to do anything bad: p)

5) log on to http://www.victim.com/and select the logon password. Then, click cookie's information to capture the information of the recorded information. Write a piece of JS and place it in the worker.

6) Let the user access http://www.badguy.com/, and then use his/her feet to control the user's redirection to the ingress in 2 seconds (> TTL time .. I will try again.

"

For the above steps, I need to explain a little bit. At first, I did not understand what he was doing.

What is the meaning of step 2. First, set the ttlvalue of http://www.badguy.com/to 1 second. This arecord is stored on the customer's DNS server and times out after 1 second. In the original article, "allow a user to access http://www.badguy.com/, and then use his/her feet to control the user's redirection to http://www.badguy.com/in 2 seconds (> TTL time /". 2 seconds later, the TTL becomes invalid. In this case, you can re-access badguy through JS, and the client will re-query DNS to obtain the IP address. Just right, hacker stopped the DNS in advance, updated the record, bound the real victim.com IP address with the badguy domain name, and then started the DNS server. Now, the ip address of the badguy requested by the client is victim. In other words, the url on the browser is indeed badguy, but the ip address directs to victim, and the customer directly accesses victim.

What then? I guess the author meant that, because the cookie of victim was saved in the client browser, the customer logged on to the victim page. There are several questions:

1. How do I save cookies in the browser of the client?

2. assuming that the cookie is successfully saved and the user has successfully logged on to victim after passive access, the page after logon is also the home page of victim, unless there are discussions about the default jump to the personal homepage after login.

The above is the principle of rebinding.

However, it should not be complete. Why is it necessary for such a complicated process, xss/csrf? Everything from getting cookies to hard redirection can be done by JS.

This is a sentence in the document:

"Using DNS rebinding,
An attacker can circumvent implements rewallto spider implements ate in-
Tranets, ex effecltrate sensitive documents, and compromise un-
Patched internal machines. An attacker can also hijack
IP address of innocent clients to send spam e-mail, commit
Click fraud, and frame clients for misdeeds. DNS rebinding
Vulnerabilities permit the attacker to read and write directly
On network sockets, subsuming the attacks possible with ex-
Isting JavaScript-based botnets [24], which can send HTTP
Requests but cannot read back the responses ."

I do not understand how it is implemented. For further understanding.

DNSSEC is powerless to protect it. However, DNS pinning can be implemented by browsers. That is, the browser caches the DNS domain name and ip address ing. Even if the local TTL of the dns server expires, the browser uses its own cached ip address to connect, that is, before the browser cache expires, no longer trust the DNS server's response.