Product

Harden-Runner Now Supports Monitoring Outbound HTTPS Requests From GitHub Actions Runners

StepSecurity Harden-Runner can now monitor the HTTP method and path of outbound HTTPS requests using eBPF to detect potential exfiltration attempts and recommend GITHUB_TOKEN permissions!

Varun Sharma
February 20, 2024

Table of Contents

Subscribe

Share This Post

Share This Post

Table of
Contents

Introduction

StepSecurity Harden-runner hardens your GitHub-hosted and self-hosted runners by providing outbound network controls and runtime security.

So far, Harden-Runner could monitor and block outbound traffic at the DNS and network layers. Many of our enterprise customers requested that it also support monitoring outbound HTTPS requests.  

Today, we are excited to announce support for monitoring the HTTP request method and path of outbound HTTPS requests from your GitHub-hosted and self-hosted VM runners!

Why Monitor Outbound HTTPS Requests From GitHub Actions Runners?

1. Better security monitoring: Many third-party Actions call github.com and api.github.com APIs. Although we can monitor and block these calls at the DNS and network level, a determined adversary can try to exfiltrate CI/CD secrets using these API calls. For instance, attackers might use the GitHub API to create a new issue or push content to their own GitHub organization.  

2. More accurate token permission recommendations: Although we already suggest GitHub-token permissions based on the third-party actions being used, we can suggest these permissions more accurately by monitoring the HTTP method and path of outbound GitHub API calls. This will help us suggest accurate GITHUB_TOKEN permissions for your workflows.

Monitoring Outbound HTTPS Requests

Let us look at how this feature works with the help of an example. Here is a GitHub Actions workflow that uses the latest version of Harden-Runner.  

https://github.com/step-security/github-actions-goat/blob/main/.github/workflows/hosted-https-monitoring-hr.yml  

The workflow creates an issue using the GitHub API. In the next step, an exfiltration is simulated by attempting to create a GitHub issue in the attacker’s organization, which would typically exfiltrate a CI/CD credential in the title or body of the issue.

Demo GitHub Actions workflow
Demo GitHub Actions workflow

The insights from a run of this workflow can be seen on the StepSecurity dashboard:

https://app.stepsecurity.io/github/step-security/github-actions-goat/actions/runs/7881624228

We now have a new tab for HTTPS events. This shows the HTTP method and PATH of outbound API calls to the github.com and api.github.com hosts.  

As you can see in the screenshot below, a POST call is made to the api.github.com host to create an issue. You can see that the PATH is as expected, and the GitHub organization (step-security) is the same where the workflow is running.  

HTTPS events on Harden-Runner insights page
HTTPS events on Harden-Runner insights page

In the next step, the exfiltration is attempted with a call to create an issue but to a different GitHub organization (hacker-org). This call has been flagged as anomalous since workflows should typically NOT make POST/ PUT API calls to a different GitHub organization. This information is highly valuable as it can aid in detecting any attempts to exfiltrate CI/CD credentials or source code via the GitHub API.

Suspicious HTTPS events
Suspicious HTTPS events

Recommendation for GITHUB_TOKEN Permissions

Monitoring the HTTP method and path of outbound GitHub API calls can help determine the necessary GITHUB_TOKEN permissions for each job. In the given example, we can observe three HTTPS events. The first is a GET request to download the source code, which corresponds to the read permission for contents. The second and third calls are POST requests to the /org/repo/issues API, which correspond to the write permission for issues.  

This information is used to display the recommended job-level GITHUB_TOKEN permissions in the Recommendations section.  

https token recommendation

How Does Harden-Runner Monitor HTTPS Requests?

Harden-runner uses eBPF to monitor HTTPS requests from GitHub-hosted and self-hosted VM runners. An MITM (Man-In-The-Middle) proxy is typically used to monitor HTTPS requests. However, using an MITM proxy has its challenges, as it requires setting up self-signed certificates. This can reduce the method's reliability and make it hard to monitor outbound traffic from docker images.  

Using eBPF, Harden-runner can solve these challenges by monitoring SSL write system calls. This eliminates the need for self-signed certificates, making the solution more reliable.

How To Enable It?

Our team and enterprise plans offer this feature, and our customers can opt-in to use it. To enable it, you need to update to the latest version of the harden-runner GitHub Action (v2.7.0), and then go to the “Settings tab” of your StepSecurity dashboard. Click on "HTTPS Monitoring Settings" and set it to "Enabled." If you prefer to disable HTTPS monitoring, you can do so using the same setting.

Once enabled, you can opt-in to email and/or Slack notifications if an anomalous HTTPS request is detected. To do this, go to the “Notification settings” under the “Settings tab” and check the “Notify when anomalous HTTPS outbound call is discovered” box. This is an example of an email notification when an anomalous HTTPS request is detected.

Notification for suspicious HTTPS events
Notification for suspicious HTTPS events

Roadmap for HTTPS Monitoring

We are working to enable the monitoring of additional hosts in addition to github.com and api.github.com.  

In addition, we are working on adding support for monitoring outbound HTTPS traffic for Kubernetes-based Actions Runner Controller (ARC) runners.

Try It Our Yourself

