Vercel mengonfirmasi pelanggaran keamanan, peretas mengklaim sedang menjual data yang dicuri

• Vercel secara resmi mengonfirmasi insiden keamanan berupa akses tidak sah ke sistem internalnya, dan saat ini bekerja sama dengan pakar respons insiden serta aparat penegak hukum
• Penyebab pelanggaran adalah aplikasi Google Workspace OAuth milik alat AI pihak ketiga Context.ai yang telah dikompromikan, sehingga akun karyawan Vercel berhasil diambil alih
• Penyerang mencantumkan variabel lingkungan non-sensitif (non-sensitive) untuk memperoleh hak akses tambahan, dan variabel tersebut disimpan dalam keadaan tidak terenkripsi
• Peretas yang mengaku sebagai ShinyHunters mengklaim menjual kunci akses, source code, data database, API key, dan lainnya di forum peretasan, serta menuntut tebusan 2 juta dolar
• Vercel menyatakan telah memverifikasi keamanan proyek open source seperti Next.js dan Turbopack, serta menyarankan pelanggan meninjau variabel lingkungan dan mengaktifkan fitur variabel sensitif

---

Ringkasan insiden keamanan

• Vercel adalah platform infrastruktur cloud hosting dan deployment yang berfokus pada framework JavaScript, pengembang Next.js, sekaligus penyedia layanan serverless function, edge computing, dan pipeline CI/CD
• Melalui pemberitahuan keamanan, perusahaan secara resmi mengonfirmasi terjadinya akses tidak sah (unauthorized access) ke sistem internal
• Diumumkan bahwa hanya sebagian kecil pelanggan (limited subset) yang terdampak, dan layanan itu sendiri tidak terpengaruh
• Perusahaan telah merekrut pakar respons insiden dan memberi tahu aparat penegak hukum, sambil melanjutkan investigasi

Jalur pelanggaran dan detail teknis

• Akar penyebab pelanggaran adalah kompromi pada aplikasi Google Workspace OAuth milik platform AI pihak ketiga Context.ai
• CEO Vercel Guillermo Rauch membagikan detail tambahan di X (sebelumnya Twitter)
  • Penyerang mengambil alih akun Google Workspace milik karyawan Vercel melalui pelanggaran di Context.ai
  • Setelah itu, dari akun tersebut penyerang meningkatkan hak akses (escalate) ke lingkungan Vercel
• Penyerang mengakses variabel lingkungan yang ditandai sebagai "non-sensitive", dan variabel ini disimpan dalam keadaan tidak terenkripsi saat disimpan (not encrypted at rest)
• Vercel menyatakan semua variabel lingkungan pelanggan disimpan dengan enkripsi penuh saat disimpan (fully encrypted at rest) dan dilindungi mekanisme pertahanan berlapis, tetapi variabel yang ditandai "non-sensitive" menjadi titik lemah
• Administrator Google Workspace disarankan memeriksa aplikasi OAuth berikut:
  • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Klaim penjualan data oleh peretas

• Pelaku ancaman yang mengaku sebagai ShinyHunters membuat posting di forum peretasan tentang pelanggaran Vercel dan penjualan data
  • Yang dijual: kunci akses, source code, data database, hak akses deployment internal, API key (termasuk token NPM dan token GitHub)
  • Mereka menampilkan data Linear sebagai bukti dan mengklaim memiliki akses ke banyak akun karyawan
• Pelaku ancaman lama yang pernah dikaitkan dengan kelompok ShinyHunters membantah kepada BleepingComputer bahwa mereka tidak terkait dengan insiden ini
• File teks yang dibagikan penyerang berisi 580 data informasi karyawan Vercel, terdiri dari nama, alamat email Vercel, status akun, dan stempel waktu aktivitas
• Turut dibagikan pula screenshot yang tampak menunjukkan dashboard internal Vercel Enterprise
• BleepingComputer menyatakan tidak dapat memverifikasi secara independen keaslian data dan screenshot tersebut
• Dalam pesan Telegram, pelaku ancaman mengklaim sedang berhubungan dengan Vercel dan menuntut tebusan (ransom) 2 juta dolar

Respons Vercel dan rekomendasi bagi pelanggan

• Dipastikan bahwa Next.js, Turbopack, dan proyek open source lainnya tetap aman
• Perusahaan telah meluncurkan halaman ringkasan variabel lingkungan di dashboard serta antarmuka yang ditingkatkan untuk mengelola variabel lingkungan sensitif
• Tindakan yang direkomendasikan kepada pelanggan:
  • Meninjau variabel lingkungan (environment variables)
  • Mengaktifkan fitur variabel lingkungan sensitif (sensitive environment variable feature) untuk memastikan enkripsi saat tidak digunakan
  • Melakukan rotasi secret (secret rotation) bila diperlukan

