Dead Simple – ASW #154
This week, we welcome Sebastian Deleersnyder, CTO at Toreon, to talk about OWASP SAMM - Software Assurance Maturity Model! In the AppSec News, Mike and John talk: ALPACA surveys protocol confusion, lessons from the EA breach, forgotten lessons about sprintf, Go fuzzing goes beta, security lessons from Kubernetes Goat, basic lessons for OT from CISA, & more!
Visit https://www.securityweekly.com/asw for all the latest episodes!
Follow us on Twitter: https://www.twitter.com/securityweekly
Like us on Facebook: https://www.facebook.com/secweekly
1. OWASP SAMM – Software Assurance Maturity Model – Sebastian Deleersnyder – ASW #154
We will provide a short introduction to OWASP SAMM, which is a flagship OWASP project allowing organizations to bootstrap and iteratively improve their secure software practice in a measurable way.
Seba will explain the SAMM model, consisting of 15 security practices. Every security practice contains a set of activities, structured into 3 maturity levels. The activities on a lower maturity level are typically easier to execute and require less formalization than the ones on a higher maturity level.
A the end we will cover how you can engage with the SAMM community and provide an overview of what happened at our latest SAMM User Day which happened on May 27th.
Security Weekly is more than happy to announce that we will be at InfoSec World 2021 IN PERSON October 25th-27th, 2021! This year, our annual partnership with InfoSec World is extra special, as we are both business units under the CyberRisk Alliance brand! What does that mean for Security Weekly listeners & InfoSec World attendees? You will get to see and hear from many of the Security Weekly team at the event AND you will save 20% off on your world pass! Visit https://securityweekly.com/isw2021 to register using our discount code!
Don't forget to check out our library of on-demand webcasts & technical trainings at securityweekly.com/ondemand.
Seba is co-founder, CTO of Toreon and a proponent of application security as a holistic endeavor. He started the Belgian OWASP chapter, was a member of the OWASP Foundation Board and performed several public presentations on Application Security. Seba also co-organized the yearly security & hacker BruCON conference and trainings in Belgium.
With a background in development and many years of experience in security, he has trained countless developers to create software more securely. He has led OWASP projects such as OWASP SAMM, thereby truly making the world a little bit safer. Now he is adapting application security models to the evolving field of DevOps and is also focused on bringing Threat Modeling to a wider audience.
2. ALPACA, EA Breach, sprintf Lives, Go Fuzzing, K8s Goat, & OT Basics – ASW #154
This week in the AppSec News, Mike and John talk: ALPACA surveys protocol confusion, lessons from the EA breach, forgotten lessons about sprintf, Go fuzzing goes beta, security lessons from Kubernetes Goat, basic lessons for OT from CISA, & more!
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!
Security Weekly is ecstatic to announce that Security Weekly Unlocked will be held IN PERSON this December 5-8 at the Hilton Lake Buena Vista! Call for presentations & early registration for Security Weekly listeners is open now! Visit securityweekly.com/unlocked to submit your presentation & register for the early registration price before it expires!
- 1. ALPACA AttackA named vuln with a cute mascot, but don't worry about herds of these threatening your systems anytime soon. As the research itself notes, cross-protocol and protocol confusion attacks have been around since at least 2001. What's new here is a larger survey of modern services and browsers and how they might be abused by this class of attacks, which boils down to an attacker with an ability to modify traffic (such as being in a privileged network position or within a browser execution context) to leak data like cookies. The takeaway here is more about correctly configuring the SNI and ALPN capabilities for your web and application servers in order to minimize the success of this class of attack. Be prepared to receive an influx of bug bounty submissions -- named vulns often set bounty hunters off to find these kinds of misconfigurations or lack of hardening. And if you have no idea how to tell an alpaca from a llama, you're not alone. We'll offer up our own named vuln, LLAMA: Long-Lost Attack Mitigation Approaches -- aka using strict protocol implementations in memory-safe languages, rejecting incorrect or unexpected data, and using HTTPS (or TLS 1.3) everywhere. Check out the PDF for "ALPACA: Application Layer Protocol Confusion-Analyzing and Mitigating Cracks in TLS Authentication" - https://alpaca-attack.com/ALPACA.pdf
- 2. Hackers Steal Wealth of Data from Game Giant EAAt a glance, this is the kind of breach that might feel like it has only a tenuous connection to application security. After all, it relied on replaying a stolen cookie to gain access to a Slack channel that the attackers then used to social engineer their way into obtaining valid credentials. (It's also reminiscent of the 2020 Twitter hack that also leveraged Slack for obtaining credentials via a social engineering attack against the company's IT Helpdesk.) It's this stolen cookie angle that hits the appsec angle. Tokens that don't expire pose a big risk to apps. Do you have a method to revoke them? Is your app's threat model consistent with a token that provides permanent access? And once you start with those questions, you'll continue into the token's construction and whether it's repeating many of the mistakes that have plagued JWTs. Some additional reading: - https://jwt.io - https://paseto.io - https://github.com/ticarpi/jwt_tool/wiki - https://www.rfc-editor.org/rfc/rfc8725.html
- 3. Akkadian Provisioning Manager Multiple Vulnerabilities DisclosureThis might not be the most recognized or used software out there, but it contains several of the most recognized and dead-simple vulns out there. While the specific details might be of use for the protesting crowd, the Security and DevOps side would benefit from using these flaws -- hard-coded passwords in shell scripts and config files, shell exec via SSH's basic functionality, and shell exec via the vi editor -- as a case-study on making sure simple security checks are in place to prevent these development patterns from being used in the first place. At the very least, this software could have benefited from a threat modeling exercise that poked at some "what if" scenarios in how command lines were being constructed and whether utilities like SSH and vi were being sandboxed correctly.
- 4. The walls have earsAnother dead-simple set of vulns this week and once again in command-line construction and hard-coded secrets. As a bonus, this one also included a classic RCE based on an sprintf and buffer combo that could be straight out of the 1996 article "Smashing the Stack for Fun and Profit" (http://phrack.org/issues/49/14.html). It's another reminder of why we like the Cyber ITL approach to evaluating compiled software. It looks like safety features like ASLR and DEP, code hygiene like avoiding risky functions (hello, sprintf), and code complexity. You can find more about their approach and tools at https://cyber-itl.org/about/methodology/#scoring
- 5. mobsfscanHere's an open source project to "can find insecure code patterns in your Android and iOS source code." It's another project that's taking advantage of semgrep, a static analysis tool that's gained many fans since it first came out. Some more resources on semgrep are at - https://github.com/returntocorp/semgrep/ - https://semgrep.dev - https://tldrsec.com/newsletter/ -- Clint Gibler works with the company building semgrep. He's covered the tool and many other infosec topics in his weekly newsletter.
- 6. Fuzzing is Beta Ready (for Go)Go is trying to make it as easy as possible to conduct fuzz testing for projects. We've long been fans of fuzzing, having covered it several times on the show. Yet one aspect we haven't really dived into is how much people are actively using fuzz testing on their own code. We know it's in heavy use on browsers as far back as 2007 (http://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/) and Google has been aggressively testing many open source libraries. But outside of well-financed orgs with dedicated staff for this kind of effort, who else has been using it successfully? As the theme of today's show is software maturity models, it seems like a good way to discuss less about the "why" of fuzzing and more about the "when".
- 7. Kubernetes GoatIn the early days of appsec, we had access to lots of unintentionally vulnerable web apps to learn and practice on. Thank you, PHP (also sorry, PHP). Over time OWASP developed several application "goats" -- intentionally vulnerable apps to learn and practice on. These ranged from WebGoat to Node.js to Serverless to mobile and more. Plenty of non-OWASP projects have developed similarly vulnerable apps for educational purposes. Here's a spectularly insecure k8s cluster environment to play with. Hopefully its configuration and design doesn't remind you of your production systems... Even if you don't have the inclination to go through the exercises (you should!), take some time to read through the manual to gain a better understanding of common attack vectors and threat scenarios for Kubernetes. You can find that doc at https://madhuakula.com/kubernetes-goat/
- 8. Rising Ransomware Threat To Operational Technology Assets (PDF)Ransomware might use a lot of non-appsec attack vectors like phishing, compromised credentials, and unpatched VPNs, but it's still a threat that hits the Availability component of the Confidentiality-Integrity-Availability triad. Although CISA's recommendations are geared towards an OT audience, the steps to prepare for and mitigate security events remain universal: maintain an asset (and app) inventory, have a business continuity plan (keep availability in your threat models), update software (and your app dependencies) in a timely manner, and use application allowlists. As we've seen over several decades of appsec, these tasks sadly remain far easier said than done. So, with a theme this week of maturity models, how can your org put this PDF to practice?