The outbound HTTPS request monitoring is an enterprise only feature. If you want to try it out, you can do so with our free trial. We're rolling out the feature selectively and if you want to try this feature out, please get in touch with us!

Get In Touch

Introduction

StepSecurity Harden-runner hardens your GitHub-hosted and self-hosted runners by providing outbound network controls and runtime security.

So far, Harden-Runner could monitor and block outbound traffic at the DNS and network layers. Many of our enterprise customers requested that it also support monitoring outbound HTTPS requests.  

Today, we are excited to announce support for monitoring the HTTP request method and path of outbound HTTPS requests from your GitHub-hosted and self-hosted VM runners!

Why Monitor Outbound HTTPS Requests From GitHub Actions Runners?

1. Better security monitoring: Many third-party Actions call github.com and api.github.com APIs. Although we can monitor and block these calls at the DNS and network level, a determined adversary can try to exfiltrate CI/CD secrets using these API calls. For instance, attackers might use the GitHub API to create a new issue or push content to their own GitHub organization.  

2. More accurate token permission recommendations: Although we already suggest GitHub-token permissions based on the third-party actions being used, we can suggest these permissions more accurately by monitoring the HTTP method and path of outbound GitHub API calls. This will help us suggest accurate GITHUB_TOKEN permissions for your workflows.

Monitoring Outbound HTTPS Requests

Let us look at how this feature works with the help of an example. Here is a GitHub Actions workflow that uses the latest version of Harden-Runner.  

https://github.com/step-security/github-actions-goat/blob/main/.github/workflows/hosted-https-monitoring-hr.yml  

The workflow creates an issue using the GitHub API. In the next step, an exfiltration is simulated by attempting to create a GitHub issue in the attacker’s organization, which would typically exfiltrate a CI/CD credential in the title or body of the issue.

Demo GitHub Actions workflow
Demo GitHub Actions workflow

The insights from a run of this workflow can be seen on the StepSecurity dashboard:

https://app.stepsecurity.io/github/step-security/github-actions-goat/actions/runs/7881624228

We now have a new tab for HTTPS events. This shows the HTTP method and PATH of outbound API calls to the github.com and api.github.com hosts.  

As you can see in the screenshot below, a POST call is made to the api.github.com host to create an issue. You can see that the PATH is as expected, and the GitHub organization (step-security) is the same where the workflow is running.  

HTTPS events on Harden-Runner insights page
HTTPS events on Harden-Runner insights page

In the next step, the exfiltration is attempted with a call to create an issue but to a different GitHub organization (hacker-org). This call has been flagged as anomalous since workflows should typically NOT make POST/ PUT API calls to a different GitHub organization. This information is highly valuable as it can aid in detecting any attempts to exfiltrate CI/CD credentials or source code via the GitHub API.

Suspicious HTTPS events
Suspicious HTTPS events

Recommendation for GITHUB_TOKEN Permissions

Monitoring the HTTP method and path of outbound GitHub API calls can help determine the necessary GITHUB_TOKEN permissions for each job. In the given example, we can observe three HTTPS events. The first is a GET request to download the source code, which corresponds to the read permission for contents. The second and third calls are POST requests to the /org/repo/issues API, which correspond to the write permission for issues.  

This information is used to display the recommended job-level GITHUB_TOKEN permissions in the Recommendations section.  

https token recommendation

How Does Harden-Runner Monitor HTTPS Requests?

Harden-runner uses eBPF to monitor HTTPS requests from GitHub-hosted and self-hosted VM runners. An MITM (Man-In-The-Middle) proxy is typically used to monitor HTTPS requests. However, using an MITM proxy has its challenges, as it requires setting up self-signed certificates. This can reduce the method's reliability and make it hard to monitor outbound traffic from docker images.  

Using eBPF, Harden-runner can solve these challenges by monitoring SSL write system calls. This eliminates the need for self-signed certificates, making the solution more reliable.

How To Enable It?

Our team and enterprise plans offer this feature, and our customers can opt-in to use it. To enable it, you need to update to the latest version of the harden-runner GitHub Action (v2.7.0), and then go to the “Settings tab” of your StepSecurity dashboard. Click on "HTTPS Monitoring Settings" and set it to "Enabled." If you prefer to disable HTTPS monitoring, you can do so using the same setting.

Once enabled, you can opt-in to email and/or Slack notifications if an anomalous HTTPS request is detected. To do this, go to the “Notification settings” under the “Settings tab” and check the “Notify when anomalous HTTPS outbound call is discovered” box. This is an example of an email notification when an anomalous HTTPS request is detected.

Notification for suspicious HTTPS events
Notification for suspicious HTTPS events

Roadmap for HTTPS Monitoring

We are working to enable the monitoring of additional hosts in addition to github.com and api.github.com.  

In addition, we are working on adding support for monitoring outbound HTTPS traffic for Kubernetes-based Actions Runner Controller (ARC) runners.

Try It Our Yourself

The outbound HTTPS request monitoring is an enterprise only feature. If you want to try it out, you can do so with our free trial. We're rolling out the feature selectively and if you want to try this feature out, please get in touch with us!

Get In Touch