[GN⁺]

Komentar Hacker News

• Pengumumannya baru saja diperbarui, dan yang tampak penting adalah penjelasan bahwa pelanggaran ini bermula dari kompromi pada aplikasi Google Workspace OAuth milik alat AI pihak ketiga
  IOC untuk membantu investigasi juga sudah dipublikasikan, dan pesannya adalah bila Anda seorang admin, segera periksa apakah aplikasi ini digunakan
  OAuth App tersebut adalah 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, dan teks aslinya bisa dilihat di pengumuman keamanan Vercel

  • Jika melihat penjelasan Guillermo Rauch, tampaknya titik awalnya adalah pelanggaran di sisi akun pelanggan Context.ai yang digunakan karyawan Vercel, lalu setelah itu akses ke akun Google Workspace dan lingkungan Vercel juga ikut didapat secara berantai
    Penjelasan bahwa akses tambahan dimungkinkan melalui enumerasi variabel lingkungan non-sensitive terasa sangat menonjol, dan juga muncul dugaan bahwa pelakunya adalah kelompok canggih yang sangat dipercepat oleh AI
    Meski begitu, fakta bahwa masih belum ada pemberitahuan email ke pengguna terasa cukup mengkhawatirkan
  • Rasanya akan lebih baik kalau mereka tidak hanya menyebut OAuth client ID, tetapi juga mengungkap nama aplikasinya
    Saya paham kalau mereka mungkin enggan langsung menunjuk pihak tertentu, tetapi menyembunyikan nama layanannya justru terasa hanya memperlambat respons
  • Bagaimanapun pada akhirnya akan terungkap juga, jadi saya benar-benar tidak paham kenapa mereka tidak menyebut langsung aplikasi yang bertanggung jawab
  • Sepertinya aplikasi itu sudah dihapus
  • Kejadian ini terasa seperti akibat alami dari arah perkembangan web selama 10 tahun terakhir
    Sekarang, alih-alih membangun di atas fondasi yang stabil, merangkai berbagai kombinasi pihak ketiga sudah menjadi hal yang terlalu lumrah, dan sebanyak itu pula titik kegagalannya
    Pada akhirnya ini kembali menunjukkan bahwa keamanan hanya sekuat mata rantai terlemahnya, dan menurut saya jelas ada risiko ketika bisnis ditumpangkan di atas alat AI yang terasa seperti vibe-coded
    Ini membuat saya bertanya pada diri sendiri apakah arah ini memang harus terus didorong, dan seberapa kompleks lagi semuanya harus menjadi sebelum orang mulai meninjau ulang

• Jika melihat analisis stack rekomendasi Claude Code, saya merasa Claude Code secara default mendorong penyedia dan framework tertentu sehingga web menjadi semakin seragam
  Kurangnya keberagaman seperti ini pada akhirnya terasa memperbesar radius dampak saat insiden terjadi

  • Jika melihat proyek-proyek vibe-coded berusaha minim yang sering muncul di reddit, sangat sering mereka berjalan di atas Vercel
    Kesan saya, ini sudah mengeras menjadi pilihan default
  • Beberapa hari lalu saya memaksa Claude Code membuat aplikasi CRUD React baru, dan default-nya langsung menumpahkan banyak dependensi Node JS dan NPM
    Jadi saya minta agar dibuat tanpa Node, dan ia langsung menulis ulang dengan backend Python, sekaligus menjelaskan sendiri bahwa ia mengubah arahnya untuk mengurangi dependensi
    Sebagai catatan, ini cuma eksperimen untuk hasil yang memang akan dibuang, bukan untuk merekomendasikan vibe coding
  • Poin yang bagus, tetapi saya tidak merasa inti masalahnya adalah Claude itu sendiri
    Pada akhirnya ini soal cara penggunaan, dan saya rasa pengembang perlu dibimbing lebih baik agar tidak membiarkan Claude yang mengambil keputusan
    Saran boleh diterima, tetapi pada akhirnya manusia tetap harus meninjaunya secara kritis, dan dalam hal itu rasanya tidak jauh berbeda dari berkolaborasi dengan rekan tim lain
  • Pikiran bahwa AI membuat konvergensi menuju rata-rata berlangsung jauh lebih cepat terus terngiang di kepala saya
    Internet memang sejak awal punya kecenderungan seperti itu, tetapi kali ini terasa sedikit berbeda nuansanya
  • Saya tidak sepenuhnya menentang menjadikan agen sebagai kambing hitam, tetapi menurut saya masalah seperti ini sebenarnya adalah pola yang selalu terlihat di antara manusia juga

