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!
CRA’s Business Intelligence Unit has launched its next survey on Zero Trust! What are Your Barriers to Zero Trust Implementation? Take our survey and enter to win a $500 Tango card by visiting https://securityweekly.com/zerotrust. Report results will be released at our upcoming Zero Trust E-Summit in March!
Security is one of the most evolving and impactful landscapes in the regulatory sphere. Proposed initiatives in the areas of Incident Response, Software and Product Assurance, Coordinated Vulnerability Disclosure (CVD), and IoT or Connected Products Regulations are among the most active and developing areas of security policy around the world. This evolving landscape also serves as an opportunity for innovation and research collaboration. Elazari will walk us through some of the most recent trends in policy proposals shaping the future of security. We will also talk about bug bounties and vulnerability disclosure, what are some of the industry’s best practices in this area, how to implement these programs to foster security, collaboration and transparency, and how this connects to the policy momentum and its impact on security researchers.
Amit Elazari – Director, Global Security Policy at Intel Corporation
Dr. Amit Elazari, J.S.D. is Director, Global Security Policy at Intel Corporation’s Global Government Affairs organization, a Lecturer at UC Berkeley School of Information, and a member of the External Advisory Committee for the Center of Long-Term Cybersecurity at UC Berkeley. She holds a doctoral degree in technology law (J.S.D) from UC Berkeley School of Law and graduated summa cum laude three prior degrees in law and business. Her work on security policy and technology law has been featured at top conferences such as RSA, Black Hat and USENIX Security, published in leading academic journals and featured in popular press, including The New York Times, The Washington Post and Wall Street Journal.
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!
We have a few webcasts coming up soon. First, join us February 16th to learn about validation techniques within applications. Then join us March 2nd to learn five things you can do to catch more bad guys! Finally, join us March 10th for an intro to KQL queries! Also join us on February 9th for a full live stream day from 1-6pm with Polarity for a chance to win cash prizes and a Samurai Sword Trophy! To register for these webcasts visit https://securityweekly.com/webcasts. Don’t forget to check out our library of on-demand webcasts & technical trainings at https://securityweekly.com/ondemand.
Vulns in an HTTP/3 server, path traversal in Argo CD, Log4Shell from the perspective of Log4j devs, DHS launches Cyber Safety Review Board, OSSF launches Alpha and Omega projects, resources for learning reverse engineering and appsec
Fastly patches memory leak HTTP/3 vulnerability in H2O HTTP server project – This is some neat research that looked at the state machine within the HTTP/3 protocol implemented by the H20 server. HTTP/3 (and HTTP/2) introduced frames as a way to handle multiple streams of data within a single connection. This flaw arises when a server makes assumptions about how to put streams back together from frames that may or may not have arrived and may or may not have been initialized. At a high level, it sounds like a common weakness when dealing with buffered data that can arrive out of order or not at all. Mishandling memory due to buffer mismanagement also sounds like a flaw common to C and C++ (i.e. memory unsafe languages). It’s nice to see the project has built-in support for LLVM’s LibFuzzer and the corpus files to go along with it.
But this sets up the questions of why a project like this chose not to adopt a memory safe language (Rust wasn’t viable at the project launch in 2014, but Go was) or what the overhead of rewriting the project in a memory safe language would be. Of course, that wouldn’t magically fix all the possible vulns, but it would be a great start.
Check out the technical write up at https://email@example.com/leaking-uninitialized-memory-from-fastly-83327bcbee1f
Argo CD releases patch for zero-day vulnerability – Supply chain security isn’t about specific vendors or specific bugs; it’s about having controls in place that limit the access and potential impact of vulns that might arise within dependencies or the tools used to build and deploy software. In this case, it’s a CD tool, which is particularly impactful since that type of tool often has access to secrets, sensitive tokens, and the ability to modify software as it’s being packaged.
What’s fun about this is that it’s a directory traversal flaw within Go code that made assumptions about the trust levels between a local file (check for traversal) and URLs (don’t apply the same checks). It’s also a chance to talk about how “input sanitization” is often a misleading recommendation or too generic to be helpful. Path traversal touches on parsing, normalization (aka canonicalization), sandboxing, and how to enforce security controls.
More details can be found at https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments/
The Apache Log4j team talks about the Log4Shell patching process – We often like to highlight postmortems from companies that demonstrate how they react to vulns and the steps they took to identify and remediate root causes. Here’s an insight into the side of fixing such a flaw in the first place, which is already under appreciated within open source and more stressful when it gets significant attention like Log4j. It can be a good reminder about how to set up collaborations with your own DevOps teams when they’re responding to bug bounty reports or fixing security bugs. The scale might be different, but the principles behind coordination, communication, and empathy remain the same.
DHS creates Cyber Safety Review Board to review significant cybersecurity incidents – Log4j’s legacy might not be an era of widespread compromises — at least not yet. While the vulnerable code was clearly widespread, the fallout doesn’t seem to be similar to the worms and ransomware we’ve seen from other vulns. But one legacy that it will surely have is being the most recent reference for teams scrambling to update their software asset inventories, improving their vulnerability scanning solutions, and patching often-unowned or previously-unknown software.
DHS has stepped into the arena with the type of effort the industry has long been waiting for — a review board to understand what went wrong, how systemic failures made the response harder for organizations, and what those orgs can do to avoid whatever the next log4j looks like. The initial members come from industry veterans with areas of expertise across government, policy, vuln research, threat analysis, and dealing with complex problems across large organizations. It shows great potential already and is something we’ll be following as their work progresses.
Another article on the topic is at https://www.zdnet.com/article/white-house-creates-board-to-review-cybersecurity-incidents-members-to-start-with-log4j/
Check out the DHS announcement at https://www.dhs.gov/news/2022/02/03/dhs-launches-first-ever-cyber-safety-review-board
The Alpha and Omega of software supply chain security – Last week we covered the recent update to the Open Source Security Foundation’s Scorecard. Here’s another article on their larger push to directly work with critical open source projects on maturing their security, as well as setting up tools to help inform a larger population of projects about what they can do to secure their software. It’s encouraging to see this sort of investment that combines manual work and automation. After all, a lot of open source projects already know what they need to do — they lack the investment in time and developers to help them accomplish those tasks.
Check out the project page and find out how to participate at https://openssf.org/community/alpha-omega/
Secrets of Successful Security Programs – Part 2 – We covered part 1 of this series two weeks ago in episode 181 (https://securityweekly.com/asw181). Part 2 goes into a lot more detail with 20 items that can set an effective baseline for a program. It’s a good companion piece to the articles this week on the DHS Cyber Safety Review Board, the Alpha and Omega efforts from the OSSF, and even the comments from the Log4j developers about their experience with fixing Log4Shell. Each of those articles speak to areas that stem from concepts in this article, and they’re a good reference for seeing the challenges in establishing security programs.
Frida HandBook – Here’s a great resource on using Frida to instrument binary applications for reverse engineering and analysis. It’s a great part of a home appsec lab and useful if you’re interested in learning new skills.
InsecureShop – We don’t want to neglect educational resources or mobile apps — so here’s a great combination of both. It’s an intentionally vulnerable app that’s helpful for those who want to understand the basics of setting up a toolbox and lab for security analysis, followed by a target that lends itself to helping understand how to conduct that analysis.
Want to Be an Ethical Hacker? Here’s Where to Begin – Here’s a list of resources for building your own lab and educating yourself on appsec topics with hands-on exercises. We covered some of the resources in the Security Weekly webcast on building a home lab for security testing, but there’s always room for more!