Last week, an untold number of Pinterest users were compromised by an attack designed to lure their Twitter and Facebook friends into a malware trap. Pinterest has yet to divulge what it knows about the apparent attack or publicly acknowledge that the attack even took place. Many unanswered questions remain about nature of the attack including what, if any personal information was compromised and what is being done to harden Pinterest's user accounts and infrastructure from similar attacks.
Despite multiple inquiries from ProgrammableWeb, Pinterest's lack of transparency has so far concealed the details of the attack in a shroud of secrecy. On the day of the attack -- June 4, 2014 -- in an indication that something questionable happened but citing nothing more than "strange activity," Pinterest emailed a password reset request to many of its users. However, that email neglected to mention that the strange activity may have resulted in a breach of those users' Pinterest, Twitter, and Facebook accounts. The email also offered no advice on what users should be doing to identify and address any collateral damage (eg: hacked user preferences). By the end of last week, most of the offending posts on Pinterest.com were deleted (or removed from public view) by the company. But evidence of the attack still remains on Twitter.
On the surface, the "MO" of the June 4 attackers is strikingly similar to that of an attack against users of the Buffer social post scheduling service on October 26, 2013. In both cases, the attackers targeted third-party services that can act as personal proxies capable of making posts to Twitter and Facebook as though the users of Twitter and Facebook were making the posts themselves. Buffer is one such service. Pinterest is another. Both attacks resulted in unauthorized "weight-loss" posts to Twitter and Facebook. According to reports, some Pinterest users fell prey to a similar weight-loss related attack earlier this year.
Back in October, Buffer was targeted for its ability to automatically mirror the same post to multiple social networks at the same time. The result was a highly scalable attack that loaded thousands of Twitter and Facebook accounts with links to supposed weight-loss solutions. By design, when posts (legitimate or not) are made to Twitter or Facebook by a proxy service, the proxy service leaves its fingerprints behind for all to see. As of the publication of this story, the fingerprints from last week's attack are still viewable on Twitter. Based on these publicly available "forensics," Pinterest was the apparent source of the offending posts. In the end, an untold number of unauthorized weight-loss-related "Pins" were posted to Pinterest user accounts (a Pin is to Pinterest as a Tweet is to Twitter). From there, those Pins were subsequently echoed to users' Twitter and Facebook accounts. In some cases that offered evidence of the degree to which the attack could scale, the attack resulted in multiple unauthorized posts (ProgrammableWeb observed as many as nine) to individual users' Twitter accounts.
However, unlike with the attack against Buffer where the attackers covered their tracks by sanitizing the weight-loss links before they could be investigated, the weight-loss links in this attack remained active long enough to be inspected for nefarious activity. ProgrammableWeb has learned that the Pinterest attackers were concealing malware behind those weight-loss links. The links that were posted to Twitter and Facebook led to Pins on Pinterest which in turn were linked to a fake women's health site, the domain name of which actually included the date of the attack: www DOT womanshealth.com-june-4 DOT us.
OAuth is an authentication technology that's often used in situations where proxy services like Hootsuite, Spotify, Buffer, Pinterest, etc. make posts to Twitter or Facebook without the need for the login credentials of the users they are representing. Whereas the attack on Buffer involved the "OAuth tokens" needed to authenticate with Twitter and Facebook without end users' IDs and passwords, the extent to which OAuth was or was not a key component of the Pinterest attack is unknown due to Pinterest's lack of transparency regarding the matter.
In its investigation, ProgrammableWeb learned from several impacted Pinterest users that their account preferences were changed in the course of the attack. Whereas any options to echo Pins to Twitter or Facebook were disabled before the attack, those same options were mysteriously enabled after the attack. However, it's unclear whether those user preferences were changed programmatically or manually. Pinterest did not advise users to double-check their preferences for unauthorized activity. It wasn't until ProgrammableWeb reached out to some of the impacted users that those users discovered that their accounts had been reconfigured.
Also unknown is exactly how the Pinterest user accounts were penetrated. Some, but not all of the victims interviewed by ProgrammableWeb reported that they enabled their Pinterest accounts for social login. In other words, they use their Twitter or Facebook credentials as opposed to a user ID and password to login to Pinterest. At least one victim interviewed by ProgrammableWeb received a notification from Twitter that their Twitter account had been accessed from an unusual location. Laying one possibility to rest, none of the victims interviewed by ProgrammableWeb reported personal usage of a third-party tool to add Pins to Pinterest. Had that been the case, it's possible that the attack could have piggy-backed the rights of that third-party tool.
Questions also remain around the potential automated posting of the offending Pins to Twitter and Facebook. Unlike the way Pinterest's user preferences can be configured to automatically echo all Pins to a user's Facebook timeline, there is no similar user preference for automatically echoing Pins to Twitter. Instead, echoing Pins to Twitter involves the ticking of a checkbox that appears as a part of the manual workflow involved in "Pinning" an image. In other words, echoing Pins to Twitter essentially requires manual intervention. The implication is that Pins that circumvent Pinterest's manual process (eg: Pins that are programmatically posted through Pinterest's API) can be echoed to Facebook but not to Twitter.
Given how the majority of unauthorized social posts went to Twitter (only one of the victims interviewed by ProgrammableWeb reported unauthorized posts to their Facebook timeline as a result of the attack), the circumstances call into question the extent to which Pinterest's API was used in the attack. While Pinterest offers no way of programmatically echoing both API- and manually-posted Pins to Twitter, there are auto-post workarounds on the Web. One workaround, for example, mashes a user's Pinterest RSS feed with the popular If This Then That platform (IFTTT.com).
Suspecting penetration of the database where Pinterest stores its OAuth tokens (as was the case in the attack on Buffer), ProgrammableWeb initially contacted Pinterest on June 4 (the date of the attack) to see if that database had been compromised. Company spokesperson Malorie Lucich replied saying that "We're looking into this issue. I'll share more info as soon as we have it." Lucich eventually followed-up saying "We haven't found any evidence of a database breach.... We don't have any further updates at this time." ProgrammableWeb replied on June 5 seeking clarification as to whether there was any breach at all. As of the original publication of this story, neither Lucich nor any other Pinterest spokesperson has replied.