E-toll security hole: don’t shoot the messenger

Organisations such as Sanral and the City of Joburg (CoJ) could stand to learn from companies such as Microsoft, Google, and Facebook when it comes to handling the disclosure of security flaws.

That’s the view of Dominic White, chief technology officer at Sensepost, an information security service provider.

In the last few months security holes were uncovered in a number of prominent websites, including those of Vodacom, Cell C, CoJ, and Sanral’s E-toll site.

While Vodacom and Cell C thanked the individuals for reporting the issue, the CoJ and Sanral responded by decrying the disclosures as cyber-attacks and threatening legal action against those responsible.

City of Joburg invoice screenshot

Full disclosure

White said that although the issue has been hotly debated for decades, responding in the way Sanral did is problematic because disclosing a vulnerability with an exploit is not the same as using the exploit for criminal purposes.

“For example, if you figure out how to unlock a car and tell people, that’s not the same as using the trick to steal cars,” White said.

It could also be argued that the efforts of “Moe1”, the person who disclosed the bug in the E-toll website, were intended to (and resulted in) making the eTolls website safer, White said.

“Sanral was made aware of the flaw, with enough information to fix it, and were given a large incentive to do so rapidly by the publicity,” White said.

“This type of disclosure is known as ‘full disclosure’.”

Responsibility, culpability, liability, and all the other -ilities

Laying blame for the existence of the flaw at the feet of the person who found and disclosed it is simply illogical, White argued.

“The responsibility for the original vulnerability clearly belongs to the developer who wrote the code, and can’t lie with the vulnerability researcher who couldn’t have had access to the code,” White said.

“However, all code has bugs, and it could be further argued that the responsibility for the flaw lies with whoever was responsible for security during development,” he continued.

This does not mean that security researchers that disclose vulnerabilities don’t have responsibilities, though.

There can be consequences depending on how a vulnerability is disclosed, White said, and responsibility for those consequences can be attributed to the researcher.

“That’s usually where people get confused,” White said.

“In short, the site developers are responsible for the flaw, and the bug finder is responsible for fall out due to the way in which they disclosed the flaw,” White said. “How responsible is not something our industry or South African law have clear guidance on just yet.”

“Responsible disclosure”

Since the person disclosing a vulnerability may be held responsible for the potential fallout, it raises the question: how should vulnerabilities be disclosed?

Asked about the industry buzz-phrase “responsible disclosure”, White said that the term is typically used when a vulnerability researcher works with the owner of the affected software to fix the flaw in private.

Only when the fix has been applied does the researcher release their findings.

“It’s a bit of a weasel term because it implies anything else is ‘irresponsible’ when it isn’t clear that collaborating with the vendor is always the best method,” White said.

He said that the preferred term nowadays is coordinated disclosure.

E-toll website

Coordinated vs full disclosure

White said that the arguments for coordinated disclosure are that risks are minimised since the public only finds out about the vulnerability after it is fixed.

The arguments against it are that vendors have limited incentives to fix the flaw (or less pressure to). While the vendor takes its time to fix the flaw, others with more malicious intent may have already found it and started abusing it.

“Truthfully, this risk isn’t measurable, and it isn’t clear which approach works the best in general,” White said.

White said that a useful guideline is if a company has a security reporting page with guidelines for submitting vulnerabilities, it is worth at least trying coordinated disclosure first.

“If that fails, then go the other route,” White said.

In the case of the Sanral website vulnerability, White said he doesn’t know whether Moe1 tried to contact Sanral, but he added that he is also not sure that one approach would have had less risk overall than the other.

What should Sanral do?

“If you have security researchers publishing vulnerabilities without contacting you, then you have a problem that won’t be fixed by going after the researchers,” White said.

“Microsoft learned this lesson many years ago.”

White said that the solution is to become responsive to security issues, publish guidelines and contacts for reporting bugs, and have the right people respond to those requests.

“You could even take it a step further and engage in bug bounty programmes like Google, Facebook, Microsoft, Mozilla and many others have done,” White said.

The least such programmes offer vulnerability researchers who report flaws is fame, and in many cases they also offer money.

White said that this offers incentives that the reporting be done in a method preferable to the company, while simultaneously encouraging that flaws are found and reported rather than “bad guys” finding and exploiting them.

More SA information security news

Website security flaws in SA – shooting the messenger

E-toll website flaw a cyber-attack: Sanral

Big Cell C security flaw uncovered

My Vodacom security flaw exposes subscriber details

City of Joburg website “hacking” case update