Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Security report: user-enumeration vulnerability at login

Report ID: teamwork-2019-01-25a

Researcher name: Julien Cretel

Researcher email: jcretel-infosec@protonmail.com

Date: 25/01/2019

Status: fixed (last checked on 22/02/2019)

Vulnerability

Teamwork's login page is vulnerable to user enumeration: it discloses whether an email address is associated to an existing Teamwork user; see this video.

Moreover, the presence of test user accounts (of the form a@a.com) in the system reveals the name of Teamwork teams, which can themselves be targeted; see this video.

Note: user enumeration is also possible via the "Link accounts" feature in Teamwork Projects, and possibly elsewhere within the Teamwork suite. An attacker can easily access that feature by creating a dummy, free-trial account.

(All my Youtube videos are unlisted.)

Risks & threats

This vulnerability can be exploited by attackers in different ways, including

  • spearphishing,
  • password guessing,
  • slow brute-force attack,
  • denial of service.

Spearphishing

The attacker targets specific users to get them to reveal their Teamwork passwords. See this video, in which I identify the email addresses used by prominent Teamwork users from the testimonials section of the home page.

Credential stuffing

Because password reuse is common, the attacker checks whether the email address of a Teamwork user was involved in a data breach and, if so, looks up her passwords in data-breach dumps and tries them on teamwork.com. See this video.

The resulting dictionary per user should be small enough to render the brute-force protection put in place by Teamwork ineffective.

Slow brute-force attack

The attacker builds a large list of Teamwork users, then rotates through them, testing one password for each email at a time. To circumvent the brute-force protection put in place by Teamwork, the attacker tries to log in with a given email address no more than once per minute, in order to wait for the counter to reset (see x-rate-limit-reset response header). Nothing prevents the attacker from trying to log in with other email addresses in the meantime.

Because of insufficient password-strength control (a 6-character alphabetical password is deemed acceptable), a slow brute-force attack is likely to yield access to some accounts quite quickly.

Denial of service

Six failed login attempts (in quick succession) for a given user email address for a given team will result in locking this account out for 30 minutes. An attacker can easily abuse this protection to lock a user out indefinitely. See this video.

Because the login page is not protected by any CAPTCHA, such an attack can be automated, run every 30m and against a large number of Teamwork users.

Remark on attacker profiles

The possibility of competitors launching such attacks, with a view to damage the Teamwork brand, should not be dismissed. Anticompetitive tactics of this kind, even stemming from such large companies as Uber, are not unheard of.

Remediation

At login, test the email-password pair at the same time, rather than email and then password. Within the app, don't allow authenticated users to ascertain the presence of a user within the system. Use CAPTCHAs at login.

Resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.