Pelanggaran Vercel: Serangan OAuth mengungkap risiko tersembunyi variabel lingkungan platform

 (trendmicro.com)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Kompromi rantai pasok OAuth berujung pada akses ke sistem internal Vercel, dan menyebabkan paparan variabel lingkungan pada sebagian kecil proyek pelanggan yang terdampak
  • Titik awalnya adalah infeksi Lumma Stealer pada seorang karyawan Context.ai, dan token OAuth Google Workspace yang bocor digunakan untuk mengakses akun karyawan Vercel serta sistem internal
  • Penyerang memperoleh hak untuk mencantumkan variabel lingkungan proyek pelanggan, dan khususnya variabel yang ditandai non-sensitive memperbesar kemungkinan paparan kredensial layanan hilir
  • Berdasarkan indikasi yang terungkap, setidaknya dalam satu kasus ada deteksi API key bocor sebelum pengungkapan oleh Vercel, sehingga jeda waktu antara deteksi dan pemberitahuan menjadi faktor risiko utama
  • Insiden ini menunjukkan bahwa hubungan kepercayaan OAuth dan cara platform menyimpan variabel lingkungan dapat bersama-sama memicu penyebaran kredensial ke seluruh rantai pasok

Implikasi utama

  • Efek amplifikasi OAuth terkonfirmasi
    • Kerusakan pada satu hubungan kepercayaan OAuth meluas berantai dari vendor hingga ke sistem internal Vercel
    • Bahkan variabel lingkungan proyek pelanggan yang tidak punya hubungan langsung dengan vendor yang dikompromikan ikut terekspos secara terbatas
  • Kemungkinan serangan yang dipercepat AI mengemuka
    • CEO secara terbuka mengaitkan kecepatan tak biasa dari penyerang dengan penguatan oleh AI
    • Namun penilaian ini masih berupa pernyataan publik, bukan kesimpulan forensik resmi
  • Keterlambatan dari deteksi ke pengungkapan menjadi sorotan
    • Dalam setidaknya satu laporan pelanggan yang dipublikasikan, ada indikasi deteksi kunci bocor 9 hari sebelum pengungkapan Vercel
    • Dalam kompromi platform, jeda setelah deteksi hingga pemberitahuan ditandai sebagai faktor risiko penting
  • Terkait dengan pola yang lebih luas pada 2026
    • Sejalan dengan LiteLLM, Axios, Codecov, dan CircleCI, insiden ini terhubung dengan arus serangan rantai pasok yang menargetkan kredensial tersimpan milik developer

Linimasa insiden

  • Sekitar Februari 2026, seorang karyawan Context.ai terinfeksi Lumma Stealer, yang mengakibatkan kredensial perusahaan, token sesi, dan token OAuth bocor
  • Sekitar Maret 2026, penyerang mengakses lingkungan AWS milik Context.ai dan mencuri token OAuth milik pengguna konsumen
    • Ini mencakup token Google Workspace milik seorang karyawan Vercel
  • Maret 2026, token OAuth yang dicuri digunakan untuk mengakses akun Google Workspace milik karyawan Vercel
  • Dari Maret hingga April 2026, setelah berpindah ke sistem internal Vercel, penyerang mulai mencantumkan variabel lingkungan pelanggan
  • Sekitar April 2026, muncul klaim bahwa pelaku yang terkait dengan ShinyHunters mulai menjual data Vercel
  • 10 April 2026, seorang pelanggan Vercel secara terbuka menyebut telah menerima notifikasi API key bocor dari OpenAI
  • 19 April 2026, Vercel memublikasikan pemberitahuan keamanan dan membuka thread di X
  • Setelah 19 April 2026, pemberitahuan kepada pelanggan, panduan rotasi kredensial, dan perubahan dashboard mulai digulirkan
  • Meski masa tinggalnya relatif singkat, sekitar 2 bulan, insiden ini memperlihatkan kecepatan eskalasi dari infeksi vendor pihak ketiga hingga kebocoran variabel lingkungan pelanggan
  • Periode retensi default untuk log audit Google Workspace OAuth adalah 6 bulan pada banyak paket
    • Masa tinggal sekitar 2 bulan kali ini kemungkinan masih berada dalam jendela retensi
    • Namun juga disorot bahwa kompromi serupa yang berlangsung lebih lama bisa melampaui periode retensi default

Rantai serangan

  • Tahap 1: kompromi OAuth pihak ketiga

    • Context.ai memiliki aplikasi Google Workspace OAuth yang telah disetujui oleh seorang karyawan Vercel
    • Kompromi aplikasi ini ditelusuri ke infeksi Lumma Stealer pada seorang karyawan Context.ai sekitar Februari 2026
    • Menurut laporan Hudson Rock dan CyberScoop, karyawan tersebut diberitakan terinfeksi setelah mengunduh skrip exploit game Roblox
    • Dengan kredensial yang dicuri, penyerang mengakses lingkungan AWS milik Context.ai dan membocorkan token OAuth untuk pengguna konsumen Context AI Office Suite yang dirilis pada Juni 2025
    • Context.ai mengumumkan bahwa mereka mendeteksi dan menghentikan akses tidak sah ke lingkungan AWS pada Maret 2026
    • Namun mereka juga menyatakan bahwa kebocoran token OAuth itu sendiri tidak teridentifikasi sampai investigasi Vercel dilakukan
    • Aplikasi OAuth yang telah disetujui memiliki karakteristik berikut
      • Tidak memerlukan kata sandi pengguna
      • Dapat tetap berlaku bahkan setelah kata sandi diubah
      • Sering memiliki cakupan izin yang luas seperti email, Drive, kalender, dan lainnya
      • Setelah persetujuan awal, jarang menjadi objek audit

  • Tahap 2: pengambilalihan akun Workspace

    • Akses ke aplikasi OAuth yang telah dikompromikan memungkinkan perpindahan ke akun Google Workspace milik karyawan Vercel
    • Ini membuka kemungkinan akses ke email, dokumen internal di Google Drive, visibilitas ke kalender dan sumber daya terkait, serta kemungkinan akses ke layanan lain yang terhubung lewat OAuth

  • Tahap 3: akses ke sistem internal

    • Dari akun Workspace yang telah dikompromikan, penyerang berpindah lebih jauh ke sistem internal Vercel
    • Rauch menyebut eskalasi berlangsung melalui serangkaian operasi yang bermula dari akun Google Workspace Vercel milik rekannya yang telah dikompromikan
    • Teknik lateral movement yang spesifik tidak diungkapkan
      • Integrasi SSO
      • Kredensial yang dikumpulkan dari email atau Drive
      • Alat internal lain yang terhubung lewat OAuth
      • Tidak diungkap mana di antara opsi tersebut yang digunakan

  • Tahap 4: enumerasi variabel lingkungan

    • Penyerang memperoleh akses ke sistem internal Vercel dengan tingkat hak yang cukup untuk mencantumkan variabel lingkungan proyek pelanggan
    • Vercel menyediakan fitur untuk menandai variabel lingkungan pelanggan sebagai “non-sensitive”
    • Berdasarkan pernyataan publik, variabel lingkungan pelanggan tidak semuanya dilindungi dengan cara yang sama, dan enumerasi atas variabel yang tidak diberi penanda sensitif memberikan akses tambahan

  • Tahap 5: potensi penyalahgunaan layanan hilir

    • Variabel lingkungan yang terekspos umumnya memuat kredensial layanan hilir
    • Menurut laporan publik Andrey Zagoruiko pada 19 April 2026, ia menerima peringatan kunci bocor dari OpenAI pada 10 April
    • Menurut klaim pelapor, kunci tersebut tidak ada di tempat lain selain Vercel
    • Indikasi ini membuka kemungkinan bahwa setidaknya satu kredensial yang terekspos telah terdeteksi secara eksternal sebelum pengungkapan Vercel

