Skip to main content

Bypassing WordPress Login Pages with WPBiff

Two-factor authentication protected WordPress login pages can be bypassed because of certain unsafe NTP practices.

The Internal clock of remote servers can be manipulated under the right conditions. Because certain WordPress Google Authenticator plugins also rely on the local timestamp, it opens up new ways to circumvent the user authentication process on the /wp-admin dashboard.

In the second part of the series, we demonstrate a practical attack against two-factor protected WordPress login pages. We are going to gain access to the dashboard without having access to the token generator app.

Quick Recap

In the first part of this series, we explored that two-factor authentication can be bypassed under the right conditions. This is because:

  • ntpd and ntpdate are vulnerable to MITM attacks
  • Tooling is available for exploiting NTP vulnerabilities
  • TOTP is vulnerable to timestamp manipulation

To put the theory into practice, we are going to bypass a WordPress dashboard login page protected by a favored third-party two-factor authentication plugin.

The Lab

We are going to need the following items to demonstrate the attack:

The network is quite simple as each Ubuntu VM is on the same subnet.

Network Diagram

Wait, What? WPBiff?

It is a new tool developed for this project. WPBiff brute-forces two-factor protected WordPress dashboards by iterating through every possible 6-digit Google Authenticator TOTP token. It supports two plugins: Google Authenticator and WP Google Authenticator.

Packages are available from PyPI and the source code is on GitHub.


In order to make this attack working, three preconditions must exist.

Firstly, we assume traffic is intercepted by the attacker (man-in-the-middle), who tampers with the NTP traffic. In order to simulate this, we modify the /etc/hosts file on the WordPress server.

Hosts File on WordPress Server

The second assumption is the sysadmin runs ntpdate every minute from the crontab to synchronize time. We have already seen that many people follow this practice.

Crontab on WordPress Server

The last one is that we already possess the login username and password (admin/admin) to the WordPress dashboard. In real life, the credentials can be obtained by phishing, key logging or exploiting password reuse.

Attack Walkthrough

As the first step, we spin-up Delorean to serve a bogus timestamp over NTP. WordPress will connect to this service every minute, and makes server time to roll back to the preset value.

Serving Time with DeloreanIn parallel, we fire up WPBiff on the other VM. We set the WordPress username, password, the same timestamp and the target URL. WPBiff starts monitoring WordPress and launches HTTP POST requests to the login page when the clock is rolled back successfully.

WPBiff in Action

After WPBiff running for 39 minutes, the utility successfully finds the valid 6-digit token. It also dumps the valid session cookies for the /wp-admin dashboard.


The token and/or the session cookies can be used to access the WordPress dashboard. Because this plugin does not allow to reuse the token, we just use the session cookies to access /wp-admin. The following images demonstrate the process:

WordPress Login Page

Adding Cookies from WPBiff

Accessing the Dashboard

An additional three tests managed to get the token in 51, 57 and 83 minutes respectively.


We have demonstrated that brute-force attacking against two-factor authentication becomes a viable operation if internal clocks can be tampered with.

By simulating a man-in-the-middle situation, we were able to manipulate the clock of a WordPress server with a bogus NTP service. As the two-factor authentication WordPress plugin relies on the TOTP algorithm, the same 6-digit verification token became valid again and again.

We exploited this situation by attempting to log in with each token from 1 million possible variations. The daunting task of brute-forcing had been automated with a new tool named WPBiff.

In the end, WPBiff managed to guess the verification code under an hour, so we were able to access the WordPress dashboard ultimately.


I want to thank Jose Selvi for his research as well as his kind help that helped me finishing the article.


wpbiff 0.1.1

This utility brute-forces two-factor protected WordPress dashboards by iterating through every possible 6-digit Google Authenticator TOTP token



wpbiff – WordPress Two-factor Authentication Brute-forcer

Update (12/11/2015): Coverage on The Register

Image courtesy of Leanne Chown

Share on LinkedInShare on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on RedditFlattr the authorEmail this to someone
Share This Post!


Founder of and, organiser of @CryptoPartySyd, privacy and infosecurity enthusiast | Threema: PRN7228A | PGP:

  • Very interesting article! It opened my eyes on something I wasn’t aware of.

    I’m the author of WP Google Authenticator. I usually like to see my plugin quoted in an article, except this one 😉

    One thing I will add it that, with WP Google Authenticator, you won’t be able to use the TOTP you found more than once because a valid TOTP is immediately blacklisted for a day after the first use.

    Now, as @konstruktors:disqus mentioned, this is a design feature of the protocol so I guess there is nothing I can do in the plugin’s codebase to avoid this kind of attack. Is that right?

    • Hey Julien, sorry about that 🙂

      You are right, the 6-digit token cannot be reused. However WPBiff dumps out the session cookie, so you can manually inject that into your browser with add-ons like Cookies Manager+. Then you can browse /wp-admin as normal.

      About what Kaspars mentioned, you are right, this is a weakness of the algorithm. The whole problem is that TOTP calculates the 6-digit code from something that was taken from an untrusted/unvalidated source.

      What could probably improve security here is implementing account-lockout policies. Now WPBiff runs circa 4,000 login requests / minute to brute-force the token. So if the WordPress plugin and/or WordPress itself locked the user account for a couple of minutes after 3-5 login attempts, the brute-forcing would take just too long to be viable.

      There is another approach: Google’s PAM module (used for protecting Linux/SSH logins) implements rate limiting. This plugin does not accept more than 3 login attempts / every 30 seconds.

      • Michael T. Babcock

        I’m a little shocked to say the least that the process doesn’t impose a delay on failed attempt sources. If IP address fails a connection, make them wait 1 full second per failure up to 30 seconds before they can try again.

  • There are many more interesting things you can do if you’re able to “stop the time” or edit /etc/hosts of a server 🙂 TOTP is specifically based on the host timestamp so this is a design feature of the protocol and not a security flaw.