• tl;dr sec
  • Posts
  • [tl;dr sec] #83 - Comparing Infrastructure as Code Scanners, Jenkins Attack Framework, Good Design Principles

[tl;dr sec] #83 - Comparing Infrastructure as Code Scanners, Jenkins Attack Framework, Good Design Principles

Benchmarking infra as code scanning tools, offense-focused Jenkins tools, and principles that can help scale security.

Author

Clint Gibler
May 11, 2021

Hey there,

I hope you’ve been doing well!

Strategery and Normalcy

Last week we had a staff offsite to plan our next quarter, and it was a blast.

Since I joined my current company, it’s been fascinating to see the inner workings of the decision making process, and an honor and privilege to play a role in influencing company direction.

It also comes with a hefty feeling of responsibility, as I feel the weight of making decisions that will affect people’s jobs and the success of the company. The team is great though, and I’m fully confident in what we can build together.

Spending several socially distanced days in person with my colleagues was energizing. I didn’t realize how much I missed spending time with people until I had some non Zoom time.

I’ve very much looking forward to seeing people more regularly, and I’m getting my second shot today!

After which, I plan to promptly take up squirrel suit skydiving and juggling flaming knives. Conservation of risk, after all.

Sponsor

📢 Try Vectrix, the new Y Combinator security platform

Vectrix.io is making cloud and SaaS security ridiculously easy.

Browse a growing library of one-click security scans that instantly identify vendor misconfigurations, suspicious activity, and best practice violations. Simply choose your scans, connect your vendors, and click ‘run scan’ to receive a complete list of security issues in minutes.

Get started with 10 free scans every week. No credit card required.

📜 In this newsletter...

  • Web Security: Sending webhooks securely, using custom Python scripts with Burp, popular Burp extensions

  • AppSec: Finding goroutine leaks with Semgrep

  • Cloud Security: Tool to exploit Firebase datastores, cloud incident response framework, IaC scanner comparison repo, tfsec VS Code extension

  • Container Security: Results from scanning many Helm charts, Google's signing their base images, Kubernetes the hard way

  • Blue Team: An open source SOAR tool

  • Red Team: Jenkins attack framework

  • Misc: Call functions across programming languages, sustainable content creation

  • Is Complexity the Enemy of Security?: Phil Venables on good design principles

Web Security

Sending webhooks securely
Trickier than it sounds. Ameya Lokare describes: mitigating SSRF, authentication (request signing, mutual TLS, IP allow lists), and certificate chain verification.

Overcoming Issues Using Custom Python Scripts with Burp Suite Professional
By JumpSec Labs: how to run custom Python scripts on every request/response processed by Burp, including those from Burp’s active scanner. Use cases include:

  • Encoding / encrypting user input (where keys and algorithms are known)

  • HTTP request signature algorithms

  • Weak CAPTCHA implementations

  • Functionality that requires a unique value per request to the server

Ben Sadeghipour Twitter thread on popular Burp extensions
Common extensions people referenced include: Logger++, Param Miner, Auto Repeater, Autorize, Turbo Intruder, Asset History, Collaborator Everywhere, Active Scan++, HUNT, and Backslash Powered Scanner.

AppSec

Discovering goroutine leaks with SemgrepTrail of Bits’
Alex Useche walks through creating a Semgrep rule to identify goroutine leaks that found bugs in Kubernetes, Minikube, azure-container-networking, and hcsshim. Alex does a good job discussing Semgrep’s pros and cons and use cases in practice.

Trail of Bits has also open sourced a semgrep-rules repo that contains Python and Golang rules they’ve used on engagements.

Cloud Security

Introducing Baserunner: a tool for exploring and exploiting Firebase datastores
Baserunner eases testing for various Firebase misconfigurations, including: unauthenticated users having read/write access to collections, trying to dump the full datastore, testing authorization across privilege levels, exploring data and actions not exposed through the UI, and more.

Cloud Incident Response Framework
Newly published by the Cloud Security Alliance, covering how to effectively manage cloud incidents through the entire lifecycle of a disruptive event, including: preparation, detection and analysis, containment, eradication, and recovery, and post-mortem.

iacsecurity/tool-compare
Repo by Indeni’s Yoni Leitersdorf that has a bunch of IaC scanning test cases and compares the results from Checkov, Indeni Cloudrail, Kics, Snyk, Terrascan, and Tfsec.

tfsec VS Code Extension
Run tfsec in your IDE, by Owen Rumney.

Container Security

Part 1: Top trends from analyzing the security posture of open-source Helm charts
Bridgecrew’s Matt Johnson discusses the results of running 103 security checks against 2,312 Helm charts across 618 repos on Artifact Hub. They’ve also open sourced their data collection process, which gets a 👍 from me for reproducibility. In part 2 they examine Helm dependency trees, and in part 3 they examine one of the most popularly used dependencies on Artifact Hub, bitnami/postgresql.

Making the Internet more secure one signed container at a time
Google is now signing all of their distroless base images with their recently released Cosign tool. These minimal base images don’t include common tools like shells or package managers, making their attack surface (and download size) smaller than traditional base images such as ubuntu or alpine.