Jeda 9 hari pada waktu pengungkapan

  • Dalam balasan thread X Guillermo Rauch pada 19 April, pelanggan Andrey Zagoruiko mengungkap bahwa ia menerima notifikasi kredensial bocor dari OpenAI pada 10 April 2026
  • Deteksi kredensial bocor oleh OpenAI umumnya bekerja ketika ditemukan di lokasi publik seperti GitHub, situs paste, dan sejenisnya
  • Jalur dari variabel lingkungan Vercel ke notifikasi OpenAI dinilai tidak sederhana dalam artikel tersebut
  • Dari tanggal yang ada, terdapat jendela 9 hari antara bukti paparan publik paling awal dan pengungkapan Vercel

  • Apa arti jeda 9 hari ini, dan apa yang tidak

    • Ini adalah satu laporan publik dan bukan hasil forensik yang telah dipastikan
    • Tidak boleh ditafsirkan sebagai bukti bahwa Vercel sudah mengetahui kompromi pada 10 April
    • Namun, tetap bermakna sebagai indikasi bahwa setidaknya satu kredensial telah terdeteksi di luar sebelum pelanggan diberi notifikasi untuk mengganti rahasia mereka

  • Implikasi bagi tiap pemangku kepentingan

    • Regulator
      • Dalam GDPR, hitungan 72 jam untuk notifikasi dimulai sejak pengendali menyadari telah terjadi pelanggaran
      • Kapan tepatnya Vercel menyadarinya muncul sebagai isu publik
    • Auditor
      • Penilai SOC 2 dan ISO 27001 dapat meninjau keterlambatan deteksi-ke-pemberitahuan sebagai bukti pemantauan berkelanjutan
    • Pelanggan
      • Tidak bisa mengasumsikan bahwa jendela paparan baru dimulai pada 19 April
      • Artikel ini menyatakan bahwa eksploitasi aktif bisa saja sudah terjadi sebelumnya
    • Notifikasi kredensial bocor yang dikirim penyedia menjadi semakin penting sebagai kanal peringatan dini
    • Contohnya termasuk OpenAI, Anthropic, GitHub, AWS, dan Stripe

Perilaku serangan yang dipercepat AI

  • Guillermo Rauch menyatakan di X pada 19 April 2026 bahwa ia sangat menduga kelompok penyerang sangat canggih dan banyak dipercepat oleh AI
  • Artikel ini memperlakukan pernyataan tersebut sebagai penilaian yang tercatat secara publik dari CEO platform yang terdampak, dan menyebut perlunya peninjauan yang hati-hati

  • Tanda-tanda yang dapat diharapkan dari bukti forensik

    • Kecepatan enumerasi yang melampaui laju kerja manual
      • Sebagiannya dapat dijelaskan hanya dengan scripting
      • Recon berbasis LLM dapat memparalelkan penjelajahan skema, probing endpoint, dan pengenalan format kredensial
    • Penyusunan kueri yang sadar konteks
      • Kueri yang seolah mengetahui terminologi khas Vercel, slug proyek, nama target deployment, dan aturan penamaan env var, bahkan tanpa reconnaissance awal yang jelas
    • Adaptabilitas respons terhadap error
      • Perubahan strategi setelah error API dan rate limit lebih fleksibel dibanding skrip statis
    • Hasil social engineering yang tampak terlokalisasi
      • Kalimat pancingan phishing, pesan commit, dan tiket dukungan memiliki kualitas yang lebih dekat dengan konteks lokal daripada terjemahan atau template

  • Pentingnya melampaui insiden Vercel

    • Terlepas dari apakah penilaian ini bertahan dalam forensik formal, kategori operasi serangan yang diperkuat AI bukan lagi sekadar spekulasi murni
    • Dalam pengumuman Microsoft April 2026, didokumentasikan contoh device-code phishing berbasis AI, pembuatan kode dinamis, umpan yang sangat dipersonalisasi, dan orkestrasi otomatisasi backend
    • Disebutkan bahwa baseline telemetri yang disesuaikan dengan tolok ukur kecepatan manusia dapat menghasilkan false negative terhadap operator yang dipercepat AI

  • Implikasi bagi rekayasa deteksi

    • Jika terjadi kompresi enumerasi dan lateral movement, aturan lama berbasis dwell time dan ambang kecepatan dapat menghasilkan peringatan yang terlalu rendah
    • Diajukan perlunya meninjau ulang hal-hal berikut
      • laju enumerasi resource unik per sesi
      • kurva pemulihan keberhasilan terhadap error
      • keragaman pola kueri dalam waktu singkat

Kerentanan inti dalam desain variabel lingkungan

  • Aspek paling krusial dalam artikel ini bukan vektor akses awal itu sendiri, melainkan model sensitivitas variabel lingkungan Vercel

  • Cara kerja variabel lingkungan Vercel saat itu

    • Proyek menyuntikkan variabel lingkungan ke fungsi serverless dan proses build
    • Ada flag sensitive per variabel
    • Nilai default adalah non-sensitive
    • sensitive perlu diaktifkan secara eksplisit
    • Variabel non-sensitive ditampilkan di dashboard
    • Variabel sensitive dimasking setelah dibuat
    • Akses melalui API internal dimungkinkan untuk non-sensitive, sedangkan sensitive dibatasi
    • Berdasarkan pernyataan publik internal, penyimpanan terenkripsi tidak diterapkan pada non-sensitive, sedangkan pada sensitive diterapkan bersama pembatasan tambahan
    • Dalam pelanggaran ini, target yang dapat diakses penyerang ditandai sebagai non-sensitive

  • Pilihan desain yang menentukan

    • Flag sensitive dinonaktifkan secara default
    • Semua DATABASE_URL, API_KEY, STRIPE_SECRET_KEY, dan AWS_SECRET_ACCESS_KEY yang tidak secara eksplisit diaktifkan oleh developer disimpan dalam bentuk tidak terenkripsi dalam model akses internal Vercel
    • Kontrol keamanan yang mengharuskan opt-in eksplisit untuk tiap secret individual, tanpa perlindungan default dan guardrail, dinilai memiliki tingkat adopsi aktual yang rendah

  • Respons Vercel

    • Dikonfirmasi telah dirilis peningkatan pada halaman ringkasan variabel lingkungan serta UI pembuatan dan pengelolaan variabel sensitif
    • Ada peningkatan dari sisi visibilitas, tetapi pada saat penulisan bukan perubahan default
    • Masih diperlukan opt-in per variabel
    • Apakah default akan diubah masih menjadi pertanyaan terbuka secara publik

  • Perbandingan industri

    • Industri bergerak ke arah penyimpanan secret khusus seperti Vault, AWS Secrets Manager, Doppler, dan Infisical
    • Insiden ini dinilai mendukung pemilihan arsitektur pengelolaan secret khusus dibanding pendekatan berbasis variabel lingkungan milik Vercel
    • Menurut tabel perbandingan
      • Vercel menggunakan default non-sensitive, tanpa deteksi otomatis
      • AWS SSM Parameter Store mendukung SecureString
      • HashiCorp Vault menyediakan enkripsi untuk semua secret dan ACL
      • GitHub Actions melakukan masking log untuk semua secret
      • Netlify menggunakan pendekatan variabel lingkungan dengan toggle secret

Credential fan-out dan risiko hilir

  • Credential fan-out adalah fenomena ketika satu pelanggaran platform memicu paparan berantai hingga ke semua layanan hilir yang diautentikasi dengan kredensial yang disimpan di platform tersebut
  • Ringkasan item yang sering dapat termasuk dalam variabel lingkungan proyek Vercel dan dampak hilirnya
    • Database
      • DATABASE_URL, POSTGRES_PASSWORD
      • Potensi akses penuh ke data
    • Cloud
      • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
      • Potensi kompromi akun cloud
    • Pembayaran
      • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
      • Risiko data keuangan dan penipuan refund
    • Autentikasi
      • AUTH0_SECRET, NEXTAUTH_SECRET
      • Potensi pemalsuan sesi dan pengambilalihan akun
    • Pengiriman email
      • SENDGRID_API_KEY, POSTMARK_TOKEN
      • Potensi phishing berbasis domain tepercaya
    • Monitoring
      • DATADOG_API_KEY, SENTRY_DSN
      • Potensi manipulasi telemetri
    • Source dan paket
      • GITHUB_TOKEN, NPM_TOKEN
      • Potensi injeksi rantai pasok
    • AI/ML
      • OPENAI_API_KEY, ANTHROPIC_API_KEY
      • Potensi penyalahgunaan API dan timbulnya biaya
  • Satu proyek Vercel umumnya memuat 10–30 variabel lingkungan
  • Pada skala organisasi, portofolio 50 proyek dapat berarti 500–1.500 kredensial berada di platform
  • Disebutkan bahwa dalam insiden ini hanya sebagian terbatas proyek pelanggan yang diakses, tetapi setiap satu kredensial yang terekspos dapat menjadi titik perpindahan ke sistem terpisah
  • Artikel ini mendefinisikan poin tersebut bukan sebagai sekadar insiden kerahasiaan platform, melainkan efek pengganda yang menyebar ke seluruh rantai pasok perangkat lunak

Hubungan kepercayaan OAuth dan penghindaran pertahanan perimeter

  • Intrusi berbasis OAuth menghindari banyak kontrol yang mendeteksi dan memblokir serangan tradisional berbasis kredensial
  • Artikel memuat kalimat sekitar 22 bulan, tetapi koreksi di bagian atas menyebutkan bahwa durasi keberadaan penyerang diperbaiki menjadi sekitar 2 bulan
  • Dijelaskan bahwa kontrol pertahanan yang diandalkan tim keamanan di kolom kiri menjadi tidak berarti atau sudah terpenuhi dalam jalur kompromi aplikasi OAuth
  • Karena asimetri ini, governance OAuth muncul sebagai domain keamanan yang terpisah dari IAM

  • Governance OAuth adalah fungsi risiko vendor

    • Banyak organisasi memperlakukan persetujuan OAuth sebagai persoalan self-service developer
    • Praktiknya berhenti pada persetujuan alat yang dibutuhkan per karyawan dan peninjauan terpusat yang minimal
    • Insiden ini diajukan sebagai dasar bahwa aplikasi OAuth yang disetujui harus diperlakukan sebagai vendor pihak ketiga dengan hak akses berkelanjutan
    • Diperlukan peninjauan vendor, persetujuan ulang berkala, dan pemantauan penggunaan yang abnormal

Klaim Pelaku Ancaman dan Atribusi

  • Dengan asumsi bahwa klaim pelaku ancaman di forum bawah tanah pada dasarnya sulit dipercaya
  • Informasi di sini dirangkum bukan sebagai fakta terverifikasi, melainkan untuk tujuan pemahaman dan pelacakan

  • Klaim keterkaitan dengan ShinyHunters

    • Poster di BreachForums mengklaim ada keterkaitan dengan ShinyHunters dan mengaku memiliki data Vercel
    • Item data yang diklaim
      • sekitar 580 catatan karyawan
      • repositori source code
      • kunci API dan token internal
      • token GitHub dan NPM
      • komunikasi internal
      • akses ke workspace Linear
    • Seluruh jumlah dan cakupan di atas belum terverifikasi

  • Faktor yang mempersulit atribusi

    • Anggota ShinyHunters yang diketahui membantah keterlibatan kepada BleepingComputer
    • Ada klaim bahwa tuntutan tebusan sebesar 2 juta dolar diajukan melalui Telegram
    • Merek ShinyHunters sejak kampanye awalnya telah digunakan oleh banyak pelaku lain atau pelaku yang tidak terkait
    • Pengumuman keamanan Vercel tidak menyebut klaim forum tersebut
    • Thread Rauch membahas rantai serangan, tetapi tidak secara langsung membahas postingan forum

  • Posisi Vercel soal jalur rilis rantai pasok

    • Rauch mengatakan ia telah menganalisis rantai pasok Next.js, Turbopack, dan banyak proyek open source, serta menyebutnya aman bagi komunitas
    • Per saat penulisan, verifikasi independen masih berlangsung
    • Organisasi yang menggunakan Next.js, Turbopack, dan open source Vercel lainnya disarankan untuk terus memeriksa sinyal integritas paket seperti checksum, signature, dan provenance attestation
    • Karena tidak ada verifikasi independen atas data yang diklaim di forum, informasi tersebut perlu diperlakukan sebagai informasi yang belum dikonfirmasi
    • Rantai serangan berbasis OAuth yang dijelaskan Vercel saja sudah cukup untuk menjelaskan insiden ini secara teknis; akses luas yang diklaim poster forum tidak dinilai sebagai syarat mutlak

