Keypoints
- TOTP generates time-based 6-digit codes from a shared secret and is commonly used because it’s simple to implement.
- Lack of rate limiting on TOTP verification enables attackers with valid credentials to brute force codes.
- CVE-2023-43320 (Proxmox) allowed unlimited TOTP attempts, enabling both brute-force access and potential DoS for legitimate users.
- The author demonstrated a multithreaded Python script that iterates through 6-digit tokens against the /api2/extjs/access/ticket endpoint to find a valid TOTP.
- Proxmox mitigated the issue by imposing attempt limits, requiring an additional 2FA method, and disabling TOTP after repeated failures until re-enabled via another factor.
- Stronger alternatives include push-based flows that require a user action tied to an on-screen value, and phishing-resistant methods like FIDO/WebAuthn or PKI-based authentication.
MITRE Techniques
- [T1110] Brute Force – Used to guess 6-digit TOTP codes by submitting many attempts (‘I had just sent 100 TOTP attempts. Would the app still let me authenticate? Why yes, it did.’).
- [T1078] Valid Accounts – Attack assumes attacker already possesses valid username/password pairs to perform TOTP brute force (‘an attacker with knowledge of a valid credential pair could brute force the PIN’).
- [T1059.006] Command and Scripting Interpreter: Python – The exploit was automated with a concurrent Python script that cycles tokens across threads (‘This Python script utilizes a concurrent approach with multiple threads to attempt various TOTP codes …’).
- [T1499] Endpoint Denial of Service – Unlimited authentication attempts could create a denial-of-service condition for legitimate users (‘allowed for DoS attacks due to unlimited TOTP authentication attempts’).
- [T1190] Exploit Public-Facing Application – The vulnerability abused Proxmox’s web authentication flow to resubmit the same 2FA request repeatedly (‘during the 2FA portion of the authentication process, I was able to submit the same request multiple times’).
Indicators of Compromise
- [Vulnerability] CVE identifier – CVE-2023-43320 (Proxmox TOTP unlimited attempts leading to brute force/DoS).
- [API endpoint] Exploit target – /api2/extjs/access/ticket (used by the Python exploit to submit TOTP tokens).
- [Target URL placeholder] Exploit script target – https://HOST:PORT (script placeholder for victim host), and other target-specific parameters in the provided code.
- [Source URL] Article/source – https://www.netspi.com/blog/technical/web-application-penetration-testing/why-totp-wont-cut-it/ (original post describing the issue and exploit).
TOTP generates short-lived numeric tokens from a shared secret and the current time, which servers verify by recalculating the expected value. When implementations do not enforce rate limiting or protect the 2FA submission flow, an attacker who already has valid username/password credentials can automate repeated submissions of 6-digit tokens until one succeeds. The author reproduced this by abusing Proxmox’s 2FA flow to resend the same request multiple times and demonstrated that a multithreaded Python script cycling through zfilled 6-digit tokens could authenticate within practical timeframes (testing showed success in around 12 hours at ~10 requests/sec).
The supplied exploit automates ticket refreshes and posts to the /api2/extjs/access/ticket endpoint using concurrent threads; success was detected by response length, and the script continuously refreshes session tickets to maintain attack throughput. This pattern illustrates three operational failures: lack of server-side rate limiting, permissive 2FA submission handling, and reliance on a short numeric secret as the sole second factor. Proxmox’s remediation added maximum attempt limits, required an additional 2FA method to enable TOTP, and disabled TOTP on repeated failures to mitigate brute force and DoS risks.
For mitigation, implement strict rate limiting and account lockouts tied to abnormal 2FA attempts, require a secondary independent factor before enabling TOTP, and prefer 2FA methods that bind a user action to a challenge (e.g., push with a code displayed in the browser and entered into the authenticator). For higher assurance, adopt phishing-resistant mechanisms such as FIDO/WebAuthn or PKI-backed authentication, which avoid shared-seed one-time codes and reduce the effectiveness of credential-plus-code brute-force workflows.
Read more: https://www.netspi.com/blog/technical/web-application-penetration-testing/why-totp-wont-cut-it/