• tl;dr sec
  • Posts
  • [tl;dr sec] #38 - Threat Modeling for Devs, Attacking JWTs, On Accepting Ads

[tl;dr sec] #38 - Threat Modeling for Devs, Attacking JWTs, On Accepting Ads

Effectively teaching devs threat modeling, forging and cracking JWTs, and some radical transparency about our process of deciding to accept sponsors.

Hey there,

I hope you’re doing well!

tl;dr sec surpasses 2,000 subscribers 🚀

When I started tl;dr sec, I didn’t expect it to ever get this popular. It feels a little strange, to be honest.

I feel incredibly honored and humbled that you see value in what I write 🙏 I will do my best to ensure tl;dr sec continues to be a good use of your time.

Panel @ DevSecCon24

I’m excited to announce that I’ll be moderating a DevSecOps panel at DevSecCon24 this upcoming Monday, June 15th at 6PM PT.

Come ask questions of an all star cast including: Justine Osborne, Tanya Janca, Doug DePerry, and Zane Lackey.

On Accepting Ads

After much reflection, I’ve decided to test allowing companies to sponsor tl;dr sec. In short, ads will be placed in a clearly demarcated box, and sponsors have no control over the content I include or exclude in the rest of the newsletter.

I really value transparency, so I wrote a post about this decision, which includes my thoughts on the goals and values of tl;dr sec, why I’m accepting ads, and a survey I did of other security creators to see how they do it. See here for details.

I’m considering this an experiment, which I may or may not continue.

Sponsor

📢 Incident Response @ Databricks

Databricks is looking for a Security Engineer to join their Security Incident Response Team (SIRT), responsible for investigating incidents, creating new security automation, and kicking out threat actors with great prejudice. Founded by the original creators of Apache Spark™ (a bunch of UC Berkeley PhDs), join Databricks and help secure the unified platform for massive-scale engineering used by more than 5,000 organizations worldwide.

Bonus ☝️: you get to work with Caleb Sima (twitter), a super sharp dude who’s founded and sold multiple security companies. He’s also a friend and advisor to tl;dr sec, playing a key role in making this newsletter what it is today.

📜 In this newsletter...

🔗 Links:

  • AppSec: A toolkit for validating, forging and cracking JWTs, resources for learning security engineering

  • Cloud Security: CloudSecList, best practices for monitoring GCP audit logs, priv esc i GCP's OS Login, actionable threat hunting in AWS, SSRF bypasses to access the AWS metadata endpoint

  • Container Security: A Kubernetes-native security toolkit

  • Red Team: A lightweight dynamic instrumentation library by Google Project Zero

  • Blue Team: Tool to automate provisioning of Active Directory labs in Azure to practice threat detection, a study of open source software supply chain attacks

  • Politics / Privacy: DEA has been given permission to investigate protesters, Signal introduces feature to blur faces in pictures, CNN and ACLU guides to protestor rights, how to help the protests from home

  • OSINT: Download subdomains for companies with bug bounty programs

  • Misc: A multi-month study plan for becoming a software engineer at a large company, defaut a car boot lock with a Bic pen, procedurally generating Chinese landscape painting

  • Threat Modeling: 3 ways to empower remote threat modeling, domain-driven design starter modelling process

📚 A Guide to Threat Modelling for Developers

Great, accessible overview of threat modelling, fit for sharing with developers.

AppSec

🔥 ticarpi/jwt_tool
“A toolkit for validating, forging and cracking JWTs” by @ticarpi. Functionality includes: checking the validity of a token, testing for known exploits, testing the validity of a secret/key file/Public Key/JWKS key, identifying weak keys via a high-speed dictionary attack, forging new token header and payload contents and creating a new signature with the key, timestamp tampering, and more.

The tool wiki also includes a JWT Attack Playbook with excellent details on known types of JWT vulnerabilities/misconfigurations and a repeatable methodology for attacking them. (h/t @HazanaSec for the link).

Learn Security Engineering
GitHub repo by Veeral Patel of links to useful articles, books, and notes about building secure systems, with an emphasis on Ross Anderson’s book Security Engineering and O. Sami Saydjari’s book Engineering Trustworthy Systems.

Good resources for people getting into security, and a nice overview of the fundamentals: threat modeling, minimizing attack surface, authorization, sandboxing, etc.

Cloud Security

If you’re not already familiar with it, I highly recommend checking out Marco Lancini’s CloudSecList newsletter.

Best practices for monitoring GCP audit logs
Guide by Datadog’s Justin Massey and Mallory Mooney on the structure of GCP audit logs, best practices for using audit logs to monitor GCP security, and how to export audit logs from GCP. They recommend monitoring for the following events: failed API calls (PERMISSION_DENIED status), service accounts and/or service account keys being created, bucket enumeration, buckets exposed to the world, logging sink modified, pub/sub subscriber modified, and pub/sub topic deleted.