Pemetaan MITRE ATT&CK

  • Rantai serangan yang telah dikonfirmasi dapat dipetakan secara alami ke teknik MITRE ATT&CK yang ada
  • Item pemetaan
    • Initial Access / Trusted Relationship / T1199
      • Aplikasi OAuth Context.ai dimanfaatkan sebagai pihak ketiga tepercaya
    • Persistence / Application Access Token / T1550.001
      • Token OAuth tetap bertahan meski kata sandi telah diubah
    • Credential Access / Valid Accounts / T1078
      • Kredensial Workspace milik karyawan yang telah dikompromikan
    • Discovery / Account Discovery / T1087
      • Enumerasi sistem dan proyek internal
    • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
      • Akses ke variabel lingkungan non-sensitive dimungkinkan
    • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
      • Kemungkinan penggunaan kredensial cloud yang terekspos
    • Collection / Data from Information Repositories / T1213
      • Enumerasi variabel lingkungan di berbagai proyek
  • Titik deteksi paling bernilai tinggi dalam pemetaan ini adalah bagian perpindahan dari akses aplikasi OAuth ke akses sistem internal
  • Organisasi perlu memantau perilaku anomali dari aplikasi OAuth yang mengakses resource di luar cakupan yang diharapkan atau dari rentang IP yang tidak diperkirakan

Pengepungan rantai pasok: LiteLLM, Axios, Vercel

  • Insiden Vercel bukan kejadian tunggal, melainkan bagian dari arus serangan rantai pasok yang terkonsentrasi pada Maret–April 2026
  • Artikel ini menyebut bahwa hal tersebut bisa jadi merupakan kampanye terkoordinasi, atau—yang lebih mungkin—hasil dari beberapa penyerang yang secara bersamaan menemukan kelemahan struktural yang sama, yakni batas kepercayaan antara repositori paket, CI/CD, penyedia OAuth, dan platform deployment

  • 24 Maret 2026: pelanggaran rantai pasok LiteLLM di PyPI

    • Paket PyPI berbahaya litellm 1.82.7 dan 1.82.8 dipublikasikan
    • Menggunakan kredensial deployment CI/CD yang dicuri dari pemindai kerentanan Trivy milik Aqua Security
    • LiteLLM adalah proxy LLM dengan sekitar 3,4 juta unduhan per hari
    • Backdoor tiga tahap menargetkan lebih dari 50 jenis kredensial di berbagai penyedia cloud utama
    • Termasuk persistensi Kubernetes DaemonSet
    • Dwell time sebelum terdeteksi dan dihapus sekitar 40 menit hingga 3 jam
    • CVE terkait adalah CVE-2026-33634

  • 31 Maret 2026: pelanggaran rantai pasok Axios di npm

    • Paket npm axios memiliki sekitar 70 juta hingga 100 juta unduhan per minggu
    • Versi berbahaya 1.14.1 dan 0.30.4 didistribusikan melalui pengambilalihan akun maintainer
    • Injeksi dependensi plain-crypto-js@4.2.1, berisi RAT lintas platform
    • Terdeteksi 135 endpoint terinfeksi berkomunikasi dengan C2 milik penyerang
    • Dwell time sekitar 2–3 jam
    • Microsoft mengatribusikan serangan ini kepada pelaku ancaman dukungan Korea Utara Sapphire Sleet

  • Pola konvergen

    • 3 serangan dalam 3 minggu
    • Vektor yang berbeda-beda
    • Target yang sama adalah kredensial dan rahasia yang disimpan developer di toolchain
    • Ringkasan tabel menampilkan hal berikut
      • LiteLLM: pencurian kredensial CI/CD → PyPI, kredensial developer dan kunci API, 40 menit–3 jam
      • Axios: pengambilalihan akun maintainer → npm, RAT workstation developer, 2–3 jam
      • Vercel: kompromi aplikasi OAuth → platform, variabel lingkungan pelanggan, di tabel tertulis sekitar 22 bulan tetapi telah dikoreksi menjadi sekitar 2 bulan di koreksi bagian atas dan isi artikel

Pola yang sama dengan pelanggaran platform sebelumnya

  • Pelanggaran Vercel terhubung dengan pola berulang di mana kompromi tingkat platform mengekspos rahasia pelanggan

  • Pelanggaran Codecov Bash Uploader, Januari–April 2021

    • Penyerang memodifikasi skrip Bash Uploader untuk membocorkan variabel lingkungan dari lingkungan CI pelanggan
    • Tidak terdeteksi selama sekitar 2 bulan
    • Lebih dari 29 ribu pelanggan berpotensi terdampak, termasuk Twitch, HashiCorp, dan Confluent
    • Kesamaannya dengan Vercel adalah paparan variabel lingkungan pelanggan melalui kompromi platform

  • Insiden keamanan CircleCI, Januari 2023

    • Malware pada perangkat pribadi mencuri token sesi SSO milik karyawan
    • Setelah mengakses sistem internal, rahasia pelanggan dan kunci enkripsi bocor
    • CircleCI menyarankan semua pelanggan untuk merotasi seluruh rahasia yang disimpan di platform
    • Strukturnya nyaris identik dengan Vercel
      • kompromi akun karyawan
      • akses ke sistem internal
      • kebocoran rahasia pelanggan

  • Serangan kredensial pelanggan Snowflake, Mei–Juni 2024

    • UNC5537 menggunakan kredensial yang diperoleh lewat infostealer dan akun tanpa MFA
    • Lebih dari 165 organisasi terdampak
    • Termasuk Ticketmaster, Santander Bank, dan AT&T

  • Pelanggaran sistem dukungan Okta, Oktober 2023

    • Mengakses sistem manajemen kasus dukungan pelanggan dengan kredensial yang dicuri
    • Melihat token sesi dalam file HAR
    • Pelanggan yang terdampak termasuk Cloudflare, 1Password, dan BeyondTrust

  • Ringkasan pola

    • Akses awal melalui hubungan tepercaya atau kredensial
    • Pergerakan lateral ke sistem internal
    • Eksfiltrasi rahasia pelanggan
    • Cakupan target bervariasi dari sebagian target hingga skala seluruh platform
    • Tabel merangkum vektor awal, aset yang terekspos, dan keterlambatan deteksi untuk tiap insiden
      • Codecov sekitar 2 bulan
      • Okta beberapa minggu
      • CircleCI beberapa minggu
      • Snowflake beberapa bulan
      • Vercel sekitar 2 bulan

