Post

1/ A former DevOps colleague recently woke up to a $70k GCP bill. And honestly, 𝗶𝘁 𝗺𝗮𝘆 𝗯𝗲 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝘁𝗵𝗶𝗻𝗴 𝘁𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱 𝘁𝗼 𝘁𝗵𝗲𝗺. After investigating, they found out that an 𝗔𝗣𝗜 𝗸𝗲𝘆 created in 𝟮𝟬𝟮𝟬 with no restrictions had been leaked and was now being 𝗮𝗯𝘂𝘀𝗲𝗱 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗚𝗲𝗺𝗶𝗻𝗶 𝗔𝗣𝗜.

2/ They disabled the key immediately, only to discover it was tied to their Firebase SSO implementation. The key was meant to exist and to be public. It wasn’t meant to be unrestricted.

3/ The developer who created it likely intended it for development only. He stayed at the company for just six months in 2020 and somehow, the key made it into production after he left. 𝗦𝗶𝘅 𝘆𝗲𝗮𝗿𝘀 𝗹𝗮𝘁𝗲𝗿, 𝗶𝘁 𝘄𝗮𝘀 𝗲𝘅𝗽𝗹𝗼𝗶𝘁𝗲𝗱. 𝗔𝗻𝗱 𝗵𝗼𝗻𝗲𝘀𝘁𝗹𝘆, 𝘁𝗵𝗶𝘀 𝗺𝗶𝗴𝗵𝘁'𝘃𝗲 𝗯𝗲𝗲𝗻 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗼𝘂𝘁𝗰𝗼𝗺𝗲. 𝗔𝘁 𝗹𝗲𝗮𝘀𝘁 𝗶𝘁 𝘄𝗮𝘀 𝘃𝗶𝘀𝗶𝗯𝗹𝗲.

4/ See, there’s a growing class of threats called 𝗔𝗣𝗜 𝘄𝗼𝗿𝗺𝘀. @trufflesec.bsky.social has been writing about them, and we now have real-world examples like 𝗦𝗵𝗮𝗶-𝗛𝘂𝗹𝘂𝗱. These rely on chaining trust across services. 𝗡𝗼𝘁 on compromising hosts.

5/ 𝗔 𝘁𝘆𝗽𝗶𝗰𝗮𝗹 𝗽𝗮𝘁𝗵 𝗹𝗼𝗼𝗸𝘀 𝗹𝗶𝗸𝗲 𝘁𝗵𝗶𝘀: 1.A leaked API key is discovered (GitHub, S3, logs, etc.) 2.That key grants access to a service (storage, analytics, CI/CD) 3.Inside that service, more credentials are discovered

6/ 4.Those credentials unlock other platforms (Jira, artifact stores, ticketing systems) 5.The process repeats across systems, accounts, and even companies The important detail is that not all keys are equal, but 𝗮𝗹𝗹 𝗸𝗲𝘆𝘀 𝗮𝗿𝗲 𝘂𝘀𝗲𝗳𝘂𝗹.

8/ - Your Jira might contain customer secrets - Your artifact store might contain embedded credentials - Your support system might expose third-party access

9/ 𝗧𝗵𝗶𝘀 𝗶𝘀 𝗲𝘅𝗮𝗰𝘁𝗹𝘆 𝗵𝗼𝘄 𝗹𝗮𝘁𝗲𝗿𝗮𝗹 𝗺𝗼𝘃𝗲𝗺𝗲𝗻𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝘁𝗼𝘂𝗰𝗵𝗶𝗻𝗴 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝘀𝗲𝗿𝘃𝗲𝗿. A $70k bill is painful. But it’s contained and obvious. The multinational he works for can live with it.

10/ Now, a an unrestricted key is a node is a much larger graph of trust relationships. 𝗜𝗳 𝗮 𝗺𝗮𝗹𝗶𝗰𝗶𝗼𝘂𝘀 𝘂𝘀𝗲𝗿 𝗰𝗮𝗻 𝘁𝗿𝗮𝘃𝗲𝗿𝘀𝗲 𝘆𝗼𝘂𝗿 𝗴𝗿𝗮𝗽𝗵, 𝗶𝘁 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝗮 𝗽𝗮𝘁𝗵𝘄𝗮𝘆 𝘁𝗼 𝗺𝘂𝗰𝗵 𝗺𝗼𝗿𝗲 𝗰𝗮𝘁𝗮𝘀𝘁𝗿𝗼𝗽𝗵𝗶𝗰 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀.