DNS rebinding in 2k19, or how to really sweat by visiting a porn site


    Hello! Today we would like to tell you about an old and almost forgotten attack called DNS rebinding. The first conversations about it began in 2007, but then experts from the field of practical information security did not give it enough attention due to the peculiarities of the operation of this attack, as well as little tangible, as it then seemed, consequences. Today we will try to convince them of you, in particular, by demonstrating that in the modern world this attack has found a second wind and no longer seems so harmless.


    What is DNS rebinding?


    Consider the following scheme:



    We have a victim's computer with IP 192.168.0.2 on the local network, and it also has a router with the IP address 192.168.0.1. The purpose of the attacker who manages the server with the address 13.37.13.37 and the domain name hacker.com (also, our own DNS server containing information about the domain is spinning on the ip-schnick) is to gain access to the router in the local network.


    To use the DNS rebinding technique, we need to lure the victim to our malicious website. Suppose we succeeded.


    Let us now analyze in detail how the attack works.


    First of all, the browser accesses the DNS servers with an A-record request:



    A chain of DNS servers leads to our server, which, in turn, produces a standard response containing the true IP address of the malicious site, and also indicates the TTL we need, in this case 59.



    Next, the browser makes a standard HTTP request for the received IP.



    At the next stage, the server responds with an HTML page with javascript code that refers to our domain.



    Now, until the TTL expires and the user is on the site, the javascript obtained above will be executed. Once the TTL is over, the browser will make an A-record request again.



    At this time, our javascript continues to run, and the DNS server we manage will respond with an A-record with the IP address from the local network where the attacker wants to reach.



    Since the domain, port and protocol remain unchanged, the SOP is not violated, and as a result, the browser contacts the domain pew.hacker.com, but it will already knock on the cherished and inaccessible router.



    As a result, we calmly receive a response from the router and redirect it to us by embedding the corresponding functionality in the javascript code loaded earlier.




    So let's summarize the above:


    • The user visits the site, getting a real IP address and a short TTL
    • While on the site, the browser makes calls to the same domain where the user is located. As soon as the cache expires, the browser requests the domain IP again.
    • Next, our DNS server issues, instead of the real address, the IP address of the internal service (in our case, the router)
    • After the request goes over the domain to the router, the result is sent to us by javascript loaded in advance by the user.

    With this sorted out! Many may have a reasonable question: "So what?", Because for operation you need to know the internal IP addresses of the services, keep the user for some time, etc.


    Yes, however, with the arrival of streaming services, video hosting, good old porn sites and other platforms where people hang for a long time, the attacker will have enough time to launch an attack. As for addresses, they are often standard or easily predictable.


    But this is all in theory, but what about in practice? We selected the 4 most relevant areas in 2019, where incidents involving the DNS rebinding attack occurred:


    • Iot
    • Crypto wallets
    • Desktop applications
    • Clouds

    Let's look at each topic in order and find out whether everything is really so harmless?


    Iot


    Google home



    Google home is a smart helper from Google. This device has (or had in the past) an API that does not require any authentication to control the device. It provides a number of features, such as:


    • Playing content
    • Scanning
    • Reboot
    • Connection in WI-FI networks, etc.

    Approximate attack scenario: an attacker can de-anonymize a user by getting the coordinates of the nearest WI-FI points. Obviously, there is no VPN here.


    Sonos wifi speakers



    These columns from Sonos bring up a web server on the UPnP local network that gives access to a number of interesting pages:


    • 192.168.1.76:1400/support/review - spits out the output of some UNIX commands
    • 192.168.1.76:1400/tools - allows you to run some UNIX commands

    In this case, the attacker has the ability to execute the traceroute command to scan the internal network topology.


    Radio Thermostat CT50



    This is one of our favorite cases. This thermostat model also has an API without any authorization and allows you to change:


    • Climate mode
    • Temperature
    • Backlight mode and other settings

    As a result, an attacker can make his victim carelessly sweat, but seriously speaking, a similar attack on a thermostat, such as a medical institution, can lead to rather unpleasant consequences.


    Roku tv



    Roku TVs have the same ailment - API without authentication.


    The API allows you to:


    • Run various applications
    • Play content
    • Make search queries on the system, etc.

    In this case, the maximum that threatens the user is leakage of sensitive data, which is also unpleasant.


    Any WI-FI router



    This IoT-device today is at home for almost everyone. It's no secret that many ordinary users do not change the standard passwords from the admin panels of their routers. With the help of DNS, rebinding does not prevent us from trying to login with standard credentials and gain access to the admin panel. If the local IP fails to pick up, WebRTC comes to the rescue.


    Total IoT


    Let's highlight some of the features that DNS rebinding provides when working with IoT:


    • Ability to de-anonymize user
    • Ability to scan the local network
    • Mock user
    • Anything, depending on the functionality of the IoT device

    Crypto wallets


    Geth


    Now let's talk about cryptocrescents. The first case examined is a client for ethereum wallets called Geth. Here the pandora’s box is covered by the JSON-RPC service. First, let's see what it is. JSON-RPC is a remote procedure call protocol in JSON format. It looks like this:



    Most clients run this service on localhost: 8545, and it, in turn, provides a set of interesting features, such as eth_sendTransactionand so on.


    Now, an example of how one can, without the knowledge of the user and using a DNS rebinding attack, get his balance and wallet address:



    EOSIO keosd wallet


    Next in line is the client for EOSIO wallets. Keosd itself runs on localhost: 8900 and automatically signs any application activity for 15 minutes after entering authorization data. Having gone deeper into the API, you can again discover interesting functionality. For clarity, using the request shown below, you can get the user's public key:



    Crypto wallets summary:


    • an attacker could steal user money
    • an attacker can change various user settings
    • possibility of deanonymization user

    Desktop applications


    Transmission client


    I would like to start the block of incidents related to desktop applications with a relatively high-profile vulnerability in the Transmission torrent client.


    Here the problem lies in all the same JSON-RPC, which we reviewed a little higher. In this case, it allows you to change user settings, for example, change the folder for downloading files:



    On the one hand, it seems to be nothing serious, however, if you specify an smb share controlled by an attacker instead of a folder (if the client uses a Windows client), you can intercept the user's hash, which can be used later.


    uTorrent web client


    This friend has in his arsenal all the same JSON-RPC service that allows you to change the user's configuration files, as well as download files.


    In this case, authentication is required, but credentials are available from http://localhost:19575/users.conf. How can this be used?


    To begin with, we make the following request:



    After receiving the token, we change the download folder to the folder where the programs run at system startup are located:



    And finally, we give the command to download the required payload:



    As a result, it evil.exewill be launched after the next reboot.


    Minikube


    Minikube is a command-line utility for configuring and running a single-cluster Kubernetes cluster in a virtual machine on a local computer.


    It always hangs on 192.168.99.100, and the web interface is available on port 3000. As a result, the attacker has the opportunity to create a malicious container with a shared folder with the main system.


    The first step is to get the csrf token.



    Next, you need to create a container, and to do this, send the following request:



    Let's see what he does. In it, we indicate that when the container is started, we need to forward the reverse-shell, and also mount the Users folder from the main system:



    Ruby on rails


    There is a gem for the Ruby on Rails framework that allows you to execute Ruby code directly in the browser.



    Let's try to figure out what we need for this?


    First we need to go to a non-existent page:



    Next, we attempt to access the console through a browser:



    And finally, we form a request for the launch of the calculator application (in this example, the vector for MAC OS X):



    Blizzard Desktop application


    Not only developers and ordinary users are subject to DNS rebinding attacks, but also gamers. Here again, we meet with the problem of JSON-RPC service, sticking in this case on localhost on port 1120. The service allows you to make updates, change settings and other various service options.


    In this case, authentication is supported, but it is not difficult to pass it by making requests from localhost:



    As a result, you can achieve something like this:



    More details can be found here .


    Total for Desktop Application:


    • an attacker can get RCE on the main system (also do not forget about VM Escape)
    • an attacker could gain access to confidential data, etc.

    Clouds


    Well, and finally, the most interesting thing remains - the clouds. The bottom line is that cloud services are often used to host software that analyzes the users coming to the site. For example, by following the headless browser link from the Referer header, in order to snooze the resource from which the client went to the site. This attack vector can also be used, because in fact a headless browser is a full-fledged web browser without a graphical interface, but with support for DOM, JS, and everything else.


    Returning to our sheep, what can we do in this case? After all, to attack, we need to detain the user (in this case, the bot) on the page. Well, for this we can use on the page an image that has a Content-Length one more than it actually is. As a result, the bot will think that the picture has not yet been uploaded and will linger on our page, and further, we use our standard DNS rebinding technique.


    As a result, since we will send requests from a trustee, we can do a lot of fun things. For example:


    • scan internal network
    • log in to internal services (theoretically)
    • steal authorization data of other services, etc.

    Let's go back directly to Amazon. AWS EC2 has such functionality as Instance Metadata Service. It allows any EC2 entity to use the REST API, located at 169.254.169.254, revealing instance information.


    For example, here is a small list of similar services in different clouds:



    Now let's take a look at the case in which we’ll be pampered with AWS.


    First let the bot make a request to the API:



    In response, we can get confidential information, for example, the credits in the script, which starts at the start of the machine:



    Next, we can pull out the name of the node, from which we will continue to work:



    Next, we will make the following appeal on the already known name and - bingo!




    We received various user information such as AccessKeyId, SecretAccessKey, Token, etc.


    Having obtained this data, we can use it for authorization through the console client:



    The overall result:


    Let's highlight the common weak points that we noticed during the operation of a DNS rebinding attack:


    • API without authentication
    • Local services without authentication
    • Ignoring the Host parameter request
    • Using http instead of https

    Thus, despite various arguments from experts in the field of practical information security, an attack of this type is born anew in the era of IoT, cloud services, cryptocurrency, and so on, even despite the need to delay the client on the malicious side, because in the world of online cinemas, video hosting and other services that provide content to the user, make it easy. Therefore, be vigilant when traveling in the online world, when buying another smart assistant, and of course, during development.


    Sources:


    Tags:

    Also popular now: