A security researcher is in a bit of a scrum with Facebook over vulnerability disclosures that not only tested the boundaries of the social network’s bug bounty program, but he said, also prompted hints of legal and criminal action.
Wesley Wineberg, a contract employee of security company Synack, said today in a personal blogpost and in emails with Threatpost that he had found some weaknesses in the Instagram infrastructure that allowed him to access source code for recent versions of Instagram, SSL certificates and private keys for Instagram.com, keys used to sign authentication cookies, email server credentials, and keys for more than a half-dozen critical other functions, including iOS and Android app signing keys and iOS push notification keys.
Wineberg also accessed employee accounts and passwords, some of which he cracked, and had access to Amazon buckets storing user images and other data prompting claims of user privacy violations from Facebook.
“To say that I had gained access to basically all of Instagram’s secret key material would probably be a fair statement. With the keys I obtained, I could now easily impersonate Instagram, or impersonate any valid user or staff member,” Wineberg wrote. “While out of scope, I would have easily been able to gain full access to any user’s account, private pictures and data. It is unclear how easy it would be to use the information I gained to then compromise the underlying servers, but it definitely opened up a lot of opportunities.”
It’s also how Wineberg arrived at that trove of Instagram keys that raised the ire of Facebook. Wineberg found three different issues, which he reported in three installments between Oct. 21 and Dec. 1. He was paid $2,500 for his first report, but the second and third reports prompted very different responses from Facebook, starting with a warning that Wineberg’s research had gone beyond the scope of the bounty program and ending with a call from Facebook CSO Alex Stamos on Dec. 1 to Synack CEO Jay Kaplan threatening legal and possibly criminal action against Wineberg.
In a statement published on Facebook, Stamos said that Wineberg’s exfiltration of user and system data was not authorized, nor was it ethical. He also alleges the Wineberg was not happy with the bounty he was paid and that Wineberg told Facebook he would write about the keys and other data he had downloaded. Believing Wineberg was acting on behalf of Synack, Stamos said that’s what prompted the call to Kaplan.
“I told Jay that we couldn’t allow Wes to set a precedent that anybody can exfiltrate unnecessary amounts of data and call it a part of legitimate bug research, and that I wanted to keep this out of the hands of the lawyers on both sides,” Stamos wrote. “I did not threaten legal action against Synack or Wes nor did I ask for Wes to be fired. I did say that Wes’s behavior reflected poorly on him and on Synack, and that it was in our common best interests to focus on the legitimate RCE report and not the unnecessary pivot into S3 and downloading of data.”
Stamos said Kaplan told him that Synack did not order, nor did it condone Wineberg’s research.
“Facebook’s concern seemed to be split between not wanting the data I obtained to be posted publicly, and not wanting the fact that I obtained it to be public,” Wineberg told Threatpost.
Facebook, meanwhile, responded with a statement and said that all of the keys Wineberg accessed have been rotated and all other avenues by which he was able to access Instagram’s infrastructure have been cut off. Facebook alleges that Wineberg withheld data on the vulnerabilities and overstepped boundaries established by the rules of the company’s bug bounty program. Facebook’s statement:
“We are strong advocates of the security researcher community and have built positive relationships with thousands of people through our bug bounty program. These interactions must include trust, however, and that includes reporting the details of bugs that are found and not using them to access private information in an unauthorized manner. In this case, the researcher intentionally withheld bugs and information from our team and went far beyond the guidelines of our program to pull private, non-user data from internal systems. We paid him for his initial bug report based on the quality, even though he was not the first to report it, but we didn’t pay for the subsequent information that he had withheld. At no point did we say he could not publish his findings—we asked that he refrain from disclosing the non-public information he accessed in violation of our program guidelines. We remain firmly committed to paying for high quality research and helping the community learn from researchers’ hard work.”
Wineberg’s odyssey begins with a tip from a fellow researcher of an Internet-accessible Instagram webserver running on an Amazon EC2 instance and running the Sensu monitoring tool. The accessibility of the site had already been reported to Facebook’s bounty program by the fellow researcher, but Wineberg picked up the trail and found a hard-coded Ruby token that was supposed to be secret. As it turns out, not only could the token be used to spoof session cookies, but Wineberg said he could use Ruby’s deserialization of session cookies for code execution. Using that vector, he was able to dump the contents of a local Postgres database to find 60 employee user accounts, including encrypted passwords, 12 of which he was able to crack, all of which he said where “extremely weak.”
He reported the Ruby token issue in the Sensu-based Instagram site on Oct. 21 and a day later, he reported that he was able to access the employee accounts. Facebook responded by putting the Sensu site behind a firewall and eventually paying Wineberg a $2,500 bounty (on Nov. 16). Wineberg, however, was notified on Oct. 28 that his report on the weak accounts went outside the scope of the bounty program without an explanation as to why, he said.
He did not stop there, however. Wineberg said that he looked at the Sensu configuration file and found an AWS key pair that listed 82 different Amazon S3 buckets, or storage containers. Access to all but one bucket was denied, but in that one bucket he found another key pair, which allowed him to read the contents of all 82 buckets. Wineberg wrote that he downloaded several buckets, some of which included the laundry list of SSL keys, credentials and other signing keys.
Wineberg published a few emails between himself and Facebook where Facebook says it discourages researchers from acting on the vulnerabilities they find and that his submission violated the program’s “expectations of preserving user privacy.”
Stamos, meanwhile, called Synack’s Kaplan—Wineberg is a contract employee and said he has permission to carry out this type of research on his own time—and told him that Wineberg had accessed Instagram employee and user data and said he did not want to involve Facebook’s legal team, and that he wasn’t sure about whether Facebook would need to involve law enforcement.
Wineberg said that he wanted to Synack to confirm Wineberg had not made any details public, that he had deleted all of the data he accessed and downloaded from Instagram, confirm that he had not accessed any user data, and agree to keep findings and interactions private and not publish them.
Wineberg wrote:
“In my opinion, the best course of action was to simply be transparent with all of my findings and interactions. I am not looking to shame any individuals or companies, but I do believe that my treatment in this situation was completely inappropriate.
I continue to hope that security research will be given appropriate recognition and legal protections. In the meantime, I believe that it’s the infosec community’s job to lead by example. I don’t think that threatening security researchers should ever be acceptable, and I believe that as a community we are better than that. I don’t need this write-up to act as a warning to other researchers; everyone is already aware of the risks that come with performing research. Instead, I hope that this write-up shows how far we still need to go as a community.”
Wineberg told Threatpost he has deleted all the data he obtained from the S3 server and said he would not make it public.
“There were really several weaknesses related to their Amazon hosting. While reconfiguring the Amazon access keys is easy, it is not clear if they fixed the other underlying issues,” he told Threatpost. “The underlying issues include a lack of access monitoring, so it’s also not clear if they were able to determine if the same type of vulnerability was ever leveraged by other attackers in the past.”
