Newly Found Authentication Flaws Highlight Dangers of Coding From Scratch

Do-it-yourself is a great way to learn coding, but it's a risky way to tackle complex application problems that have scant room for error, such as authentication and encryption.

A new vulnerability report by software-security firm Synopsys has reinforced that recurring software-development theme, with the disclosure of two flaws in the GOautodial call-center software suite. GOautodial has a variety of features, including customer relationship management (CRM), a variety of dialing features, and reports and analytics, but the software also has an application programming interface (API) that routes requests to other files and does not correctly authenticate users.

The vulnerability — along with a second remote-file-inclusion issue — is not earth-shattering, but both are entirely preventable, says Scott Tolley, a security sales engineer at Synopsys. The team that developed the open source software package, which is used by more than 50,000 users, could have used an existing software package or product for authentication, he says.

"You can take a Web application framework off the shelf in all sorts of languages and just use that well-tested existing software," Tolley says. "The point is, you can take something that is well-tested and use it for authentication, rather than writing it yourself, because if you write it yourself, there are bugs. And if you are writing software that has an impact on the security of the system, then those bugs have an impact on the security of the system."

The risks associated with creating custom versions of security-impactful software components is apparent just by perusing the OWASP Top 10 Web Application Risks. Created using data on application vulnerabilities discovered by nearly a dozen firms, the list ranks the most encountered and most important security issues affecting Web and cloud applications.

The top risk is Broken Access Controls, which likely encompasses the GOautodial vulnerability, but the No. 7 risk is Identification and Authentication Failures. Errors using encryption or flawed cryptographic components is the No. 2 risk.

Any development team without a large security organization behind them should really use existing components for security and authentication, says Tolley.

These issues are "really focused on a specific functionality," he says. "And [smaller development shops are] not a Microsoft or a Google, with an enormous security team to do this kind of validation, or open source projects that have the history and participation to be absolutely bulletproof."

A 'Simple Mistake'
The GOautodial issue uses a custom API router to handle externally requested actions, often requiring a username and password. Unfortunately, the router did not correctly validate the information, which allows an attacker to use any values instead of the user's credentials.

The vulnerability was a simple mistake in the code, Tolley says.

"This code takes a username and password that is supplied with the API request and requests a count of the number of records in the user database for which this pair matches. The idea is that if the result is zero, [there] is not a match, and this is not a valid user," he says. "The problem is the query they were running was not returning a single number like zero or one — it was returning a single record with a name and a numeric value."

Because it returned the record rather than the number of matches, the comparison was always greater than zero, and so was assumed to be true — the user existed and was authorized.

Overall, the severity of the flaw was mitigated by the requirement that the attacker already had some access to the system. The issues did not allow a remote-code exploit, Tolley says. The vulnerabilities are still risky, he says.

"If the attacker gets deployed where they can get access to a call center worker, they would normally be limited in what they can do," he says. "But with the vulnerability, you can turn that into admin privileges."

Check Out Vetted Code Libraries
Developers should adopt well-known, well-vetted,code libraries, Tolley stresses. As the vulnerabilities show, authentication is hard to do right — and with critical consequences when done wrong. Companies should train their developers to recognize authentication issues and provide libraries, services, or open source components that have been tested and validated.

"There is a reason why authentication issues are in the top 10, so using existing well-scrutinized libraries to do authentication is important," he says.