LAS VEGAS — Alongside the well-known DEF CON and Black Hat security conferences held every year here is the smaller, more intimate BSides Las Vegas get-together. It often features presentations that didn't make it into Black Hat, and at only $100, costs a fraction of the price to attend.
One common theme at BSides this year was misconfigurations. Two of the talks we saw on the conference's first day (Tuesday, Aug. 8) had to with how security protocols and practices can be undermined by developers failing to understand implementation and/or using sloppy coding.
The perils of passwordless
Aldo Salas, appsec lead at HYPR, kicked off the day with an explanation of how poorly some passwordless implementations can be configured.
"Passwordless is not less secure than passwords," Salas said. "But there are vulnerabilities, and nobody is talking about them."
The deployment of passwordless interfaces can be difficult, he explained, and their documentation might leave out important details relating to security.
For example, Salas said, WebAuthn requires a name, displayname and user ID to add a new authenticator to an account. Yet in one implementation Salas cited, the web application did not perform a server-side check on these values, with the result that an authenticated adversary could take over an account by tampering with the parameters.
"That application was using the WebAuthn specification to the letter," Salas said. "The specification does not mention that this data should not be trusted. How many other applications are implementing the specifications without additional checks? Developers who aren't security-minded may set this up without taking additional steps that aren't specified."
Or, Salas said, when registering a new user account, a passwordless app might not check to see if the account already exists. If it does, then the app just adds another authenticated user to the existing account.
Lastly, Salas worries that developers and managers might imagine that passwordless is a magic bullet that solves all security problems. But passwordless won't fix insecure direct object references (IDORs), parameter tampering, leaky APIs or software supply-chain issues.
"Applications using passwordless are still vulnerable to regular web app vulnerabilities," he said.
Developers need to secure their software development life cycle, Salas said, and use both manual and automated AppSec testing.
"All these flaws I've mentioned were found by humans, not automated tools," he said.
A scanner darkly
Poor coding practices are also a major reason why vulnerability scanners and software composition analysis (SCA) tools may miss security flaws, said Yotam Perkal, head of vulnerability research at Rezilion, in a presentation at the end of the day Tuesday.
Failure to detect vulnerabilities can occur because developers often don't use the official package managers to install and maintain open-source projects, Perkal said.
"Every vulnerability scanner or SCA tool is also an SBOM [software bill of materials] tool," he explained. "Each must first identify the software components before assessing whether they are secure. Suboptimal performance in either step will result in misidentification."
The SCA tools and vulnerability scanners rely on the package managers to know what they're looking at, Perkal said. When a developer skips the package manager and instead uses wget, curl or copy to quickly add or modify a piece of code, that developer is throwing off a vulnerability scanner's ability to properly detect any flaw the developer might have introduced.
Perkal said that Rezilion had manually examined the 20 most popular Docker containers, including Apache HTTPd, Apache Tomcat, Drupal, Jenkins, MongoDB, Nginx, Postgres and WordPress, and found 450 high-priority or critical vulnerabilities across all 20.
However, six automated vulnerability scanners were able to find on average only 73% of those flaws. Other factors besides lack of package management played a part, Perkal admitted, but not taking shortcuts during development is an easily fixable way to make code more secure.
Perkal ran a live demo of four vulnerability scanners examining a build of Apache HTTPD known to have a bit more than 200 flaws. Three of the four scanners detected only about 175 flaws, while the last (Grype) found about 200 and was the only one to spot two flaws that were on CISA's list of known exploited vulnerabilities.
"Developers should always opt to install the required components via the relevant package manager," Perkal said. "Don't take shortcuts."
Security practitioners need to be aware of what Perkal called an "inherent detection gap, which is common to most vulnerability scanners and SCA tools."
"Take scanner results with a grain of salt," he said, adding that scanner makers need to "be aware of these inherent blind spots and work to address them."