Biz & IT —

Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass

Accounts accessed from Wi-Fi hotspots and other unsecured networks are wide open.

Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass

Memo to anyone who logs in to a WordPress.com-hosted blog from a public Wi-Fi connection or other unsecured network: It's trivial for the script kiddie a few tables down to hijack your site even if it's protected by two-factor authentication.

Yan Zhu, a staff technologist at the Electronic Frontier Foundation, came to that determination after noticing that WordPress.com servers send a key browser cookie in plain text, rather than encrypting it, as long mandated by widely accepted security practices. The cookie, which carries the tag "wordpress_logged_in," is set once an end user has entered a valid WordPress.com user name and password. It's the website equivalent of a plastic bracelets used by nightclubs. Once a browser presents the cookie, WordPress.com servers will usher the user behind a velvet rope to highly privileged sections that reveal private messages, update some user settings, publish blog posts, and more. The move by WordPress engineers to allow the cookie to be transmitted unencrypted makes them susceptible to interception in many cases.

Zhu snagged a cookie for her own account the same way a malicious hacker might and then pasted it into a fresh browser profile. When she visited WordPress she was immediately logged in—without having to enter her credentials and even though she had enabled two-factor authentication. She was then able to publish blog posts, read private posts and blog stats, and post comments that were attributed to her account. As if that wasn't enough, she was able to use the cookie to change the e-mail address assigned to the account and, if two-factor authentication wasn't already in place, set up the feature. That means a hacker exploiting the vulnerability could lock out a vulnerable user. When the legitimate user tried to access the account, the attempt would fail, since the one-time passcode would be sent to a number controlled by the attacker. Remarkably, the pilfered cookie will remain valid for three years, even if the victim logs out of the account before then. Zhu blogged about the vulnerability late Thursday.

Update: In a statement emailed to Ars WordPress lead developer Andrew Nacin wrote:

Most issues Yan identified apply specifically to WordPress.com. WordPress.com is a hosted service by Automattic, and is independent from the WordPress open source project they contribute to and use. These issues should able to be fixed and deployed fairly quickly by Automattic's security team, though it seems like this was publicly disclosed without much forewarning.

Though the WordPress core software works fairly well over SSL now, there are a number of things we've already had slated for the next release to improve SSL support out of the box. I only wish having an SSL certificate were more commonplace.

In a Tweet made Thursday, Nacin, who contributes to the WordPress open-source project and doesn't work for for Automattic/WordPress.com, confirmed that "cookies can be replayed until expiration." He said a fix is scheduled for the next WordPress release. In fairness, the exploit doesn't permit attackers to change passwords, since that setting requires a separate authentication cookie tagged "wordpress_sec," containing the "secure" flag that causes it to be sent encrypted.

Fortunately, WordPress sites that are self-hosted on a server with full HTTPS support are not susceptible, as long as every page supports HTTPS and cookies contain the "secure" flag. Until a fix is available, WordPress.com users should ensure the site they're logging into contains the full HTTPS support. If not, users should avoid logging in on unsecured networks. Even when using networks they trust, users should be aware that privileged employees at ISPs and network providers are able to intercept the unencrypted cookie, and government snoops may be able to do the same.

Article updated in the last paragraph to add detail about full HTTPS support, add e-mail comment from Nacin.

Channel Ars Technica