Privilege Escalation in Google Cloud Platform’s OS Login
Detailed write-up by Chris Moberly: “How GCP’s OS Login works and then outline three methods of privilege escalation. The first two (via LXD and via Docker) are straight-forward and use previously-known methods to abuse the OS Login implementation. The third (hijacking the metadata server) is brand new.”

Actionable Threat Hunting in AWS
Notes from Chris Farris’s SEC339 talk at re:Invent 2019, which contains all the queries used in the talk, and focuses on the Preparation & Identification aspects of the SANS Incident Response framework. Tools used: Centralized CloudTrail and GuardDuty, Antiope (AWS Inventory and Compliance Framework), and Splunk.

  • Converted Decimal IP: http://2852039166/latest/meta-data/

  • IPV6 Compressed: http://[::ffff:a9fe:a9fe]/latest/meta-data/

  • IPV6 Expanded: http://[0:0:0:0:0:ffff:a9fe:a9fe]/latest/meta-data/

Container Security

aquasecurity/starboard
“Starboard integrates security tools into a Kubernetes environment, so that users can find and view the risks that relate to different resources in a Kubernetes-native way. Starboard provides custom security resources definitions and a Go module to work with a range of existing security tools, as well as a kubectl-compatible command-line tool and an Octant plug-in that make security reports available through familiar Kubernetes tools.”

Red Team

googleprojectzero/TinyInst
By Google Project Zero: “A lightweight dynamic instrumentation library that can be used to instrument only selected module(s) in the process, while leaving the rest of the process to run natively.” Built on top of a custom debugger, is not intended to run on malware (assumes target is well-behaved).

Blue Team

Automating the provisioning of Active Directory labs in Azure
Christophe Tafani-Dereeper released Adaz, a project “allowing you to easily spin up Active Directory labs for hunting, testing threat detection methods, and more generally having fun with AD and Windows.” Run with terraform apply, comes with Sysmon, WEF, Windows 10 workstations, pre-configured audit policies and a ready-to-query Kibana+ES instance.

Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks
“This paper presents a dataset of 174 malicious software packages that were used in real-world attacks on open source software supply chains, and which were distributed via the popular package repositories npm, PyPI, and RubyGems. Those packages, dating from November 2015 to November 2019, were manually collected and analyzed. The paper also presents two general attack trees to provide a structured overview about techniques to inject malicious code into the dependency tree of downstream users, and to execute such code at different times and under different conditions.”

Politics / Privacy

The DEA Has Been Given Permission To Investigate People Protesting George Floyd’s Death
“The Justice Department gave the agency the temporary power ‘to enforce any federal crime committed as a result of the protests over the death of George Floyd.’ Three DEA sources told BuzzFeed News they are troubled by the memo and see it as an example of the Justice Department potentially abusing its power in an attempt to smear the protests and crack down on protected First Amendment activity.”

Blur tools for Signal
“The latest version of Signal for Android and iOS introduces a new blur feature in the image editor that can help protect the privacy of the people in the photos you share. Now it’s easy to give every face a hiding place, or draw a fuzzy trace over something you want to erase.”

Can’t Go Out and Protest? Here’s How to Help From Home
Links to bail funds, organizations on the ground, contact public officials, etc.

OSINT

chaos.projectdiscovery.io
Continuous, Internet-wide asset discovery. Download lists of subdomains by company, and filter by if they have a bug bounty program.

Misc

Coding Interview University
Massively large “multi-month study plan for going from web developer (self-taught, no CS degree) to software engineer for a large company.” Probably the most thorough list of algorithms, data structures, and links to supporting resources I’ve ever seen in one place.

Procedurally generated Chinese landscape painting
Wow! Computers are magic sometimes 🧙‍♂️ Generate your own here.

Threat Modeling

Three ways to empower remote threat modeling
Article based on a discussion Security Journey’s Chris Romeo had with Adam Shostack on the Application Security Podcast. They recommend the drawing tool Miro as a collaborative whiteboard and OWASP Threat Dragon as a more threat modeling-focused option.

Domain-Driven Design Starter Modelling Process
“A step-by-step guide for learning and practically applying each aspect of Domain-Driven Design (DDD) - from orienting around an organisation’s business model to coding a domain model.” Not quite threat modeling, but I feel like there are some philosophical similarities, in that it involves big picture thinking and likely cross-functional collaboration.