Hal-hal yang masih belum diungkap

  • Meski sudah banyak laporan publik dan pernyataan eksekutif, celah informasi penting masih ada
  • Pertanyaan yang belum terjawab dalam catatan publik
    • kapan Vercel pertama kali mendeteksi aktivitas anomali
    • alasan selisih 9 hari antara bukti penyalahgunaan kredensial publik paling awal dan pengungkapan
    • jumlah pelanggan yang terdampak
      • Rauch menyebutnya “quite limited”, tetapi angka spesifik tidak diungkap
    • apakah klaim forum ShinyHunters berasal dari pelaku yang sama
    • status Context.ai saat ini dan apakah pelanggan hilir telah diberi notifikasi
    • cakupan penuh akses internal Vercel
      • jumlah tim, proyek, dan variabel lingkungan yang terdampak tidak diungkap
      • apakah ada akses ke sistem internal lain selain variabel lingkungan pelanggan juga belum dikonfirmasi
  • Artikel menekankan bahwa analisis yang ketat perlu tidak hanya merangkum fakta yang diketahui, tetapi juga secara eksplisit mengakui hal-hal yang belum diungkap

Panduan deteksi dan hunting

  • Tindakan segera untuk pelanggan Vercel

    • Perlu audit semua variabel lingkungan proyek
    • Artikel menyertakan contoh CLI berikut
      • vercel env ls --environment production
      • vercel env ls --environment preview
      • vercel env ls --environment development
    • CLI saat ini tidak mengekspos flag sensitive secara langsung, sehingga perlu memeriksa dashboard atau API

  • Menelusuri penggunaan tidak sah atas kredensial yang terekspos

    • Cari log audit penyedia cloud
      • AWS CloudTrail
        • Filter eventSource yang mencakup sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
        • Cari userIdentity.accessKeyId yang cocok dengan access key tersimpan di Vercel yang sudah diputar
        • Deteksi sourceIPAddress di luar CIDR organisasi yang sudah dikenal, python-requests, curl, Go-http-client, dan string otomatisasi userAgent yang tidak familier
        • Periode dari Februari 2026 hingga saat ini
      • GCP Audit Logs
        • Cari protoPayload.authenticationInfo.principalEmail dari akun layanan yang memakai kunci yang disimpan di Vercel
        • callerIp di luar rentang yang dikenal
        • Periksa metode seperti storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create
      • Azure Activity Logs
        • Filter berdasarkan application ID atau service principal yang ada di env vars Vercel
        • callerIpAddress di luar rentang yang diharapkan
        • Prioritaskan pemeriksaan Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write
    • Cari log akses database
      • Semua target DB yang string koneksinya ada di variabel lingkungan Vercel
      • Analisis seluruh rentang Februari–April 2026
      • Periksa IP di luar rentang egress yang dikenal seperti Vercel edge IP, VPN, kantor, dan sebagainya
      • Deteksi koneksi yang menggunakan kredensial terekspos di luar jendela deployment normal
      • Untuk PostgreSQL gunakan pg_stat_activity, log_connections
      • Untuk MySQL gunakan general log atau audit plugin
      • Untuk MongoDB Atlas gunakan event DATA_EXPLORER, CONNECT di Project Activity Feed
    • Cari log pemroses pembayaran
      • Stripe Dashboard → Developers → Logs
      • source_ip di luar server yang diharapkan
      • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
      • Periksa log setara di Braintree, Adyen
      • Dahulukan API key yang disimpan sebagai non-sensitive env var dan belum diputar
      • Periksa juga pengiriman tak terduga di log layanan pengiriman email
    • Perlu memeriksa notifikasi kebocoran kredensial tidak sukarela dari OpenAI, Anthropic, GitHub, AWS, Stripe, dan lainnya

  • Rotasi dan redeploy harus dilakukan bersamaan

    • Berdasarkan dokumentasi Vercel, memutar variabel lingkungan saja tidak membatalkan nilai kredensial lama pada deployment sebelumnya
    • Deployment lama akan terus memakai kredensial sebelumnya sampai dilakukan redeploy
    • Karena itu, semua rotasi memerlukan redeploy untuk semua environment yang memakai variabel tersebut atau penonaktifan eksplisit deployment lama
    • Prioritas dalam urutan berikut
      • Kredensial penyedia cloud
      • String koneksi database
      • Kunci pemroses pembayaran
      • Rahasia autentikasi
      • API key pihak ketiga
      • Token monitoring dan logging

  • Respons proaktif untuk tim keamanan

    • Tinjau semua aplikasi OAuth yang disetujui di Google Workspace Admin Console → Security → API Controls → Third-party app access
    • Tandai aplikasi dengan scope luas seperti Drive, Gmail, Calendar
    • Selidiki aplikasi vendor yang tidak memiliki hubungan bisnis aktif
    • Pantau penggunaan token OAuth dari rentang IP yang tidak diharapkan
    • Perlu mencari OAuth Client ID berbahaya yang sudah dikenal
      • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Logika deteksi SIEM

  • Tanda anomali aplikasi OAuth, tahap 1–2

    • Beri peringatan segera untuk event refresh token atau otorisasi yang terkait dengan OAuth Client ID berbahaya yang sudah dikenal
    • Cocokkan event pemberian izin scope luas seperti akses penuh email, baca/tulis Drive, akses kalender dengan daftar vendor saat ini
    • Aplikasi yang sudah tidak lagi dipakai untuk bisnis harus dicabut
    • Jika penggunaan token oleh aplikasi OAuth yang disetujui terjadi dari IP di luar rentang CIDR perusahaan dan vendor yang diharapkan, perlu investigasi

  • Akses sistem internal dan lateral movement, tahap 3

    • Event autentikasi SSO/SAML yang aneh
      • Ketika akun Workspace yang disusupi login ke aplikasi internal dari IP, wilayah, atau sidik jari perangkat yang belum pernah terlihat
    • Pengumpulan kredensial berbasis email dan Drive
      • Pencarian massal kata kunci seperti API key, secret, token, password, .env
      • Akses ke repositori kredensial bersama, runbook engineering, dokumentasi infrastruktur
      • Pembuatan aturan penerusan email
    • Akses alat internal yang terhubung OAuth
      • Pembuatan sesi atau aktivitas API di Slack, Jira, GitHub, dashboard internal, dan lainnya pada jam atau dari infrastruktur yang tidak biasa
    • Upaya eskalasi hak akses
      • Bergabung ke grup·peran baru
      • Akses ke konsol admin yang tidak digunakan
      • Pantau panggilan Directory API di Google Workspace, perubahan delegasi, dan upaya enumerasi token OAuth pengguna lain

  • Enumerasi variabel lingkungan, tahap 4

    • Deteksi pola volume/frekuensi tidak normal dalam log audit tim Vercel untuk panggilan bernuansa env read, list, decrypt
    • Pertama perlu membangun baseline waktu build CI/CD normal
    • Setelah itu, beri peringatan untuk akses yang volume, waktu, atau subjek sumbernya menyimpang dari baseline
    • Perhatikan akses dari akun pengguna non-service account, serta akses dari akun yang biasanya tidak berinteraksi dengan proyek tersebut

  • Penyalahgunaan kredensial hilir, tahap 5

    • Periksa log semua layanan target yang kredensialnya pernah disimpan sebagai non-sensitive Vercel environment variable selama jendela Februari–April 2026
    • Untuk AWS, cari CloudTrail berdasarkan access key ID tertentu
    • Untuk GCP dan Azure, cari log audit berdasarkan akun layanan atau application ID
    • Untuk SaaS API seperti Stripe, OpenAI, Anthropic, SendGrid, Twilio, periksa di dashboard atau log API apakah ada penggunaan dari IP tak dikenal atau pada jam nonaktif
    • Penggunaan yang tidak bisa diatribusikan ke infrastruktur sendiri harus segera dianggap sebagai kredensial yang dikompromikan dan perlu diputar serta diselidiki aktivitasnya

  • Notifikasi kebocoran kredensial pihak ketiga

    • Perlu memantau notifikasi pemindaian rahasia otomatis seperti GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud, dan lainnya
    • Notifikasi untuk kunci yang hanya pernah ada di platform deployment harus diperlakukan bukan sebagai peringatan kebersihan biasa, melainkan indikator kompromi platform

