Researcher to FireEye: If you’re not paying, I’m not talking

On Sunday, Kristian Erik Hermansen disclosed an unauthorized file disclosure vulnerability in FireEye‘s core product. The zero-day disclosure quickly generated public attention, as did the discussion around three other vulnerabilities that haven’t been published and the $10,000 USD price tag on the flaws.

But the disclosed vulnerability and the three other unpublished flaws are not the only thing FireEye has to be concerned about, there’s plenty more where that came from.

Hermansen, along with researcher Ron Perris, has claimed the discovery of at least thirty additional flaws in FireEye’s products. Many of them are in the HX line, but plenty of others exist in various products too, Hermansen added.

As word of Hermansen’s disclosure spread online, the opinions of those discussing the issue were split.

There were calls of stunt hacking, and others condemning the zero-day disclosure of a bug that was discovered eighteen months ago. Finally, some said Hermansen did the right thing, and if his claims were true, he stands to make a good sum of money off his work.

Yet, the disclosure of the unpatched flaw itself is what has become the hot topic of the moment.

In a statement to Salted Hash, FireEye chided Hermansen in a way. The company started by offering their thanks for him and Perris, while adding that they’ve always encouraged responsible disclosure, giving the impression the company doesn’t feel that happened in this case.

“FireEye has a documented policy for researchers to responsibly disclose and inform us of potential security issues. We have reached out to the researchers regarding these potential security issues in order to quickly determine, and potentially remediate, any impacts to the security of our platform and our customers,” the statement said.

When asked, Hermansen was unable to confirm FireEye’s statement that they’ve reached out to him, but he wasn’t without thoughts regarding contact:

“What frustrates me is they are all ears now, when they ignored the issues for a long time,” he said, adding that he will let the company sit for a bit while they try to fix what they know.

“When they implement a bug bounty or security rewards process I will reply to them. Until then, they get cold silence as reciprocity. They have been giving me lip service about implementing such a program for more than a year. Let them announce it publicly and then I will talk to them again. I’m sure there are lots of other bugs in their products that are not yet disclosed.”

Again, FireEye hammered home their desire for responsible disclosure, which might lead some to think that Hermansen didn’t make an honest attempt. Only, the fact is, he did try to disclose the vulnerabilities, the process failed due to financial reasons.

Once the vulnerabilities were reported to FireEye, in July of 2014, Hermansen was told via email that the company didn’t have a bug bounty program. FireEye said the formal reporting process was new, but they were considering offering paid bounties in the future.

As things stand now, FireEye has a portal to disclose security issues; however, while the disclosing researcher might get a gift and a named acknowledgement if there is a security bulletin published, the company doesn’t offer any financial compensation. This lack of payment is the problem for Hermansen, who is asking for at least $10,000 per vulnerability.

So who is right? Should Hermansen have kept his knowledge to himself and not disclosed anything? Should he have given his work to FireEye at no cost? Or does he have the right to do what he pleases with the vulnerabilities?

Your answer will depend on where you stand on the disclosure debate.

Bug bounty programs are a mixed bag. On one hand, they demonstrate (in some cases) that an organization “gets it” and is willing to work with researchers. When money is offered, that usually leads to more researchers taking an interest in the bounty program itself, which isn’t a bad thing.

However, the down side is that the organization can take as long as they want to fix an issue before they allow disclosure. Another issue is that some bounty programs are being viewed as a replacement for normal security life cycles.

“The danger of bug bounty programs is that they are being advertised as a replacement for structured security verification. This can lead to a false sense of security from companies that aren’t doing enough for their own security testing programs,” said Contrast Security’s Jeff Williams, when asked about bounty programs as part of the Hacked Opinions series.

The topic of bounty programs for FireEye is a complicated one. They’re interested in them, they agree with them on principle, but implementing one is harder than it looks.

Researchers who have worked with FireEye in the past have told Salted Hash that it isn’t hard to see the company isn’t where they want to be in terms of maturity for a vulnerability reporting program. In fact, they’re further behind than most would expect.

One of the main challenges for developing a program centered on getting product into the hands of researchers. FireEye appliances are expensive, which creates a financial hurdle almost immediately.

Next, FireEye has to determine the value of the reported bugs. This is arguably the hardest part of the process, because while the company would see a given reward as a fair market price, a researcher might feel their efforts are worth twice that and chose to sell to a third-party broker.

Bugcrowd’s Casey Ellis addressed the topic of paying for vulnerabilities as part of the Hacked Opinions series. What can be done to make it worth the researcher’s time and effort to work with a vendor directly?

“The simple answer is to increase the rewards for the researchers. As this concept of incentivized disclosure grows, you end up with a marketplace where companies will compete for the attention of researchers. Then, as there’s more competition for this attention, companies will want to offer more rewards,” he explained.

“It’s a classic business exchange, the kind we participate in every day – the seller wants to sell their bug for as much as they can, but the buyer doesn’t want to pay too much. At the end of the day, it comes down to finding that reasonable middle ground where the value is being transacted in both directions.”

At this point, it isn’t clear when or if FireEye will ever develop a paid bounty program. But unless they do, Hermansen, and researchers like him, will either keep their cards close to the vest, or look towards a buyer with cash to spend.

Update:

In a vulnerability report, FireEye says the vulnerability disclosed by Hermansen on Sunday was previously patched flaw in the HX system.

“Recent updates have reduced the impact of this issue to customers running legacy versions of the product (HX 2.1.x and DMZ 2.1.x). However, in order to eliminate risk immediately, FireEye strongly recommends upgrading to the current release (version 2.6.x) of the HX product. For customers who remain on the legacy version, FireEye is actively working on a fix for the reported issue in the HX 2.1.x series and will update impacted customers through our official Customer Support channels.”

Reached via email, Hermansen said that he was glad to see FireEye pushing fixes for this and other issues.

“When you run your web server as root, and don’t have adequate SDLC process, you get smacked pretty badly because even a minor bug can allow full remote compromise. No security company should be doing things like that in this decade. They are supposed to be leading he charge against 0day in customer networks and yet cannot even be bothered to harden their own devices…”