it only took 2 characters - CourtneyR.dev's 2nd Brain

it only took 2 characters 🔗 **Source:** [it only took 2 characters](https://www.youtube.com/watch?v=dOgWVdWqXRU) > [!note]+ Document Notes > tags: [cybersecurity, aws, regex] > author: ThePrimeagen > source: YouTube > reference: https://www.youtube.com/watch?v=dOgWVdWqXRU > date created: 2024-12-19 15:30 > > # 🏷️ Title: AWS SDK JavaScript v3 Regex Vulnerability - Two Characters That Nearly Compromised Half the Fortune 500 >  ## 🧰 Action Inbox - [H1] Review regex patterns in CI/CD configurations — security audit #security - [H2] Implement proper actor ID validation — avoid regex for ID lists #devops - [H3] Audit GitHub webhook configurations — check for similar vulnerabilities #ci-cd ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Whiz.io Security Research](https://whiz.io) - [AWS SDK JavaScript v3](https://github.com/aws/aws-sdk-js-v3) ## 📝 Summary - White hat hackers discovered a critical vulnerability in AWS SDK JavaScript v3's CI/CD configuration that could have compromised half the Fortune 500 - The bug involved a regex pattern using pipe separators instead of exact matching for GitHub actor IDs in AWS CodeBuild - Attackers could create GitHub accounts with IDs containing substrings of authorized IDs to bypass authentication - This highlights the recurring theme that CI/CD vulnerabilities often stem from YAML configuration errors and regex misuse - The vulnerability was responsibly disclosed and fixed without malicious exploitation ## 📖 Main Content The AWS SDK JavaScript v3 repository is one of the most critical codebases on the internet, running on virtually every AWS cloud instance. A successful compromise could have affected half the Fortune 500 companies. Security researchers at Whiz.io discovered a vulnerability that allowed unauthorized access to the repository's CI/CD system through a deceptively simple regex error. The vulnerability existed in AWS CodeBuild's webhook configuration, where authorized GitHub actor IDs were listed with pipe separators (|) instead of exact matching. This created an unintended regex pattern where any GitHub account ID containing those digit sequences as substrings would be accepted. For example, if the authorized ID was "755743", any account with an ID like "1755743" or "7557431" would pass validation. Since GitHub creates approximately two new accounts per second, attackers could systematically create accounts until they obtained an ID matching the pattern. This attack vector is particularly dangerous because CI/CD systems typically have elevated privileges, including GitHub tokens for repository management and NPM tokens for package publishing. Successful exploitation could allow attackers to inject malicious code, steal sensitive tokens, or publish compromised versions of widely-used packages. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/dOgWVdWqXRU?t=0) — [H1] AWS SDK JavaScript v3 Critical Importance - Key idea: The repository runs on virtually every AWS cloud instance and could compromise half the Fortune 500 if breached - Evidence: "It runs on effectively every single cloud instance up in the cloud on AWS's kind of hosted service" #### ⏱️ [00:30](https://youtu.be/dOgWVdWqXRU?t=30) — [H2] White Hat Discovery and Simple Mistake - Key idea: White hat hackers discovered the vulnerability, which was an obviously simple mistake once revealed - Evidence: "It's such a simple mistake that I know for a fact that I would have made" #### ⏱️ [01:00](https://youtu.be/dOgWVdWqXRU?t=60) — [H2] Cloud CI Integration Pattern - Key idea: Cloud CI vulnerabilities have been a recurring theme throughout the past year - Evidence: "The theme of the last 365 days have been, hey, you got a cloud CI, you probably got a vulnerability" #### ⏱️ [01:30](https://youtu.be/dOgWVdWqXRU?t=90) — [H3] AWS CodeBuild Context - Key idea: AWS CodeBuild is a managed CI service for compiling, testing, and packaging software - Evidence: "It's a fully managed continuous integration service that compiles source code, run tests, and produces software packages" #### ⏱️ [02:00](https://youtu.be/dOgWVdWqXRU?t=120) — [H2] Similar Previous Attack - Singularity NX - Key idea: Previous CI vulnerability allowed hackers to control NX repository through PR title echo statements - Evidence: "A simple echo statement of the PR's title allowed a hacker to gain control of the entire NX repository system" #### ⏱️ [02:45](https://youtu.be/dOgWVdWqXRU?t=165) — [H1] The Regex Vulnerability Revealed - Key idea: The vulnerability was in actor ID validation using pipe separators instead of exact matching - Evidence: "Why would you ever separate a bunch of numbers with bars, right? Like, would you use commas?" #### ⏱️ [04:00](https://youtu.be/dOgWVdWqXRU?t=240) — [H2] Regex Demonstration - Key idea: The pipe separator creates a regex that matches any ID containing those digit sequences - Evidence: "So that means the attackers just had to have an account ID on GitHub that had the at least the same subset of numbers" #### ⏱️ [05:15](https://youtu.be/dOgWVdWqXRU?t=315) — [H2] Attack Strategy - GitHub Account Creation - Key idea: Attackers exploited GitHub's account creation rate to obtain matching IDs - Evidence: "A new GitHub account every two GitHub accounts are created a second" #### ⏱️ [06:00](https://youtu.be/dOgWVdWqXRU?t=360) — [H1] CI/CD Privilege Escalation Risk - Key idea: CI systems have elevated privileges including GitHub and NPM tokens - Evidence: "They have privileged GitHub tokens because they have to do things on behalf of GitHub" #### ⏱️ [06:45](https://youtu.be/dOgWVdWqXRU?t=405) — [H2] Token Extraction Method - Key idea: Attackers could inject CI jobs to extract sensitive tokens from the environment - Evidence: "I could add a new CI job... that goes into your process end gets all of the tokens" #### ⏱️ [07:30](https://youtu.be/dOgWVdWqXRU?t=450) — [H2] Package Publishing Attack Vector - Key idea: Stolen tokens could be used to publish malicious versions of popular packages - Evidence: "Now I can use your tokens to get everything... to publish, say, my own versions of your SDK" #### ⏱️ [08:00](https://youtu.be/dOgWVdWqXRU?t=480) — [H3] Regex as Common Vulnerability Source - Key idea: Regular expressions are frequently the source of production bugs and security issues - Evidence: "50% of all production bugs were in fact could be like traced back to a reax" ## 📚 References - [Whiz.io Security Research](https://whiz.io) - [AWS SDK JavaScript v3 Repository](https://github.com/aws/aws-sdk-js-v3) - [AWS CodeBuild Documentation](https://aws.amazon.com/codebuild/) ## 🗣️ Paraphrase - A critical security vulnerability in the AWS JavaScript SDK's CI/CD system could have compromised major corporations through a simple regex configuration error - The vulnerability allowed attackers to create GitHub accounts with IDs that matched authorized patterns due to improper use of pipe separators in validation - CI/CD systems are high-value targets because they contain elevated privileges and tokens that can be exploited to inject malicious code or steal credentials ## 📰 Newsletter 🚨 **Critical AWS SDK Vulnerability Highlights CI/CD Security Risks** A recent security discovery in the AWS JavaScript SDK v3 repository serves as a stark reminder of how simple configuration errors can create massive security risks. White hat researchers found that a two-character regex mistake could have compromised some of the world's largest companies. **The Issue**: AWS CodeBuild's webhook configuration used pipe separators (|) for GitHub actor ID validation, creating an unintended regex pattern that accepted any account ID containing those digits as substrings. **Key Takeaways for WordPress Developers**: - Audit your CI/CD configurations for similar regex patterns - Use exact matching instead of regex for ID validation when possible - Implement proper access controls for automated deployment systems - Consider the privileges your CI/CD systems have and minimize them **Resources**: - [GitHub Actions Security](https://docs.github.com/en/actions/security-guides) - [WordPress.org Security Guidelines](https://make.wordpress.org/core/handbook/security/) - [WP-CLI Security Best Practices](https://wp-cli.org/docs/security/) Stay vigilant with your deployment pipelines – it's often the simplest mistakes that create the biggest risks! 🛡️ ## ✅ Action Items #### DevRel - Developer advocacy: Create content about CI/CD security best practices, present at WordCamps on deployment security - Education: Develop workshops on secure GitHub Actions configurations, create regex security guidelines - Developer experience: Review WordPress.org CI/CD documentation for similar vulnerabilities - Developer marketing: Promote security-first development practices in campaigns - Community management: Monitor discussions about CI/CD vulnerabilities, facilitate security feedback #### OSPO - Policy & Governance: Establish CI/CD security review requirements, update contribution security policies - License Compliance: Scan for regex-based validation vulnerabilities in dependencies - Security Management: Create vulnerability intake process for CI/CD issues, establish security attestation requirements - Software Inventory: Audit all repositories for similar regex patterns in YAML configurations - Developer Support: Provide security training on CI/CD best practices, create secure configuration templates - Community Engagement: Fund security research initiatives, establish responsible disclosure agreements - Strategic Alignment: Include CI/CD security metrics in OKRs, establish security-first KPIs #### Community - Maintainers: Provide security review templates for CI/CD configurations, establish governance for automated deployments - Contributors: Create security-focused first-issue programs, implement secure onboarding for CI access - Sponsors: Report transparently on security investments, demonstrate impact of security funding - Ecosystem: Coordinate cross-project security standards, share threat intelligence #### WordPress - Core: Audit GitHub Actions for regex vulnerabilities, implement security reviews for CI changes - Core Performance: Ensure performance testing CI doesn't expose sensitive data - Core AI: Implement security guardrails for AI-assisted code review in CI - Meta: Review WordPress.org deployment pipelines for similar vulnerabilities, establish security SLAs - CLI: Audit WP-CLI's automated testing for token exposure risks - Plugins: Establish security liaison program for plugin CI/CD reviews - Themes: Implement security checks in theme review automation #### The WPCC - Programs: Fund security fellowships focused on CI/CD vulnerability research - Projects: Support governance clinics for secure deployment practices - Funding: Provide matched grants for security improvements in community tools #### FAIR - Technical independence: Establish metadata standards for CI/CD security verification - Policies: Implement funding transparency for security-related projects - Governance artifacts: Create operator agreements including security requirements ## 🧪 Hypotheses - Regex-based validation systems are more vulnerable to bypass attacks than exact matching systems - CI/CD systems with elevated privileges are high-value targets that require specialized security controls - The frequency of GitHub account creation enables systematic exploitation of substring-based validation vulnerabilities - Cloud-based CI/CD services introduce additional attack vectors through webhook misconfigurations ### 📊 Methodology - Static analysis of YAML configurations to identify regex patterns in access control - Dynamic testing of webhook validation systems with crafted account IDs - Survey of popular repositories to assess prevalence of similar vulnerabilities - Controlled experiments measuring GitHub account creation rates and ID patterns ### ❓ Questions - How many other major repositories use similar regex-based validation patterns? - What automated tools could detect these types of configuration vulnerabilities? - How should organizations balance CI/CD automation convenience with security requirements? ### 🔮 Future Research - Development of automated CI/CD security scanning tools - Analysis of webhook authentication patterns across major Git hosting platforms - Investigation of supply chain security implications for package registries ### 💡 Implications - Practice: Review all CI/CD configurations for regex-based vulnerabilities immediately - Policy: Establish mandatory security reviews for CI/CD configuration changes - Security: Implement least-privilege principles for automated deployment systems - Education: Include regex security and CI/CD hardening in developer training programs - Funding: Allocate resources for security audits of critical infrastructure repositories ### 🧠 Learning Styles Assessment Reading level estimate: 10th grade #### 👀 Visual learners - Present: Code examples, regex pattern demonstrations - Improve: Architecture diagrams showing attack flow, visual comparison of secure vs vulnerable configurations #### 🔊 Aural learners - Present: Video explanation with narrator - Improve: Podcast-style discussion of CI/CD security patterns #### 🗣️ Verbal learners - Present: Clear analogies (Netflix example), defined technical terms - Improve: More real-world analogies for regex vulnerabilities #### 🧩 Kinesthetic learners - Present: Code demonstrations, step-by-step attack recreation - Improve: Interactive sandbox for testing regex patterns safely #### 🧠 Logical learners - Present: Clear cause-and-effect explanation, timeline of attack - Improve: Decision tree for secure CI/CD configuration choices #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion prompts, shared vulnerability experiences - Improve: Collaborative security review frameworks #### 🧘‍♀️ Solitary learners - Present: Self-contained explanation with examples - Improve: Self-assessment checklist for CI/CD security #### 🌿 Naturalistic learners - Present: Ecosystem-wide impact analysis - Improve: Supply chain vulnerability lifecycle thinking ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, code block descriptions - Improve: More descriptive alt text for code examples, ARIA labels for technical concepts #### Keyboard navigation - Present: Logical tab order through content - Improve: Skip links for code sections, keyboard shortcuts for examples #### Contrast and readability - Present: High contrast code examples - Improve: Ensure syntax highlighting maintains accessibility standards #### Text resizing and reflow - Present: Responsive layout at 200% zoom - Improve: Test code block overflow behavior #### Media and captions - Present: Video captions available - Improve: Transcript with timestamp markers, audio descriptions of visual code elements #### Forms and interactions - Present: Accessible embedded examples - Improve: Form validation for any interactive security testing tools ### 🌍 DEIB Assessment #### Cultural breadth - Present: Universal security concerns affecting global infrastructure - Improve: Examples from diverse geographic regions, international compliance considerations #### Inclusive language - Present: Gender-neutral technical terms - Improve: Plain-language explanations of complex regex concepts #### Neurodiversity support - Present: Structured content with clear headings - Improve: Visual breaks between complex technical sections #### Representation - Present: Credit to diverse security research community - Improve: Highlight contributions from underrepresented groups in cybersecurity #### Psychological safety - Present: No blame for common mistakes, learning-focused framing - Improve: Emphasize that regex mistakes are common and understandable ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical flow from regex pattern to vulnerability exploitation - Inductive strength: Pattern recognition across multiple CI/CD vulnerabilities - Causal reasoning: Direct cause-effect relationship between configuration and security breach - --- ## Full Transcript [00:00] AWS SDK JavaScript v3 is perhaps one of [00:04] the single most important and popular [00:07] repositories on the internet there is. [00:10] It runs on effectively every single [00:13] cloud instance up in the cloud on AWS's [00:16] kind of hosted service. If this were to [00:18] be compromised like half of the Fortune [00:20] 500 companies would be compromised along [00:23] with it and someone actually figured out [00:25] how to do it. Yikes. Now, just wait [00:28] until you see this. Just like I actually [00:32] just genuinely feel bad for cuz when you [00:35] see it, you can't unsee it. It's just so [00:37] obvious. Your heart goes out for the [00:39] team, okay? Cuz it's such a simple [00:42] mistake that I know for a fact that I [00:44] would have made. Now, this particular [00:45] bug uh once again involves [00:48] cloud CI integration. And it kind of [00:51] seems like the theme of the last 365 [00:54] days have been, hey, you got a cloud CI, [00:57] you probably got a vulnerability. And [00:58] this one comes courtesy of course of AWS [01:00] code build. Now, it's nothing that AWS [01:02] code build it did itself. It's just [01:05] configuration. Again, it's always it [01:07] just feel it's just the same stuff every [01:09] single time. There's a YAML file out [01:11] there and it's going to ruin your [01:14] company. Of course, for those that don't [01:15] know anything about AWS Code Bill, it's [01:18] a fully managed continuous integration [01:21] service that compiles source code, run [01:23] tests, and produces software packages [01:26] that are ready to deploy. Thanks, AI. I [01:29] appreciate that, old Gemini. You little [01:31] rascal. Now, the most recent one that [01:33] comes to mind from these CI [01:34] vulnerabilities, of course, is the big [01:36] singularity NX hack, where a simple echo [01:39] statement of the PR's title allowed a [01:42] hacker to gain control of the entire NX [01:45] repository system and then release out [01:47] malicious ones that would exfiltrate [01:49] important tokens from users of said NX [01:52] packages or even transcendentally using [01:55] NX packages. Now, luckily this time, [01:57] it's not shahalude or singularity just [01:59] giving it to us. Instead, these were [02:01] some white hat hackers who were able to [02:03] just take control of the AWSJS SDK and [02:07] were able to get admin rights and then [02:08] have the whole thing fixed. Now, here's [02:11] how it happened. Just like GitHub, this [02:13] code build has this kind of like web [02:15] hook thing that goes on in which you [02:17] have like push and pull request created [02:19] and pull request updated. All the same [02:22] kind of hooks you would expect. And then [02:23] right here it says actor ID and then you [02:26] see this kind of list of actor IDs. Now, [02:29] I already know some of you right away [02:32] looked at that and went, "Oh my gosh." [02:35] No. Please tell me it's not so. Please [02:38] tell me it is not so. Yes, it is. So, it [02:42] is that simple. Now, for the rest of us, [02:44] if you if you really look at that list, [02:46] like zoom in, okay, look at the list. [02:48] Why would you ever separate a bunch of [02:50] numbers with bars, right? Like, would [02:52] you use commas? Well, yes. That's if you [02:55] wanted a comma-epparated list. This is [02:58] not a comma-epparated list. This is a [03:00] reax. Now, me personally, I have my own [03:02] kind of runin with the reax. You may [03:04] look at this right here. This is the old [03:06] Netflix TV signin. I accidentally added [03:09] a reax way back in the day, like 10 [03:11] years ago, where you could just keep on [03:13] clicking at Gmail and you'd keep on [03:15] getting more atgmails, but it said your [03:17] email address was valid. Okay. I've [03:19] personally been bit by rejaxes, so I [03:22] cannot judge the fine folks over uh at [03:25] this AWSJSSDKV3. [03:28] All right, so for those that don't [03:29] actually have any idea what's happening, [03:31] let me just type this up really quickly [03:32] for you. Okay, so I'm going go like [03:33] this. Const a equals we have like 1 2 3 [03:36] 4 pipe 1337. So that is pretty much the [03:39] exact same thing, right? It's a reax [03:41] with the pipe separator saying, "Hey, [03:43] either one of these numbers." Now I go [03:44] like this a test and then I can put in [03:46] something here like 1 2 3 4 and look [03:49] that's true. If I put in 1 124 you'll [03:52] notice oh no that's not correct. If I [03:54] put in 1337 it is correct. 1338 though [03:58] not correct. So where is the bug? Well [04:00] it's as simple as this. You see that [04:02] number? You think that passes the above [04:05] check? Why yes it does. So that means [04:08] the attackers just had to have an [04:10] account ID on GitHub that had the at [04:14] least the same subset of numbers. Their [04:17] ID just simply had to contain one of [04:20] these many IDs. And look at this one. [04:22] 755743. [04:24] That probably happens every now and then [04:25] on GitHub. That's not even a very long [04:27] number. So our fine friends over at [04:29] Whiz.io, the ones who originally [04:30] discovered this bug, what they did is [04:32] this. They figured out it was kind of [04:33] like a global race condition against [04:35] GitHub. a new GitHub account every two [04:37] GitHub accounts are created a second. [04:39] And so all they had to do was wait until [04:42] they got near an ID that appeared on [04:44] that list and then they just created [04:46] literally hundreds of accounts in that [04:48] moment and boom, they got an account who [04:51] had an ID who contained that submatch. [04:54] Now you're probably thinking, okay, well [04:56] what's the big deal? Wh why does that [04:57] matter? Okay, you can run these CI jobs. [05:00] What really actually matters with this? [05:02] Well, here's the thing is a lot of these [05:04] CI jobs, it's not the fact that you can [05:06] run them that is the problem. It's that [05:09] you get to choose what gets ran because [05:11] in most of these environments, they have [05:14] privileged GitHub tokens because they [05:15] have to do things on behalf of GitHub. [05:18] They have to close down PRs. They have [05:20] to say yes, this can be merged. No, this [05:22] can't be merged. Sometimes they allow [05:24] for automerging from one branch to [05:26] another. Second, there's all these npm [05:28] tokens that NPM There we go. There, [05:31] there, there it is. You have all these [05:32] npm tokens that exist and that allows [05:35] you to like push or delete or do [05:38] whatever the heck goes on in npm these [05:39] days. I don't think you can delete [05:40] anymore, but you can do all this and [05:42] push up your own version. So if you can [05:44] control CI, theoretically I could add a [05:48] new CI job or a set of tasks that need [05:50] to be ran during CI in which goes into [05:52] your process end gets all of the tokens [05:55] from your pro process end and then sends [05:57] it out to one of my own personal little [05:59] clouds and I could go, "Oh, look at [06:02] this. My little cloud my little cloud [06:03] has all of your tokens and now I can use [06:06] your tokens to get everything." Okay, [06:08] now guess what? Now you're going to have [06:09] to hide your kids, hide your wives, and [06:11] hide your husbands because I'm out there [06:12] taking everybody's tokens. And of [06:14] course, this would allow me then to [06:15] publish, say, my own versions of your [06:17] SDK. And this is effectively exactly [06:20] what happened with the singularity hack [06:22] and NX is that all they had to do was [06:25] get a hold of a running GitHub action. [06:28] And once you get that, oh baby, you get [06:30] those keys to the kingdom. And honestly, [06:32] when I see this, I just feel so bad [06:34] because of course it's a reax. It's [06:36] always a reax. I swear there's just [06:38] something so funny about the fact that [06:40] it's always a reax. There are memes [06:42] dedicated to the fact that it's always a [06:45] reax. There was even a fun phrase during [06:47] like 2014 2015 era over at Netflix where [06:51] we used to say that 50% of all [06:53] production bugs were in fact could be [06:55] like traced back to a reax. It is always [06:59] a reax. I don't know why. I don't know [07:02] how. It's just they just always are [07:05] there screwing your life over. Awesome [07:07] article. You should go read about it. [07:09] It's really really good. This is up on [07:11] Whiz.io. And of course, there's a [07:13] shorter version of just the tweet [07:14] highlight reel if you want to go look at [07:16] that. Links are in the description. [07:18] Thanks for watching. The name is you're [07:20] never going to catch me using a rejaxen. [07:24] By the way, have you ever met people [07:25] that call them regg? I mean, I actually [07:27] agree with the fact that they probably [07:28] should be called regex because it's a [07:30] regular expression. regular expression [07:32] reg x but some odd reason I just feel [07:34] like they're called regaxes. Same with [07:36] character versus char. Why do I call it [07:39] a char? Shouldn't it be a car? A car [07:42] star is the appropriate way to say a [07:44] caricaturer pointer. I don't what is [07:47] with what is wrong with me that I just [07:50] have these I just decide some G's need [07:53] to go J just like GitHub probably should [07:55] be Jithub. I should you know honestly if [07:57] I was honest with myself it'd just be [07:59] called Jithub. Hey, is that HTTP? Get [08:02] that out of here. That's not how we [08:04] order coffee. We order coffee via SSH [08:06] terminal.shop. Yeah, you want a real [08:08] experience. You want real coffee. You [08:10] want awesome subscriptions so you never [08:12] have to remember again? Oh, you want [08:14] exclusive blends with exclusive coffee [08:17] and exclusive content? Then check out [08:20] Kron. You don't know what SSH is? [08:22] >> Well, maybe the coffee is not for you. [08:28] in hand. [08:30] Living the dream.  ## 📺 Video ![](https://www.youtube.com/watch?v=dOgWVdWqXRU) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: AWS SDK JavaScript v3 Regex Vulnerability - Two Characters That Nearly Compromised Half the Fortune 500 ## 🧰 Action Inbox - [H1] Review regex patterns in CI/CD configurations — security audit #security - [H2] Implement proper actor ID validation — avoid regex for ID lists #devops - [H3] Audit GitHub webhook configurations — check for similar vulnerabilities #ci-cd ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Whiz.io Security Research](https://whiz.io) - [AWS SDK JavaScript v3](https://github.com/aws/aws-sdk-js-v3) ## 📝 Summary - White hat hackers discovered a critical vulnerability in AWS SDK JavaScript v3's CI/CD configuration that could have compromised half the Fortune 500 - The bug involved a regex pattern using pipe separators instead of exact matching for GitHub actor IDs in AWS CodeBuild - Attackers could create GitHub accounts with IDs containing substrings of authorized IDs to bypass authentication - This highlights the recurring theme that CI/CD vulnerabilities often stem from YAML configuration errors and regex misuse - The vulnerability was responsibly disclosed and fixed without malicious exploitation ## 📖 Main Content The AWS SDK JavaScript v3 repository is one of the most critical codebases on the internet, running on virtually every AWS cloud instance. A successful compromise could have affected half the Fortune 500 companies. Security researchers at Whiz.io discovered a vulnerability that allowed unauthorized access to the repository's CI/CD system through a deceptively simple regex error. The vulnerability existed in AWS CodeBuild's webhook configuration, where authorized GitHub actor IDs were listed with pipe separators (|) instead of exact matching. This created an unintended regex pattern where any GitHub account ID containing those digit sequences as substrings would be accepted. For example, if the authorized ID was "755743", any account with an ID like "1755743" or "7557431" would pass validation. Since GitHub creates approximately two new accounts per second, attackers could systematically create accounts until they obtained an ID matching the pattern. This attack vector is particularly dangerous because CI/CD systems typically have elevated privileges, including GitHub tokens for repository management and NPM tokens for package publishing. Successful exploitation could allow attackers to inject malicious code, steal sensitive tokens, or publish compromised versions of widely-used packages. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/dOgWVdWqXRU?t=0) — [H1] AWS SDK JavaScript v3 Critical Importance - Key idea: The repository runs on virtually every AWS cloud instance and could compromise half the Fortune 500 if breached - Evidence: "It runs on effectively every single cloud instance up in the cloud on AWS's kind of hosted service" #### ⏱️ [00:30](https://youtu.be/dOgWVdWqXRU?t=30) — [H2] White Hat Discovery and Simple Mistake - Key idea: White hat hackers discovered the vulnerability, which was an obviously simple mistake once revealed - Evidence: "It's such a simple mistake that I know for a fact that I would have made" #### ⏱️ [01:00](https://youtu.be/dOgWVdWqXRU?t=60) — [H2] Cloud CI Integration Pattern - Key idea: Cloud CI vulnerabilities have been a recurring theme throughout the past year - Evidence: "The theme of the last 365 days have been, hey, you got a cloud CI, you probably got a vulnerability" #### ⏱️ [01:30](https://youtu.be/dOgWVdWqXRU?t=90) — [H3] AWS CodeBuild Context - Key idea: AWS CodeBuild is a managed CI service for compiling, testing, and packaging software - Evidence: "It's a fully managed continuous integration service that compiles source code, run tests, and produces software packages" #### ⏱️ [02:00](https://youtu.be/dOgWVdWqXRU?t=120) — [H2] Similar Previous Attack - Singularity NX - Key idea: Previous CI vulnerability allowed hackers to control NX repository through PR title echo statements - Evidence: "A simple echo statement of the PR's title allowed a hacker to gain control of the entire NX repository system" #### ⏱️ [02:45](https://youtu.be/dOgWVdWqXRU?t=165) — [H1] The Regex Vulnerability Revealed - Key idea: The vulnerability was in actor ID validation using pipe separators instead of exact matching - Evidence: "Why would you ever separate a bunch of numbers with bars, right? Like, would you use commas?" #### ⏱️ [04:00](https://youtu.be/dOgWVdWqXRU?t=240) — [H2] Regex Demonstration - Key idea: The pipe separator creates a regex that matches any ID containing those digit sequences - Evidence: "So that means the attackers just had to have an account ID on GitHub that had the at least the same subset of numbers" #### ⏱️ [05:15](https://youtu.be/dOgWVdWqXRU?t=315) — [H2] Attack Strategy - GitHub Account Creation - Key idea: Attackers exploited GitHub's account creation rate to obtain matching IDs - Evidence: "A new GitHub account every two GitHub accounts are created a second" #### ⏱️ [06:00](https://youtu.be/dOgWVdWqXRU?t=360) — [H1] CI/CD Privilege Escalation Risk - Key idea: CI systems have elevated privileges including GitHub and NPM tokens - Evidence: "They have privileged GitHub tokens because they have to do things on behalf of GitHub" #### ⏱️ [06:45](https://youtu.be/dOgWVdWqXRU?t=405) — [H2] Token Extraction Method - Key idea: Attackers could inject CI jobs to extract sensitive tokens from the environment - Evidence: "I could add a new CI job... that goes into your process end gets all of the tokens" #### ⏱️ [07:30](https://youtu.be/dOgWVdWqXRU?t=450) — [H2] Package Publishing Attack Vector - Key idea: Stolen tokens could be used to publish malicious versions of popular packages - Evidence: "Now I can use your tokens to get everything... to publish, say, my own versions of your SDK" #### ⏱️ [08:00](https://youtu.be/dOgWVdWqXRU?t=480) — [H3] Regex as Common Vulnerability Source - Key idea: Regular expressions are frequently the source of production bugs and security issues - Evidence: "50% of all production bugs were in fact could be like traced back to a reax" ## 📚 References - [Whiz.io Security Research](https://whiz.io) - [AWS SDK JavaScript v3 Repository](https://github.com/aws/aws-sdk-js-v3) - [AWS CodeBuild Documentation](https://aws.amazon.com/codebuild/) ## 🗣️ Paraphrase - A critical security vulnerability in the AWS JavaScript SDK's CI/CD system could have compromised major corporations through a simple regex configuration error - The vulnerability allowed attackers to create GitHub accounts with IDs that matched authorized patterns due to improper use of pipe separators in validation - CI/CD systems are high-value targets because they contain elevated privileges and tokens that can be exploited to inject malicious code or steal credentials ## 📰 Newsletter 🚨 **Critical AWS SDK Vulnerability Highlights CI/CD Security Risks** A recent security discovery in the AWS JavaScript SDK v3 repository serves as a stark reminder of how simple configuration errors can create massive security risks. White hat researchers found that a two-character regex mistake could have compromised some of the world's largest companies. **The Issue**: AWS CodeBuild's webhook configuration used pipe separators (|) for GitHub actor ID validation, creating an unintended regex pattern that accepted any account ID containing those digits as substrings. **Key Takeaways for WordPress Developers**: - Audit your CI/CD configurations for similar regex patterns - Use exact matching instead of regex for ID validation when possible - Implement proper access controls for automated deployment systems - Consider the privileges your CI/CD systems have and minimize them **Resources**: - [GitHub Actions Security](https://docs.github.com/en/actions/security-guides) - [WordPress.org Security Guidelines](https://make.wordpress.org/core/handbook/security/) - [WP-CLI Security Best Practices](https://wp-cli.org/docs/security/) Stay vigilant with your deployment pipelines – it's often the simplest mistakes that create the biggest risks! 🛡️ ## ✅ Action Items #### DevRel - Developer advocacy: Create content about CI/CD security best practices, present at WordCamps on deployment security - Education: Develop workshops on secure GitHub Actions configurations, create regex security guidelines - Developer experience: Review WordPress.org CI/CD documentation for similar vulnerabilities - Developer marketing: Promote security-first development practices in campaigns - Community management: Monitor discussions about CI/CD vulnerabilities, facilitate security feedback #### OSPO - Policy & Governance: Establish CI/CD security review requirements, update contribution security policies - License Compliance: Scan for regex-based validation vulnerabilities in dependencies - Security Management: Create vulnerability intake process for CI/CD issues, establish security attestation requirements - Software Inventory: Audit all repositories for similar regex patterns in YAML configurations - Developer Support: Provide security training on CI/CD best practices, create secure configuration templates - Community Engagement: Fund security research initiatives, establish responsible disclosure agreements - Strategic Alignment: Include CI/CD security metrics in OKRs, establish security-first KPIs #### Community - Maintainers: Provide security review templates for CI/CD configurations, establish governance for automated deployments - Contributors: Create security-focused first-issue programs, implement secure onboarding for CI access - Sponsors: Report transparently on security investments, demonstrate impact of security funding - Ecosystem: Coordinate cross-project security standards, share threat intelligence #### WordPress - Core: Audit GitHub Actions for regex vulnerabilities, implement security reviews for CI changes - Core Performance: Ensure performance testing CI doesn't expose sensitive data - Core AI: Implement security guardrails for AI-assisted code review in CI - Meta: Review WordPress.org deployment pipelines for similar vulnerabilities, establish security SLAs - CLI: Audit WP-CLI's automated testing for token exposure risks - Plugins: Establish security liaison program for plugin CI/CD reviews - Themes: Implement security checks in theme review automation #### The WPCC - Programs: Fund security fellowships focused on CI/CD vulnerability research - Projects: Support governance clinics for secure deployment practices - Funding: Provide matched grants for security improvements in community tools #### FAIR - Technical independence: Establish metadata standards for CI/CD security verification - Policies: Implement funding transparency for security-related projects - Governance artifacts: Create operator agreements including security requirements ## 🧪 Hypotheses - Regex-based validation systems are more vulnerable to bypass attacks than exact matching systems - CI/CD systems with elevated privileges are high-value targets that require specialized security controls - The frequency of GitHub account creation enables systematic exploitation of substring-based validation vulnerabilities - Cloud-based CI/CD services introduce additional attack vectors through webhook misconfigurations ### 📊 Methodology - Static analysis of YAML configurations to identify regex patterns in access control - Dynamic testing of webhook validation systems with crafted account IDs - Survey of popular repositories to assess prevalence of similar vulnerabilities - Controlled experiments measuring GitHub account creation rates and ID patterns ### ❓ Questions - How many other major repositories use similar regex-based validation patterns? - What automated tools could detect these types of configuration vulnerabilities? - How should organizations balance CI/CD automation convenience with security requirements? ### 🔮 Future Research - Development of automated CI/CD security scanning tools - Analysis of webhook authentication patterns across major Git hosting platforms - Investigation of supply chain security implications for package registries ### 💡 Implications - Practice: Review all CI/CD configurations for regex-based vulnerabilities immediately - Policy: Establish mandatory security reviews for CI/CD configuration changes - Security: Implement least-privilege principles for automated deployment systems - Education: Include regex security and CI/CD hardening in developer training programs - Funding: Allocate resources for security audits of critical infrastructure repositories ### 🧠 Learning Styles Assessment Reading level estimate: 10th grade #### 👀 Visual learners - Present: Code examples, regex pattern demonstrations - Improve: Architecture diagrams showing attack flow, visual comparison of secure vs vulnerable configurations #### 🔊 Aural learners - Present: Video explanation with narrator - Improve: Podcast-style discussion of CI/CD security patterns #### 🗣️ Verbal learners - Present: Clear analogies (Netflix example), defined technical terms - Improve: More real-world analogies for regex vulnerabilities #### 🧩 Kinesthetic learners - Present: Code demonstrations, step-by-step attack recreation - Improve: Interactive sandbox for testing regex patterns safely #### 🧠 Logical learners - Present: Clear cause-and-effect explanation, timeline of attack - Improve: Decision tree for secure CI/CD configuration choices #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion prompts, shared vulnerability experiences - Improve: Collaborative security review frameworks #### 🧘‍♀️ Solitary learners - Present: Self-contained explanation with examples - Improve: Self-assessment checklist for CI/CD security #### 🌿 Naturalistic learners - Present: Ecosystem-wide impact analysis - Improve: Supply chain vulnerability lifecycle thinking ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, code block descriptions - Improve: More descriptive alt text for code examples, ARIA labels for technical concepts #### Keyboard navigation - Present: Logical tab order through content - Improve: Skip links for code sections, keyboard shortcuts for examples #### Contrast and readability - Present: High contrast code examples - Improve: Ensure syntax highlighting maintains accessibility standards #### Text resizing and reflow - Present: Responsive layout at 200% zoom - Improve: Test code block overflow behavior #### Media and captions - Present: Video captions available - Improve: Transcript with timestamp markers, audio descriptions of visual code elements #### Forms and interactions - Present: Accessible embedded examples - Improve: Form validation for any interactive security testing tools ### 🌍 DEIB Assessment #### Cultural breadth - Present: Universal security concerns affecting global infrastructure - Improve: Examples from diverse geographic regions, international compliance considerations #### Inclusive language - Present: Gender-neutral technical terms - Improve: Plain-language explanations of complex regex concepts #### Neurodiversity support - Present: Structured content with clear headings - Improve: Visual breaks between complex technical sections #### Representation - Present: Credit to diverse security research community - Improve: Highlight contributions from underrepresented groups in cybersecurity #### Psychological safety - Present: No blame for common mistakes, learning-focused framing - Improve: Emphasize that regex mistakes are common and understandable ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical flow from regex pattern to vulnerability exploitation - Inductive strength: Pattern recognition across multiple CI/CD vulnerabilities - Causal reasoning: Direct cause-effect relationship between configuration and security breach - --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=dOgWVdWqXRU)* **[00:00]** AWS SDK JavaScript v3 is perhaps one of the single most important and popular repositories on the internet there is. It runs on effectively every single cloud instance up in the cloud on AWS's kind of hosted service. If this were to be compromised like half of the Fortune 500 companies would be compromised along with it and someone actually figured out how to do it. Yikes. Now, just wait until you see this. Just like I actually **[00:32]** just genuinely feel bad for cuz when you see it, you can't unsee it. It's just so obvious. Your heart goes out for the team, okay? Cuz it's such a simple mistake that I know for a fact that I would have made. Now, this particular bug uh once again involves cloud CI integration. And it kind of seems like the theme of the last 365 days have been, hey, you got a cloud CI, you probably got a vulnerability. And this one comes courtesy of course of AWS code build. Now, it's nothing that AWS code build it did itself. It's just **[01:05]** configuration. Again, it's always it just feel it's just the same stuff every single time. There's a YAML file out there and it's going to ruin your company. Of course, for those that don't know anything about AWS Code Bill, it's a fully managed continuous integration service that compiles source code, run tests, and produces software packages that are ready to deploy. Thanks, AI. I appreciate that, old Gemini. You little rascal. Now, the most recent one that comes to mind from these CI vulnerabilities, of course, is the big **[01:36]** singularity NX hack, where a simple echo statement of the PR's title allowed a hacker to gain control of the entire NX repository system and then release out malicious ones that would exfiltrate important tokens from users of said NX packages or even transcendentally using NX packages. Now, luckily this time, it's not shahalude or singularity just giving it to us. Instead, these were some white hat hackers who were able to just take control of the AWSJS SDK and **[02:07]** were able to get admin rights and then have the whole thing fixed. Now, here's how it happened. Just like GitHub, this code build has this kind of like web hook thing that goes on in which you have like push and pull request created and pull request updated. All the same kind of hooks you would expect. And then right here it says actor ID and then you see this kind of list of actor IDs. Now, I already know some of you right away looked at that and went, "Oh my gosh." No. Please tell me it's not so. Please **[02:38]** tell me it is not so. Yes, it is. So, it is that simple. Now, for the rest of us, if you if you really look at that list, like zoom in, okay, look at the list. Why would you ever separate a bunch of numbers with bars, right? Like, would you use commas? Well, yes. That's if you wanted a comma-epparated list. This is not a comma-epparated list. This is a reax. Now, me personally, I have my own kind of runin with the reax. You may look at this right here. This is the old Netflix TV signin. I accidentally added **[03:09]** a reax way back in the day, like 10 years ago, where you could just keep on clicking at Gmail and you'd keep on getting more atgmails, but it said your email address was valid. Okay. I've personally been bit by rejaxes, so I cannot judge the fine folks over uh at this AWSJSSDKV3. All right, so for those that don't actually have any idea what's happening, let me just type this up really quickly for you. Okay, so I'm going go like this. Const a equals we have like 1 2 3 4 pipe 1337. So that is pretty much the **[03:39]** exact same thing, right? It's a reax with the pipe separator saying, "Hey, either one of these numbers." Now I go like this a test and then I can put in something here like 1 2 3 4 and look that's true. If I put in 1 124 you'll notice oh no that's not correct. If I put in 1337 it is correct. 1338 though not correct. So where is the bug? Well it's as simple as this. You see that number? You think that passes the above check? Why yes it does. So that means the attackers just had to have an **[04:10]** account ID on GitHub that had the at least the same subset of numbers. Their ID just simply had to contain one of these many IDs. And look at this one. 755743. That probably happens every now and then on GitHub. That's not even a very long number. So our fine friends over at Whiz.io, the ones who originally discovered this bug, what they did is this. They figured out it was kind of like a global race condition against GitHub. a new GitHub account every two GitHub accounts are created a second. And so all they had to do was wait until **[04:42]** they got near an ID that appeared on that list and then they just created literally hundreds of accounts in that moment and boom, they got an account who had an ID who contained that submatch. Now you're probably thinking, okay, well what's the big deal? Wh why does that matter? Okay, you can run these CI jobs. What really actually matters with this? Well, here's the thing is a lot of these CI jobs, it's not the fact that you can run them that is the problem. It's that you get to choose what gets ran because in most of these environments, they have **[05:14]** privileged GitHub tokens because they have to do things on behalf of GitHub. They have to close down PRs. They have to say yes, this can be merged. No, this can't be merged. Sometimes they allow for automerging from one branch to another. Second, there's all these npm tokens that NPM There we go. There, there, there it is. You have all these npm tokens that exist and that allows you to like push or delete or do whatever the heck goes on in npm these days. I don't think you can delete anymore, but you can do all this and push up your own version. So if you can **[05:44]** control CI, theoretically I could add a new CI job or a set of tasks that need to be ran during CI in which goes into your process end gets all of the tokens from your pro process end and then sends it out to one of my own personal little clouds and I could go, "Oh, look at this. My little cloud my little cloud has all of your tokens and now I can use your tokens to get everything." Okay, now guess what? Now you're going to have to hide your kids, hide your wives, and hide your husbands because I'm out there taking everybody's tokens. And of course, this would allow me then to **[06:15]** publish, say, my own versions of your SDK. And this is effectively exactly what happened with the singularity hack and NX is that all they had to do was get a hold of a running GitHub action. And once you get that, oh baby, you get those keys to the kingdom. And honestly, when I see this, I just feel so bad because of course it's a reax. It's always a reax. I swear there's just something so funny about the fact that it's always a reax. There are memes dedicated to the fact that it's always a **[06:45]** reax. There was even a fun phrase during like 2014 2015 era over at Netflix where we used to say that 50% of all production bugs were in fact could be like traced back to a reax. It is always a reax. I don't know why. I don't know how. It's just they just always are there screwing your life over. Awesome article. You should go read about it. It's really really good. This is up on Whiz.io. And of course, there's a shorter version of just the tweet highlight reel if you want to go look at **[07:16]** that. Links are in the description. Thanks for watching. The name is you're never going to catch me using a rejaxen. By the way, have you ever met people that call them regg? I mean, I actually agree with the fact that they probably should be called regex because it's a regular expression. regular expression reg x but some odd reason I just feel like they're called regaxes. Same with character versus char. Why do I call it a char? Shouldn't it be a car? A car star is the appropriate way to say a caricaturer pointer. I don't what is **[07:47]** with what is wrong with me that I just have these I just decide some G's need to go J just like GitHub probably should be Jithub. I should you know honestly if I was honest with myself it'd just be called Jithub. Hey, is that HTTP? Get that out of here. That's not how we order coffee. We order coffee via SSH terminal.shop. Yeah, you want a real experience. You want real coffee. You want awesome subscriptions so you never have to remember again? Oh, you want exclusive blends with exclusive coffee **[08:17]** and exclusive content? Then check out Kron. You don't know what SSH is? >> Well, maybe the coffee is not for you. in hand. Living the dream.