Prosedur manual threat hunting

  • Pencarian manual di Google Workspace Admin Console

    • Admin Console → Reports → Audit and Investigation → OAuth Log Events
    • Application Name = Context.ai atau Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Rentang waktu dari Februari 2026 hingga sekarang
    • Jika ada hasil, segera cabut izin dan lakukan investigasi insiden

  • Pemeriksaan aplikasi OAuth pihak ketiga dengan scope luas

    • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
    • Urutkan aplikasi dengan App access = Unrestricted
    • Item yang perlu diperiksa untuk tiap aplikasi
      • Apakah ada hubungan vendor aktif
      • Justifikasi bisnis untuk scope tersebut
      • Tanggal penggunaan terakhir
    • Aplikasi yang tidak digunakan selama lebih dari 90 hari harus dicabut

Rekomendasi pertahanan

  • Tindakan segera, 0~48 jam

    • Rotasi semua variabel lingkungan Vercel yang tidak ditandai sebagai sensitive
    • Deploy ulang semua environment setelah rotasi
    • Aktifkan flag sensitive untuk semua variabel lingkungan yang berisi kredensial, token, key, dan secret
    • Audit persetujuan aplikasi OAuth di konsol admin Google Workspace atau Microsoft Entra
    • Cabut akses aplikasi yang tidak lagi digunakan secara aktif
    • Tinjau log akses semua layanan yang menggunakan kredensial yang pernah disimpan di variabel lingkungan Vercel, dari Februari 2026 hingga sekarang

  • Penguatan jangka pendek, 1~4 minggu

    • Migrasi ke penggunaan pengelola secret khusus seperti HashiCorp Vault, AWS Secrets Manager, Doppler, dan Infisical
    • Gunakan metode injeksi saat runtime alih-alih penyimpanan variabel lingkungan di platform
    • Jika didukung, hilangkan kredensial jangka panjang dengan autentikasi berbasis OIDC
    • Terapkan pemantauan aplikasi OAuth
      • Nudge Security, Grip Security, Valence Security, atau fitur administrasi bawaan Google Workspace
    • Bangun otomatisasi rotasi kredensial
      • Disarankan siklus 30~90 hari
    • Sertakan persetujuan OAuth dalam inventaris risiko pihak ketiga seperti vendor kontrak

  • Perubahan struktural, 1~6 bulan

    • Adopsi postur Zero Trust untuk variabel lingkungan
      • Asumsikan semua secret yang disimpan di platform deployment dapat terekspos jika platform tersebut dibobol
    • Terapkan scope dengan hak akses minimum
      • Hak minimum untuk akun DB
      • Batasi ruang lingkup operasi API key
      • Untuk kredensial cloud, gunakan kredensial sementara berbasis peran alih-alih access key jangka panjang
    • Lakukan peninjauan keamanan pihak ketiga dan peninjauan ulang berkala untuk semua aplikasi dan integrasi OAuth yang mengakses sistem identitas perusahaan
    • Masukkan platform PaaS ke dalam inventaris SBOM/ASPM
      • Perlu diperlakukan bukan sebagai layanan eksternal, melainkan dependensi rantai pasok tingkat satu

  • Pemantauan yang direkomendasikan

    • Audit OAuth Client ID di Google Workspace Admin Console seperti di atas
    • Pantau panggilan API env.read, env.list yang tidak terduga di log audit Vercel
    • Tinjau di CloudTrail, GCP Audit Logs, dan Azure Activity Logs apakah ada penggunaan IP atau user agent yang tidak terduga untuk kredensial yang disimpan di Vercel env vars antara Februari~April 2026
    • Jika pohon dependensi memuat LiteLLM atau Axios, pantau juga IOC yang disebut dalam masing-masing advisori
    • Awasi notifikasi kredensial bocor tak disengaja dari penyedia API utama selama periode paparan