• Sebagai orang yang dulu pernah berada di tim respons insiden keamanan, saya bisa memahami betapa beratnya kerja tim respons kali ini
  Tetap saja, pengumuman pertamanya benar-benar terlihat seperti komunikasi yang buruk
  Mereka tidak menjelaskan apa yang sebenarnya terjadi, hanya memakai ungkapan bahwa ini cukup serius sampai harus diberitahukan ke penegak hukum, sementara panduan tindakan untuk pelanggan hanya sebatas "tinjau variabel lingkungan"
  Namun dari sudut pandang pelanggan, itu terlalu tidak jelas untuk ditindaklanjuti. Apakah maksudnya memeriksa apakah nilainya masih ada, atau bagaimana cara menilai apakah itu sudah bocor, sama sekali tidak jelas
  Menurut saya, mereka seharusnya langsung mengatakan agar semua kata sandi, access token, dan data sensitif yang dipercayakan ke Vercel segera dirotasi seluruhnya, lalu mengarahkan pelanggan untuk mengaudit log akses dan anomali pada data pelanggan
  Salah satu alasan membayar hosting mahal pada akhirnya adalah harapan bahwa keamanan dan keandalan akan dikelola secara profesional, tetapi sekarang ini, bahkan dengan mempertimbangkan ketidakpastian di fase awal, semuanya terlihat terlalu sengaja dibuat samar

  • Saat melihat halaman insidennya, tertulis bahwa variabel lingkungan yang ditandai sensitive di Vercel disimpan sedemikian rupa sehingga tidak bisa dibaca, dan sejauh ini tidak ada bukti akses terhadapnya
    Namun, bila nilai rahasia seperti API key, token, kredensial DB, atau signing key tidak ditandai sebagai sensitive, maka itu harus dianggap berpotensi terekspos dan diprioritaskan untuk diganti
    Sumbernya adalah incident page, dan saat saya melihatnya itu pukul 4:22 sore waktu Timur
  • Jujur saya tidak paham kenapa saya justru membaca ini di sini lebih dulu
    Saya sudah jadi pelanggan berbayar lebih dari setahun, tetapi alih-alih email perusahaan, justru news aggregator yang memberi tahu lebih dulu, dan itu terasa absurd
  • Tahun lalu juga pernah ada kejadian Vercel menangani dengan buruk respons terhadap kerentanan Next middleware, jadi kali ini pun tidak terasa sepenuhnya baru
    Konteks terkait bisa dilihat di thread HN dan reaksi saat itu
  • Keamanan memang sangat sulit, dan saya merasa hanya mempercayai tiga vendor: AWS, Google, dan IBM
    Selain itu, kebanyakan terasa seperti pilihan yang mengundang masalah sendiri
  • Alasan membayar mahal memang termasuk ekspektasi soal keamanan dan keandalan, tetapi kemudahan deploy instan dengan beberapa klik juga sangat besar nilainya
    Namun saya sekarang memutuskan untuk tidak lagi bergantung pada kenyamanan itu, dan sudah memindahkan semuanya dari Render ke linode
    Dulu saya membayar lebih dari 50 dolar per bulan ke Render, sekarang hanya sekitar 3~5 dolar, jadi ke depan saya hampir tidak berniat lagi memakai penyedia hosting seperti itu

• Saat membaca kalimat "Vercel tidak mengungkap sistem mana yang ditembus", saya merasa bahkan tanpa menjadi pakar keamanan pun ini adalah sikap yang cukup sulit diterima
  Itu juga memberi kesan bahwa mereka lebih fokus membela diri sendiri daripada membantu pelanggan memahami dampaknya

  • Di sisi lain, saya juga berpikir bahwa menyebut nama sistem dengan lebih spesifik belum tentu lebih berguna
    Misalnya, kalau mereka bilang sub-sistem X yang kurang dikenal di GitHub yang ditembus, itu mungkin tidak benar-benar membantu lebih banyak dibanding informasi yang sudah ada bahwa "sebagian lingkungan pelanggan telah dikompromikan"

• Setelah melihat lagi bahwa IOC telah ditambahkan ke pengumuman, jelas bahwa fakta bahwa insiden ini bermula dari kompromi aplikasi Google Workspace OAuth adalah informasi penting bagi seluruh komunitas
  Saya merasa admin dan pemilik akun harus segera memeriksa pengenal aplikasi tersebut, dan rinciannya ada di pengumuman Vercel

  • Saya benar-benar penasaran alat apa sebenarnya aplikasi OAuth itu

