Contents
5.3.1 Dropbox
We found that the Dropbox website was vulnerable to a variant of the Unexpired Email Change Attack.
Unexpired Email Change Attack.
As described in Section 4.4, the attacker could create an account using the victim’s email address. Dropbox would then send an email to the victim, asking them to confirm their email address. However, having not signed up for a Dropbox account, the victim might ignore this email because it did not give any instructions as to what they should do if they did not create the account. The attacker would then start the change-of-email process changing to the attacker’s email address, and Dropbox would send a confirmation email to the attacker’s email address (transition S 2 to S 6 in Figure 2). This email contained a URL to confirm the change-of-email, but the attacker would not yet use it. When the victim tried to create an account using their own email address, this would fail because the email is already associated with an account, and Dropbox would instead ask the victim to sign in to that account. The victim might then use email-based account recovery and set a new password, causing the attacker to lose access to the account. As shown in Figure 4a, alert victims might notice the pending email change notification in the user interface (UI) and cancel this. However, some victims might not notice this. Some time later, the attacker could make the victim visit the change-of-email confirmation URL (e.g., through a CSRF at- tack [13]), which would associate the attacker’s email address with the account. The victim would then see the UI shown in Figure 4b. The attacker could then use the email-based password reset feature to gain access to the account. As Dropbox is a cloud-based file storage service and an IdP, a successful attack could allow the attacker to access the victim’s private files and sign in to other services where the victim uses Dropbox as an IdP. However, observant victims might notice that the attacker’s email address is also shown in their account (pending confirmation), and might take action to remove this, which would block the attack. Furthermore, we were not able to test the validity period of the confirmation URL (and the confirmation email did not state a validity period). The validity period of this URL would also limit the possible window of attack.
We responsibly disclosed our findings to Dropbox via HackerOne in June 2021.
Session fixation attack.
During our experiments, we also discovered a session fixation attack against Dropbox, which allows an attacker to directly sign in to an existing Dropbox account by fixing the session ID [31]. When we reported this issue via HackerOne, it was marked as a duplicate as it had been concurrently reported by another researcher. Details of the concurrent report are not yet publicly available.