Dampak regulasi dan kepatuhan

  • Organisasi yang mungkin mengalami paparan kredensial akibat pelanggaran ini perlu menilai kewajiban berikut

  • GDPR

    • Jika kredensial yang terekspos memungkinkan akses ke sistem yang berisi data pribadi UE, hitungan 72 jam untuk notifikasi dapat dimulai sejak saat paparan terkonfirmasi
    • Notifikasi OpenAI pada 10 April menimbulkan pertanyaan bahwa bagi sebagian organisasi, titik kesadaran insiden mungkin lebih awal daripada pengungkapan publik pada 19 April

  • CCPA/CPRA

    • Paparan kredensial yang memberi hak akses ke data konsumen dapat memicu kewajiban notifikasi

  • PCI DSS

    • Jika kredensial pemrosesan pembayaran seperti Stripe, Braintree, atau Adyen terekspos, prosedur respons insiden dan investigasi forensik mungkin diwajibkan

  • SOC 2

    • Catatan insiden, tindakan rotasi kredensial, dan kontrol yang diperbarui perlu tercermin dalam bukti pemantauan berkelanjutan

  • SEC Cybersecurity Rules 8-K

    • Perusahaan publik yang menilai insiden ini material wajib melakukan pengungkapan dalam 4 hari kerja
    • Artikel tersebut menunjukkan bahwa meskipun penggunaan akses tidak sah yang sebenarnya mungkin belum diketahui, banyak kerangka regulasi dapat beroperasi berdasarkan paparan itu sendiri, bukan konfirmasi eksploitasi

