Security Best Practices for GitHub Actions

ACM.256 Options for Hardening GitHub Actions According to GitHub

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: GitHub Security | Application Security | Secure Code

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I took a look at GitHub actions and some of the risks involved with using them.

Now let’s take a look at GitHub’s recommended best security practices.

Github Secrets

We’ve already looked at AWS Secrets Manager and how to use it to keep secrets out of GitHub.

GitHub also has a method of protecting secrets and describes this feature in the GitHub Actions hardening documentation. You can store a secret in GitHub’s secret mechanism and then use those secrets within your workflow, similar to how we use secrets in AWS Secrets Manager.

Trusting Microsoft to keep it all secure

The question is really, do you trust GitHub with your AWS credentials? What if an unauthorized user can trigger a code check in event that then triggers and update to your website with some unwanted content? GitHub basically has free reign to push data to your website, though in theory everything is secured by Microsoft, right?

I’ve already written about the recent Microsoft code validation error that caused a breach of US government email systems in this post:

I wrote about vulnerabilities in GitHub actions in the last post that would have facilitated the scenario I’m describing.

Microsoft has had numerous outages as of late which points to lack of validation in actions taken to update systems. This concerns me.

I’ve experienced my own issues with Microsoft Azure systems including not being able to spin up a cloud VM and trying to get Microsoft to admit there was a bug in a new service for over a month.

So all that being said, although I think the Microsoft research and penetration testing folks I follow or have met are great, I’m not one to blindly trust the security of Microsoft products. So I’m going to think a bit about how to limit the damage in the case of a compromised GitHub action if I go that route.

Secrets in Logs

Let’s not forget these warnings:

• Structured data can cause secret redaction within logs to fail (meaning secrets may be exposed in GitHub logs. Who has access to these logs? Only you or people at Microsoft? May it’s supposed to be only you…
• Any sensitive value used in your workflow needs to be registered as a secret to be redacted in logs, including transformation of your secret in any way like base64 encoding it or generation of a new secret.
• Of course you’ll want auditing and logging of all secrets and related activities.

Leveraging Code Reviews

• You can use the CODEOWNERS feature on your workflow repository to require approval from a designated reviewer. I wrote about code reviews and why you need them here:

Code Injection

There’s a great section on all the ways code injection may occur in your workflow code. Anything can be altered in a web request or event that triggers a GitHub action can be used for code injection if it is referenced within the workflow code. These are exactly the type of things I look for on penetration tests.

This author writes about exfiltrating secrets in vulnerable GitHub actions that use particular events improperly:

There is a significant amount of risk when using a GitHub action, even when using GitHub secrets. If the action has access to the secrets and something in the GitHub environment is insecure then injected code may be able to retrieve those secrets. If those secrets include access to a cloud environment, such as was the case for Circle CI customers when Circle CI got breached, you might be needing to quickly rotate credentials — presuming you find out about a compromise before attackers have infiltrated your environment. Otherwise you may also be cleaning up the mess and potentially reporting a breach.

OpenID Connect (OIDC) and eradication of long-lived credentials

How does OIDC help us? The credentials are short lived credentials issued by a cloud provider and not stored in GitHub secrets. What that means is an attacker cannot obtain secrets from GitHub secrets. If they obtain the token used by an action it will only be usable for a short period of time.

Great, right?!

Well, whenever the workflow is triggered a token is issued. What if an attacker can trigger the event that triggers the workflow? They will potentially be able to generate the tokens they need.

What if some vulnerability allows the attacker to trigger the workflow even if the event has not occurred? Again, the attacker can trigger generation of a token.

What if the attacker steals the credentials of the person that can trigger the workflow? You guessed it — the attacker can generate a token.

Everyone is on the rampage to get rid of long-lived credentials at the moment. The problem is that even if you get rid of the long lived credentials, access to an active session is essentially the same thing. Even though the credentials are short lived, an attacker with access to a code injection vulnerability might be able to trigger the workflow and obtain the short-lived credentials in some way.

Rather than simply getting rid of long-lived tokens we need to think about the overall threat model and how to architect a solution that protects both long lived tokens and active sessions.

I wrote about session compromise here:

And faulty security control logic here:

Network restrictions to prevent workflow abuse

One way to help limit the chances an attacker external to GitHub itself (the people and systems at GitHub) would be to limit access to the GitHub repository and actions to a specific network.

Well, you can. And by the way, if you use the IP Allow list I described in earlier posts, you’ll need to use self-hosted runners.

This is why I made a note in the last post that self-hosted runners sounded interesting. Before even discovering this note above, I was thinking that with a self-hosted runner you could lock down the network to your own IP addresses. That would limit a lot of direct Internet scanning and attacks. Let’s say there’s some log4j-style vulnerability where an injection reaches out to the Internet in a workflow to exfiltrate some data. It won’t succeed if you’ve locked it all down to a private network.

But creating a self-hosted runner also sounds a bit involved, time-consuming, will likely involve additional expense to be constantly running to respond to actions and has it’s own set of security complications.

I was not sure I wanted to use GitHub actions in the first place, but if I do at some point, it will definitely involve a self-hosted runner and a locked down network. But I think that time and expense is overkill and at this point I’m not convinced the risk is worth it.

You can read about how to restrict network access to and from GitHub in these posts:

By the way, while creating an AWS Prefix List of all the IPs I need in my firewall rules to allow access to GitHub, I discovered that GitHub actions requires you to open up access to hundreds of IP ranges. It is extremely difficult to implement network security when companies design products like this. Hopeflly a private runner negates the need for all those IP ranges? I’m not sure as I haven’t taken it further.

At the moment, I’m thinking about some alternative mechanisms for triggering an update when I check code into GitHub. Stay tuned as I ponder different approaches to solving this problem.

Next up:

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab