Dead Simple – ASW #154

A 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

At 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

This 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.

Another 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

Here'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.

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".

In 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/

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?