Indikator kompromi

  • IoC yang terkonfirmasi

    • OAuth Client ID
      • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
      • Nilai yang terkait dengan aplikasi OAuth Context.ai yang telah dikompromikan

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Ini mengingatkanku bahwa saat Vercel pertama kali merilis UI variabel lingkungan, bahkan belum ada opsi sensitive sama sekali. Fitur itu baru hadir setelah hampir lebih dari 2 tahun. Diskusi terkait masih ada di GitHub discussion dan Vercel changelog

    • Menurutku, meski menambahkan flag sensitive di UI, runtime-nya tidak berubah. Begitu masuk ke process.env saat build, dependensi yang berniat mengintip tetap bisa membacanya. Masalah sebenarnya adalah semua secret dimasukkan ke satu kantong env lalu diserahkan utuh ke build tool. Cloudflare dengan scoped bindings atau Fly sudah memisahkannya, dan menurutku platform lain tertinggal dalam hal ini
    • Menurutku sensitive bukan berarti tidak bisa dibaca, melainkan hanya berarti disembunyikan dari UI. Kalau action function atau route mengembalikan props sedikit terlalu banyak, nilainya bisa bocor dengan mudah. Untuk mencegah masalah seperti ini, pada akhirnya nilai environment harus dienkripsi dengan key milik sendiri, dan karena tidak ada sarana isolasi yang memadai, tampaknya sebagian secret bisa dibake-in ke source sebagai jalan memutar. Penyerang bukan hanya harus membaca nilai environment, tetapi juga mengunduh hasil build dan mencari key dekripsi, jadi hambatannya sedikit lebih tinggi. Memang tidak ideal, tetapi sepertinya bisa bekerja sebagai langkah sementara

  • Terasa seperti insiden yang benar-benar memalukan. Jika kutipan itu akurat, bagian yang paling bikin heran adalah infeksi Lumma Stealer bermula dari pegawai Context.ai yang mengunduh Roblox exploit script

  • Bagian ketika CEO secara terbuka menyalahkan gerak cepat penyerang pada teknik serangan yang dipercepat AI menurutku hampir tidak punya dasar yang terlihat. Jadi rasanya juga tidak banyak informasi substantif yang benar-benar terungkap

    • Belakangan ini AI bahkan tampak mengguncang pasar alasan yang mengada-ada, dan media seperti mengulanginya tanpa verifikasi, yang terasa cukup sinis
    • Di sisi lain, ini juga mengingatkanku bahwa solusi vibe coded sering cenderung merekomendasikan Vercel. Rasanya mirip dengan gelombang rekomendasi Axios dulu

  • Aku kurang paham penjelasan Stage 2. Kalau aplikasi ContextAI memang meminta semua izin seperti Google mail, drive, dan calendar, itu terasa berlebihan. Ini bukan perusahaan kecil, jadi sulit dipercaya mereka menyetujui menjalankan hal seperti itu di luar lingkungan mereka sendiri. Namun, setelah membaca posting pembaruan keamanan dari Context.ai, kesannya justru satu pegawai Vercel secara pribadi memilih memberi akses ke seluruh Google Workspace miliknya

  • Aku masih belum menangkap jelas bagaimana alur ini bekerja. Aku penasaran apakah OAuth token yang dimaksud di sini adalah token yang diterima setelah Sign in with Google. Biasanya bukankah itu terikat pada client id dan client secret milik Google App tertentu? Walau penyerang mengetahui OAuth token pengguna dan informasi client, aku masih bisa memahami akses ke Drive dan semacamnya, tetapi bagaimana itu berlanjut sampai login ke control plane Vercel masih sulit kupahami. Apakah pada akhirnya mereka menemukan kredensial di dalam Google Drive?

    • Menurutku laporan itu tidak menjelaskannya dengan jelas. Karena itu justru memunculkan dugaan bahwa ada kesalahan yang lebih memalukan dan sedang disembunyikan. Mungkin kata sandi ada di Drive atau Gmail, atau mungkin seperti komentar lain, berupa passwordless login link
    • Setelah proses OAuth selesai, inti penjelasannya tampaknya adalah bahwa pada akhirnya Anda mendapat session token, dan dengan itu Anda bisa mengirim permintaan API. Kemungkinan besar token yang diterbitkan juga memiliki akses ke inbox korban, dan penyerang lalu membaca email untuk memperoleh kata sandi sekali pakai, magic link, atau informasi sensitif lain
    • Aku juga bingung. Aku penasaran apakah yang benar-benar dibobol adalah aplikasi OAuth milik Context.ai, sehingga penyerang ikut mendapatkan visibilitas ke semua workspace pelanggan yang bisa dilihat Context.ai. Tapi lalu kenapa tanggung jawabnya seolah terpusat pada satu pegawai tertentu? Pada akhirnya poin kuncinya tampaknya adalah apakah pegawai Vercel itu memberi persetujuan kepada Context.ai untuk membaca seluruh workspace Vercel

  • Aku setuju dengan pernyataan bahwa “aplikasi OAuth harus diperlakukan seperti vendor pihak ketiga, secret platform jangka panjang harus dihapus, dan sistem harus dirancang dengan asumsi provider-side compromise,” tetapi merancang dengan asumsi kompromi di sisi penyedia memang terasa sangat sulit. Karena pada dasarnya kepercayaan adalah titik awal sistem

    • Dari posisi kami yang juga memikirkan aplikasi OAuth untuk SaaS, ini terasa sebagai masalah yang sangat sulit. Aku juga penasaran apakah ada marketplace yang menyelesaikan ini dengan baik. Setelah insiden Salesloft, Cloudflare mengusulkan agar semua lalu lintas OAuth dan API pihak ketiga diproksikan lewat mereka, tetapi itu juga terasa seperti hanya memindahkan vektor ancaman ke tempat lain. Selain praktik dasar seperti minimisasi scope, masa berlaku yang lebih pendek, dan rotasi client secret, rasanya sulit membayangkan apa lagi yang bisa dilakukan. Mungkin allowlist IP asal permintaan per client
    • Melihat kasus seperti ini membuatku merasa bahwa banyak dari zero-trust yang selama ini dibicarakan sebenarnya hanya retorika pemasaran. Kalau benar-benar security by design, asumsi bahwa penyedia tingkat atas bisa dibobol total melalui serangan rantai pasok seharusnya dimasukkan sejak awal

  • Menurutku ke depan insiden seperti ini akan jauh lebih sering muncul. Baik perusahaan besar maupun kecil sudah banyak bereksperimen dengan tool AI, dan sekarang seluruh ekonomi TI sedang menerima utang risiko itu secara terlambat. Jadi aku membacanya bukan sebagai “AI-enabled tradecraft,” melainkan sebagai akibat dari kepemimpinan perusahaan yang menekan pemasangan dan pengujian tool AI di seluruh organisasi demi kecepatan. Serangan seperti ini sendiri terlalu biasa, dan hampir semua perusahaan yang tidak punya allowlist pemasangan AI yang bisa dipaksakan kemungkinan sudah terekspos. Kalau Anda bertanya ke staf TI berapa banyak tool seperti Context yang sudah terpasang di lingkungan lokal dan SaaS, angkanya kemungkinan cukup banyak. Masalahnya, tool semacam ini praktis punya akses ke hampir segalanya, sementara vendor keamanan atau ekosistem RBAC untuk mengendalikan ini kemungkinan baru akan matang 18~24 bulan lagi. Vercel tampak seperti burung kenari di tambang batu bara, dan menurutku tidak mungkin hanya Context yang menjadi sasaran. Ini tampak seperti vektor ancaman yang sudah lama dikenal tetapi diabaikan, di mana jika satu tempat jebol, tempat lain bisa ikut terungkap secara berantai. Enam bulan ke depan bisa sangat berat, dan semua orang mungkin sedang mengaudit pemasangan AI mereka atau seharusnya melakukannya, sementara penyerang juga akan bergerak menggunakan akses yang mereka miliki sebelum diblokir. Sebagai catatan, aku adalah kepala keamanan di industri teknologi

    • Aku juga sudah bertahun-tahun mengatakan bahwa akan banyak insiden keamanan aneh muncul di berita
    • Aku juga melihatnya dengan cara yang sama. Rasanya kita sedang memasuki masa yang cukup menarik

  • Saat melihat ringkasan bahwa “hubungan kepercayaan OAuth meluas menjadi paparan seluruh platform, CEO menyalahkan kecepatan serangan pada AI, dan ada pertanyaan soal jeda dari deteksi sampai pengungkapan,” kegagalan utama yang kulihat terasa sangat khas. Ada akun pengguna dengan hak akses berlebihan, dan mungkin ada akun serupa lainnya. Kemungkinan juga tidak ada 2FA atau ZeroTrust, atau penerapannya sangat terbatas. Menurutku kebersihan keamanan secara keseluruhan juga buruk

    • Ke depan, menyalahkan AI sepertinya akan menjadi alasan serbaguna untuk insiden keamanan, mirip dengan kecenderungan selalu menyalahkan DDoS ketika sebuah situs tumbang

  • Ada satu hal yang sering terlewat. Di Vercel, meski Anda merotasi variabel lingkungan, deploy lama tidak otomatis dinonaktifkan, jadi deploy sebelumnya tetap berjalan dengan kredensial lama sampai dideploy ulang atau dihapus. Jadi meskipun setelah pengumuman key sudah diganti, jika semua deploy belum dinaikkan ulang, nilai yang bocor mungkin masih hidup. Dan menurutku riwayat persetujuan OAuth di Google Workspace juga harus diperiksa. Jika masuk ke Admin Console > Security > API Controls > Third-party app access, besar kemungkinan aplikasi yang disetujui dua tahun lalu untuk demo masih memegang izin penuh ke mail dan Drive

    • Karena alasan ini kami memisahkan beberapa akun Google. Namun banyak organisasi tidak bisa melakukannya karena beban biaya per pengguna di Google Workspace. Aku juga pernah mencoba mendorong agar persetujuan OAuth seperti ini diberikan lewat akun terpisah, bukan akun utama, di tempat kerja lamaku, tetapi gagal
    • Biasanya kalau bicara rotasi kredensial, aku menganggap itu mencakup penonaktifan kredensial lama. Aku hampir tidak pernah mendengar pendekatan yang hanya membuat yang baru sambil membiarkan yang lama tetap aktif
    • Kalimat di laporan itu juga cukup membingungkanku. Fakta bahwa deploy lama memakai env var lama sebenarnya tidak menentukan apakah kredensial tersebut masih valid atau tidak. Ini terasa lebih seperti footgun yang memengaruhi ketersediaan daripada kerahasiaan. Bagian laporan “Environment variable enumeration (Stage 4)” juga terasa aneh. Terutama penjelasan seperti “lihat apakah akses ke environment variable terjadi dari user account alih-alih service account, atau dari akun yang biasanya tidak berinteraksi dengan proyek itu,” membuatku bertanya-tanya apakah orang memang mengambil kredensial dari Vercel env var lalu memakainya di sistem lain
    • Preview deploy terasa lebih parah. Untuk setiap PR bisa muncul satu dengan env var yang sama, dan tidak ada yang membersihkannya. Walau key dirotasi dan prod dideploy ulang, mungkin masih ada ratusan preview zombie yang menyimpan nilai lama
    • Saat melakukan rotasi, tentu variabel lama juga harus kedaluwarsa

  • Sebagian detail dalam laporan ini, khususnya linimasa yang dimulai dari 2024~2025, terasa seperti tidak banyak diberitakan di tempat lain. Misalnya tanggal seperti “akhir 2024~awal 2025 penyerang beralih dari akses OAuth Context.ai ke akun Google Workspace pegawai Vercel” dan “awal~pertengahan 2025 dimulainya akses ke sistem internal Vercel dan enumerasi environment variable pelanggan” membuatku penasaran dari mana asalnya

    • Menurutku tanggal-tanggal seperti itu semuanya dibuat-buat, kemungkinan besar hasil halusinasi