Responsible disclosure: EteSync vulnerabilities

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

Using 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

Password protection for purchases in Google Play can be bypassed. (And some other issues.) How to defend yourself?

Google Play allows you to buy apps, books and music. Once you enter a payment method, (e.g. payment card or carrier invoice), it is saved, so you can use the same payment method in the next purchase. Google offers password protection for that. It sounds great, but it can be bypassed. We actually don't have an additional security, but an unkept promise, which may have the opposite effect – the user might rely on the security enhancement, which does not work correctly.

There is an extra issue for users with multiple Android devices. The thief of one device can install apps on the other devices of that user. I'll also mention another related issue, but the last one is fixed.

This is just a warning about security issues, not a manual for the abuse.

This article is a translation (with minor modifications) of my recent article. I am sorry for the delay, I hoped to release this article sooner.

Google will not fix it.

Well, there were also some related issues in two-factor authentication, but Google fixed them quickly after they were reported. Google however refused to fix two Google Play related issues I will talk about.

By the way, Google has paid a bug bounty and listed me in the Hall of Fame, but they said they were happy with the current situation.

Where is the merit of the issue?

Google Play allow us to purchase some content using the Google Play application for Android, which is usually password protected. I haven't looked in the details of password verification, but I hope this is designed correctly. However, this is not the only way I can buy an item in Google Play. I can also use the web interface on https://play.google.com/. The web interface does not require the password for buying an item.

Moreover, the attacker does not need the victim to be logged in a Google account in a browser on the stolen device. Once the Google account is present in the device (which very likely due to the connections to the Android ecosystem), we can use the account also in a web browser. We just need a tool, which is often pre-installed in Android devices. I am talking about Google Chrome for Android, which suggest the attack when you are on the Google login page:

Well, it is unclear from the screenshot if there is a real attack possible. For example, Google might consider this login method to be something inferior, so Google would ask for password when buying an application. This is, however, not the case. Google allows you to use this passwordless login for buying apps without knowing the password.

There is one more issue. The attacker can install any application (paid or free) on other devices of the victim. For example, If you have your tablet stolen, the thief might abuse this feature for spying your phone.

How could Google fix it?

I've suggested some countermeasures:

• Remove the passwordless login feature. This would surely mitigate these attacks, but it costs too much of user convenience and there are some more convenient ways.
• If user uses the passwordless login, the Google Play webapp would require the user's password for any application installation request. If user logs in with the password, Google would allow installing apps without entering the password again.
• The password would be required always when the user purchases some item in Google Play.
• Some combination of the above. My preferred approach is asking for password when user buys an item (regardless the authentication method) and asking for password when installing any application (either paid or free) on a remote device using the passwordless login feature. However, when user uses, say, Firefox for Android, so he can log in only with the password-based authentication, he would allow the attacker to install any free application on other devices of the victim.

How can I defend myself?

First, when you lose an Android device, you should change your Google account password as soon as possible. (I also recommend changing all the passwords of other affected accounts, not just the Google account.) This performs a remote logout on the Android devices.

Screen lock might help, but it can be bypassed in general. In some cases, it might be very easy, e.g. on phone with enough access to recovery. In some cases, it might be hard, but one can disassemble the phone and directly access the flash memory. (Well, this extreme case is hard and might not be worth the cost.) Nevertheless, screen lock is likely to discourage some people.

Remote wipe tools can also help, but they should not be a primary countermeasure for this issue. First, I advise you to change the password regardless of remote wipe tools, because you can never be sure if you have it done in time. Moreover, I am not aware of any secure delete functionality in Android remote wipe tools. Of course, when you change the password, there might be still some other reasons for doing a remote wipe, so I don't suggest remote wipe tools to be useless. They are useful, but you should not rely on them too much…

And of course, the best countermeasure is not having your device lost :)

Issues outside the Google Play

Of course, there are some other parts Google ecosystem affected by passwordless login.

Two-factor authentication

There are some apps (e.g. Android) not supporting the two-factor authentication, so Google allows you to generate an application-specific password for these purposes. In order to generate an application-specific password, you have to re-enter your password, which is good. However, it used to be enough to use the password-less authentication in Android for generating new application-specific password. This could be abused by a thief of an Android device for having an access to the account even after the user changes the password.

Well, Google sends an e-mail when user generates a new application-specific password, but the attacker is very likely to have access to his GMail account, so he can easily delete it.

It is worth noting that this used to be also an issue for Android non-users. An adversary was able to abuse this feature for cloning an application-specific password and use the cloned one even after the old one is revoked. Some social engineering (like choosing a good name for it) might be needed for successful attack.

Fortunately, this issue was fixed quickly after I reported it.

Access to history and some other more protected data

Google tries to protect some data more than others. For example, when you go to https://history.google.com/, Google is likely to require your password even if you are logged in. The passwordless login seems to weaken this extra protection. Google sees this to be just a feature, not a bug. You can see the history data by using Google Search app. So, mobile devices (including tablets) seem to have a different security policy from desktops. It might be confusing, but we should be aware of it.