Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label AWS Hijacking. Show all posts

AWS CodeBuild Misconfiguration Could Have Enabled Full GitHub Repository Takeover

 

One mistake in how Amazon Web Services set up its CodeBuild tool might have let hackers grab control of official AWS GitHub accounts. That access could spill into more parts of AWS, opening doors for wide-reaching attacks on software supplies. Cloud security team Wiz found the weak spot and called it CodeBreach. They told AWS about it on August 25, 2025. Fixes arrived by September that year. Experts say key pieces inside AWS were at stake - like the popular JavaScript SDK developers rely on every day. 

Into trusted repositories, attackers might have slipped harmful code thanks to CodeBreach, said Wiz team members Yuval Avrahami and Nir Ohfeld. If exploited, many apps using AWS SDKs could face consequences - possibly even disruptions in how the AWS Console functions or risks within user setups. Not a bug inside CodeBuild caused this, but gaps found deeper in automated build processes. These weak spots lived where tools merge and deploy code automatically. 

Something went wrong because the webhook filters had been set up incorrectly. They’re supposed to decide which GitHub actions get permission to start CodeBuild tasks. Only certain people or selected branches should be allowed through, keeping unsafe code changes out of high-access areas. But in a few open-source projects run by AWS, the rules meant to check user IDs didn’t work right. The patterns written to match those users failed at their job. 

Notably, some repositories used regex patterns missing boundary markers at beginning or end, leading to incomplete matches rather than full validation. This gap meant a GitHub user identifier only needed to include an authorized maintainer's number within a larger sequence to slip through. Because GitHub hands out IDs in order, those at Wiz showed how likely it became for upcoming identifiers to accidentally align with known legitimate ones. 

Ahead of any manual effort, bots made it possible to spam GitHub App setups nonstop. One after another, these fake apps rolled out - just waiting for a specific ID pattern to slip through broken checks. When the right match appeared, everything changed quietly. A hidden workflow fired up inside CodeBuild, pulled from what should have stayed locked down. Secrets spilled into logs nobody monitored closely. For aws-sdk-js-v3, that leak handed total control away - tied straight to a powerful token meant to stay private. If hackers gained that much control, they might slip harmful code into secure branches without warning. 

Malicious changes could get approved through rigged pull requests, while hidden data stored in the repo gets quietly pulled out. Once inside, corrupted updates might travel unnoticed through trusted AWS libraries to users relying on them. AWS eventually confirmed some repos lacked tight webhook checks. Still, they noted only certain setups were exposed. 

Now fixed, Amazon says it adjusted those flawed settings. Exposed keys were swapped out, safeguards tightened around building software. Evidence shows CodeBreach wasn’t used by attackers, the firm added. Yet specialists warn - small gaps in automated pipelines might lead to big problems down the line. Now worries grow around CI/CD safety, a new report adds fuel. 

Lately, studies have revealed that poorly set up GitHub Actions might spill sensitive tokens. This mistake lets hackers gain higher permissions in large open-source efforts. What we’re seeing shows tighter checks matter. Running on minimal needed access helps too. How unknown data is processed in builds turns out to be critical. Each step shapes whether systems stay secure.

More than 60,000 Parked Domains Were Vulnerable to AWS Hijacking

 

MarkMonitor, a domain registrar, had left over 60,000 parked domains susceptible to domain hijacking.

MarkMonitor, now part of Clarivate, is a domain management firm that assists in establishing and protecting the online presence of the world's biggest brands - and the billions who use them. 

The parked domains were found referring to non-existent Amazon S3 bucket addresses, indicating a domain takeover vulnerability. 

Ian Carroll, a security engineer, and bug bounty hunter, saw his automation script flag hundreds of domains belonging to various businesses as exposed to domain hijacking earlier this week. After that, Carroll was joined by Nagli and d0xing, who assisted the engineer in tracing the origin of the security flaw. MarkMonitor was the registrar for all of the domains. 

A (sub)domain takeover arises when an unauthorized actor is permitted to deliver the content of their preference on a domain that they do not own or control. This can happen, for instance, if the domain name contains a canonical name (CNAME) DNS entry pointing to a host that doesn't provide any content for it. This generally occurs when the website hasn't been launched yet, or when the virtual host has been withdrawn from a hosting provider, but the domain's DNS records still link to the host. 

Carroll explained, "If testing.example.com is pointed towards Amazon S3, what will S3 do if that bucket hasn't been created yet? It will just throw a 404 error—and wait for someone to claim it. If we claim this domain inside S3 before example.com's owners do, then we can claim the right to use it with S3 and upload anything we want." 

The issue affected over 60,000 domains, lasted less than an hour

After Carroll emailed MarkMonitor's security contact, the researcher did not hear back. But, he noticed that the domains previously throwing S3 "bucket not found" errors gradually started showing the proper MarkMonitor landing page. 

"After I sent an email to security@markmonitor.com that went unacknowledged, domains stopped pointing to S3 over an hour after it began. I claimed over 800 root domains in this timeframe, and other researchers had similar amounts of claimed domains," added Carroll. 

Carroll's primary concern was that up to 62,000 domains parked at MarkMonitor could be compromised and exploited for phishing. 

BleepingComputer contacted both Amazon and MarkMonitor for further information, and received the following response from MarkMonitor's parent firm, Clarivate: 

"During a planned move of our parking page to the cloud, our DDoS protection vendor temporarily routed traffic in an unexpected manner for some domains using MarkMonitor's parking page service." 

"Neither live domains nor DNS were impacted. We take the protection of the domains entrusted to us – including parked domains – extremely seriously, and we work every day to make sure we are following the best security practices and guidelines." 

"This includes having active and static scanning, ongoing DNS monitoring, annual 3rd party penetration testing, and other security audits," added Clarivate spokesperson. 

As per MarkMonitor, the firm quickly reversed its DDoS vendor settings to send traffic to an internally-hosted web server's parked page as soon as the unexpected behavior was discovered. The whole detection, investigation, and remediation process took less than an hour. 

The registrar discovered no instances of harmful content being hosted for any parked page. Carroll responded to a question about what organizations may do to effectively protect themselves against domain takeover vulnerabilities: 

"Until cloud providers like Amazon move to prevent domain takeovers like this, companies need to be careful when pointing traffic to them, either via DNS records or otherwise," Carroll told BleepingComputer. 

The engineer stated in his blog post, "This issue is not entirely the fault of MarkMonitor. While they need to be careful with handling parked domains, AWS is at fault for not being more stringent with claiming S3 buckets. Google Cloud, for example, has required domain verification for years, rendering this [attack] useless." 

MarkMonitor spokesperson concluded, "We are also evaluating mechanisms to be alerted more quickly of any HTTP error responses from domains that are parked with our parking service, which may allow us to identify and react to unexpected behavior even more quickly in the future."