1. DevSecOps, Compliance GRC, and the Future of Application Security – 12:30 PM-01:00 PM
Throughout 2022, CRA’s Business Intelligence Unit will be releasing research reports on the top topics across the security industry. Our first report will be on Third-Party Risk and the Supply Chain. To participate in the survey, please visit https://securityweekly.com/thirdpartyrisk. The results will be shared at our Third-Party Risk eSummit in January.
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!
DevSecOps has been traditionally very people centric. It is hard to measure software security and the landscape is becoming increasingly more complex with container, cloud, and infrastructure. Driving an appsec program at scale is often an art that only few can master and the majority of organizations remain uncovered from an appsec perspective. Measuring DevSecOps and evolving risk-based vulnerability management is a must. Bringing along risk people and GRC has traditionally been challenging.
Francesco Cipollone – CEO & Founder at AppSec Phoenix Ltd
Francesco Cipollone a multi start-upper and cybersecurity professional, Francesco was the ex AppSec and Cloud Security lead for HSBC, Lead Cloud Security for AWS Professional Service, and previously consulted with the United Nations. Francesco is also Chair of the Cloud security alliance, published author, podcaster and public speaker.
Co-founder & CTO at Cysense
Security Partner at Square
2. Log4Shell, Mozilla’s BigFix & New Sandbox, Rust in Linux Kernel, Path Traversal in Go – 01:00 PM-01:30 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.
XS-Leaks bypass same-origin policy – A new category of web vulnerabilities, titled “cross-site leaks” leverages an ability to bypass a browser’s “Same Origin” policy, designed to prevent this type of thing. Basically by using side-channel (timing) attacks, it’s possible to see if a user has, say, used another website or has an account on it.
Adding Rust support to Linux Kernel – This is a fairly nerdy link – a source code patch for new functionality in the Linux Kernel. But in particular, this is the patch which would add support for using Rust code in the kernel. This makes it a great example of things to think about, and actions to take, to add Rust to an existing project.
– Mixing data and code: The vuln stems from the log4j Lookups feature that provides “a way to add values to the Log4j configuration at arbitrary places”. Slightly rephrased, adding user-influenced values to arbitrary places that control an app’s execution basically described arbitrary and remote command execution.
– Secure defaults: How many folks were surprised their app supported the macro substitution and JNDI connections from their logging systems? How many needed such a feature? How many would ever need such a feature?
– Deprecating features: What are good strategies moving away from insecure designs and features? Windows in particular has been hampered by an adherence to backwards compatibility.
– Network controls: How many networks block egress traffic from production systems by default? Or at least proxy them through a controlled, audited centralized server? How many networks block DNS lookups, too?
– SBOMs: How much more efficient would a response be if you had details about the dependencies and libraries in the third-party apps and devices on your network? This isn’t about the code you build and the SCA tools checking that code’s dependency graph; it’s about visibility into all the other apps and devices sitting on your network.
– Security & surprises: Fixing this and then worrying about the next 0-day isn’t a strategy. No one should be trying to create a BugOps team. There are basic practices that can make these kinds of events an audit exercise rather than a forensic scramble.
Want to be part of the solution for securing open source software like this? Check out security projects from the OpenSSF (https://openssf.org) and the LXF Platform (https://lfx.linuxfoundation.org). They’ll benefit from funding, participation, and support.
A few more resources to check out:
– https://twitter.com/NSA_CSDirector/status/1469305071116636167?s=20 (mostly because it’s funny to see all the places where this vuln has appeared)
– https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf (an overview of JNDI and LDAP as attack vectors from 2016)
– https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/ (resources and information curated by NCC Group)
This shouldn’t have happened: A vulnerability postmortem – Sure, it’s a title that can apply to just about any vuln we’ve covered on the show. This writeup talks about how Mozilla implemented a bunch of recommended, effective security practices and yet a bug still slipped through. What’s interesting is that a slightly different fuzzing strategy found what’s (in retrospect) a relatively straightforward vuln. Even so, good software design meant this particular flaw didn’t end up on the “CVSS 10 out of 10” list in news stories. It’s a good lesson that maturity in SDLC practices doesn’t mean all the bugs and vulns will go away, but it can mean that they’re less common and less impactful.
GraphQL API authorization flaw found in major B2B financial platform – This type of flaw seems simple when you look at how it’s exploited — change a user ID or a transaction ID in order to execute actions against another user’s account. It’s the kind of reminder that as architectures change, security threats remain the same. A key step is not just understanding what can go wrong with default open authorization checks, but in designing APIs so that complex properties like authorization can be represented, enforced, and audited throughout the many microservices that might lay behind an API.
We also talked about API security and the need for careful attention to authorization in GraphQL-backed queries in episode 172. Check it out at https://securityweekly.com/asw172
Check out the research at https://salt.security/blog/api-threat-research-graphql-authorization-flaws-in-financial-technology-platform
CVE-2021-43798 – Path Traversal Vulnerability in Grafana – Fine. Java and log4j get all the attention this week, but I’m not going to let a path traversal go by without a proper mention. This is also a chance to reinforce the theme that, while memory safe languages address an inordinately large attack class, languages like Java (ok, may not too surprising…) and Go may have equally impactful vulns that have nothing to do with memory safety, buffers, stacks, or heaps. That doesn’t mean we’re in a nihilistic land where we should abandon all programming languages — it just means we have to continue to work on language primitives that make introducing these types of flaws difficult and language analysis tools that can effectively identify them.
How is the Security Profession Doing? – How fortuitous to have an article that’s taking a good self-evaluation of the security profession during the same week the security profession is dealing with a flaw across a massive amount of apps and services. When there’s time to take a postmortem on log4shell, how would it compare with how orgs reacted to Shellshock and Heartbleed before it? Do we have effective recommendations on basic practices that can minimize the surprise from these kinds of vulns and maximize the response to them? Do we have the practices and tooling to follow through on those recommendations?
Plus, the security profession encompasses a varied amount of roles and domains of expertise. This article presents a way to better think about how security could both reflect something that’s everyone’s responsibility as well as considering paths towards making security practices more grounded in scientific methods and standardized practices.
Announcing NCC Group’s Cryptopals Guided Tour! – Taking a guided tour through cryptography analysis and common flaws is a great way to understand these concepts without needing a deep experience in math, programming, crypto, or a good memory for acronyms.