Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mitigate CSRF and DNS Rebinding attacks #9353

Closed
zelivans opened this issue Feb 25, 2018 · 6 comments
Closed

Mitigate CSRF and DNS Rebinding attacks #9353

zelivans opened this issue Feb 25, 2018 · 6 comments
Assignees
@gyuho
Labels
area/security type/feature

Comments

@zelivans
Copy link

zelivans commented Feb 25, 2018 •
edited
Loading

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.

Example PoC:

<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.

Success example:
image

Whitelisting hostnames is a possible simple solution. See taviso's comment on this or the fix he sent to Transmission.
@gyuho gyuho self-assigned this Feb 25, 2018
This was referenced Feb 27, 2018
Merged
Merged
Merged
@gyuho
Copy link
Contributor

gyuho commented Mar 1, 2018

We've added --host-whitelist flag. This will be released in 3.4.

Thanks for report!

@sidhax
Copy link

sidhax commented Apr 3, 2018

any cve assigned to these issues ?

@zelivans
Copy link
Author

zelivans commented Apr 3, 2018

@sidhax I've attempted to assign CVE IDs through DWF but CoreOS is acquired by Red Hat so it was
forwarded to them and I wasn't yet informed of anything from their side

@pedrohc
Copy link

pedrohc commented Apr 3, 2018

Two CVEs were assigned for this:

CVE-2018-1098 etcd: Cross-site request forgery via crafted local POST forms
CVE-2018-1099 etcd: DNS rebinding vulnerability in etcd server

@zelivans
Copy link
Author

zelivans commented Apr 4, 2018

Thanks @pedrohc

@zhsj
Copy link

zhsj commented Feb 13, 2019

Hi, does this affect stable release? and is there any plan to backport the security fix, especially 3.2.x?

@zumbi zumbi mentioned this issue Feb 15, 2019
Closed
@yinzara yinzara mentioned this issue Apr 15, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gyuho gyuho

Labels
area/security type/feature
Milestone
No milestone
Development

No branches or pull requests
5 participants
@zhsj @sidhax @pedrohc @gyuho @zelivans