Security Weekly listeners, save $100 on your RSA Conference 2022 Full Conference Pass! RSA Conference will be live in San Francisco June 6th-9th, 2022. Security Weekly will be there in full force, delivering real-time, live coverage and interviewing some of the event’s top speakers and sponsors. To register using our discount code, please visit https://securityweekly.com/rsac2022 and use the code 52UCYBER. We hope to see you there!
Don’t miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!
With 77 percent of all financial transactions touching an SAP system, SAP is the backbone and heart of most organizations. Add to this the vast amounts of customer facing personal data used within SAP, and you can see why SAP security is critical. However, SAP’s complexity – in the form of extensive customization, thousands of configurations, and typical misunderstandings about who and which group is responsible – make SAP security a challenge. Hear SecurityBridge CEO Christoph Nagy discuss with Security Weekly how organizations can navigate and address these challenges by taking critical steps such as patching, creating baselines, and developing roadmaps for risk prioritization and more to become SAP security heroes.
Christoph Nagy – CEO at SecurityBridge
Christoph Nagy has 20 years of working experience within the SAP industry. He has utilized this knowledge as a founding member and CEO at SecurityBridge – a global SAP security provider serving many of the world’s leading brands and now operating in the U.S. Through his efforts, the SecurityBridge Platform for SAP has become renowned as a strategic security solution for automated analysis of SAP security settings, and detection of cyber-attacks in real-time. Prior to SecurityBridge, Nagy applied his skills as a SAP technology consultant at Adidas and Audi.
Co-founder & CTO at Cysense
Security Partner at Square
2. Smart Contract Security, Heroku Breach, & Real World Crypto Highlights – 01:00 PM-01:30 PM
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!
In the AppSec News Mike and John discuss: Secure coding practices and smart contracts, lessons from the Heroku breach, Real World Crypto conference highlights, and an entertaining bug in Google Docs, & more!
Co-founder & CTO at Cysense
Study finds smart contract developers not focused on security – 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.
Prefetch vulnerability found in Apple Silicon CPUs – 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
Do we know what secure software development is? – 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?
Security Partner at Square
Incident 2413 | Heroku Status – 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
TLStorm 2.0 – 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.
Themes from Real World Crypto 2022 – 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.
Path traversal flaw found in OWASP enterprise library of security controls – 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/
White House Moves to Shore Up US Post-Quantum Cryptography Posture – 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.