On February 26th, WIRED’s security reporter Andy Greenberg received an email from Sophia Tupolev, the head of communications at the security firm Beame.io, saying she’d found a security issue on WIRED.com. Tupolev’s company had discovered sensitive data in the source code on many pages on our site, including obfuscated, “hashed” passwords and email addresses for current and former WIRED writers.
We corrected the problem right away. About two hours after we found out about the issue, we had a fix in place, and had cleared the data from the affected pages. Shortly thereafter, we invalidated everyone’s passwords, even though we believed the hashed passwords were relatively safe. Moreover, everyone accesses WIRED’s content management system with two-factor authentication. That makes it even more unlikely anyone breached our system, and in fact we’ve found no evidence that has happened. It did raise a concern with us, though, of what might happen if anyone was using those same passwords on other systems.
We sent emails to our writers explaining what had happened. People who still write for WIRED all had to change their passwords, and we suggested that if they used the same password for other accounts, personal or business, they might want to change them.
Since this security issue potentially affects people who had an association with WIRED but no longer do, we also decided to publish this article---hoping that if our other attempts to reach them didn’t work, perhaps this article would. Also, we believe in being transparent with you, our audience, and this kind of issue is exactly what we’d cover if it happened to someone else. Plus, it’s interesting.
To be clear: This situation did not expose the data of anyone in WIRED’s audience. The potentially exposed data was limited to users who write and edit stories on WIRED.com---people who use our content management system. This data has no relationship to our Ad Free customers or magazine subscribers. These systems are entirely independent.
Beame published an account of this incident on their website today. We've been waiting to publish this story until we notified affected individuals and saw the leaked data disappear from various web caches. These two tasks have taken considerable time.
Here’s a detailed account of what happened, and what we did about it.
While building a new part of WIRED’s website aimed at showing videos, we needed to create a button for viewers to load more videos onto the page. To create this “Load More” button, we needed to take data from a WordPress function called “get_queried_object.” Basically it retrieves data for the page you’re on---if the page is a single article, it’ll return the article content and associated metadata (e.g., publish time, author ID, last modified time). On a category page like “science” or “culture,” it returns the category information (e.g., description, ID, relationships to other categories).
For the “Load More” button to work, we needed to expose some of the data from “get_queried_object” to the frontend---in other words, we had to take the results of this function and embed it into our Javascript. By making this data available to our frontend JS code, we expose it in the public source code.
Our intention was for the queried object data to only be present on video category pages, but that’s not what happened. A conditional statement that should have only returned “true” on video category pages instead returned “true” on all pages. The data from “get_queried_object” was displayed on every single page across WIRED’s site.
That’s a problem because the queried object data for our writer pages includes all of the data for that user, stored in WordPress’ “users” database table. That includes the user’s email address and hashed password. All told, this information was available on roughly 19,000 pages for approximately 1,500 writers starting in June, when we built the video page, until we discovered the problem and corrected the code in February.
We already share writer email addresses publicly, so that wasn’t a problem. And we use two-factor authentication, which helped protect WIRED.com even if someone was able to reverse the password hashes.
But that said, the more worrisome part here was the combination of the password hashes---obfuscated versions of user passwords---in conjunction with email addresses.
After reviewing the algorithms we used to hash writer passwords, we recognized that with some effort, the hashed passwords could be potentially reversible. We invalidated all the passwords and sent emails to our writers explaining the situation.
We have taken a number of steps to limit the data exposure.
- We fixed the initial issue and cleared all caches under our control that contain the data.
- We attempted to clear search engine caches that may have the data, including Google, Bing, Yahoo, Baidu, Yandex and the Internet Archive.
- We regenerated all user passwords and required current users to go through a manual reset procedure.
- We updated our hashes to use a more sophisticated algorithm.
- We implemented stronger user requirements and internal controls for passwords.
In addition to these changes, we are reviewing our coding and other processes to help us avoid deploying code with security implications in the future.
