Because of unsafe NTP practices, internal clocks on remote machines can be manipulated under the right conditions. Once time is altered, expired SSL certificates become valid again and causes HSTS policies to expire.
But what about authentication? Certain TOTP implementations such as popular WordPress plugins also rely on the local timestamp.
This two-part article demonstrates a proof of concept for accessing two-factor authentication protected WordPress dashboards.
The Achilles’ Heel of TOTP
Google Authenticator and many other token generators rely on the TOTP algorithm. In a nutshell, the logic takes a secret key and the local Unix timestamp every 30 seconds to generate the well-known 6-digit code.
One weakness of TOTP is that the same combination of secret key and timestamp always generates the same 6-digit code. If the internal clock was moved back on a device, the 6-digit codes from earlier would become valid again.
This opens up an opportunity for brute-forcing attacks. If the clock was fixated to a certain timestamp, the token would become constant with just 1 million variations (i.e. 000 000-999,999) to be tried out.
Manipulating Server Clocks
In the past year or so, multiple studies, whitepapers, and presentations demonstrated the risks of unauthenticated NTP traffic.
In 2014, Delorean was published, which serves fake timestamps over NTP to its connecting clients. A paper came out this October with the title of Attacking the Network Time Protocol that details a few additional attack vectors concerning NTP. (Update 12/11/15: the paper is partly based on Jose Selvi’s presentation at DEF CON 23)
By combining these with various MITM techniques, an attacker could potentially gain control over the clock of a remote server under certain conditions.
NTP vs. ntpdate
Clocks can be manipulated with the standard ntpd daemon. Unfortunately, the service does not accept bogus timestamps from NTP servers like Delorean because of some validation algorithms. It is still doable however by remotely crashing and force-restarting the daemon, combined with vulnerabilities like CVE-2015-5300.
On the other hand, setting time with ntpdate is more straightforward. Since it was meant to sync time on a one-off basis, ntpdate simply accepts anything from the upstream NTP service. So if we could serve a fake timestamp with Delorean, ntpdate would blindly accept that.
Dangerous Sysadmin Practices
Apparently, people tend to use ntpdate as a drop-in replacement for ntpd. The bad practice of running “ntpdate <hostname>” from the crontab file is recommended by the Ubuntu Wiki, the official Chef cookbook, and countless of tech and personal blogs.
IoT OS-maker Yocto Project also uses crontabs to keep the clocks updated, like OpenWRT. Startups also update the clocks on their WordPress hosts with cron. Configuration guides of VPS providers also recommend this broken practice.
Oh boy, but it was already told in 2002 that running ntpdate as a cron job was not a good idea.
Theory of Attack
Let’s recap what we have so far and how we could utilize them to bypass TOTP enabled two-factor authentication.
- ntpd and ntpdate are vulnerable to MITM attacks
- Tooling is available for exploiting NTP vulnerabilities
- TOTP is vulnerable to timestamp manipulation
Breaking into WordPress
Several plugins exist for bolting two-factor onto WordPress. Many of those rely on TOTP and the internal clock to calculate the 6-digit code.
The most popular TOTP implementation is probably the Google Authenticator add-on from Henrick Schack. It modifies the login page on wp-login.php as seen on the screenshot below. The user needs to enter a 6-digit code in addition to the username and password.
This plugin takes the timestamp from the underlying server’s clock for calculating the 6-digit passcode. If the user-supplied token from the login page matches the generated one on the server side, the user is redirected to the admin dashboard.
But what if we could control the internal clock on the WordPress server? The assumption is that if we could re-adjust the server’s clock over and over again, the WordPress plugin would generate the same 6-digit token that never changes.
In plain English, the 6-digit code would become brute-forcible. There would be only 1 million token variations, which is a simple job to try each of them out.
In the first part of the article, we have reviewed an attack theory of brute-forcing 6-digit authentication tokens.
We identified that TOTP is vulnerable to time-manipulation attacks. With the combination of recent ntpd vulnerabilities, bad sysadmin practices, known MITM techniques and special NTP tools, we can make the brute-forcing of 6-digit tokens a viable operation.
In the second part of this article, we put the theory into practice. We will demonstrate a practical attack against a WordPress dashboard protected by two-factor authentication. We will also introduce a new CLI tool that automates the brute-forcing process.