ASW #196 – Christoph Nagy

Heroku has provided more details on the breach, which gives us a chance to revisit an old topic -- communications -- and a new topic -- leaked password hashes. As with all these kinds of breaches, we don't have full Knowledge of events, but it's still very surprising to hear that a compromised OAuth token also lead to access of a database that contained hashed and salted passwords. That sounds like bad news for the app's architecture, encryption schemes, and authorization model. Here's Heroku's reflection on their need to improve communications: https://blog.heroku.com/we-heard-your-feedback Find more news coverage at - https://www.zdnet.com/article/heroku-fesses-up-to-customer-password-theft-due-to-oauth-token-attack/ - https://therecord.media/heroku-breach-salesforce-oauth-github/

We first mentioned TLStorm back in episode 188 (https://securityweekly.com/asw188), so we'll skip a rehash of the vulns other than to use it as a reminder that handling error conditions correctly to "fail secure" is critical within any software that handles a security boundary or security state. We'll use the updated notes on this flaw as an example of developing an appsec strategy around flaws identified from efforts like bug bounties and pentesting. It's always more effective to target a class of vulns -- like error handling for TLS connections -- than just fixing the flaws that a security test might have identified. Unfortunately, it's also more time intensive and requires more investment from appsec and DevOps teams.

This is a great guide through different cryptographic topics presented at this year's RWC conference. But even if you're not implementing or analyzing crypto protocols, there's one takeaway that remains universal to software -- "Security tooling is still too difficult to use". It's great to see a shout out for compilers as a way to build in more security analysis and hardening, but there's clearly still a lot of work to do to get beyond security awareness and into security tools and compilers.

Yes, of course this is going to make the list. It mentions path traversal. But the discussion is more about building security libraries versus secure code. After all, even one of the project maintainers explains the trade-offs of using the ESAPI, with a conclusion to mostly avoid it. Yet a premise of modern security engineering is to create "paved roads" and "guardrails" and other metaphors that mean providing resources for DevOps teams to use rather than just giving them recommendations. This is a chance to talk about what paved roads should look like and whether the ESAPI matches that criteria. Plus, there's a quote that sounds like a fundamental reason why we'll always have insecure code: "[this function] acts differently when a value for a directory is not ‘/’ terminated. I think that’s a bit unintuitive." Any code that can be referred to as unintuitive is likely at best being damned with faint praise and at worst laden with assumptions just waiting to become CVEs. The PDF of the flaw is at https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/GHSL-2022-008_The_OWASP_Enterprise_Security_API.pdf Check out the OWASP ESAPI project at https://owasp.org/www-project-enterprise-security-api/

The takeaway here is more about knowing that a software change will be necessary in years to come and enacting a concrete plan to make that change. A quote from the article illustrates this well, "...although the reality of a quantum-computing threat is likely 'years away,' the country needs to prepare now." Now think back to the pace of changes for software to move off MD5, SHA-1, RSA 512 bit keys, TLS 1.0, and similar items that still show up on secure coding checklists.

To rephrase Fermat's Last Theorem, "...someone discovered a truly marvelous proof of concept, which this margin is narrow enough to contain." AND. AND. AND. AND. AND. Yep, it's a real bug: https://support.google.com/docs/thread/162510194?hl=en&msgid=162543191

While I don't want to be quite as snarky as the register (at the moment), this article discusses and links to a paper where researchers interviewed 30 smart contract developers - and gave them a task to perform a security-focused code review on a contract with four vulnerabilities in it. The "experienced" developers were able to find the issues 40-60% of the time, while the junior coders had at best 20% chance of finding the issues. Also, there's 2 flow charts, showing how an experienced dev performed the code review, vs how a junior coder did. At the end, the authors cite a few issues with the Solidity contract language and etherium, in that security does not seem to have been strongly considered during their design.

Similar to spectre/meltdown, a vulnerability has been found in Apple Silicon CPUs, in how they attempt to improve performance by speculative loading of data before it's needed. In this vulnerability, name Augury, the situation is slightly worse - whereas Spectre could only access memory related to the program, Augury is able to access any memory in the system

Secure Code Warrior conducted a survey of 1200 developers asking questions around what efforts they take to write secure software, and how much time and priority are given to those efforts. The linked article makes a statement that only 29% of developers know what secure software development is ("active practice of writing code that was free of vulnerabilities"). Knowing what it is vs what's prioritized is one nitpick here, but also does writing secure software possibility mean different things to different roles in an organization?