• Saya memakai MacBook Pro dan Chrome 147.0.7727.56, dan begitu menekan logo Vercel di kiri atas halaman, aplikasi Chrome langsung crash seketika
  Rasanya seperti bug yang cukup menarik

  • Saya memakai Arch Linux, dan di Chrome 147.0.7727.101 crash yang sama bisa direproduksi, sementara di Firefox 149.0.2 maupun Chromium 147.0.7727.101 tidak terjadi
    Agak lucu bahwa semua orang sekarang sedang membaca kabar bahwa Vercel tampaknya mengalami sesuatu seperti pelanggaran, lalu sekalian mencoba mereproduksi crash pada halaman webnya
    Tentu saja, rasanya mustahil permainan reproduksi massal seperti ini tidak akan berbalik merugikan
  • Sayangnya, di Chrome 147.0.7727.101 pada Windows 11 Pro saya tidak berhasil mereproduksi crash itu
    Saya bahkan merekam videonya, dan sempat mengira uBlock Origin Lite penyebabnya, tetapi setelah dimatikan pun tetap tidak crash
    Kalau bisa direproduksi mungkin akan sedikit menarik
  • Ini mengingatkan saya pada bug Chromium sekitar 2021 ketika membuka menu dropdown GitHub di Linux bisa membuat seluruh sistem mati
    Itu sempat berlangsung beberapa waktu lalu akhirnya diperbaiki
  • Saya juga melihat gejala yang sama di Chrome pada Windows 11
    Tetapi setelah sekali membuka beranda Vercel langsung lewat URL, menekan logo itu tidak lagi menyebabkan crash
  • Lingkungan saya MBP M4 Max dan Chrome 146.0.7680.178, dan tidak ada crash
    Sebagai gantinya, sekarang saya jadi agak enggan menekan tombol Finish update

• Untuk informasi terkait, saya sedang melihat thread HN lainnya bersama beberapa postingan di X
  Di komentar awal Theo, ia mengatakan ini tampak kredibel, dan di postingan lanjutan ia mengatakan env var yang ditandai sensitive aman sementara nilai yang tidak ditandai sebaiknya diganti sebagai tindakan pencegahan
  Lalu di postingan lain ia mengatakan jenis peretasan seperti ini bisa terjadi pada host mana pun, dan di komentar lain lagi disebutkan kemungkinan kaitan dengan ShinyHunters

  • Jika nilai yang tidak ditandai sensitive memang benar-benar tidak sensitif, saya rasa tidak ada alasan untuk menggantinya
    Kalau ada nilai yang memang wajib diganti, bukankah itu berarti sejak awal nilainya memang sensitif dan seharusnya sudah ditandai sebagai sensitive?
  • Saya penasaran, siapa sebenarnya Theo ini sampai banyak orang terus mengutipnya
    Pada titik ini, isinya juga tidak terlihat sangat substansial

• Kejadian seperti ini kembali mengingatkan betapa ekosistem web modern terpusat pada single point of failure
  Pengungkapan sejauh ini terasa relatif transparan, tetapi profil risiko dari keputusan untuk sepenuhnya bergantung pada PaaS yang dikelola penuh jadi perlu dihitung ulang

• Ungkapan "sebagian pelanggan yang terbatas" secara teknis bisa saja tetap berlaku bahkan kalau angkanya 99%, jadi terdengar seperti ungkapan yang cukup ambigu

• Saya juga curiga jangan-jangan kenyataannya banyak pelanggan terdampak, tetapi yang disebut sebagai subset hanyalah pelanggan besar yang keberangkatannya akan jadi masalah

  • Ini memang hanya spekulasi, tetapi saya merasa jarang sekali ungkapan "limited subset" ternyata merupakan kabar baik
    Biasanya kalau benar-benar ingin menenangkan orang, mereka akan menyebut angka konkret seperti "kurang dari 1% pengguna", tetapi kali ini tidak begitu
    Jadi saya menduga visibilitas mereka masih kurang, atau angkanya memang tidak menyenangkan
    Meski begitu, saya tetap bisa memahami betapa berat kerja tim responsnya, dan berharap ke depan mereka bisa berkomunikasi dengan lebih terbuka dan transparan

[click]

Di sini juga terlihat karakter Hindi. Belakangan ini, terlepas dari openai, claude, atau google, cukup sering terjadi output berbahasa Korea bercampur Hindi. Apakah pelabelan dataset bahasa Korea dikerjakan oleh orang India?
Saya dulu kurang suka model Tiongkok karena respons bahasa Koreanya bercampur bahasa Mandarin, tetapi belakangan model frontier malah terus mencampurkan Hindi, jadi rasa penolakan saya terhadap model Tiongkok justru berkurang.

[slowandsnow]

Saat memakai Claude, bahasa Jepang sering muncul. Kemarin juga begitu.