When white hat hacker OJ Reeves publicly disclosed a remote code execution vulnerability in Seagate’s Network Attached Storage (NAS) device software, along with two fully operational exploits leveraging the flaw, he didn’t do it out of malice. Or to put innocent users at risk. Or to mar the company’s reputation. He did it as a last resort.
“In my opinion, not all vendors are equal. Not all software is equal. Not all devices are equal. Not all bugs are equal,” Reeves told iDigitalTimes. “To me it doesn’t necessarily make sense to treat all disclosures as equal. The hardest part is knowing how long to wait before going public.”
Despite 130 days of responsible disclosure proceedings by Reeves the vulnerability remains, as of March 1, unpatched. Thousands of users are currently at risk.
Seagate is a well-known vendor of hardware solutions, with products available worldwide. It is the #2 supplier of storage hardware holding 41 percent of the market worldwide. Seagate’s storage shipments grew 17 percent last year to 61.3 exabytes.
Seagate's line of NAS products targeted at businesses is called Business Storage 2-Bay NAS and comes with a web-enabled management application software that allows administrators to perform device configuration functions such as adding users, setting up access control, managing files, and more. These devices can be found inside home and business networks, and in many cases they are publicly exposed. It is in this line that Reeves found and tested his software vulnerability.
By going public, Reeves hopes to force Seagate’s hand to make the necessary changes. It’s a common strategy in the world of responsible vulnerability reporting.
The zero-day vulnerability Reeves disclosed allows any attacker on the same network as the vulnerable devices to take complete control of the devices as root user, without requiring a valid login. All the attacker needs to do is make their way to the application’s front end and profit.
“It’s basically a ‘push button, receive bacon’ situation,” Reeves said.
There is a wide range of sinister deeds, including stealing data, completely wiping the memory of the device, using it to mine Bitcoins, create botnets or host malware and illegal files, that can be leveraged through this vulnerability. In addition, Reeves shared that Seagate’s NAS boxes use a weak hashing mechanism for passwords, which could lead to wider-spread security problems.
“We all know what people are like for reusing passwords,” said Reeves. “If the NAS is compromised attackers can easily crack the unsalted MD5 hashes to retrieve the original passwords, then they can reuse those credentials elsewhere.”
“As far as CVSS scores go, it probably doesn't get any worse,” Reeves said.
Reeves wrote in his public disclosure advisory that the vulnerability affects the latest Seagate NAS firmware version, and likely all previous versions too. Reeves tested his exploitation tool on two different network storage devices made by Seagate and found both to be vulnerable. After conducting a Shodan query of the NAS box models he used during testing, Reeves found approximately 2,500 of those boxes were currently on public Internet networks. That left them wide open to attackers. Since the software used on the tested devices is also used on numerous other Seagate products, Reeves feels certain the problem extends even further.
The information is significant and will likely cause a stir in the Dark Web, as unethical hackers will get to work leveraging the tool against unsuspecting victims.
But white hat hackers are supposed to be good, right? Then why put thousands of users at risk? Is it for notoriety? Spite? To collect a ransom of some kind? No. For Reeves, the decision to publicly disclose the vulnerability has been a painful one. One that he has agonized over for the last 130 days of disclosure proceedings.
Since establishing contact with Seagate last October, Reeves admits, he’s had a pretty frustrating experience.
“The interaction I had with them for the first 30-60 days was really quite terrible and for a long period of time I failed to even get past front-line support.”
Reeves began his disclosure process by searching Seagate’s website for security contact information, but failed to locate anything other than an insecure support portal.
Reeves then headed to Twitter, hoping he might have better luck there. After unfruitful interactions with @askseagate, he decided to post his concern on the portal and see what would happen. The results were less than thrilling.
“We had some back and forth over a period of weeks,” Reeves said. “I was asking questions like 'can you validate that you are able to exploit your devices using the script that I've given you' and at no point did they appear to attempt to use what I had told them. Instead, they just came back with questions like, ‘are you storing passwords in a browser’, and ‘are you using ssh’ -- questions that implied that they had no idea what I was disclosing to them.”
Reeves went above and beyond with the kind of information he had shared, describing the problems in detail and providing suggestions for solutions.
“I gave them a proof of concept exploit, and a 3-4 page diatribe in fairly technical detail as to why these issues existed. I told them about design decision in their code, I told them about the technologies that it all sits on and why they weren't an appropriate choice,” he said. “It wasn't just a ‘hey your stuff isn't working,’ it was a really big attempt to make sure that they understood what was happening. Part of my frustration at that point came from the fact that it felt like they didn't read it.”
It was now mid-December and Reeves decided to search for a proper contact via LinkedIn, but to no avail. Frustrated, Reeves took to Twitter to blow off some steam and piqued the interest of an individual who had contacts within Seagate.
“I had ranted a little on Twitter and a guy answered me asking what issues I was having and who the vendor was,” Reeves said. “We talked to each other privately and he said he might know someone in there that could help me and put me in touch with them. When I contacted the individual, he jumped right on it, said he was the guy I needed to reach and gave me his PGP key.”
Now that he made meaningful contact with someone inside Seagate, Reeves began to feel optimistic about the situation.
“I was pretty excited about that response,” said Reeves, who had now been interacting with the company for 85 days, “but I was also pondering what to do with the initial timeline, because I gave them a 100-day deadline. I didn't feel it was right to hold this guy to the same timeline as I was holding the other people because he wasn’t made aware of the issue until 85 days in. At the same time, I couldn’t just keep extending timelines by 100 days -- I needed to put pressure on them to fix this because I had clients who were vulnerable. There are also about 2,500 instances of this device currently public facing and that can be popped fairly easily.”
Hoping to reach a fair deadline, Reeves consulted several security professionals and decided to extend it by 30 days. The extension allowed Seagate 45 days to release a patch. Reeves then re-sent the information he had initially posted on the support forum along with an updated exploit.
Reeves heard back from the Seagate security contact within a couple of days. The situation continued to look positive.
“He responded and said ‘yeah, we've used your exploit and we can see that things are vulnerable, we're on it,’ and I thought, ‘wow, that's the most feedback I've had so far’, so I was really quite happy with that.”
For the next couple of weeks, Reeves received several emails from the Seagate security contact, affirming that they “were on it” and didn’t need anything else from Reeves. Then, suddenly, everything went silent.
On February 16, with the deadline less than two weeks away, Reeves emailed Seagate’s security team asking for an update on the fix. He received no response.
“The last time I heard from him was on the 5th of February,” said Reeves. “It would have been nice to know where things were at because the disclosure date was approaching -- of which he was fully aware."
Speaking with Reeves, it’s obvious he was torn about the decision to disclose. But the situation left him with no other alternative.
“They’ve been silent on what is going on behind the scenes. There is no visibility of a timeline for having things fixed. There is no indication of whether they are working on a fix or if they were even going to fix the problem at all. I'd given them all this information and all I got back was a ‘thanks, we're working on it’.”
We asked Reeves how his decision might have changed if communication had been better, and Reeves asserted that it would have made all the difference in the world.
“To be honest, if they said they were going to release a patch in a week and they didn't have any evidence to back it, I would have still held off on disclosing publicly,” said Reeves. “If they came to me and said ‘look, we can't match your timeline but in the next two weeks we'll have a version that will fix 80 percent of the issues’, I'd wait two weeks. In fact, I'd wait three weeks to give people time to patch.”
Reeves found himself balancing the guilt of disclosing a vulnerability that could affect thousands with his duty to protect his clients who were exposed.
“I didn’t want to look like I was a holding a gun to their heads -- that certainly wasn’t my intention. I wanted things fixed. That was my goal. I have a client who's vulnerable. I know other people who are vulnerable. I know there are 2,500 vulnerable boxes on the web. Things need to be fixed,” he said.
But outside of the individual vulnerability fix, Reeves hopes his decision to publicly disclose the flaw will lead to bigger changes in Seagate’s vulnerability reporting structure.
“They need to feel a little pain to force them to improve things -- and I don't just mean fix the vulnerabilities. I mean, deal with disclosure properly,” he said. “Have a publicly visible page that any researcher can access that says ‘here's our email, PGP key, here's how you can responsibly disclose issues’ and then from there have a more transparent level of communication so the researchers are aware of what is going on. I want them to have a more painless way for people to disclose things, because this will happen again.”
iDigitalTimes has reached out to Seagate for comment concerning the public vulnerability disclosure by Reeves, but at this time, has yet to receive a response.
Read OJ’s full public disclosure advisory, here.
UPDATE 03/06/15
A spokesperson for Seagate has responded to iDigitalTimes request for information about the disclosed vulnerability stating that a patch would be available in May 2015. The full email can be found below:
“Security and data privacy are a priority for Seagate. We are aware of the vulnerability report and after careful analysis, Seagate has confirmed that the vulnerability on our Business Storage NAS products is low risk and affects only those Business Storage NAS products used on networks that are publicly accessible via the Internet.
With factory settings, Business NAS products are not vulnerable. The user has to intentionally change a default setting to become susceptible.
All Business Storage NAS customers are encouraged to follow the instructions outlined in the article linked below to ensure the product is secure and inaccessible by an unauthorized third party. Additionally, Seagate recommends as a best practice that customers secure their internal network by implementing a firewall.
For those customers who choose to keep their networks open, Seagate will be issuing a software patch for download expected May, 2015.
