1. Solving Systemic Risk in Software Development – 12:30 PM-01:00 PM
In an overabundance of caution, we have decided to flip this year’s SW Unlocked to a virtual format. The safety of our listeners and hosts is our number one priority. We will miss seeing you all in person, but we hope you can still join us at Security Weekly Unlocked Virtual! The event will now take place on Thursday, Dec 16 from 9am-6pm ET. You can still register for free at https://securityweekly.com/unlocked.
In today’s session Chris Wysopal will address a number of topics with Mike, including systemic risk in software development and how developers and security teams can work together to meet common goals and solve the speed vs. security dilemma. Specifically, they’ll discuss processes for fixing more vulnerabilities faster and tools for ensuring developer success. And they’ll talk about improving the overall maturity of DevOps teams through good development practices, good testing, remediation, and training.
Chris Wysopal – Co-Founder, CTO & CISO at Veracode
Chris Wysopal is Chief Technology Officer and co-founder at Veracode. He oversees technology strategy and information security. Prior to co-founding Veracode in 2006, Chris was vice president of research and development at security consultancy @stake, which was acquired by Symantec. In the 1990s, Chris was one of the original vulnerability researchers at The L0pht, a hacker think tank, where he was one of the first to publicize the risks of insecure software. He has testified to the US Congress on the subjects of government security and how vulnerabilities are discovered in software. Chris received a BS in computer and systems engineering from Rensselaer Polytechnic Institute. He is the author of The Art of Software Security Testing.
Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!
What is interesting, is why the researcher published the new vulnerability: Abdelhamid Naceri was annoyed at Microsoft for their move to pay less for bug bounties, claiming that the firm now pays a bounty of $1000 for a vulnerability which they used to pay $10,000 for. Is this something companies will have to consider as we encourage them to set up and manage bug bounties?
From a quick search, I don’t find any announcement from Microsoft saying they were restructuring their bounties.
As a note, looks like msft is paying around $13 million per year for the last few years in bounties.
“As tools improve and companies become better at application security, the easiest to find vulnerabilities — so-called “low-hanging fruit” — disappear and only hard-to-find issues are left. This means as the bug bounty ecosystem matures, maintaining the interest of researchers requires larger bounties”
Over a million WordPress sites breached – For once apparently a compromise _not_ due to a WordPress flaw, but a compromise of GoDaddy’s hosted WordPress credentials and SSL certs. It appears an attacker used a compromise password to gain access to a system that stored customers’ SFTP credentials. Even if the credentials were hashed, plenty of customers are sure to have weak passwords and, sadly, plenty are likely to have the same password for that SFTP system as for their email. The appsec angle is a simple and obvious one: treat credentials as highly sensitive data and place significant restrictions on what services may access those credentials, even their hashed version. As an added bonus, consider alerts on access patterns to that credential store or the amount or rate of egress traffic from it.
GoDaddy’s breach notification is at https://aboutus.godaddy.net/newsroom/company-news/news-details/2021/GoDaddy-Announces-Security-Incident-Affecting-Managed-WordPress-Service/default.aspx
Looking for vulnerabilities in MediaTek audio DSP – This is a technical writeup about reverse engineering firmware in a DSP present on a significant amount of Android devices. It exploits a sequence of flaws to eventually change parameters for the DSP. For example, a parameter might be update to log speech processing information — which an attacker could then exfiltrate from the device.
The “classic heap overflow” and “improper validation of array index” mentioned in the writeup is basically boilerplate appsec commentary for C code. One detail that stands out is this comment, “…generally, device manufacturers ?do not care about validating configuration files properly because they are not available to unprivileged users. But in our case, we are in control of the configuration files. The [Hardware abstraction layer] configuration becomes an attack vector.”
The writeup mentions that the vendor’s response is to remove a capability that sets the config file for the device. That seems effective in terms of disrupting the attack. It would also be interesting to consider whether signing config files, for provenance or integrity, would be something to consider or whether that’s less effective as a device (i.e., client-side) control.
If you’re interested in getting into lots more C code, check out https://www.freertos.org.
This mode still needs work. It doesn’t yet support WebAssembly, something we talked about just last episode at https://securityweekly.com/asw175
Researchers found an implementation bug in how WebKit handles CSP violations. WebKit is the browser engine within Safari as well as used by any app from Apple’s App Store that uses web browsing. They would target URLs commonly used for SSO or OAuth (i.e., they expect to redirect to different domains as part of the workflow), create a CSP directive that would trigger a violation report to that URL, then receive the redirected URL back to Safari. The POC for the exploit is only about seven lines of HTML and could be used for account takeovers. While a successful attack still needed user interaction to bypass Safari’s Intelligent Tracking Prevention, there are still several steps a site can take to harden their OAuth flows. Adopting SameSite cookies would be one of the fastest and best — presuming the site’s domain structure and interactions wouldn’t inhibit such adoption.
The researchers brought this exploit to many bug bounty programs in order to get sites to harden their OAuth flows. In the article, they note how it took a while to educate various security teams on why this was impactful and how weaknesses in their authentication and authorization flows could be exploited.
Give their article a read and check out their recorded presentation at the end.