source code red horizontal logo

ATTACKING AND DEFENDING THE SOFTWARE SUPPLY CHAIN

A High Level Description of a SourceCodeRED Training System

$
Background

What is the Software Supply Chain?

A software supply chain is anything that your application needs to work. Typically, this is defined as the components, libraries, frameworks, tools, tests, and processes used to develop, build, and publish a software artifact and/or application.

I will go one step further and say that the software supply chain also includes the software engineers that build, maintain and deploy that software as well. After all, those engineers are a fundamental part of the process, and without them the supply chain grinds to a halt.

$

Relevance

Why do we Need to Attack & Defend this Supply Chain?

Two facts are important to understand here. First, the software supply chain is under increased threat. These threats have increased 600% or more every year since the start of the global COVID-19 pandemic. There are orders of magnitude more threats spread across the software supply chain and the software development lifecycle (SDLC). These threats are often new and novel, with things like dependency confusion, repo name-squatting, and malicious package managers being new threat types. The speed and scale that these threats have grown, are unlike any other IT related threat we have seen to date aside from ransomware.

The second fact is that software engineering and security teams are not keeping up with these new types of threats. 80% of software engineers admit to releasing software with known bugs, and 70% of engineers admitted to skipping existing security steps when under a time crunch.

Most importantly, our society requires highly iterative software development lifecycles. Software bonds us all together, and our society has grown totally dependent on it.

Understanding this, our society needs to make sure that software is scalable, secure and performant. And the best way to do that is to use the same principles we use for all other important manufacturing processes that our society is dependent on: We need to test it, and we need to test it thoroughly.

Goals of this Training.

The purpose of this training is to learn about the security posture of a specific software supply chain.

This training is not necessarily to compromise existing software supply chains, but instead to teach you how a target typically writes, builds and deploys its applications.

From that insight will come an understanding of the weaknesses and attack vectors available against that target.

Given the right expertise and time, this allows you to understand how to compromise a targets software supply chain and build your own apps that are resilient against this type of attack.

What is the Target?

The training will target one of three things:

An application

A software engineering team that writes applications
A company

Once the target has been identified, the training can be customized. Understand, that the way you proceed changes somewhat depending on which type of target you have.

$
OUR WORKSHOPS

Who Should Take this Training?

This workshop is intended to help bug bounty researchers, red teams, blue teams and purple teams. Moreover, anyone that is interested in understanding the weaknesses in software supply chains, and is legally entitled to test them, should take this training.

Use Cases for Different Targets

Most commonly, in a penetration testing scenario, your target will be a specific application, or application environment.

This is defined by the scope; typically an application centric penetration test, will only focus on a specific URL like https://app.example.org.

For bug bounty researchers the target will more commonly be a companies whole estate of applications. Most typically, all of the target companies web applications.

Bug bounty researchers are looking first for a set of flags that show, based on their experience, that there is an increased probability that an application can successfully be hacked. These signals can be combed through best when you start with all of a target companies web applications, and then narrow your focus based on these signals.

Finally, nation state actors or organizations conducting industrial espionage, or seeking intellectual property will most often target individual software engineers. This is typically driven by specific access that individual human, or group of humans, has.

For example, if the Russian SVR identified that a specific software engineer who worked at Solarwinds had the access they needed to compromise the build environment, they would target that individual. In fact, this may have been what the SVR did across a range of software engineers who had increased access and capabilities across the Solarwinds continuous integration and deployment lifecycle. Think about team leads, or engineering managers that don’t have the same level of guardrails applied to their access. If I was in the Russian SVR and targeting Solarwinds, this is exactly who I would target.

You can see my talk about the Solarwinds software supply chain attack and what we can all learn from it here:

We Will Leverage the DevSecOps Playbook

Most of the topics we will talk about during this training are originally covered in the DevSecOps Playbook written by Paul McCarty. You can find the Playbook here: github.com/6mile/DevSecOps-Playbook

RAD Structure

This training will use a graduated function called RAD. This stands for “Recon, Attack and Defend”.

