Headline

CVE-2018-1098: Mitigate CSRF and DNS Rebinding attacks · Issue #9353 · etcd-io/etcd

A cross-site request forgery flaw was found in etcd 3.3.1 and earlier. An attacker can set up a website that tries to send a POST request to the etcd server and modify a key. Adding a key is done with PUT so it is theoretically safe (can’t PUT from an HTML form or such) but POST allows creating in-order keys that an attacker can send.

6 years ago

CVE

Open in Source

#csrf #web #auth

After explaining the issue in private with the security mailing list, we determined it is low enough in severity to make it a public discussion.

This issue is relevant only to etcd deployment on local networks with no authentication scheme set up. It may not be a common scenario but it affects anyone who work with etcd locally or on a local network and use it without authentication, which is the default. For the sake of demonstration, I’m using a scenario where etcd is deployed on localhost. This can be any LAN address though (the attacker would have to know the address as a perquisite, but localhost is pretty common).

The first issue is with CSRF. An attacker can set up a website that tries to send a POST request to the etcd server and modify a key. Adding a key is done with PUT so it is theoretically safe (can’t PUT from an HTML form or such) but POST allows creating in-order keys that an attacker can send.

<html>
    <body onload="document.forms[0].submit()">
        <h1>CSRF</h1>
        <form action="http://localhost:2379/v2/keys/bla" method="POST">
            <input type="hidden" name="value" value="MALICIOUS"/>
            <input type="submit" value="Send"/>
        </form>
    </body>
</html>

The second issue is with DNS rebinding. It essentially means an attacker can control his DNS records to direct to localhost, and trick the browser into sending requests to localhost (or any other address).

There are many resources on how this attack works.

PoC here (based on taviso’s work). If the issue is unclear though please let me know and I will explain the attack in further details.

Whitelisting hostnames is a possible simple solution. See taviso’s comment on this or the fix he sent to Transmission.