EteSync is a software for end-to-end encrypted data synchronization. The idea is great. The implementation might be decent, but not perfect. I’ve discovered some vulnerabilities, reported them, but they weren’t fixed within the 90-day deadline. At the time of publishing, I saw no indication of fixes coming in a near future, so I decided to publish the vulnerabilities in order to inform users. After publishing this report, the vulnerabilities got fixed and a new version of EteSync DAV bridge was released.
What is affected?
EteSync consists of multiple components, e.g. Android app, iOS app, DAV bridge, server etc. The vulnerabilities directly affect just the DAV bridge. However, even if you don’t use EteSync DAV bridge, you might be somewhat affected:
While I don’t think the DAV bridge is used as a component of some other app, I am not 100% sure.Update: developer has confirmed that other apps aren't affected.- More importantly, the reaction raises questions how would be future reports processed. While I’d like to use EteSync, I can’t recommend it until I see more active development of EteSync or its fork.
The vulnerabilities
While none of the vulnerabilities look horrible on its own, they can be chained together. When an attacker knows your username and persuades you to open malicious website (without any extra permissions), they can connect to etesync-dav (even if it listens just on localhost) and extract sensitive data. Modification of the data wasn’t tested, but it might be possible. Potential techniques that would allow the attacker to guess the username haven’t been much investigated.
1. Incorrect password validation
When you log into EteSync DAV bridge, you get another password, which
allows you to access the DAV endpoints and the EteSync DAV bridge web
interface. This password is different from the encryption password and
is only meaningful when interacting with the bridge. While the DAV
endpoints seem to validate the password, the web interface actually
accepts any password, which consequentially breaks the security of DAV
endpoints (see below).
I’ve briefly looked at the implementation. It seems that the bridge
validates the password against the EteSync server. This is wrong,
because the password should be validated locally and EteSync server
doesn’t care about it. Unfortunately, the endpoint ignores the
credentials and returns a 200-ish response, which makes the EteSync DAV
bridge consider the credentials as valid. My initial understanding of what happens was probably wrong, I'll investigate it later.
While the DAV endpoints seem to validate the password properly, they aren’t secure, though. After the attacker logs in to the web interface with any password, the web interface provides them the correct password that can be used with the DAV endpoints.
2. DNS rebinding AKA “But it listens just on localhost, doesn’t it?”
Unfortunately, even if your instance of EteSync DAV bridge listens just on localhost, it doesn’t mean it is properly protected. Web is a complex thing and there are techniques that allow you accessing some server indirectly through a confused deputy. In this case, attacker can abuse victim’s web browser as a proxy to EteSync DAV bridge through DNS rebinding attack.
Fixing the vulnerabilities
Fixing shouldn’t be hard.
- DNS rebinding attack can be resolved by proper Host header validation. Unrecognized non-IP Host headers are a sign of a potential DNS rebinding attacks. Rejecting requests with bad Host headers (and maybe requests with no Host header) resolves DNS rebinding attack.
Password validation is already implemented for the DAV part, so we can reuse it.
However, I was unable to build etesync-dav (commit b9b23bf6fba60d42012008ba06023bccd9109c08) from source even without any modifications:
% pip install -r requirements.txt
…
ERROR: Cannot install -r requirements.txt (line 31) and itsdangerous==2.0.1 because these package versions have conflicting dependencies.
The conflict is caused by:
The user requested itsdangerous==2.0.1
flask 2.3.2 depends on itsdangerous>=2.1.2
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflictsUsing venv doesn’t help, neither does using other distro (Debian instead of Fedora). Unfortunately, I have not received further guidance from the developer. I could have dug deeper and fix the dependency issue, but I wasn’t dedicated enough to do it.
Developer response
The vulnerabilities were reported according to security.txt on 14th August 2024 with deadline set to 12th November 2024, giving the developers about 90 days. (Well, rounded to 90 days.). I got the first response on 1st September 2024. At beginning, it looked promising, but the conversation faded away. The developer seems to be busy with other things. I have to admit that part of the delay was caused by me, as I wasn't very responsive in September.
After publishing the vulnerabilities, I got a reaction from EteSync developer, clarified what was unclear and the developer released fixes for those vulnerabilities.
Fixes by developer
Password validation bug is fixed. DNS rebinding is fixed partially, i.e., DAV endpoints aren't protected from DNS rebinding yet, but this shouldn't be an issue when authentication works and DAV password isn't leaked.
Recommended actions for users
Stop using EteSync DAV until those vulnerabilities are fixed.Upgrade EteSync DAV bridge and regenerate DAV password by re-adding your account.- Consider stopping using other EteSync clients until there is some evidence that they are maintained. Unfortunately, I don’t have any suggestion for direct alternative. While DecSync CC + Syncthing looks like a good alternative, the development activity doesn’t look encouraging. Moreover, I am not sure about soundness of their data model, considering that the file synchronization might occur in any order, which might introduce various edge cases.
Request for developers
While I am still grateful for developing the awesome product and I understand that you are busy with other tasks, I unfortunately cannot currently recommend EteSync. Adding some other people who can properly respond the vulnerability reports and fix the vulnerabilities can make EteSync great again.
Update history
- Fix was released
- Developer communication
- Understanding of the password validation bug