I really enjoyed this article by Jim Gumbley. If you’re new to threat modeling, or you want to introduce developers to threat modeling, this seems like a nice, comprehensive guide: approachable, minimal security jargon, emphasizes fitting security within business priorities, and concrete examples 🤘

 Overall Tips 

  1. Focus primarily on technical (e.g. software weaknesses like missing security controls such as encryption or authorization) rather than broad threats (like hacker groups, insider threat, etc. Your primary concern is probably not nation state actors.).

    1. Starting from the structure and data-flow of your system allows you to start from your existing strengths as a developer, understanding the technical details of your system, of which you’re already quite familiar, unlike guessing at the relative risk and capabilities of different adversaries.

  2. Adopt a collaborative, team based approach. A wide variety of perspectives will lead to better decision making and increase the likelihood that you’ll identify the most important threats.

    1. Product owners are great to involve because they have insight into user behavior, business context, and the value of particular services and the impact if the data was exposed or lost.

    2. Don’t get stuck rabbit holing about creating the “perfect threat model.” Your system is constantly change and you will never find all the threats. See how far you can get instead by following the steps in the guide.

  3. Start threat modelling ‘little and often.’ Though each session will be tiny, the cumulative effect of doing them will have a huge impact.

    1. “When you know you’ll be doing this again every iteration, there’s less incentive to try to do everything at once and more incentive to prioritize the most important work right now.”

    2. “Each threat modelling session with the team should be short and focussed enough to be quickly digested into something that can be delivered. Start by analysing the thinnest slice of your system possible; just what you are working on right now. Rather than trying to analyse your entire system upfront, build your team’s muscle memory with threat modelling a little bit at a time.”

    3. There’s no reason why threat modeling needs to be an exhaustive upfront analysis. After all, that’s not how agile teams work.

The cyber security problem is not just about ticking technical boxes, its about making good investment decisions to protect the business.

Deciding the right focus and level of detail for your session is called ‘identifying the scope’. Make sure you have decided this ahead of getting people together to perform the activity. Be guided by what has most value right now. Perhaps its simply the user stories you are working on this iteration?

Here are some examples of scopes which have worked well:

  • Scope in current iteration.

  • An upcoming security sensitive feature, such as a new user registration flow.

  • The continuous delivery pipeline and delivery infrastructure.

  • A particular microservice and its collaborating services

  • A high level overview of a system to identify security tech debt.

 The 3 Key Threat Modeling Questions 

Spend roughly equal time on each.

  1. What are you building? Draw a ‘lo-fi’ technical diagram to get everyone on the same page.

    1. Show relevant components, show users on the diagram and their relative trust levels (e.g. anonymous user, standard user, admin or internal users).

    2. Draw arrows to show data flow, label networks and network boundaries, show your assets (e.g. data or services with business value, such as personal data)

  2. What can go wrong? Brainstorm threats to the system you have drawn. You can use something like STRIDE (a mnemonic for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege), perhaps using cue cards from ThoughtWorks.

    1. You can filter out implausible or less risky threats when you prioritize later in the session. For now, concentrate on brainstorming.

    2. Make sure that everyone is involved and no single voice is allowed to dominate.

    3. “If you need of inspiration, follow data-flow lines on your diagram one by one. How might one of the STRIDE concepts apply, for that data-flow?”

    4. Capture threats on sticky notes or otherwise jot them down next to the relevant component or data-flow.

  3. What are you going to do about it? You generally don’t have unlimited bandwidth to stop feature development and address every threat identified. Thus, you need to filter down and prioritize a few most important actions which you can take away and execute on effectively.

    1. Add fixes to the backlog, and use existing processes to support this.

    2. Creating a special spreadsheet or tracking document for security work is a common anti-pattern. Instead, apply a custom label or tag (e.g. “security”) to the issue. This label is useful for monitoring that security work is being prioritized and to demonstrate to risk management or security team members the details of the controls that have been implemented.

    3. For each prioritized threat, define concrete next steps (controls, mitigations, safeguards, security fixes) with specific, testable acceptance and “done” criteria.

The best way to make sure your threat modelling has an impact is to deliver the fixes and then do threat modelling again.

Question #4: “Did we do a good enough job?” 

Do a retrospective on your threat modelling efforts.

  • What went well and what could be improved?

  • Is the timing right?

  • Was the scope too granular? Not granular enough?

  • What about the location or remote tools you have used?

  • What issues cropped up after the session?

  • How long did the scope take to deliver?

Asking questions like these will help your team adapt and build mastery over time, doubling down on what works and discarding what adds little value.

The killer application of threat modelling is promoting security understanding across the whole team. This is the first step to making security everyone’s responsibility. Just like business outcomes, quality, integration and infrastructure - security can be central to how teams think about software delivery, rather than something bolted on at the end. In my experience, a team with the muscle memory of threat modelling is a team that proactively manages cyber-risk.

✉️ 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