Kubernetes The Hard Way
A tutorial by Kelsey Hightower that guides you through bootstrapping a highly available Kubernetes cluster with end-to-end encryption between components and RBAC authentication on GCP.

Blue Team

frikky/Shuffle
An open source Security Orchestration, Automation and Response (SOAR) tool by Frikky. The security-openapis repo contains OpenAPI specifications for a number of security products and services, nice!

Red Team

Jenkins Attack Framework
Toolkit by Accenture’s Bryan Alexander and Shelby Spencer with a variety of useful offense-focused functionality, including understanding your current privileges, dumping LDAP or domain joining credentials, and “ghost jobs” - long running worker shells that aren’t visibile within Jenkins.

Misc

🤯 metacall/core by Vicente Eduardo Ferrer Garcia
MetaCall allows calling functions, methods or procedures between programming languages. Currently supports NodeJS, Vanilla JavaScript, TypeScript, Python, Ruby, C#, Go, C, C++, Rust, D, Cobol and more.

  1. Make sure you enjoy making your content separate from peoples’ reaction to it.

  2. Try to make content that’s evergreen, or as close as possible to it.

  3. Make sure you can happily take breaks for days, weeks, or even months at a time.

  4. It’s ok to enjoy nice comments, but don’t get to where you need them.

  5. Don’t compare yourself to other creators’ popularity or statistics.

Complexity is not the enemy of security. Bad design is.

Great post by Phil Venables in which he outlines 13 different examples of good design principles.

Here are a few parts I especially liked, along with some brief musings:

#1 Abstraction

Abstract complexity away through hiding it behind APIs and other interfaces. Then, think about security policy objectives and see if they require you to consider and enforce controls at multiple levels of abstraction.

#3 Opinionated Defaults

How can we abstract away sharp edges so most of the time developers don’t have to worry about security?

#4 Declarative Configuration

Define a configuration of the system in a declarative manner so that the actual configuration of the system can be generated and continuously compared to the specification. Treat policy/controls as a lifecycle managed part of the configuration. If you have controls as code then you need to inspect the ability of that control configuration to match intended policy, not just inspect the instantiated environment that results from the declarative configuration.

Explicit is better than implicit, and declarative configurations make it easy (/possible) to detect drift and auto-remediate.

#5 Idempotence

…if you push something to happen such as enforcing a particular control then no matter how many times you push it won’t have any other affect than sustaining the control. This is an important design property for applying declarative configurations in complex environments as you simply assert the outcome and let the control plane worry about state.

#7 Affordances

Look for opportunities to build in better affordances where the means of interacting with a system, element or controls intuitively conveys the capabilities it has. To quote Don Norman, “When affordances are taken advantage of, the user knows what to do just by looking: no picture, label, or instruction needed.”, like door handles that don’t have to come with a label of “push” or “pull” because the design makes that clear.

How can we make security controls and systems self-explanatory?

#8 Observability and Feedback Loops

Observability of the behavior of the system overall is critical, but it is only useful if the data from observation is put into feedback loops - either positive or negative - to correctly amplify or dampen behaviors.

#9 Reduce Error Messages and Guidance

Work to eliminate error messages, user guides and other configuration or set-up guidance for systems. Instead of creating better error messages work to reduce the scope of errors needing messaging. Similarly, if your user and configuration guides keep getting bigger and more numerous then ask yourself: are you making the right design choices on defaults, linked behaviors, and levels of abstraction?

Working to eliminate error messages and user guides is an aggressively strong position, and I love it. We owe it to our customers (developers and colleagues) to hold ourselves to this high standard.

#10 System-wide Invariants : People, Process and Technology

It is valuable to set system wide invariants - properties you want to be held true - and then build processes to enforce them. For example, if you want no single points of failure then build processes to find them and the feedback loops to eliminate them, and the design review practices to discourage the design patterns that lead to them. Additionally, work hard to not experience broken processes.

Secure guardrails and enforcing invariants are some of the highest leverage ways I’ve seen companies scale their security, and have featured prominently in talks I’ve given (BSidesSF, Global AppSec SF).

#11 Desire Lines : Principle of Least Action

One unifying theme here, borrowed from physics, is that where we see return on investment, our work aligns with the principle of least action. If our controls and approach can align with the natural “happy path” for our employees and our customers then that will likely provide the maximum returns over time. Another concept, is desire lines, if you consistently see an actual or attempted engineer or end user behavior (particularly in a complex environment) then you should find that and make that a secure path.

People are going to do what it takes to get their jobs done. How can we help them do their jobs easier, faster, and more securely?

If you don’t subscribe to Phil’s blog, you’re seriously missing out, his posts are consistently great.

Also, Laksh Raghavan shared some thoughts on this post.

✉️ Wrapping Up

Have questions, comments, or feedback? Just reply directly, I'd love to hear from you.

If you find this newsletter useful and know other people who would too, I'd really appreciate if you'd forward it to them 🙏

Thanks for reading!

Cheers,
Clint