For each topic, we will first describe how to identify issues with reconnaissance. Then we will explain how to take advantage of that issue by attacking it. Finally, we will describe how you address or mitigate that issue with controls or activities so you can effectively defend that topic.

Scope of this Training

There are four main areas we will spend time on during this training. Those four areas represent close to 100% of the attack surface for the software supply chain.

Software Engineers – The software engineers that write and deploy applications

SCM – Continuous Integration is how multiple developers interact at the code level and how their code is merged and aggregated

SCM – continuous deployment/delivery is the process of testing newly merged code, identifying if there are any problems in that code, combining many different software artifacts and dependencies and testing for functionality, security and other issues. If no issues are found then the application is built and deployed as an application

Software dependencies, including third-party libraries and frameworks. These dependencies can come from code, build processes, containers, runtimes, binaries, operating systems, cloud-native resources and a lot more

Additionally, we will apply the RAD structure to all 4 areas above. We will also cover both black box and white box techniques for recon.

What the Training Will Cover

Secure Software Engineers
L
Secure Software Engineers

Software Engineers

Identifying who engineers are and how they work is the single best way to attack the software supply chain. Some of the things we will cover in this training are:

  1. Recon (split into black box and white box)
    1. How does the engineer work? what tools and processes do they use?
    2. Identify the dev, and handles, etc.
    3. Are they using best practices?
    4. Social presence?
  2. Attack
    1. Use information from recon to take advantages of gaps that individual or team has.
    2. Focus on the local development processes and environment.
  3. Defend
    1. Harden environment and processes.
    2. Use security tools locally
    3. Harden git/IDE
    4. Implement local automation.
Secure CI Processes
L
Secure CI Processes

Continuous Integration

  1. Recon (split into black box and white box)
    1. How does the team work? What are the roles?
    2. Focus on CI steps and where there are gaps.
    3. Is the individual or team following best practices?
    4. How is identity handled?
  2. Attack
    1. Use information from recon to attack gaps in identity
    2. Abuse privileges
    3. Malicious code injection
  3. Defend
    1. Harden identity and access
    2. Use best practices for commit and merging
    3. Take advantage of tools in SCM
Secure CD Processes
L
Secure CD Processes

Continuous Deployment

  1. Recon (split into black box and white box)
    1. Is the team using CD?
    2. Are they testing, and if so, what?
    3. How are credentials handled?
    4. What the public exposure?
    5. What access do the CD tasks/stages have?
    6. Does the target have observability above the native SCM?
  2. Attack
    1. Typically, testing maturity is vastly overestimated
    2. Learn to chain small things together to make big things
    3. If there are good areas of test coverage, focus your efforts elsewhere
    4. Are prod and test secured the same way? If not, focus on test and learn
    5. Spend extra time on public attack surface
  3. Defend
    1. Implement testing coverage
    2. Safely store credentials
    3. Isolate development environments
    4. Limit CD access and roles
Secure Dependencies
L
Secure Dependencies

Dependencies & Techstack

  1. Recon (split into black box and white box)
    1. Identify as many dependencies as you can: code, cloud, third-party, etc
    2. Of those dependencies, which of them are actually useable? (theoretical vs actually attackable)
    3. What is the tech stack? Serverless? Containers? Servers?
    4. Is the target using old tech stack?
  2. Attack
    1. Use tech stack observations from above to focus on attacks that fit the environment
    2. Dependency vulnerability chaining is difficult, so focus on low hanging fruit
    3. Containers are easier than libraries and cloud services are easier than containers
    4. Privilege escalation is king. Always prioritize privesc over dependency manipulation.
  3. Defend
    1. Know your assets
    2. Implement visibility tooling for all of your asset classes (cloud, source, third party, etc)
    3. Understand that modern applications and traditional 3 tier apps have different security challenges. Understand what types of apps the target builds and account for the security challenges for that type of app.
    4. Continuous testing focus.
    5. Leverage up to date comprehensive SBOMs

CONTACT US

Service

Gold Coast office

16 Nexus Way, Southport, QLD 4215

ACN: 669 707 680